Re: Validating daml+oil-ex.daml

From: Peter F. Patel-Schneider ([email protected])
Date: 10/31/01

From: Jeff Heflin <[email protected]>
Subject: Validating daml+oil-ex.daml
Date: Wed, 31 Oct 2001 15:47:20 -0500

> Hi everyone,
> Some of my students have tried running the daml+oil-ex.daml example [1]
> through BBN's DAML Validator [2] and suprisingly received 27 indications
> of potential problems. Fortunately, many of these errors are due to
> limitations of the validation tool, but a few are errors in the example.
> Below, I discuss the errors found by the Validator, and for each suggest
> whether the bug is in the Validator or the example.
> 1) The Santa example creates an associatedData of type xsd:real, but XML
> Schema does not define a real datatype. This should probably be changed
> to xsd:decimal, xsd:float, or xsd:double in the example.

Changed to xsd:float.

> 2) The Person class has a restriction stating the a person can have only
> one FullTimeOccupation, but FullTimeOccupation is not defined in the
> ontology. The FullTimeOccupation class should be added to the ontology.

It probably should be, but it is not strictly necessary, as its position in a
restriction makes it an rdf:Class.

> 3) BigFoot is an rdfs:Class instead of a daml:Class. However it is used
> in the domain of intersectionOf, which requires a daml:Class, generating
> a domain type mismatch error. The example should be changed.

Again, things are OK as they are, as the domain restriction on BigFoot will
``force'' it into daml:Class.

> 4) The Validator raises an error because hasMom is samePropertyAs
> hasMother, but hasMom is an ObjectProperty and hasMother is a
> UniqueProperty (which could be an ObjectProperty or DatatypeProperty).
> Personally, I don't think this should be an error; it should only be an
> error if you say an ObjectProperty is samePropertyAs a DatatypeProperty.
> I'd like to get the committee's opinion on the situation.

Indeed --- not an error, should not be an error, and there is absolutely no
reason to consider it an error.  :-)

> 5) The Validator raises errors anytime a cardinality restriction is
> violated. In the case of the example, this is mostly because Adam,
> Santa, Peter, and Ian do not have any parents mentioned. I don't think
> an error should be raise here, because other values for the property may
> be found on other web pages. One possibility, is to raise an error only
> when a maximum cardinality constraint is violated, but even in this
> case, it is possible that an as yet undiscovered equivalentTo property
> will be found, reducing the total number of distinct values. Therefore,
> I suggest that all violations of cardinality constraints be presented as
> warnings (not errors), but would like feedback from the rest of the
> committee.

The condition signalled as an error here is not even worth making a warning

The other condition is also not an error, but it might be worthwhile to
issue a warning.  (By the way, it is not the case that extra equivalentTo's
would move this from an ``error'' to a ``non-error''.  If there are no
equivalentTo's then there must be some equivalence between the ``fillers'',
but it is not an ``error''.) 

> 6) The Validator generates a number of errors because it doesn't support
> the daml:collection parse type yet. Hopefully, that will be fixed in the
> near future.

Hopefully by getting rid of daml:collection parsetype.  :-)

> What this situation indicates to me, is that we need a much clearer
> description of exactly how should treat a DAML document, i.e., what
> results in an error, what results in a warning, etc. Do you think this
> is an issue for the Joint Committee or the WebOnt working group?

There already is a precise description of when to signal an error ----
never!  [:-), but only partly!]  As long as the syntax is correct, there
is no reason to signal an error.

As an aid to (fallable) humans creating DAML+OIL KBs, the software might
consider signalling the following conditions:

1/ an inconsistency, as exactly determinable from the model theory
2/ an incoherent class, as exactly determinable from the model theory

3/ a situation where some unusual consequence follows, such as the too-many
   fillers example above, but this is not determinable from the model theory

However these are not really errors!

> Jeff


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