Re: UPDATE: why RDF syntax is not suitable for OWL

>Here are my current thoughts on why OWL should not use the same syntax as
>RDF,

Is anyone suggesting that OWL should actually *use* RDF syntax?? Or 
did you mean, why OWL syntax should not be encoded or described in 
RDF (??)

>no matter what we do with the semantics.
>
>Peter F. Patel-Schneider
>Bell Labs Research
>
>
>
>		Why Triples are Terrible for Syntax
>
>
>Summary:  RDF containers, RDF reification, and DAML+OIL syntax all show
>	  that triples are terrible for syntax.
>

Neat slogan, but it misses the target. See below for comments.

>Triples, at least RDF triples, are terrible for representing syntax.
>These triples have all the wrong properties for representing syntax.
>1/ They only allow three pieces of information to be collected into an
>    atomic entity.
>2/ There is no grouping of triples possible.

Thats a problem (inadequacy) of current RDF, but its not inherent to 
the idea of using triples.

>3/ There is no way to close off access to a triple.

? what does that mean? (Do you mean, no way to have an unasserted 
triple? If so, I agree.)

>4/ All triples are independent.
>
>
>An RDF triple consists of three pieces, generally thought of as the
>subject, predicate, and object of the triple.  Triples are collected into
>documents, with no internal structure besides the enclosed collection of
>triples.
>
>To create larger syntactic units, a group of triples has to be used.

True. And a better version of RDF would provide a grouping primitive. 
This is widely recognized both in and outside the RDF world, and many 
people building RDF tools already provide it in some form. Its not in 
RDF 1.0 - OK, WGs move slowly, and they have narrowly written 
charters - but I bet it will be in RDF 2, when that WG gets started.

>This is done in RDF containers, where a collection of triples is used to
>create a sequence or bag.

That is a terrible way to do grouping, largely because RDF 
'containers' are actually *descriptions* of containers. There are 
much better ways already in use. My own favorite (given the 
limitations of current RDF) is the one used by Jos DeRoo, which is so 
simple and obvious that someone should give it a prize: you put the 
triples you want to 'group' into another document, and use the uri of 
the document to identify the group. (Compare the use of jpegs in 
HTML.)

>  In essence, one RDF resource is used to
>represent the sequence or bag, and it is related to its elements by
>triples, each of which has the collection resource as its subject, one of a
>sequence of special resources as its predicate, and a collection member as
>its object.
>
>RDF containers have caused lots of problems.

True, but that says something about RDF containers, not about triples 
or even about grouping as such.

>  Because the special predicate
>resources identify the ``position'' of the element in the collection it is
>possible to have collections that are missing their ``first'' element.
>Because there is no way of preventing the addition of more of these
>triples, it is impossible to state that all the elements of the collection
>have been given. 
>
>For example, one document can have
>
>	x:foo rdf:type rdf:Bag .
>	x:foo rdf:_2 y:John .
>	x:foo rdf:_3 y:Susan.
>
>which is missing its ``first element''. Another document can augment x:foo,
>as in
>
>	x:foo rdf:_1 y:Mary .
>
>to result in a completed bag.  Yet another document can augment x:foo
>further, as in
>
>	x:foo rdf:_4 y:Joseph .
>	x:foo rdf:_3 y:Andrew .
>
>There is no way of determining the elements of this bag, as they can always
>be augmented.

Again, true but one can easily hack around it, eg by including a 
'last' element (compare LISP nil) and ignoring anything past that. 
BTW, calling it a bag is just verbiage: all RDF containers in fact 
*are* linearly ordered sequences as far as RDF is concerned.

