- From: Seth Russell <seth@robustai.net>
- Date: Wed, 6 Feb 2002 08:02:18 -0800
- To: "Enrico Franconi" <franconi@cs.man.ac.uk>, <www-rdf-logic@w3.org>
From: "Enrico Franconi" <franconi@cs.man.ac.uk> > Sorry if this question looks naive, or if you had on this already a > big discussion in the past (which is likely anyway). > > Suppose that a unique id is associated to each triple. This could be > either implicit (i.e., generated internally like OIDs in O-O data > models) or explicit (if you want to mention it later). > > The additional (explicit) ID serves as a reference in other triples > willing to state something on it (as a foreign key). I understand that > this is the spirit of reification. > For the triples where the ID is implicit, the syntax wouldn't change, > and the semantics could be the standard MT already devised. > > If the current MT wants to ignore reification (as it correctly does), > then it should just ignore the presence of those additional IDs. This > makes a lot of sense since the semantics of reification is still > unclear, and a lot of work should be done. A future extension of the > MT (based supposedly on HOL) could then take IDs into account. > > This is more or less in the spirit of Nejdl's proposal. > > - do you have the feeling that this would solve all the problems (on > expressiveness and on semantic clarity) of reification? [please, > note the naivete of the question :-)] > > - Would this be an impossible addition to the rdf standard syntax? Actually there is the idAttr allowable on a property element .. see section D production 6.12 of the revised syntax: <http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218/#section-Grammar> But I'm not sure whether it is practical to used that for your purpose. But isn't it better just to keep piling more and more restraints on a reified statement untill it can only be satisfied by one instance of the triple? See my example at the bottom of the following post: http://lists.w3.org/Archives/Public/www-rdf-logic/2002Feb/0031.html Seth Russell
Received on Wednesday, 6 February 2002 11:05:56 UTC