Re: Bugs in 2000/12 daml+oil reference on DAML collections

On January 12, Dickinson, Ian J writes:

I'll skip the stuff about typos in the reference document

[snip]

Good point about Disjoint.

The reason for the different use of List in Disjoint and oneOf is that
Disjoint is an axiom that makes an assertion about the elements of the
list, but which does not define a new class. Note that this affects
the semantic interpretation of each of the elements, but daml+oil does
not assign any semantics to the Disjoint class itself.

oneOf is not, by itself, an axiom: it is a class constructor.  It
builds a new class from the elements of the List and, only when it is
used as a property of a class C do we have an axiom asserting that the
interpretation of C is the same as the interpretation of the class
built by oneOf.

However, this doesn't solve the problem with the daml:collection parse
type. If daml:collection turns the enclosed elements into a List
structure, then it doesn't make sense to use it inside another list
without an intervening property. I don't like using equivalentTo (as
suggested by Dan) as the List itself doesn't have any semantics,
so its hard to see how it can be equivalent to anything. I would
suggest that a better way to do it would be:

 <daml:Disjoint>
   <daml:first rdf:resource="#Car"/>
   <daml:rest rdf:parseType="daml:collection">
     <rdfs:Class rdf:about="#Person"/>
     <rdfs:Class rdf:about="#Plant"/>
   </daml:rest>
 </daml:Disjoint>

Regards, Ian


> The second problem is that it would be nice if we could apply a simple
> syntactic transformation to remove the parseType daml:collection's
before
> parsing with a standard RDF parser (as suggested in the reference
document).
> This is made more difficult because parseType daml:collection is applied
to
> both properties and instances in slightly different ways.
>
> For example, the e.g. in the reference document uses the oneOf property.
The
> example translates:
>
> <oneOf rdf:parseType="daml:collection">
>   <Thing rdf:resource="#red"/>
>   <Thing rdf:resource="#white"/>
>   <Thing rdf:resource="#blue"/>
> </oneOf>
>
> to:
>
> <List>
>  <first>
>   <Thing rdf:resource="#red">
>  </first>
>  <rest>
>   ... elided for brevity ...
>  </rest>
> </List>
>
> Presumably, then, the final document contains (or should be interpreted
as):
>
> <oneOf>
>   <List>
>    <first>
>     <Thing rdf:resource="#red">
>    </first>
>    <rest>
>     ... elided for brevity ...
>    </rest>
>   </List>
> </oneOf>
>
> So the interpretation of the daml:collection attribute on a property is
that
> the _value_ of the property is a List.
>
> However, a disjoint axiom also has parseType daml:collection:
>
> <daml:Disjoint rdf:parseType="daml:collection">
>   <rdfs:Class rdf:about="#Car"/>
>   <rdfs:Class rdf:about="#Person"/>
>   <rdfs:Class rdf:about="#Plant"/>
> </daml:Disjoint>
>
> Since daml:Disjoint is a sub-class of List (which seems like an
engineering
> convenience rather than a deep statement about the domain of axioms and
> lists), presumably the correct interpretation is:
>
> <daml:Disjoint>
>   <first>
>     <rdfs:Class rdf:about="#Car"/>
>   </first>
>   <rest>
>     ... nested list of person and plant ...
>   </rest>
> </daml:Disjoint>
>
> I.e. the Disjoint instance itself takes the place of the outer List in
the
> content of the oneOf property, so the interpretation of daml:collection
here
> is that the axiom instance _is_ a list.
>
> The other alternative is that there should be an intervening property
> between the Disjoint axiom instance and the translated List (and by
> corollary, Disjoints contain lists but are not sub-classes of List), but
it
> is not clear what this property would be.
>
> Either way, a transformation to translate daml:collection's to the List
form
> can't be a context-free grammar at the XML level, since it's an RDF
> convention that distinguishes instances from classes from properties. At
the
> XML level they're all just elements.  And if we want to do document
> translation pre the RDF parse phase, the only interpretation level
available
> is XML.
>
> Comments welcome, espec

Received on Friday, 12 January 2001 12:54:46 UTC