W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: RDFCore last call WD's: Two comments on the RDF documents

From: Bob MacGregor <macgregor@ISI.EDU>
Date: Wed, 29 Jan 2003 10:49:55 -0800
Message-Id: <>
To: Frank Manola <fmanola@mitre.org>
Cc: www-rdf-comments@w3.org, stefan Decker <stefan@ISI.EDU>, macgreg@ISI.EDU


I will try to clarify, but this seems to be an area where its really hard to
get agreement on nomenclature.  The best I can do is to argue that there
are (at least) two different notions wrt statements/reified statements, 
that RDF
only captures one of them, and that the RDF documents should be careful
that they don't give the impression that RDF has the ability to express both
kinds of notions.

At 07:48 AM 1/29/2003 -0500, Frank Manola wrote:
>Thanks for the comments.  I want to clarify your comments on the Primer so 
>I can decide the changes that are needed.  My questions follow.
>Bob MacGregor wrote:
>>In examining the RDFCore documents, I have found two sections where I believe
>>the language needs to be rewritten.
>>In the excerpt below from the RDF Primer, I believe that the use of double
>>brackets in the example is misleading, and should be replaced by 
>>something else.
>>It illustrates a statement syntactically nested within another 
>>statement.  There
>>is nothing in the current RDF equivalent to such a construct.  It preceeds a
>>discussion of reification, which might lead a reader to believe that RDF's
>>notion of a reified statement (a "stating") is somehow related to this 
>>kind of
>>     RDF Primer
>>     4.3 RDF Reification
>>     Now, suppose we wanted to say in RDF that this statement was made by 
>> John
>>     Smith. Since in RDF we can only make statements about resources, 
>> what we would
>>     like to be able to do is write something like:
>>      [[exproducts:item10245  exterms:weight  "2.4" .]] dc:creator
>>exstaff:85740 .
>The intent here was to indicate the need to be able to treat a statement 
>as a resource, in order to make statements about it, not to indicate that 
>we want to support nesting per se (which we don't).  Would a diagram 
>(along the lines of Figure 8 in the original Model and Syntax spec) be 
>less misleading in your opinion?  Or perhaps eliminating the double 
>brackets and say that we want to treat the statement as a resource, say by 
>assigning URI "foo" to it, and then illustrate statements with "foo" as 
>the subject?

Consider the following two sentences.

Yesterday John said "Bill is a clown."
John believes that Bill is a clown.

The common sentence/expression 'Bill is a clown' is referenced in two 
different ways.  In the first, it is a stating, having author John and 
'yesterday'.  In the second, the object of John's belief is the TRUTH of that
sentence, not the sentence itself (Pat Hayes will likely disagree with 
this, owing
perhaps to the fact that none of our discussions have been able to assign a 
name for
the notion of a 'proposition').

In a language such as KIF, an assertion for the second might look like
     (believes John (type Bill Clown))
Again, Pat will probably object (since he always does), but I've seen lots 
of folks
model belief using syntax similar to this.  For whatever reason, I've seen 
few examples of people modeling statings, but if they did, they might
use something like quotation:
     (and (type s1 sentence)
            (contents s1 (quote (type Bill clown)))
            (author s1 John)
            (timestamp s1 yesterday))

Actually, I'm not sure how I would model statings in KIF, so I'm not going to
try too hard to defend the above example.

The point, though, is that I probably wouldn't use nesting when referencing a
stating, without introducing
something like quotation to "remove" the semantics (to convert the nested
expression from a proposition to a sentence).  In English, there is no 
people just use nesting and figure out on their own whether quotation is
implied or not.

So, how am I recommending that you fix things?  Unfortunately, I'm mostly
stating what you should NOT do.  I'm claiming that
using nested syntax will convey the wrong impression to many readers (e.g.,
those that model belief they way I did above), so something like an
EXPLICIT quotation needs to be included.  To me, the use of double brackets
didn't adequately convey the notion of quotation.

The link between a statement and a stating in RDF still seems to be
somewhat tenuous.  When I wrote above, using KIF
      (contents s1 (quote (type Bill clown)))
I was inventing a way to link the stating 's1' with a syntactic statement.
RDF doesn't seem to have any explicit way to model that link, but if it did,
that would be how your discussion should represent it.

>>Here are two quotes from Pat Hayes' emails:
>>" ... rather like saying that the
>>ability to sing eliminates the need to stand on one foot. Nesting hasn't got
>>anything to do with reification."
>>"Many people have suggested using reification to simulate expression 
>>nesting in
>>recursive syntax, but this kind of usage for reification was a mistake 
>>from the
>>Pat is claiming that reification and nested statement syntax have nothing 
>>to do
>>with each other, while the excerpt from 4.3 uses nesting as a lead-in to a
>>discussion on reification.  While my personal belief is that there IS a
>>connection, I will affirm that nested statements do not correlate with the
>>notion of a "stating" that RDF has adopted.  Hence my recommendation that
>>the example of nested syntax be replaced by something else.
>The intent of the text was to introduce what we would *like* to be able to 
>do, not what we actually can do.  The rest of the text describes the 
>*intended* interpretation, and then points out that we can't actually do 
>that (and this latter discussion is along the lines of what Pat actually 
>says in the Semantics document).  Is that discussion not clear, or is it 
>just that the apparent "nesting" example at the beginning throws the whole 
>discussion off?  Would saying at the beginning that we can't actually do 
>those "stating" descriptions using "reification" help?

I consider introducing "what we would *like* to be able to do" very 
dangerous.  It
gives the impression that RDF might be used to represent propositional 
when in fact it can't.  I would prefer that the WG be as up front as 
possible about
stating the limitations it has placed on RDF.  I say that in the hope that 
a future
committee might be motivated to remedy those deficiencies.

Here's another quotation from Pat Hayes:
   "It is indeed a pity that RDF is so propositionally weak and 
inexpressive, if one wants to think
    of it as   a full KR language. Clearly it is not a full KR language. To 
extend it to allow full
    propositional expressivity would have gone beyond the WG's charter. I 
would suggest that
    you think of RDF as a useful way of encoding simple atomic assertions 
and use some
    extension of RDF to encode more elaborate propositional content."

Pat is stating two things here: (1) RDF is very weak. (2) Use something 
else (an extension)
if you want more power.

I find this attitude very disappointing.  I would have preferred
something like:
    (1) RDF is very weak. (2) It doesn't have to be, and a future WG could 
upgrade it into
     a language capable of standing on its own (from a utility standpoint).

Cheers, Bob
Received on Wednesday, 29 January 2003 13:53:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:31 GMT