- From: Dan Brickley <danbri@w3.org>
- Date: Wed, 23 May 2001 17:20:40 -0400 (EDT)
- To: Frank Manola <fmanola@mitre.org>
- cc: <w3c-rdfcore-wg@w3.org>
Hi Frank, On Wed, 23 May 2001, Frank Manola wrote: > from the minutes of the 2001-05-18 teleconference: > > ACTION ITEM: Ghram Klyne and Frank Manola agree to summarize www-rdf-logic > > perspective of reification as it applies to both logic and rdf and > > report back to rdfcore wg > > The following hasn't been coordinated with Graham, but represents an > initial cut on my part at summarizing what the issues seem to be. As > Graham (correctly) noted in a recent message, these issues are tightly > bound up with general questions about RDF semantics. Many thanks for having a stab at this, the thorniest of RDF topics! That said, I'm going to leap straight in with with asking for more... (I think you hint at this need above in your comment about RDF semantics). You've provided a pretty useful overview of various of the threads on the RDF IG mailing lists, but it's not immediately clear what we should draw from this in terms of our work on the specs. Reification is one of those topics that has generated 100s, perhaps 1000s of messages in the various archives. I think this is large part because we never made the design motivations behind reification sufficiently clear in the M+S spec, and people have been attempting to use it for a rather wide variety of tasks (such as those you list). Somehow we need to move beyond this, and introduce some more precision into our description of the reification mechanism. Our problem here is that the primitive terms that we all use in our discussion of RDF reification ("resource", "statement" etc) are themselves contested terms with multiple interpretations. For example, when you write: > Background: Reification is introduced into RDF because RDF statements > (as they stand) are not resources. In order for RDF to be able to > make statements about statements (e.g., the "Ralph Swick" example), > there needs to be a way to turn RDF statements into resources. ...I am a little concerned because the problem is couched in terms of 'resources' and 'statements', and with appeal to operations such as transformation ("turn into statements") that we lack clear definitions for. As a broad-brush characterisation of reification, I have no problem with the above paragraph. But as an attempt to summarise threads that area largely caused by our collective confusion about the meaning of 'resource', 'statement', I feel it's missing something. I'd like you to have a go at revisiting the various perspectives you have summarised with a view to two specific goals: test case creation, and spec changes. (1) test case creation Your summary provides raw materials for the next phase of the analysis, which should be the creation of test cases that elucidate some of the confusion and dispute. For example, rather than simply use the term 'statement', consider this term a part of the problem. The RDF spec has resulted in people having a variety of instincts about the notion of an RDF statement. Our goal is to clean up the confusion through making testable clains about statements (and reification, and RDF parsers, and ...). It would be good to have one or two test cases to clarify reification; it would be great to have 5 or 6. Here is a draft of one: [ [reification-testcase-danbri1] "Are members of the class rdf:Statement uniquely picked out by their predicate/subject/object properties?" Note: this question could be written very formally in an extension of the DAML language in which the daml:UniqueProperty and daml:UnambiguousProperty constructs were extended to allow *combinations* of properties to have the "at most one" semantic assigned them by the DAML axioms. It might be worth going throuhg this exercise. See http://www.daml.org/2001/03/daml+oil-index.html or copied here for convenience. Extension of this for multi-properties should be simple enough. It allows us to conclude that two objects are the same, based on their having some unambiguouos-property in common. I claim this is just what we need to dientangle some aspects of the reification debate. http://www.daml.org/2001/03/axiomatic-semantics.html 5.1.10. UnambiguousProperty %%?UnambiguousProperty? is type ?Class?. Ax64. (Type UnambiguousProperty Class) %% An object P is type ?UnambiguousProperty? if and only if P is type ?AbstractProperty? and if an object V is a value of P for an object X and V is a value of P for an object Y then X is equal to Y (i.e., then X and Y are the same object). Ax65. (<=> (Type ?p UnambiguousProperty) (and (Type ?p AbstractProperty) (forall (?x ?y ?v) (=> (and (PropertyValue ?p ?x ?v) (PropertyValue ?p ?y ?v)) (= ?x ?y))))) ] That's a rough-cut at a formalisation of the notion of 'statement' that is used in prose discussions. It asks a concrete question about the class of resources we call rdf:Statement and about the identity criteria for members of that class (just as daml:UnambiguousProperty is used to bring precision to models of -- say -- Persons and socialSecurityNumbers). So the second goal... (2) Changes to the specification(s) We are looking for practical changes to the specs in the light of our issue summaries and test cases. Regarding reification, your summary of the numerous uses to which it is being put has some clear editorial implications. The spec needs to give a better account of what RDF is *for*. But beyond that, we also need to ensure the technical consistency of the spec, by analysing it in terms of our test cases. To follow through with the example above, having noticed that there are (in rdf-logic and rdf-interest threads) two views on rdf:Statement identity conditions, we might revisit the spec looking for cases where different parts of the document take opposing views as to the answer given for that test case. Another part of this goal is looking at the reification summary with an eye to partitioning the spec's treatment of the topic. We sometimes hear talk of "dropping reification" without a detailed account of what this would mean for the spec. I can think of several things that we might do; I'd like to see these options listed comprehensively. Off the top of my head: - we might stop saying that RDF parsers should output reification triples - we might stop saying that they should reflect syntactic structures using Bags of reified rdf:Statements - we might remove some/all of the XML syntax support for reification in RDF/XML (bag IDs etc) - we might drop (move to another spec, etc) the RDF vocabulary provided to support reification (predicat/subject/object/Statement) - ... (is this exhaustive? what are the cross-dependencies? ...) I don't want to go on, hopefully the point is clear. Reification is the one big tricky topic that has bedevilled discussions of RDF to date, and our only hope of getting past it (in my opinion) is in using some formality in characterising the different views and interpretations that are out there. I hope this doesn't appear ungrateful w.r.t. the initial overview you've provided, but provides some "next obvious steps" for where to go from here. Does this sound feasible? Are there practical test cases (beyond the one I draft above) that will help us understand the reification issues at this stage in the RDFCore effort? If not, it may be worth focussing on the details of the XML syntax and revisiting this topic once we've got some more closure on the syntax front... Dan
Received on Wednesday, 23 May 2001 17:20:45 UTC