RE: RDF Terminologicus

Graham,

> >"reified statement" seems to be common parlance.
> 
> But do we all mean the same thing by it?  ;-)

No, but it'll be used irregardless of what it means, so one might as well
monopolise the meaning :)


> >  It could be kept and
> >instead outlined explicitly that a statement has an infinite 
> number of
> >"reified statements" that refer to it, as opposed to more 
> than one. That has
> >implications for aggregators. In one sense using four 
> statements to reify a
> >statement is useful in that they can be aggregated/merged 
> based on the
> >pattern held within the four rather than the nominal 
> reifying resource
> >inside those four statements. That resource can be treated 
> in most cases as
> >a search wildcard or a prolog underscore operator.
> 
> Nothing in any of these definitions should, per se, limit what an 
> implementer can do within the accepted framework of RDF.

Of course, but there's a big (some would say very big) difference betwen
"more than one" and "infinite".


> As for aggregating:  I think different reifications may refer 
> to the same 
> statement but still be distinct reifications.  One 
> reification may be used 
> to say something about one stating, and another to say 
> something different 
> about that statement. E.g.
> 
>     [s1] --rdf:type------> [rdf:Statement]
>     [  ] --rdf:property--> [p]
>     [  ] --rdf:subject---> [s]
>     [  ] --rdf:object----> [o]
>     [  ] --atTime--------> "Yesterday"
>     [  ] --truth---------> "True"
> 
> and
> 
>     [s2] --rdf:type------> [rdf:Statement]
>     [  ] --rdf:property--> [p]
>     [  ] --rdf:subject---> [s]
>     [  ] --rdf:object----> [o]
>     [  ] --atTime--------> "Today"
>     [  ] --truth---------> "False"
>
> I.e. a given statement that was true yesterday is not true 
> today.  In each 
> case it is the same statement being described, but the different 
> reifications cannot be aggregated without creating a conflict 
> of meaning.
> 
> Maybe this is what you intended -- I'm just trying to be clear.
 
You caught me there. Which would be in my mind:

     [s1] --rdf:type------> [rdf:Statement]
     [  ] --rdf:property--> [p]
     [  ] --rdf:subject---> [s]
     [  ] --rdf:object----> [o]
     [  ] --atTime--------> "Yesterday"
     [  ] --truth---------> "True"
     [  ] --atTime--------> "Today"
     [  ] --truth---------> "False"

Ah, looks like I've warped the meaning. But. There's a conflict of meaning
independent of the reification anyway, merging just makes it explicit. If
truth is temporal, then you need to bind truth to S2 indirectly via atTime
where it has appropriate scope. This implies a defective temporal model. So
I still think that merging by reification patterns is valid.

Imagine a retract free for all, leaving:

     [  ] --truth---------> "True"
     [  ] --truth---------> "False"

We have to remember that statements live on their own outside the
refication. This example shows why I whine about procedural semantics for
statements involved in a reification. I'm stealing it :)


> > > Thus, I would re-word my definition to be:
> > >
> > > Stating:
> > >     The expression of an RDF statement [or set of statements]
> > >     in some context of discourse that is taken to be an assertion
> > >     of the truth of the statement[s] in that context.
> >
> >This is very clear.
> >
> >A W3C note on terminology is an excellent idea.
> 
> Thank you ... though I think terminology alone would be less 
> helpful than 
> terminology supported by some explanation of the concepts 
> thus referenced.

Sample xml serialisations would also help to ground them.

-Bill

-----
Bill de hÓra  :  InterX  :  bdehora@interx.com

Received on Thursday, 4 January 2001 11:47:41 UTC