Re: action item on reification

Dan,
Frank,
and all,

I'm finding myself getting a bit lost in the details of this emerging 
discussion.

I hadn't previously noted that ambiguity about the nature of an RDF 
statement was causing a problem.  If it is, might this be better handled as 
a separate issue rather than becoming bound up in the reification debate?

Based on off-list exchange with Frank, I'd like to suggest that the next 
step for clarifying reification would be to actually enumerate what we 
expect reification to achieve, or make possible.  This might be parallel 
with or as a precursor to DanBri's call for test cases.  Here's an initial, 
off-the-cuff list to get the process started:


(1) to make assertions about statements [M&S, 4]
(2) to reference statements without asserting their truth  [Vague allusion 
in M&S, 4.1 para beginning "A new resource..."]
(3) modelling the statement grouping implied by description elements [M&S 
4.1]  (In conjunction with rdf:Bag, bagID, etc.)
(4) modelling other aspects of statement grouping;  e.g. statements from 
some common source.  (I view (3) as a particular case of this.)
(5) to provide a framework upon which richer semantics can be defined.
(6) quotation has also been mentioned (but I think this is wrong... see below)


The first two cases are exemplified by the common example in RDFM&S, here 
using N3 purely as a syntactic replacement for RDF/XML:

   @prefix rdf: <http//www.w3.org/1999/02/22-rdf-syntax-ns#>.
   @prefix a:   <http//description.org/schema/>.
     [ a rdf:Statement ;
       rdf:predicate  a:creator ;
       rdf:subject    <http//www.w3.org/Home/Lassila> ;
       rdf:object     "Ora Lassila" ;
       a:attributedTo "Ralph Swick" ].


For the third and fourth cases, a collection of two statements might be:

   @prefix rdf: <http//www.w3.org/1999/02/22-rdf-syntax-ns#>.
   @prefix a:   <http//description.org/schema/>.
     [ a rdf:Bag ]
       rdf:_1 [ a rdf:Statement ;
                rdf:predicate  a:creator ;
                rdf:subject    <http//www.w3.org/Home/Lassila> ;
                rdf:object     "Ora Lassila" ] ;
       rdf:_2 [ a rdf:Statement ;
                rdf:predicate  a:title ;
                rdf:subject    <http//www.w3.org/Home/Lassila> ;
                rdf:object     "Ora Lassila's home page" ] .

Describing a bag containing the following two statements:

   @prefix rdf: <http//www.w3.org/1999/02/22-rdf-syntax-ns#>.
   @prefix a:   <http//description.org/schema/>.
     <http//www.w3.org/Home/Lassila>
       a:creator "Ora Lasilla" ;
       a:title   "Ora Lassila's home page" .


The fifth case is somewhat controversial.  It is raised by TimBL in 
http://www.w3.org/DesignIssues/Toolbox.html:

[[[
The RDF model currently is that of an (unordered) set of assertions. We
will demonstrate that this remains all that is needed to represent the new
langauge features. Every new feature can be introduced as a new RDF property.
However, we will see that this is an impractical way of actually processing
information, as it involves using RDF indirectly to describe the parts of a 
statement instead of making it directly. This process (called reification) is
described in the RDF Model & Syntax document. An RDF statement in a model
can be reified by four triples. Three are needed to assert the subject,
object, and predicates of the assertion. One to assert that the triple is part
of the given model (set of triples) -- where  more than one model can 
exist. Reification therefore blows up the storage requirement by a factor of
four.

We will see how reification ends up being replied successively, making the
verbosity become quite unnacceptable. Therefore, while we will derive each
language feature simply by defining a new RDF property, to make it practically
useful we will also need a syntax which allows the new langauge to be written
less verbosely

Reification turns what is an explict statement into a description of  a
statement which is not specifically asserted, but which is described and can
be talked about. In languages this is typically done by quotation. In RDF
synatax to date there is now way of doing this, so let as start with that as
then we can do anything.
]]]

I think this is one of the most difficult aspects of reification, and that 
we should proceed very carefully on this front.  (I think the appeal to 
"quotation" is wrong, or at least excessive, as that brings the RDF 
"language" into its own domain of discourse.)

By way of example, suppose that I want to assert that the statement:

       <http//www.w3.org/Home/Lassila> a:creator "Ora Lassila".

is NOT TRUE (something that base RDF cannot express).

According to the general approach proposed by TimBL and others, this is 
done by introducing a new property, say rdf:truth, and assigning to it the 
corresponding semantics (these semantics being supplied from outside RDF, 
not expressed in RDF), and using it in a statement that references a 
reification of the statement; e.g.

   @prefix rdf: <http//www.w3.org/1999/02/22-rdf-syntax-ns#>.
   @prefix a:   <http//description.org/schema/>.
   [ a rdf:Statement ;
     rdf:predicate  a:creator ;
     rdf:subject    <http//www.w3.org/Home/Lassila> ;
     rdf:object     "Ora Lassila" ]
       rdf:truth "0".

I think this example hints at how getting into the realm of defining new 
semantics to be used with RDF seems to require some model theoretic notion 
of truth.

...

In summary:  my purpose here was to state, for debate, some perceived goals 
of reification and give some examples of how reification might be applied 
for these purposes.

#g
--


At 07:13 PM 5/23/01 -0400, Frank Manola wrote:
>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

------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Thursday, 24 May 2001 10:46:54 UTC