Re: Meaning of RDF:Statement

On Mon, 13 Dec 1999, Pierre-Antoine CHAMPIN wrote:

> Dan Brickley wrote:
> > Recap...
> > First reading: statements with same subject/predicate/object occur many
> > times, for the various belief and disbelief scenarios in which they
> > occur[*]
> 
> > Second reading: identity condition for statements is having the same
> > subject/predicate/object. There's really only one statement resource for
> > each state-able triple -- if we use a variety of URIs instead of one
> > that's a pragmatic hack rather than recognition that there are multiple
> > statements.
> 
> I would call that a FACT more than a STATEMENT ;
> I read in the word 'statement' the action of 'stating',
> that's why I'm rather pro first-reading...


Guha's point when objecting (unfairly as it happened but fairly in this
case?) to my msg was that these are not FACTs since they may well be
false. I believe the RDF M&S spec is closer to the second reading. In
neither case is 'FACT' appropriate, since even the RDF system does not
necessarily believe the triple concerned. If the RDF system also
contains the raw unquoted triple we might say it believes it, or holds
it to be a fact, but to talk unreservedly about the information item
being a FACT will I suspect lead to confusion. (I've seen 'factoid' used
in a few places, which is kind of cute but perhaps not what we're after
here...?)

> 
> Though, even if reified statements have unique identifiers only based on their s/p/o,
> we could easily add a level with a Class of resources like "Stating" and an appropriate link to the correpsondong statement.

Yep, this was exactly the node'n'arc diagram I was playing with on
friday which prompted my initial message. I was talking with some others
at W3C about RDF for annotations, and the relationship between Web
annotations and RDF reification came up. If someone creates an
annotation on a page saying that it is a 'medically suspect' site or
'morally bankrupt' resource, there turns out to be a spectrum of ways in
which we can model that in RDF. (I'll try to document these in a
separate post).

>   [Stating]  <--type-+[local-URI]--states--> [unique-URI]+-type--> [Statement]
>   "12/13/99" <--date-+                                   +-subject--> [...]
> "champin" <--author--'                                   +-object--> [...]
>                                                          `-predicate--> [...]
> 
> Such a dichotomty between the unique universal "statement"
> and each local "stating" might be useful ;

Yes. The latter being more of an 'event', and perhaps sharing structure
with other events (publications, agreements, properties of agents
etc)...?

> 
> Since, this is clearly not the way it is recommanded in RDF M&S :
> properties like "author" are directly attached to the Statement resources
> which is therefore considered emminently local.

I'm not sure about the 'therefore' here. We have some big philosophical
issues we're glossing over here for sake of having something
implementable in non-geological timescales. One is the distinction
between intrinsic and (I guess) extrinsic properties. A 'car' might be
'intrinsically' 'red','heavy','rusty', in that these are intrinsically
properties of the car. Less intrinsic to the car is the fact(oid) that I
dreamt about it last night, that it is 'desiredTobeOwnedBy' (say) Guha,
or that it was talkedAboutInConversationOn '[1999-12-13]'.

Since the directionality of arcs in RDF is pretty much an artifact of
the vocabulary creators whim, glossing over any distinction between
intrinsic and non-intrinsic properties is fine by me. People do it all
the time. So... my reading of RDF M&S is that the examples of
reification it gives are doing just this. A statement is an abstract
resource representing a state-able triple; by attaching the propertes
like 'author' to that resource the M&S examples are saying something
more like 'advocatedBy'.

On this general line of thought I'm most interested in
objections/comments w.r.t. the suggestion that RDF processors might use
a common canonicalisation algorithm for determinining the URIs for
Statements. eg. How for example to reconcile this with instance data
that already associates a URI with an object of type 'statement'? 
All paths seem to lead back to the 'resources have one URI / many URIs'
debate...

Dan

Received on Monday, 13 December 1999 08:24:55 UTC