Re: [issue needed] Re: RDFCore last call WD's: Two comments on the RDF documents

Frank,

At 07:15 PM 2/27/2003 -0500, Frank Manola wrote:
>Bob--
>
>This last message of yours summarizing the situation helps a lot to 
>clarify things, in my opinion.  First of all, you should understand that 
>all this messaging is part of a process, which says that either we as 
>individual editors decide we can handle an issue as a simple editorial 
>change to our individual documents, or we have to refer it to the working 
>group as an "issue".  That's what I requested be done with the issues 
>you'd raised about reification, for the reasons I mentioned in my 
>message.  The process is designed to explicitly respond to comments, and 
>make sure to deal with them in some kind of structured manner.  So we 
>couldn't really "drop" anything from our end unless you agreed to "drop" 
>it too.  In other words, I wasn't trying to raise a new issue, I was 
>trying to resolve an old one, by saying the working group needed to decide 
>how to handle this.
>
>Speaking for myself, my summary reply to your summary analysis is 
>something like this:
>
>1.  I agree 100% with you about the difficulty of the semantics of 
>propositional attitudes.  You can, of course, write triples with something 
>like ex:believes as the predicate, but that's not the same thing.  We're 
>not going to get into those semantics.
>
>2.  I agree with you about the the problem with provenance, i.e., the 
>inability (at least, in terms of a built-in RDF facility) to explicitly 
>identify specific statements.  Of course, if you (externally to RDF) have 
>a way of assigning URIrefs to individual RDF statements, everything is 
>cool. (See below for more on this).
>
>3.  We don't explicitly say that we don't support propositional 
>attitudes.  To do that, we may have to explain what the problem is (e.g., 
>why the semantics of a predicate like ex:believes are hard to pin down), 
>which could get a bit complicated.  As far as the Primer is concerned, 
>I've thought about adding a short bit about this (basically saying these 
>things are propositional attitudes, they're complicated, and go off and 
>read the following references to see why).

In some sense, anything is possible in the long run, even support for 
something as
hard to pin down as propositional attitudes.  So I can see why you wouldn't 
want to come
right out and say that they aren't supported.  However, it is quite 
difficult for an outside
reader to figure out exactly where the boundaries are (what's supported, 
what's not, if
not, why not).

I like the suggestion you just made:  "  ... propositional attitudes,  ... 
read the references."
In some sense, writing about something outside of the specification is odd, but
it addresses an issue that will probably keep coming back.   And, if in the 
future,
someone on RDF-interest asks "How do I represent 'I believe that Mary is a 
juggler' in RDF?",
you can begin by pointing them to the section in the Primer.

