W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2002

Re: Patel-Schneider Paradox ...

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 18 Feb 2002 14:28:40 -0600
Message-Id: <p05101401b8970f9cde8a@[]>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: webont <www-webont-wg@w3.org>
>From: Pat Hayes <phayes@ai.uwf.edu>
>Subject: Re: Patel-Schneider Paradox ...
>Date: Fri, 15 Feb 2002 20:29:37 -0500
>>  >However, there is lots more to RDF than
>>  >that.  For example,
>>  >
>>  >1/ RDF reification - particularly as understood / used
>>  So simple it is almost embarrassing.
>Well, the MT that you (and I) would like to have for reification is
>simple.  But I don't think that that is what it is being used for.  In
>particular, the notions of stating are, to me, rather complex.

They are potentially complex notions to fully explicate, but RDF only 
says that they exist and have some properties; and since those 
properties have no particular special consequences that are 
expressible in RDF, the MT doesn't in fact have to say *anything* 
about them (and probably won't).

>>  >2/ RDF containers - particularly alternative, but even sequences are
>>  >complicated
>>  Nah, sequences are easy. (rdf:Alt is a black hole, I agree; and we
>>  will punt on that one, I hope.)
>Well, again, there is the cleaned up MT and there is the notion that an
>instance of rdf:Bag is a bag.  You may say that bags are simple, but RDF
>bags can include themselves and don't have a well-defined motion of

The point is that they are underdetermined compared to what most 
programming languages deal with. True, but that doesn't make RDF 
*complex*, it just means that there is less that you can say in it. 
The notion of membership is perfectly clear, seems to me, if a bit 
catholic. And putting containers in themselves is a very simple idea 
which is as old as the hills. In naive set theory and in Aczel's 
formal set theory you can put sets in themselves, and in LISP you can 
put lists in themselves. The basic idea is common to both, and a 
child can understand it. Of course you are free to define other kinds 
of container that are more restricted in what they can contain, if 
you want to have them.

>  > >3/ RDF syntax - particularly some of the automatic reification components
>>  There aren't any automatic reification components. :-)
>Well there are.  Such components include rdf:bagID and rdf:ID on property
>elements.  RDF syntax also includes things like parseType="literal", which
>apparently are supposed to be very complex.

I agree that parseType is a complication that I have tried to avoid 
(and I have no idea what it means.)  OK, you win that one.

>  > RDF syntax is *really* easy, particularly now we can have tidy
>>  literal nodes. (A recent decision not reflected in the MT document
>>  yet.)
>You are talking about the triple syntax, which is not the only RDF syntax.

True. but I take that as the primary syntax. I leave XML syntax to 
the XML guys, and indeed there might be some nightmares hidden in 
that box.  But I don't think you can blame RDF for those.

>>  >Then we get to RDFS, which has its own complexity, including
>>  >
>>  >1/ two readings for constraints, neither well-specified
>>  ?? I don't follow what you mean here.
>Well there was a debate over whether domains and ranges were prescriptive
>(whatever that means) or descriptive (which is also not defined in the RDFS
>spec).  This has now been fixed by the MT.

Not so much fixed as killed off. But yes.

>>  >2/ the conditions on domain and range
>>  No problems, we aligned that with the DAML usage several months ago,
>>  its in the issues document.
>Yes, this one has been fixed.
>>  >3/ properties with no formal meaning
>>  OK, so what? They have no meaning, you can do what you like. That's
>>  not a problem.
>On the contrary, such constructs are endless sources of problems when they
>occur in a specification.   Sure they cause no formal problems, but they do
>cause the generation of considerable amounts of non-luminous warmth.

That is a political issue, not one about the complexity of the 
language. (I tend to agree with you, by the way.)

>>  >4/ the extensibility mechanism
>>  What extensibility mechanism?
>RDFS Specification, Section 4. Extensibility Mechanisms, particularly
>4.2. Evolvability of the RDF Schema Constraint Mechanism.

We decided to toss this, cf. 

>>  >Now the RDF Core WG is trying very hard to address some of these sources of
>>  >complexity, but the end result, as far as I can see, is *not* going to be a
>>  >simple formalism.
>>  Well, like I say, a formal spec for RDF itself fits on a small 3x5
>>  card, and Ora has implemented an RDFS closure checker that runs on a
>>  cell phone. None of this seems very complex to me.
>Does this include the syntax for RDF?

Yes. Not for RDF/XML, but see above.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Monday, 18 February 2002 15:28:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:27 UTC