Pergunta

Considere uma frase como:

John Smith viajou para Washington.

Um etiquetador identificaria, num dia bom, 'John Smith' como uma pessoa e 'Washington' como um lugar.No entanto, sem outras provas, não é possível dizer qual de todos os possíveis 'John Smith's no mundo, ou mesmo qual dos vários 'Washington's, tem.

Eventualmente, algum processo de resolução poderá decidir, com base em outras evidências.Até esse ponto, porém, qual é uma boa prática para representar essas referências em RDF?Atribuir a eles identificadores exclusivos inventados em algum namespace?Faça tuplas em branco (por exemplo'Alguma pessoa chamada John Smith foi referenciada no Documento d'.)?Alguma outra alternativa?Um livro que tenho dá um exemplo envolvendo estações meteorológicas anônimas, mas não estou entendendo bem como o exemplo deles se encaixa em tudo o mais que está sendo descrito sobre RDF.

Foi útil?

Solução

Atribua-lhes identificadores exclusivos em seu próprio namespace.Se você mais tarde descobrir que este "Washington" é o mesmo que http://dbpedia.org/resource/Washington,_d.c ., Ou seja o que for, você pode adicionar uma coruja: Saméas para afirmar isso.

Outras dicas

em primeiro lugar, existem bons serviços que você pode usar para reconhecimento de entidades, como OpenCalais, Zemanta e Alquimia.

Para ser mais específico, sim, simplesmente 'cunha' seus próprios URIs (identificadores) para cada coisa e depois fale sobre eles - para oferecer uma representação para essas informações em tartaruga

@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 você combiná-los mais tarde, poderá usar owl:sameAs mencionado por Glenn McDonald.

Pode ser relevante para você ler como o Apache Stanbol faz isso: http://stanbol.apache.org/docs/trunk/components/enhancer/enhancesentstructure.html

Você pode criar seu próprio URI conforme discutido acima ou usar um nó em branco.Existem prós e contras para ambas as abordagens:

Os URIs possuem uma identidade externa, portanto você pode referir-se explicitamente ao seu conceito em consultas futuras, o que pode tornar algumas consultas muito mais simples;mas, você tem uma identidade externa, então o algoritmo que você usa para construir os URIs se torna uma parte crítica da sua infraestrutura e você tem que garantir que eles sejam estáveis ​​e únicos.Isso pode ser trivial no início, mas quando você começa a lidar com vários documentos sendo reprocessados ​​em momentos diferentes, muitas vezes em paralelo, e em sistemas distribuídos, rapidamente deixa de ser simples.

Os nós em branco foram incluídos especificamente para resolver este problema, sua singularidade é garantida pelo seu escopo;mas, se você precisar se referir explicitamente a um nó em branco em uma consulta, precisará usar uma extensão não padrão ou encontrar alguma maneira de caracterizar o nó.

Em ambos os casos, mas especialmente se você usar um nó em branco, deverá incluir declarações de proveniência para caracterizá-lo de qualquer maneira.

O exemplo de @nathan é bom para se ter uma ideia.

Portanto, um exemplo usando nós em branco pode ser:

@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 .

Observe o uso de identificadores de texto/fragmento simples rfc5147 para identificar exclusivamente o arquivo que está sendo processado, isso fornece flexibilidade sobre como você deseja identificar execuções individuais.A alternativa é capturar tudo isso no URI da raiz do documento ou abandonar completamente a proveniência.

@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 .

Você notará que foaf:name possui um intervalo de owl:Thing, portanto pode ser aplicado a qualquer coisa.Uma alternativa pode usar skos:Concept e rdfs:label para os nomes próprios.

Uma consideração final para nó em branco vs.URI é que qualquer armazenamento de dados que você usar terá que armazenar qualquer URI que você usar, e isso pode ter implicações em relação ao desempenho se você estiver usando conjuntos de dados muito grandes.

Em última análise, se eu fosse publicar as informações de proveniência no gráfico junto com as entidades unificadas finais, estaria inclinado a usar nós em branco e alocar URIs para os conceitos com os quais unifico as entidades.

Se, no entanto, eu não for rastrear a origem das inferências, e esta for apenas uma passagem de muitas em um pipeline que acabará descartando os resultados intermediários, eu apenas cunharia URIs usando algum tipo de hash de documento, carimbo de data/hora e id e acabar com isso.

@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 .
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top