Re: action item on reification

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