- From: Dan Brickley <Daniel.Brickley@bristol.ac.uk>
- Date: Mon, 13 Dec 1999 13:23:56 +0000 (GMT)
- To: Pierre-Antoine CHAMPIN <champin@cpe.fr>
- cc: www-rdf-interest@w3.org
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