Re: Patel-Schneider Paradox ...

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.

> >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
membership.

> >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.

> 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.

[...]

> >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.

> >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.

> >4/ the extensibility mechanism
> 
> What extensibility mechanism?

RDFS Specification, Section 4. Extensibility Mechanisms, particularly
4.2. Evolvability of the RDF Schema Constraint Mechanism.

> >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?  

> >So, I still maintain that RDF is an extremely complex representation
> >formalism, as is RDFS.  (Well maybe it would have been better to say that
> >RDF is an extremely complex specification, but I still say that RDF is an
> >extremely complex representation formalism.)
> 
> If you think RDF/S is extremely complex, I wonder how you survive 
> when looking at DAML+OIL, or even at Java.

Well Java is a programming language, with a very large set of libraries, so
the metrics to use are very different.  Also DAML+OIL is specified in
RDF(S) and much of its complexity derives from that. 

> Pat
[...]

Peter F. Patel-Schneider

Received on Saturday, 16 February 2002 15:17:37 UTC