BUt in any case, using RDF containers to do grouping is a terrible 
idea in any case. That is the one place where DAML seriously screwed 
up in aligning itself with RDF, in my view (I was partly responsible, 
BTW, but I didn't see all the problems at the time.) But OK, lets put 
that screw-up behind us, and keep it in perspective. So we made a 
Pinto: that doesn't mean that all cars are bad.

>RDF reification also uses a collection of triples, four in this case.
>A reified statement is represented by a resource.  This resource has
>four triples; one giving rdf:Statement as the rdf:type of the resource, and
>three more identifying the subject, predicate, and object of the resource.
>
>Again, RDF reification has caused lots of problems.  Because the four
>triples are independent, it is possible to have a reification without a
>subject, predicate, or object.

That is perfectly OK. The reification is a description, so of course 
it can be incomplete.

>To prevent multiple subject, predicates, or
>objects, there is a special condition on reified statements that they can
>have only one subject, predicate, or object triple.

There is? Where is that stated in the RDF specs??

>This breaks the
>general RDF model, and is only possible for concepts that are
>defined in RDF itself, not for additions to RDF.
>
>For example,
>
>	x:s1 rdf:type rdf:Statement .
>
>is illegal in RDF, as it does not have the required three properties.
>Similarly
>
>	x:s2 rdf:type rdf:Statement .
>	x:s2 rdf:subject y:subject .
>	x:s2 rdf:object y:object .
>	x:s2 rdf:predicate y:predicate1 .
>	x:s2 rdf:predicate y:predicate2 .
>
>is illegal, but, again, only because there is special wording in the RDF
>M&S that makes it so.

There is certainly no such requirement in the model theory, and I 
don't expect there ever will be. I think this is a non-problem, in 
any case, since even if there were such a requirement on RDF 
reifications, it would not apply to reifications of non-RDF syntax. 
You are free to invent an RDF namespace for describing OWL syntax if 
you want: go ahead, RDF won't mind.

>DAML+OIL uses its own lists in its syntax.  These lists are members of a
>special class, List.  A list is either the empty list or has a first
>element and a remainder.

Exactly; those are part of the DAML syntactic theory.

>DAML+OIL lists have several problems.  It is possible to create a list
>without a first element or a remainder.  It is possible to create lists
>with several first elements or several remainders.

This is misleading. RDF doesn't 'create' anything; it only describes 
things. It is possible to say damn silly things in RDF about lists, 
just as it is possible to say silly things about, say, elephants. So 
what? How could it be otherwise? A description language cannot 
prevent people from saying nonsense in it.

>For example,
>
>   x:foo daml:intersectionOf x:list .
>   x:list daml:first x:Person .
>   x:list daml:first x:Rock .
>   x:lsit daml:rest daml:nil .
>
>has a list with two first elements.

It asserts that such a thing exists, but it's probably wrong. So 
what? It wouldn't be hard to write a special-purpose checker that 
could look out for such special kinds of nonsense and flag them or 
complain about them.

>Some DAML+OIL syntax constructs work like RDF reification.  The construct
>is represented by a resource that is a member of a special class.  There
>are several triples, each of which have that resource as subject, that
>together embody the construct. 
>
>Again, this sort of construction has problems because of the properties of
>triples.   First, some of the triples can be missing

That isn't a problem with triples; its a problem with ANY descriptive 
language. You could describe DAML syntax in higher-order logic with 
functional types, and you would still be able to have some things 
'missing' in this sense. Monotonic assertional languages are like 
that.

>, so, for example, it
>is possible to create a hasClass restriction without a property.

Don't say 'create'. It is possible that a description is incomplete. 
That is a basic fact of Tarskian semantics. So what is your point??

>Second,
>there can be multiple triples, so, for example, it is possible to create a
>hasClass restriction with two properties or two classes.
>
>For example,
>
>    x:foo rdf:type daml:Restriction .
>    x:foo daml:onProperty x:age .
>    x:foo daml:hasClass x:c1 .
>    x:foo daml:onProperty x:shoesize .
>
>is a possible restriction, which has an unusual meaning.
>
>
>None of the above problems are really solvable using RDF triples.  A much
>better syntax carrier would allow syntax to be represented as tuples or,
>even better, as trees.

That would be irrelevant to the above points. What you are really 
complaining about is not triples versus trees/tuples, but the use of 
a *descriptive* language in a place where what you want is a 
*computational* specification. It is possible (not sanctioned by the 
MT, but possible) to look at triple stores as a computational system 
also - a datastructuring tool, basically - and then all the above 
worries go away, because its not hard to write code that can ensure 
that the 'bad' cases don't arise or are flagged in some way. So the 
issue is not triples versus tuples versus trees - that's a battle of 
programming style, basically, and while it might be fun, its 
basically a matter of taste with no clear winners. The real issue 
here is whether it makes sense to "implement" a syntax by 
*describing* it in assertional language. There I think the answer is 
probably NO, but that requires a different way of tackling the 
OWL/RDF relationship. I don't think the real issue has anything much 
to do with triples; and since so many people like triples, then why 
not let 'em use 'em, I would suggest.

Pat Hayes

PS Sorry  Ive not been reading webont emails fast enough lately. Ive 
been snowed under with RDFcore stuff.



-- 
---------------------------------------------------------------------
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 01:50:22 UTC