W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2004

Re: RDF graph merging question

From: Graham Klyne <gk@ninebynine.org>
Date: Wed, 18 Aug 2004 13:26:24 +0100
Message-Id: <>
To: algermissen@acm.org
Cc: "www-rdf-interest@w3.org" <www-rdf-interest@w3.org>


Hmmm... I notice that Damian has addressed your question at the modelling 
level, and what he writes looks OK to me ... basically, what you have 
appears  not to be a job for reification.

In my continuing response below, I'll offer another reason why reification 
isn't the right tool for this kind of application.  In view of Damian's 
response, this may all be rather academic.

The topic of separation of reifications of a statement was discussed at 
some length by the RDFcore working group when it was realized that there 
were different possible uses for the reification vocabulary, with different 
semantic treatment.  It was not possible for the same semantics to be 
usable for the different use-cases.  The conflict was sometimes called 
"statings vs statements" in these discussions.

In the end, after consultation with developers and users of RDF, the WG 
came to a view that the most widely used use-case was related to provenance 
(e.g. the statement X was made in document Y by publisher Z).  Statements 
meaning the same thing may be made independently in different publications, 
and sometimes that's important.  E.g. "Fred says 'X is great value' and I 
trust him, but I don't trust Harry when he says 'X is great value'".  There 
are two distinct statements referred to here, though what they say is the same.

So I suspect that you ae trying to use the reification vocabulary in a way 
that is contrary to its defined semantics (weak as they are).

IIRC, the section from the RDF semantics that I quoted previously was a 
result of this debate.


At 20:41 17/08/04 +0200, Jan Algermissen wrote:
>Graham, Thomas,
>thanks for the quick reply. Your clarifications are helping a lot.
>Comments below.
>Graham Klyne wrote:
> > >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?
> >
> > Er, no.  See section 3.3.1 of the RDF semantics specification, particulatly
> > the final couple of paragraphs:
> > -- http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#Reif
> >
> > Which effectively says that separate nodes must be maintained for each
> > reification that appears.
>Just to confirm: this means, that gathering separate nodes that actually
>represent the same 'thing' remains the burdon of the user of RDF (e.g.
>at the query-formulation-level), right?
>Example: Suppose two computers are connected and we represent this as
>   foo:host1 bar:connectedTo foo:host2
>Now, in RDF graph A the triple is reified to attach the information
>   foo:conn-host1-host2 baz:connectionType foo:ethernet to it
>(the connection is an ethernet connection)
>Now in some strore B, the same triple exists and is reified to attach
>a cable number:
>   foo:connection-123 baz:cableNumber "XY-T-5665"
>An RDF store (at least one that does not provide some non-standard
>extension) cannot by itself provide me with the information that
>the connection is of type ethernet and has cable number "XY-T-5665",
>It would be the burdon of the one formulating the query to traverse all
>the rdf:subject, rdf:predicate and rdf:object arcs to find the two
>seperate nodes for what is actually a single 'thing'.
>Is that true? Or am I approaching this in a completely wrong way?
> > ... so there's no conflict to resolve.
>Yes, appearently not ;-)
>In case it seemed so: my intention was not to point out a conflict, but
>I am evaluating several data models for their suitability for data integration
>and the issues above are my primary interest.
>Thanks again.
>Jan Algermissen                           http://www.topicmapping.com
>Consultant & Programmer                   http://www.gooseworks.org

Graham Klyne
For email:
Received on Thursday, 19 August 2004 07:26:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:52 UTC