W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2002

RE: [xml-dev] RDF for unstructured databases, RDF for axiomatic

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 21 Nov 2002 14:47:42 +0000
Message-Id: <>
To: "Shelley Powers" <shelleyp@burningbird.net>, "pat hayes" <phayes@ai.uwf.edu>
Cc: "Jonathan Borden" <jonathan@openhealth.org>, <www-rdf-comments@w3.org>

At 07:00 21/11/2002 -0600, Shelley Powers wrote:At 07:00 21/11/2002 -0600, 
Shelley Powers wrote:

>Pat, I understand the constraints that you all work under, but you're doing
>future consumers of RDF a deservice with this approach. This has
>re-introduced ambiguity. More than that, this approach makes it difficult to
>determine what is or is not 'compliant' RDF.

Since this has been posted to www-rdf-comments, I think its only fair to ask:

   o what is ambiguous?  Is there a test case?
   o Do you have test case for which it is unclear whether it is or is not 
'compliant'.  I don't recall us defining a notion of compliance.

>Your charter does not preclude you using the deprecation marker. From the
>HTML document:

The advice we received from our W3C representative was not to deprecate.


>I'm actually not as concerned about the semantics document as I am the
>other. I think the biggest problem with the documents in difficulty
>understanding who your audience is.

My view, Pat, feel free to disagree/expand:

The model theory began in my mind as a technical tool to help the WG have 
useful discussions.  I had too much experience of long and ineffective 
discussion or RDF which foundered because there no precise language for 
discussing what RDF meant.  The formal semantics has been wonderfully 
useful to the WG; we may disagree about things, but is much clearer what we 
disagree about, and when we make a decision, what decision we have 
made.  It is so useful, we decided to publish.

So there is your first audience, the RDFCore WG.  A second audience are 
other WG's that are building on RDF, e.g. WEBONT.  They have people who can 
read the math and understand exactly what RDF does and does not mean.

I must pay tribute to the effort and skill that Pat has put in to extending 
the reach of the document to those with college level knowledge of 
mathematics.  Time will tell how much of this audience will reach, but it 
does mean that many of the WG at least can understand and use it, and I 
hope will extend far beyond that.

But I think there will be folks who find the mathematical approach a little 
offputting.  That is why the other specs are there, the concepts document 
and the schema document.  They are intended to say mostly the same things, 
but in precise, but less mathematical terms.  The primer should be 
understandable by anyone, and should be all that many will need to read.


> >
> > No, not at all. The problems run deeper. The real problem is that if
> > containers are unordered (like rdf:bag) and you use an ordered set of
> > selection functions on them, then you are kind of imposing an order
> > on what is conceptually an unordered thing. So your description in a
> > sense says *too much* about it. So if we allow RDF to make any formal
> > entailments about bags, they are almost all going to be wrong, in
> > fact, so we had to block them. For example suppose you say that A is
> > a bag and its first item is X and its second item is Y. If you allow
> > RDF to permute the items, then you can infer that Y is the first
> > item. But now *both* X and Y are the first item...
> > There are other problems, notably with there being no way to say that
> > a container is 'closed', ie has no more elements.
> >
>And that's why I don't like containers in this type of model.

I suggest we've done as much as we can to make the M&S definition of 
containers precise.  If you want to suggest we delete or deprecate them, 
then the thing to do is post the suggestion to RDF comments and explain 
why.  The WG will listen.

Received on Thursday, 21 November 2002 09:46:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:01 UTC