RDF Rappresentazione dei riferimenti di entità nel testo

Question

Considera una frase come:

.

John Smith ha viaggiato a Washington.

Un tagger del nome identificherebbe, in una buona giornata, "John Smith" come persona e "Washington" come luogo.Tuttavia, senza altre prove, non può dire quale di tutto il possibile "John Smith è nel mondo, o anche quale dei vari" Washington's, è ottenuto.

Alla fine, un processo di risoluzione potrebbe decidere, in base ad altre prove.Fino a quel punto, tuttavia, qual è una buona pratica per rappresentare questi riferimenti in RDF?Assegnale i identificatori univoci inventati in alcuni rifiuti dei nomi?Fai tuple vuote (ad esempio "Qualche persona di nome John Smith è stata referenziata nel documento D '.)?Qualche altra alternativa?Un libro che ho dato un esempio che coinvolge stazioni meteorologiche anonime, ma non sto seguendo come il loro esempio si inserisce con tutto il resto su RDF descritto.

Answer 1

Assegna loro identificatori univoci nel proprio spazio dei nomi.Se in seguito scopri che questo "Washington" è lo stesso di http://dbpedia.org/resource/Washington ,_d.c ., O qualsiasi altra cosa, puoi aggiungere un gufo: Sameas per affermarlo.

Answer 2

Prima di tutto, ci sono buoni servizi esistenti che puoi utilizzare per il riconoscimento dell'entità come OpenCalais , Zemanta e Alchimia .

Per essere più specifico però, sì semplicemente 'menta' i tuoi tuoi uris (identificatori) per ogni cosa, poi parlando di loro - per offrire una rappresentazione per queste informazioni a Turtle

@prefix : <http://yourdomain.com/data/> .
@prefix myont: <http://yourdomain.com/ontology/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix dbpedia-owl: <http://dbpedia.org/ontology/Place>.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:John_Smith#d rdf:type foaf:Person ;
  foaf:name "John Smith"@en .

:Washington#d rdf:type dbpedia-owl:Place ;
  rdfs:label "Washington"@en .

:John_Smith#d myont:travelled_to :Washington#d .

<http://yourdomain.com/some-doc#this> rdf:type foaf:Document ;
  dcterms:references :John_Smith#d, :Washington#d .

.

E se in seguito si abbinano, puoi usare il gufo: Sameas poiché Glenn McDonald menziona.

Answer 3

potrebbe essere rilevante per te da leggere come lo fa Apache Stanbol: http://stanbol.apache.org/docs/trunk/components/enhancer/enhancementstructure.html

Answer 4

È possibile menta il tuo URI come discusso sopra o utilizzare un nodo vuoto. Ci sono pro e contro per entrambi gli approcci:

URI ha un'identità esterna, quindi è possibile fare riferimento esplicitamente al tuo concetto in query future che possono rendere alcune query molto più semplici; Ma, hai un'identità esterna, quindi l'algoritmo che usi per costruire gli URI diventa una parte critica della tua infrastruttura e devi garantire che siano sia stabili che unici. Questo può essere all'inizio banale, ma quando inizi a occuparti di più documenti che vengono rielaborati a tempi diversi, spesso in parallelo, e sui sistemi distribuiti, smettono abbastanza rapidamente di essere diretto.

I nodi in bianco sono stati inclusi specificamente per risolvere questo problema, la loro unicità è garantita dal loro ambito; Ma se necessario fare riferimento a un nodo vuoto in una query esplicitamente dovrai utilizzare un'estensione non standard o trovare un modo per caratterizzare il nodo.

In entrambi i casi, ma soprattutto dovresti usare un nodo vuoto, è necessario includere le dichiarazioni di provenienza per caratterizzarlo comunque.

@ Esempio di Nathan è buono per ottenere l'idea.

Quindi un esempio usando i nodi vuoti potrebbe essere:

@prefix my: <http://yourdomain.com/2010/07/20/conceptmap#> .
@prefix proc: <http://yourdomain.com/2010/07/20/processing#> .
@prefix prg: <http://yourdomain.com/processors#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.example.org/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix doc: <http://yourdomain.com/doc-path/> .

_:1 rdf:type proc:ProcessRun ; 
    proc:parser prg:tagger ;
    proc:version "1.0.2" ;
    proc:time "2010-07-03 20:35:45"^^<xsd:Timestamp> ;
    proc:host prg:hostname-of-processing-node ;
    proc:file doc:some-doc#line=1,;md5=md5_sum_goes_here,mime-charset_goes_here ;

_:2 rdf:type foaf:Person ;
    foaf:name "John Smith"@en ;
    proc:identifiedBy _:1 ;
    proc:atLocation doc:some-doc#char=0,9 .


_:3 rdf:type owl:Thing ;
    foaf:name "Washington"@en ;
    proc:identifiedBy _:1 ;
    proc:atLocation doc:some-doc#char=24,33 .

<http://yourdomain.com/some-doc#this> rdf:type foaf:Document ;
                                      dcterms:references _:2, _:3 .

.

Nota L'utilizzo di RFC5147 Identificatori di frammenti di testo / frammenti in chiaro per identificare in modo univoco il file elaborato, questo fornisce flessibilità su come si desidera identificare le singole corse. L'alternativa è quella di catturare tutto questo nell'URI per la radice del documento, o per abbandonare del tutto la provenienza.

@prefix : <http://yourdomain.com/ProcessRun/parser=tagger/version=1.0.2/time=2010-07-03+20:35:45/host=hostname-of-processing-node/file=http%3A%2F%2Fyourdomain.com%2Fdoc-path%2Fsome-doc%23line%3D1%2C%3Bmd5%3Dmd5_sum_goes_here%2Cmime-charset_goes_here/$gt; .

@prefix my: <http://yourdomain.com/2010/07/20/conceptmap#> .
@prefix proc: <http://yourdomain.com/2010/07/20/processing#> .
@prefix prg: <http://yourdomain.com/processors#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.example.org/> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix doc: <http://yourdomain.com/doc-path/some-doc#> .

:1 rdf:type proc:ProcessRun ; 
    proc:parser prg:tagger ;
    proc:version "1.0.2" ;
    proc:time "2010-07-03 20:35:45"^^<xsd:Timestamp> ;
    proc:host prg:hostname-of-processing-node ;
    proc:file doc:some-doc#line=1,;md5=md5_sum_goes_here,mime-charset_goes_here ;

:2 rdf:type foaf:Person ;
    foaf:name "John Smith"@en ;
    proc:identifiedBy :1 ;
    proc:atLocation doc:some-doc#char=0,9 .


:3 rdf:type owl:Thing ;
    foaf:name "Washington"@en ;
    proc:identifiedBy :1 ;
    proc:atLocation doc:some-doc#char=24,33 .

<http://yourdomain.com/some-doc#this> rdf:type foaf:Document ;
                                      dcterms:references :2, :3 .

.

Si noterà che foof: il nome ha una gamma di gufo: cosa, quindi può essere applicata a qualsiasi cosa. Un'alternativa potrebbe usare SKOS: concetto e RDFS: etichetta per i nomi corretti.

Un'ultima considerazione per il nodo vuoto vs. Uri è che qualsiasi datastore che usi sarà alla fine sarà necessario memorizzare qualsiasi URI che usi, e questo può avere implicazioni relative alle prestazioni se si utilizzano set di dati molto grandi.

In definitiva, se avessi intenzione di pubblicare le informazioni di provenienza nel grafico insieme alle entità finali unificate, sarei inclinato ad andare con nodi in bianco e assegnare Uri ai concetti che alla fine unificano le entità con.

Se comunque non sto rintracciando la provenienza delle inferenze, e questo è solo un passaggio di molti in una pipeline che alla fine scartarà i risultati intermedi, vorrei solo menta Uris utilizzando una sorta di documento hash, timestamp e id e essere fatto con esso.

@prefix : <http://yourdomain.com/entities#> .
@prefix my: <http://yourdomain.com/2010/07/20/conceptmap#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

:filename_timestamp_1 rdf:type foaf:Person ;
                      foaf:name "John Smith"@en .

:filename_timestamp_2 rdf:type owl:Thing ;
    foaf:name "Washington"@en .

<http://yourdomain.com/some-doc#this> rdf:type foaf:Document ;
                                      dcterms:references :2, :3 .

.