From: Peter F. Patel-Schneider (pfps@research.bell-labs.com)
Date: 10/31/01
From: Jeff Heflin <heflin@cse.lehigh.edu> 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 for. 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 peter
This archive was generated by hypermail 2.1.4 : 04/02/02 EST