Re: question about new-style RDF lists

>From: pat hayes <>
>Subject: Re: question about new-style RDF lists
>Date: Mon, 23 Sep 2002 12:02:20 -0500


>  > Now, this doesnt matter if that is being
>>  asserted by someone, since the assertion forces the list to exist.
>>  But the primary reason for introducing lists is to provide a
>>  technique for encoding syntax of other languages (as you know :-) and
>>  in that case - and in others - we want to be able to freely *infer*
>>  that lists exist. For example, consider the OWL entailment written in
>>  RDF:
>>  Peter rdf:type ex:Human .
>>  Peter rdf:type ex:Employee .
>>  |=
>>  Peter rdf:type _:x .
>>  _:x owl:intersectionOf _:l1 .
>>  _:l1 rdf:first owl:Human .
>>  _:l1 rdf:rest _:l2 .
>>  _:l2 rdf:first owl:Employee .
>>  _:l2 rdf:rest rdf:nil
>>  The OWL closure conditions guarantee that the intersection class
>>  exists, but they do not guarantee that the list exists (which the
>>  conclusion requires).
>But OWL could be written in a way that guarantees that such lists exist.

It could be, but what is the point? There are several problems with 
this approach, to my mind. First, and chiefly, there seems to be 
little point in introducing the list vocabulary into RDF if RDF does 
not provide a useful semantics for it which captures the intended 
intuitive meaning as far as possible. Second, all these various uses 
of the RDF list vocabulary should use it in the same way. If they do, 
then it just makes sense to incorporate that meaning into RDF. If 
they do not, interoperability will be severely compromised. Third, 
there is something wrong with a situation where a namespace is 
incorporated in one language but is requires to conform to a 
semantics imposed on it by a different language. It seems to me that 
when the decision was taken to change owl:List (etc) to rdf:List 
(etc), the responsibility for saying what this means was passed from 
OWL to RDF. And finally, I don't like basing technical decisions on 
loosely articulated subjective impressions about what the 'overall 
philosophy' is.

>>  In order for inferences like this to go through
>>  smoothly RDF needs to supply lists to order, as it were, even if they
>>  havn't been mentioned explicitly in any antecedents. 
>RDF doesn't need to do this.  Any other formalism using RDF lists could do
>this for itself.  As it would have to if it wanted to use RDF containers.
>>  And it seems to
>>  me that this 'supplying to order' is what the list vocabulary is
>>  usually taken to mean; one doesn't usually worry about whether lists
>>  exist: of *course* they exist, that goes without saying.
>But exactly the same thing could be said about bags and sequences. 
>RDF and RDFS do not provide preconstructed bags and sequences.

Well, the reason that it doesnt provide them is that there is no need 
for it to, given the rather odd style of container description in 
RDF. In an earlier draft of the RDF MT I did 'provide' them - the 
universe was required to contain all sequences of elements - until I 
realized that in fact the RDF container vocabulary does not actually 
mention containers at all. It would be harmless to include them, in 
fact, but nobody seemed to think that it was worth bothering with, 
and I tend to agree. As far as I know, nobody has suggested any use 
cases where one needs to infer the existence of RDF containers.

>>  Talking
>>  (slightly misleadingly) in terms of 'constructing' lists, this is
>>  like saying that its always kosher to construct any list you like:
>>  you don't have to worry that any list construction is illegal or
>>  forbidden. This seems to me to be just like the freedom one has to
>>  assert that a container property holds between anything and anything
>>  else.
>I see the analogy completely differently.  To me, the container properties
>of RDF are analogous to rdf:first, rdf:rest, and rdf:nil.

Right, one could take that view. But then I think incorporating the 
list vocabulary into RDF would be highly misleading. This vocabulary 
has a conventional meaning which is in widespread use, and which 
*does* incorporate a very strong existence assumption (one that goes 
well beyond the one I used: that all recursive functions over lists 
have a unique fixed point). So to use it in a simple, bare 
assertional mode is just going to lead to needless confusion and a 
failure to live up to expectations. And since it as easy to do it 
right as to do it wrong, why not do it right?

The only good argument I can see would be if someone wanted to clam 
that there was an intuitively reasonable use for the list vocabulary 
which did not conform to the stronger semantics, and I don't believe 
that there is. Even if one wanted, for some strange reason, to 
describe the dynamic workings of a LISP interpreter in RDF, that 
could be done by introducing a property on lists to express the fact 
that the list had been constructed.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

Received on Monday, 23 September 2002 16:28:42 UTC