>***Do you think that type of material on propositional attitudes is 
>absolutely necessary in the Primer?***  (Alternatively, how bad would it 
>be if the Primer didn't cover that?) Note that I'm speaking just for the 
>Primer.  If you think this needs to be explicitly mentioned in any other 
>document, you probably should explicitly indicate that/those other document(s).

Not mentioning propositional attitudes at all is an alternative 
option.  However, that means
purging references to them in ALL of the RDF documents, not just the primer.
Right now, for example, the "I don't believe that George is a clown" 
section implicitly mentions the
same issue.  So you would need the WG to make that decision.

>4. Regarding provenance, I'm a little confused.  The whole last half of 
>the Primer section on reification basically says exactly what you've 
>said;  that the reificiation mechanism per se has no way of identifying 
>the individual triples it describes.  There is, for example, a paragraph 
>starting "This does not mean that such 'provenance' information cannot be 
>expressed in RDF, just that it cannot be done using only the meaning RDF 
>associates with the reification vocabulary."  It does on to explain that 
>if you have a way of assigning URIs to individual statements, you can make 
>statements about those statements without needing to use reification at all.

The Primer does go to great lengths to describe the limitations of RDF's 
reification.  But
its kind of like the old joke "How do you make a sculpture of an 
elephant?"  Answer:
"Simple, start with a block of clay, and cut away anything that doesn't 
look like an
elephant."   Imagine if the Primer had said, "Here is how to make a reified 
statement
point to a triple ...  S1 rdf:containedIn graphURI ..."  Everything would 
be pretty
clear, except for the problem that there is no "rdf:containedIn" 
property.  Unfortunately,
it is not normal in a specification to give examples of how to do something,
and then say, well, you can't do that after all.  But I think that if you 
did you that (i.e.,
if you did hint at the use of a 'my:containedIn" property)
readers would find the entire issue MUCH more comprehensible.

The awkwardness of RDF's partial support for provenance is apparently 
historical.
The first RDF reification mechanism probably intended that reified statements
only referred to edges in the same graph.  When observers pointed out that 
making
statement about statements in other graphs is a pretty reasonable thing to 
want to
do, the obvious thing to do would have been to fix things up.  But the 
Charter precludes
that.  So you are left with a partial solution that I claim will be 
mystifying to the
uninitiated unless you go out of your way to illustrate what a full 
solution looks like.

>The point here is that RDF as we started working on it had a reification 
>vocabulary with multiple interpretations.  We decided not to change the 
>vocabulary this go-round (too many different views of what was wanted, 
>possibly outside our charter as requiring too extensive a fix), and we're 
>reporting on the appropriate interpretation of what's there.  Note that we 
>can't just drop reification.  My organization, for one, has people using 
>it (that is, they defined a way to assign URIs to statements, and use the 
>reification vocabulary to describe the statements).
>
>   My confusion boils down to this (to try to nail things down *very 
> precisely*):  are you saying the Primer:
>
>a.  doesn't explicitly say that you can't really do provenance with only 
>the built-in facilities in RDF?  (I sure think it does)
>
>b.  isn't clear enough about this? (I thought at least the paragraph I 
>mentioned above, and the surrounding text, was pretty clear)
>
>c.  doesn't say why reification is still in RDF, even though it doesn't do 
>provenance the way some people thought it did?  (The Primer doesn't talk 
>about that, and I'm not sure it should.  We're trying to describe the 
>facilities of a specific language, not why the language isn't some other 
>language.)
>
>Given your choice of zero, one, or more of a, b, and c above, what 
>specifically would you like changed in the Primer?

I would choose (c).  The RDF spec does say that you can't really do 
provenance, but its kind of like having
to read the fine print of a legal document -- it takes a lot of reading and 
rereading to figure
out what is and is not supported (so I'm not saying (a)). The actual 
semantics might be
considered a masterful way to avoid eliminating reification from the 
specification without
overstepping the bounds of the Charter (take a bow, Pat), but IMHO its not 
intuitive.  The
non-intuitiveness means that even when you try very hard to describe it 
clearly, it
will be hard for many readers to come away with the right 
understanding.  So I'm not
saying (b) either, because the problem isn't with what you said, its with 
what you didn't say.

I'm saying that indeed, you should say why the language isn't some other 
language.  That's
perhaps a very odd thing to do, but then, the current reification semantics 
is a bit odd.

As an aside on the issue of "understanding a language", I recall 
discussions about
about the design of the programming language Pascal that went "Why does Pascal
allow A but not B?"   The design decisions became more intuitive
once we understood that Per Brinch Hansen included everything he needed to 
write
a parser in Pascal (e.g., long jumps), and tended to leave everything else 
out.  None
of the books I saw on Pascal included that particular tid-bit, but it would 
have been
helpful if they did.

>Again, thanks for the comments.  This last message was very helpful (at 
>least to me).
>
>--Frank
>
>PS:  I'm still going to change the "apparent nested statement" example in 
>the Primer as we've discussed already.
>
>
>
>
>Bob MacGregor wrote:
>
>>Hi Frank,
>>Currently, only you and Pat Hayes have responded (back to me) to the
>>comments that I posted earlier to RDF-comments, and those responses did not
>>include consideration of some of the issues I raised.  The
>>discussions with Pat made it clear that the WG charter imposes
>>constraints that IMHO preclude a satisfactory resolution of the
>>reification issue. I don't want to tilt endlessly at windmills
>>that aren't going to yield, so I've pretty much dropped the
>>discussion.  However, if you indeed can create a new issue out
>>of this, that would be a good thing.  Below, I've summarized my
>>impression of the body of issues related to reification in RDF.
>>Below, I first pose some of the key questions; then I summarize
>>my take on the status of reification in RDF; then I provide my
>>answers to each of the questions; and finally I make some
>>summary recommendations.
>>1. Should RDF be able to represent statements about statements?
>>2. Does the current RDF support statements about statements?
>>For each of 1 and 2, what kind of semantics do we have in mind:
>>     3. Should/can RDF express propositional attitudes?
>>     4. Should/can RDF express provenance information about statements?
>>First, some background remarks:
>>  Propositional attitudes:
>>    The semantics are very hard to pin down here.  It is hard to
>>    imagine the WG reaching agreement on what they are in this
>>    go-round (if ever).  So, while I was arguing for their inclusion
>>    in RDF a while back, it seems pretty clear that they are not a part
>>    of RDF now (and perhaps forever).
>>  Provenance information:
>>    The semantics here are much more tractable, both from what
>>    is meant, and what adjustments are needed in the language
>>    to support them.  HOWEVER, there is a big hole in the current
>>    RDF support for provenance information:
>>    Suppose I wish to make a statement that John is the author of
>>    a statement [S P O].  I can write something like:
>>      S1 type ReifiedStatement.
>>      S1 subject S.
>>      S1 predicate P.
>>      S1 object O.
>>      S1 dc:creator John.
>>    Support there are two different graphs G1 and G2 that both contain
>>    statements with values S,P,O.  Which one is John the author
>>    of, i.e., which one does S1 refer to? We have no idea, because
>>    RDF makes no provisions for identifying which among a set of
>>    statements a reified statement refers to.
>>    Is this easy to fix?  Unfortunately, in order to select among
>>    a set of graphs, we run into another open RDF issue, which is
>>    roughly phrased as "Does a URI that matches an RDF file URI
>>    denote the document or the graph within it?".  Resolving that
>>    that issue might be regarded as a prerequisite to resolving the
>>    provenance issue.  Perhaps a resolution of the issue of "contexts"
>>    is also a prerequisite.  In any event, there is at present no means
>>    for creating a URI that denotes an RDF graph.
>>Back to the original question.  My impression is that there is a 
>>(non-explicit)
>>consensus within the WG that the current RDF cannot represent
>>propositional attitudes, i.e., the answer to
>>question 3 above is "No".  Can RDF represent provenance information
>>(question 4)?  I claim that RDF provides some very simple (and
>>non-controversial) hooks (the subject, predicate, object properties)
>>and omits a key notion (the ability to refer to a graph) that is
>>needed to make the whole provenance notion workable.  So, while
>>from a mathematical standpoint the answer to question 4 might be
>>"Yes", from a PRAGMATIC standpoint, the answer is "No".
>>If one agrees that the answers to questions 3 and 4 are "No" and
>>"No", then the answer to question 2 is probably "No" also.
>>Hence, one possible recommendation (which I posited in an earlier
>>e-mail) is to drop the entire notion of reification from RDF.  However,
>>it seems pretty clear that this is a non-starter.  Hence, I have
>>some alternative recommendations.
>>Recommendations:
>>   We probably want RDF to support representation of provenance information.
>>   There ought to be an open issue in one of the RDF documents that states
>>   roughly "RDF currently does NOT provide adequate support for
>>   provenance information, but it may in the future."
>>   Propositional attitudes are probably out of bounds.  In that case,
>>   this should be made clear in the documents.  Right now the
>>   "I don't believe that George is a clown" discussion leaves the
>>   impression that this kind of propositional attitude is something
>>   that we can say in RDF.  I recommend eliminating this from the
>>   Concepts and Abstract Syntax document.  The (non-RDF) example
>>   of a nested statement in the Primer further contributes to such an
>>   impression.  I recommend rewording that example (Frank has already
>>   acknowledged this latter comment).
>>   Asserted and non-asserted forms:  The RDF documents do not include
>>   any example of a graph that contains both asserted and non-asserted
>>   RDF statements, unless one counts reified statements as providing
>>   an example of (possily) unasserted statements.  If that is what is
>>   meant, then this should be stated plainly.  If some other notion
>>   (that I can't guess at) is meant, then that should be stated plainly.
>>   Otherwise, the entire section on asserted and unasserted forms
>>   should be eliminated.
>>Cheers, Bob
>>Ironic note: Because we need to represent provenance information in some
>>of our RDF applications, and because its not currently supported,
>>we had to look for other ways to make things work.  We have invented
>>a variant form of context that solves our problem, AND, we like
>>that solution much better than the reified statement solution.  So,
>>if an RDF WG ever fixes reification, we probably won't use it anyway.
>
>
>--
>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-875
>

Robert MacGregor
Project Leader
USC Information Sciences Institute
4676 Admiralty Way, Marina del Rey, CA 90292
macgregor@isi.edu
Phone: 310/448-8423, Fax: 310/822-6592
Mobile: 310/251-8488

Received on Thursday, 27 February 2003 20:12:59 UTC