Re: action item on reification

Dan--

Thanks for the comments.  Detailed comments interspersed below.

Dan Brickley wrote:
> 
> 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).

No doubt about the need for more.  This was just to try to summarize the
problem areas (and also I'd promised something "early in the week"!).

> 
> 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).

That's true to some extent;  another problem is the one you note in the
next paragraph about the interpretation of the more primitive concepts; 
and still another problem is the perception that the two uses of
reification that *are* explicitly described in the M&S (the Ralph Swick
type of example and the handling of Description elements) seem to be
rather different in meaning.  

> 
> 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 agree.  However, (and I hope this doesn't sound too defensive), the
real problem is that the background statement is, I think, a pretty fair
paraphrase of the way the M&S describes reification (and hence
illustrates the point you made just above).

> 
> 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.

I agree completely.

> 
> 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).
> 

Great!  Useful example.

> 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.

Yep.

> 
> 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.

I certainly agree with this program.  I just want to note at this point
the *extreme* importance of the part involving giving "a better account
of what RDF is *for*".  I don't think this is just an exercise in
clearer writing.  I think some of us have different ideas as to what RDF
is *supposed* to be able to do, let alone what it actually does (forget
whether these ideas are very clear in our own minds, for the moment). 
This gets back, for example, to deciding the question of "RDF as
abstract syntax" vs. "RDF as conveying domain semantics" that Graham and
others have noted [parenthetically, my own view is that RDF is supposed
to do the latter, using what John Sowa would call the "Existential
Conjunctive" subset of logic.]  The point is that with a consistent idea
of what we want the notation to do, we can more easily determine which
mechanisms (or treatments of those mechanisms) are consistent with those
goals.  Without that, we run the risk of having the specs determine our
usage, rather than the other way around.  

> 
> 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.

No, not ungrateful at all.  This really *was* meant to be an "initial
overview" (and rather rough at that).  Test cases seem to me a very
practical way to drive out places we need to focus on (not to mention
the only way I can really understand what's going on!).  

> 
> 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...

It sounds very feasible.  One of the things I didn't have time to do
this go around, for instance, was to extract the examples that folks had
used in the discussions on rdf-logic to illustrate the points they were
making.  These would provide starting points for a number of test
cases.  I can imagine others as well.  And I think these can be couched
in terms of triples (or something else relatively abstract) so they
don't get too tangled with the XML syntax (until it comes time for the
XML syntax to support any new mechanisms needed in the test cases, of
course!).  

So, to summarize, I'm certainly prepared to carry on (in a number of
senses!) with this activity, and I hope we can count on the sort of
active interaction you've provided here.  Thanks again!  

--Frank


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Wednesday, 23 May 2001 19:13:41 UTC