Re: RDF graph merging question

Jan Algermissen wrote:

> I have a question regarding the merging of RDF graphs, that contain
> reified statements.
> 
> I am using the example[1] from the RDF Primer.
> 
> Suppose I have RDF graph A containing the following set of triples:
> 
> exproducts:triple12345   rdf:type        rdf:Statement .
> exproducts:triple12345   rdf:subject     exproducts:item10245 .
> exproducts:triple12345   rdf:predicate   exterms:weight . 
> exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .
> 
> Now, assume I also have a graph B, containing the following set:
> 
> foo:bar   rdf:type        rdf:Statement .
> foo:bar   rdf:subject     exproducts:item10245 .
> foo:bar   rdf:predicate   exterms:weight . 
> foo:bar   rdf:object      "2.4"^^xsd:decimal .
> 
> In my understanding the semantics of rdf:subject, rdf:predicate and
> rdf:property allow to conclude that the two reified statements are the
> same statement and should be represented as a single node in the
> resulting merged RDF graph.
> 
> Correct?
> 

The existence of a reified statement does not imply the existence of any 
specific instantiated triple (in RDF semantics).  If you cannot 
associate the reified Statement with an actual instantiated triple, I 
don't see how you can infer that two of them represent the same 
statement.  Also, a statement is not represented "as a single node". 
It's two nodes connected by an edge.

> But then, since the statements have been assigned different URIs (by
> the different authors of the two graphs) it is not possible to
> actually perform the merge, since RDF graphs only allow a single URI
> per node.
> 
> Correct?
> 

There is nothing that prevents the existence of two nodes with different 
identifiers that actually identify the same individual.  In fact, in OWL 
there is the property sameIndividualAs to let you specifically say that 
two nodes do in fact refer to the same individual.

> 
> Now, assume the assigned URIs mactch, but the objects are different:
> 
> exproducts:triple12345   rdf:type        rdf:Statement .
> exproducts:triple12345   rdf:subject     exproducts:item10245 .
> exproducts:triple12345   rdf:predicate   exterms:weight . 
> exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .
> 
> and
> 
> exproducts:triple12345   rdf:type        rdf:Statement .
> exproducts:triple12345   rdf:subject     exproducts:item10245 .
> exproducts:triple12345   rdf:predicate   exterms:weight . 
> exproducts:triple12345   rdf:object      "117.89"^^xsd:decimal .
> 
> Now the assigned URI demands the merge, but the semantics of rdf:subject,
> rdf:predicate and rdf:property tell us, that there are really two different
> statements.
> 

Not at all.  Assuming that there were actual triples having the same 
content as these reified statements, they would just indicate that the 
weight predicate can have multiple values.  Think that can't happen? 
It's not uncommon.  Think of a predicate for the name of one's child. 
If you have more than one child, you can have more than one such 
statement, each with a different value for the object (name of a child).

> What happens during the merge?

Still assuming these were actual triples, it's a non-issue unless you 
happen to know that the predicate in question can only have a single 
value.  Then you have a contradiction.  You need to work out how to 
handle them.

> Note that the underlying issue is, if the combination of rdf:subject,
> rdf:predicate and rdf:property is identity-providing and if so, how
> this means of identity-providing relates to the URI-means of providing
> identity. Is one stronger than the other? Etc...
> 

It's only identity-providing if the property is an 
"InverseFunctionalProperty".  That's why threads on IFPs keep popping 
up, they're important in many applications.

As an illustration, consider a "haircolor" property.  The haircolor 
brown does not identify any specific individual except in rare and 
restricted contexts.  In fact, most predicates are not IFPs.  A close 
analogy would be primary keys and candidate keys in a relational 
database.  Most columns are not primary or candidate keys - i.e., they 
are not identifying properties.

> I would really apprechiate if someone could shed some light on these
> issues, thanks a lot in advance.

And you thought that Topic Maps semantics were confusing!

Cheers,

Tom P
-- 
Thomas B. Passin
Explorer's Guide to the Semantic Web (Manning Books)
http://www.manning.com/catalog/view.php?book=passin

Received on Tuesday, 17 August 2004 13:38:14 UTC