Re: DAML: restricting number of elements in a list

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Tue, 12 Feb 2002 11:13:35 +0000
To: "Andrei S. Lopatenko" <andrei@derpi.tuwien.ac.at>
```On February 11, Andrei S. Lopatenko writes:
>
> Would it be a right way
>    create class
> VertexInPoligon  subClassOf Vertex
> with   property connectsTo   - range VertexInPoligon
> So we can create an ordered list of Vertexes
> Then class Polygon also has property connectsTo which points to the first
> vertex in ordered list of vertexes for polygon
> Property connectsTo must be transitive
> And for class Polygon mincardinality of connectsTo is three.
> So an ORDERED list of vertexes is supported and cardinality is supported as
> well
>
> The only problem in such schema one VertexInPoligon can connects to a few
> other Vertexes. Due to transitivety of property it would be wrong to say
> maxcardinality connectsTo is one for VertexInPoligon
> As far as I understand due to transitivity of connectsTo it is imposible to
> request to which VertexInPolygon Polygon connects first. But taking all
> Vertexes of given polynom and relation connectsTo between them such order
> can be easily reconstructed assuming that there no cycles and wrong
> assertation which are not really prohibit in this schema

constructs. This is possible, but I think that the best way is to
define a non transitive "next" property. If you want to get at the
whole list you can also define a transitive super-property called,
say, "rest". You can't, however, use transitive properties in
cardinality restrictions (see "small print" in language spec - this
leads to undecidability) so to impose the min 3 constraints you should
simply use a hasClass restriction of the form:

(restriction on next hasClass (restriction on next hasClass
(restriction on next hasClass VertexInPoligon)))

Note that next should be a unique (functional) property in order to
make sure that it is a list and not a tree.

Ian

>
>
> <daml:Class rdf:ID="VertexInPolygon">
>     <rdfs:subClassOf rdf:resource="#Vertex">
> </daml:Class>
>
> <daml:TransitiveProperty rdf:ID="connectsTo">
>     <rdfs:Range rdf:Resource="#VertexInPolygon"/>
>     <rdfs:Domain>
>         <daml:unionOf>
>         </daml:unionOf>
>     </rdfs:Domain>
> </daml:TransitiveProperty>
>
> <daml:Class rdf:ID="Polygon">
>   <rdfs:subClassOf>
>     <daml:Restriction daml:minCardinality="3">
>       <daml:onProperty rdf:resource="connectsTo"/>
>     </daml:Restriction>
>   </rdfs:subClassOf>
>  </daml:Class>
>
>
> Best regards
> MSc Andrei S. Lopatenko
> Researcher
> Vienna University of Technology
> A chairman of CERIF Task Group
> euroCRIS conc.
> http://purl.org/NET/andrei
>
>
> ----- Original Message -----
> From: "Ian Horrocks" <horrocks@cs.man.ac.uk>
> Cc: <www-rdf-logic@w3.org>
> Sent: Saturday, February 09, 2002 6:36 PM
> Subject: Re: DAML: restricting number of elements in a list
>
>
> > 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