RE: RDF Terminologicus

At 04:46 PM 1/4/01 +0000, Bill dehOra wrote:
> > 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.

I agree that there are ways of modelling these statements that overcomes 
the conflict illustrated.  But I think the core of RDF should be as liberal 
as it can be about how it is used.  Much as the core of RDF does not of 
itself impose a particular logic framework, hence allows alternatives to be 
used in different situations.

I see nothing gained by allowing aggregation of reifications in the way you 
suggest, and possible loss of expressive options.  (Eventually, I dare say 
we won't use all these possible options, but until we better understand how 
to deal with a range of info modelling issues I'd prefer to keep open as 
many options as possible.)

>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 :)

I'm not sure I understand what you're trying to say, but I'll make a couple 
of responses anyway (or, the same response in two different ways):

(a) I don't recognize retract as a legitimate option, other than as an 
implementation technique when constructing models.  Once a statement has 
been stated, it exists;  it may be forgotten, or ignored, or refuted, but 
not abolished.  (I don't claim this is the only possible usage scenario, 
but its one that interests me.)

(b) I am not trying to invoke procedural semantics.  If anything, I'm a 
wannabe functional programmer, ever since I read John Backus' ACM Turing 
award lecture, oh so many years ago.  I really like the cleanliness and 
relative predictability of non-procedural definitions.

#g

Received on Thursday, 4 January 2001 15:47:40 UTC