Re: daml:item - still confused

Jim Hendler wrote:

> OK, history is we received a request from Bijan Parsia to add daml:item 
> to OWL.  I passed his mail to the group [1] - he explained that DAML-S 
> finds daml:item important because they need to be able to build "typed 
> lists".
>  Jeremy responded [2] to point out that if we added this it would be to 
> Full, not DL, since DL doesn't allow the use of lists.  Jeremy is 
> correct, but that doesn't answer the question - Bijan didn't ask to add 
> it to DL, he asked to add it to OWL (i.e. Full would address his issue).
>  Today I said on the telecon that I thought this related to the issue of 
> lists, and was told it didn't - but all the previous email about this 
> issue has been in the context of lists, and we have it indexed under 
> issue 5.5 which is the issue of lists.
>  So I would like to ask if anyone would actually oppose the addition of 
> owl:item to Owl Full.  Otherwise I will (in separate email) propose we 
> open issue 5.5, add to the closing text the inclusion of owl:item in Owl 
> Full, and then reclose the issue.
>   -JH

One (esthetic) reason for not having owl:item is that it breaks the 
"same-vocabulary" principle for OWL Full and OWL DL.

I must admit I'm somewhat in the dark about the meaning of daml:item. In 
the original DAML+OIL documentation (http://www.daml.org) the only 
description of daml:item I could find is in the following:

[[
<rdf:Property rdf:ID="item">
   <rdfs:comment>
     for item(L, I) read: I is an item in L; either first(L, I)
     or item(R, I) where rest(L, R).
   </rdfs:comment>
   <rdfs:domain rdf:resource="#List"/>
</rdf:Property>
]]

(I may be looking at the wrong documents, but is definitely not easy to 
find any sort of info on daml:item.)

I assume the definition in the comment slot is sloppy ("rest(L,R)" 
should be replace with a recursive defintion?!).

Bijan writes that he uses this to specify restrictions on list elements. 
I'm intersted to see an example. I tried to think of one for Reference, 
e.g. a list of opera's (note: didn't check the RDF/XML):

   1) without owl:item

   <rdfs:Class rdf:ID="OperaList">
     <rdfs:subClassOf rdf:resource="&rdf;List"/>
     <rdfs:subClassOf>
       <Restriction>
         <onProperty rdf:resource="&rdf;first"/>
         <allValuesFrom rdf:resource="#Opera"/>
       </Restriction>
     </rdfs:subClassOf>
     <rdfs:subClassOf>
       <Restriction>
         <onProperty rdf:resource="&rdf;rest"/>
         <allValuesFrom rdf:resource="#OperaList"/>
       </Restriction>
     </rdfs:subClassOf>
   </rdfs:Class>

   2) with owl:item

   <rdfs:Class rdf:ID="OperaList">
     <rdfs:subClassOf rdf:resource="&rdf;List"/>
     <rdfs:subClassOf>
       <Restriction>
         <onProperty rdf:resource="&owl:item"/>
         <allValuesFrom rdf:resource="#Opera"/>
       </Restriction>
     </rdfs:subClassOf>
   </rdfs:Class>

I agree 2) is neater, but I'm not sure it is worth the effort and the 
esthetic sacrifice.

Guus

PS. I actually encountered similr examples when writing a OWL schema of 
OWL, where notions like ClassList, IndividualList and LiteralList are 
needed to specify the range of intersection/unionOf and oneOf.

> 
> 
> [1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Jun/0290.html
> [2]
> 

-- 
Free University Amsterdam, Computer Science
De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands
Tel: +31 20 444 7739/7718
E-mail: schreiber@cs.vu.nl
Home page: http://www.cs.vu.nl/~guus/

Received on Tuesday, 8 July 2003 10:05:27 UTC