Re: New version of walk-through available

From: Ian Horrocks ([email protected])
Date: 12/26/00


On December 24, Frank van Harmelen writes:
> 
> Dear joint-everybody,
> 
> The location http://www.cs.vu.nl/~frankh/spool/DAML+OIL now contains exactly the same files as in Ian's earlier announcement of the DAML+OIL material, with two changes:
> 
> - a new version of the annotated example has been added (walkthru.html)
> - the example itself (daml+oil-ex.daml) has been changed in various places to allow better exposition of the language featurs. 
> 
> You can inspect the changes quite easily:
> 
> All the interesting changes in the walkthrough in  http://www.cs.vu.nl/~frankh/spool/DAML+OIL/daml+oil-walkthru.html are marked in grey. (There are many more smaller changes in sequence and formulation of the material, but I've only marked those which are of major importance).
> 
> All the interesting changes in in the example in 
> http://www.cs.vu.nl/~frankh/spool/DAML+OIL/daml+oil-ex.daml are marked with comments labelled "FvH". Again, I've only labelled the important changes. 
> (Use "view source" if your Netscape only appears to show you an empty file). 
> 
> After receiving your feedback I will make any requested amendments, remove the change-annotations, and then the material is ready for release. 
> 
> By that time, I also hope to have a reference document ready. This should be an amended version of the OIL white paper, which is a systematic description of all the language elements. 

Frank,

1. I notice that you didn't change the domain restriction on "height"
(currently "Person"). I think that this is a mistake because, as I
showed in Washington, skyscrapers end up being either inconsistent (if
Building and Person are disjoint) or a sub-class of Person. At the
very least the property should be renamed to something like
personHeight.

2. As I already mentioned to you, the "spouse" example is a bad one
because it implies that persons can have many spouses, provided that
only one of them is a Person. It is hard to come up with good examples
of cardinalityQ constraints - how about a structural example such as
"a person can have at most 2 limbs of type Leg"? Another possibility
would be to have a Class "FullTimeOccupation" and state that a person
can have at most one FullTimeOccupation (but maybe several part time
jobs).

3. About UnambiguousProperty. We could of course infer that the
inverse of a UniqueProperty must be an UnambiguousProperty (in fact
having both kinds of property is redundant). Maybe we should mention
this. Maybe we should use an example where the UnambiguousProperty
statement isn't redundant (because we don't already know that the
inverse is Unique).

Ian


This archive was generated by hypermail 2.1.4 : 04/02/02 EST