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

Re: Patel-Schneider Paradox ...

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 15 Feb 2002 20:29:37 -0500
Message-Id: <p0510145eb893627dd9e9@[192.168.0.6]>
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 02:27:33 -0500
>
>>  >From: Dan Brickley <danbri@w3.org>
>>  >Subject: Re: Patel-Schneider Paradox ...
>>  >Date: Fri, 18 Jan 2002 17:00:34 -0500 (EST)
>>  >
>>  >>  RDF 1.0 was
>>  >>  kept pretty simple, and it isn't suprising that we're pushing at the
>>  >>  limits of what we can get done with such a simple 
>>representational system.
>>  >
>>  >>  Dan
>>  >
>>  >
>>  >I just cannot let this statement go by without registering the strongest
>>  >protest.
>>  >
>>  >I believe that RDF is *not* simple.  On the contrary, I firmly hold the
>>  >view that RDF is one of the most complex representation formalisms I have
>>  >ever encountered.
>>  >
>>  >Complexity is not (solely) measured by the amount of implementation effort
>>  >required to build a minimal parser for a language, although even building a
>>  >minimal parser for RDF is considerably more complex than building a minimal
>>  >parser for many representation formalisms.  Complexity also has 
>>to do with how
>>  >hard it is to understand the syntax of a representation formalism, how hard
>>  >it is to come up with an understanding of the basic principles of the
>>  >representation formalism, and how hard it is to determine just what the
>>  >constructs of the representation formalism mean, among other aspects.  In
>>  >all three of the above areas RDF is significantly more complex than most
>>  >representation formalisms.
>>  >
>>
>>  Well, I can't let that go by, either. (Let me see, how to phrase
>>  this....) Balls.
>>
>>  RDF is about as simple as a representational language could possibly
>>  be. It is first-order positive existential conjunctive logic
>>  restricted to binary relations. Period. (Oh, well, it also has
>>  datatyping for literals, but that isn't very complicated either.)
>>
>>  There is nothing complex or difficult about it. It is easy to map it
>>  into a conventional logical notation, and trivial to map it into KIF.
>>  Its entire proof theory can be captured in one lemma (see the MT
>>  document) and its model theory can be written on a postcard. Parsing
>>  the graph syntax can be done by a finite-state machine in one pass.
>>  If you can see any complexity in it, Peter, you must be smoking some
>>  really good ganja.
>>
>>  Pat Hayes
>
>If your statements above are true, then what is the RDF Core WG doing?

I take the 5th at this point. BUt seriously, its resolving all kinds 
of detailed issues to do with things like how to use URI fragments, 
how best to reconcile with XML character codes, all kinds of 
low-level stuff that needs to be done but isnt really germane to 
anything with any semantic depth. Datatypes took a long time, but 
were close to having that done; we've almost finished deciding to 
make reification so simple you could eat it with a spoon, and 
containers are going to be almost invisible.

OK, sometimes it takes a long time to pin down some simple stuff. And 
although the datatyping isnt really hard now it is done, it took a 
hell of a lot of work to sort out the simple answer from all the 
input and confusion.

>You and I may both agree that the understandable parts of the formal
>meaning of RDF is dead trivial.

Well, not trivial; but not *complex*. Java, now that is complex. OS-X 
is complex. But RDF ??

>However, there is lots more to RDF than
>that.  For example,
>
>1/ RDF reification - particularly as understood / used

So simple it is almost embarrassing.

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

>3/ RDF syntax - particularly some of the automatic reification components

There aren't any automatic reification components. :-)

RDF syntax is *really* easy, particularly now we can have tidy 
literal nodes. (A recent decision not reflected in the MT document 
yet.)

>
>To add to the above RDF M&S is vague, unclear, misleading, and
>self-contradictory, even in the ``formal'' parts, which only adds to the
>complexity of RDF.

The old documentation is a tangle, I agree. Thats largely what the WG 
is for, to sort out that mess. But there is a nice clean rock under 
the ivy and brambles.

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

>2/ the conditions on domain and range

No problems, we aligned that with the DAML usage several months ago, 
its in the issues document.

>3/ properties with no formal meaning

OK, so what? They have no meaning, you can do what you like. That's 
not a problem.

>4/ the extensibility mechanism

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

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

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Friday, 15 February 2002 20:29:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:47 GMT