Re: DAML: restricting number of elements in a list

On February 11, Steven Gollery writes:
> Ian,
> 

Steven,

The language aims to provide only basic building blocks and leaves it
up to the user to determine how they want to represent more complex
concepts (like order) - as I mentioned in earlier email, you can
represent (some aspects of) order in a variety of ways, e.g., by
describing your own list structure.

Ian

> It seems to me that the concept of "order" is fundamental in describing
> elements of many ontologies. Why was the decision made not to include this in
> DAML?
> 
> Steven Gollery
> 
> Ian Horrocks wrote:
> 
> > On February 6, Steven Gollery writes:
> > > I'm working on an ontology in DAML that includes some geometric
> > > concepts. I would like to be able to somehow define a property Vertices
> > > whose domain is the Polygon class and whose range is ordered collections
> > > of instances of the Point class, where the length of the ordered
> > > collection is at least three.
> > >
> > > It would be fairly straightforward to say that each Polygon must have at
> > > least three values of a Vertex property which is restricted to class
> > > Point, but that would lose the idea the vertices have an order -- the
> > > order is obviously a fundamental part of the semantics for the polygon.
> > >
> > > Does DAML provide any way to restrict the number of elements in a list?
> > > Or is there some other way to do what I need here?
> >
> > There is no language construct that supports this - properties of a
> > DAML class are always unordered. One possible solution is to make the
> > range of Vertex a more complex structure that describes both the point
> > and its place in the list. This is not completely satisfactory as it
> > is difficult to ensure that the list values are sensibly ordered.
> >
> > Another solution is to define subproperties of Vertex called Vertex1,
> > Vertex2 etc., each being a unique property (i.e., functional). The
> > main disadvantage with this method is that the maximum number of
> > vertices must be decided a priori. Ensuring that values are sensibly
> > ordered is a little easier in this case because the functionality
> > already precludes the case where there is more than one vertex with
> > the same number. Simply asserting, for each n from 2 to the max vertex
> > number, that the existence of the property Vertexn implies the
> > existence of the property Vertexn-1 should be enough to ensure that
> > there are no "gaps" in the list of vertices.
> >
> > Hope this helps.
> >
> > Ian Horrocks
> >
> > >
> > > Thanks in advance,
> > >
> > > Steve Gollery
> > > sgollery@cadrc.calpoly.edu
> > >
> > >

Received on Tuesday, 19 February 2002 10:55:18 UTC