- From: Dan Brickley <danbri@w3.org>
- Date: Sat, 18 Nov 2000 13:31:33 -0500 (EST)
- To: Seth Russell <seth@robustai.net>
- cc: RDF-IG <www-rdf-interest@w3.org>
We have a name for this problem on the Issue Tracking page: http://www.w3.org/2000/03/rdf-tracking/#rdfms-identity-of-statements [snip] My take is that the Model and Syntax specification is unclear as to whether the members of the class rdf:Statement are uniquely identified by having common values for rdf:subject,rdf:predicate,rdf:object. From what I've seen, this confusion has resulted in different implementation styles. By analogy, members of the class util:Person might be uniquely picked out w.r.t. values of properties such as util:personalMailbox or util:humanGenomeChecksum. While RDF itself does not provide machinery to express this state of affairs, additional schema annotations can be used to provide such info. For example, I have an aggregating RDF robot that 'knows' to treat personalMailbox as uniquely identifying, ie. that any given value of that property can apply to at most one resource. My expectation is that this technique (w.r.t. single properties or combinations of properties, eg pred/subj/obj) will be a common trick for folding together scattered pieces of RDF data. I believe this perspective on the problem helps focus the choice we're faced: either we treat rdf:Statements as being uniquely identified by p/s/o or not. If we do, properties ascripbed to instances of that class (eg. 'by' some agent, 'on' some date) will be folded together and attached to a common resource, at least in RDF aggregation systems such as the one I'm working on. If this is a fair characterisation of the problem, it would be good to get implementors feedback on what an Errata for M+S might best look like. My current inclination as an implementor is to allow multiple instances of rdf:Statement with the same p/s/o, since this allows individual statements to be qualified without risk of confusion. What about the rest of you? Dan
Received on Saturday, 18 November 2000 13:31:34 UTC