From: Jeff Heflin (heflin@cse.lehigh.edu)
Date: 11/01/01
Peter, Thanks for you point-by-point responses. I've included my responses inline below. "Peter F. Patel-Schneider" wrote: > > 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. See my reply to Frank concerning my opinion on this. > > 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. As with 2 above, I don't really see the benefit of this kind of inference. Sure, I understand that it's sanctioned by the model theory, but I just don't think it's useful in a practical sense. If someone (who doesn't understand DAML very well) tries to use intersectionOf with a particular property (instead of a class) as the domain, then this would mean that we should infer that the property is also a class! This seems very dangerous to me. What harm is done in being a stickler about explicit types in this case? > > > 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. :-) What about the case where someone says an ObjectProperty is samePropertyAs a DatatypeProperty? Aren't ObjectProperty and DatatypeProperty supposed to be disjoint? (Interesting, I just noticed that we don't make that explicit in daml+oil.daml). > > 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. I don't know. I think a useful feature in a validator would be the ability to say "Determine the validity of this set of documents if we treat them as a closed world." In such a test, this would be a useful condition to know. Obviously, it would be annoying if issued as a standard warning, but I think it would be a good user option. I know I'm starting to get into implementation details here, but from the language specification level, I think it is important to identify different "compatibility levels" and what constitutes errors and warnings in each. > 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''.) Yes, I understand this point. Sorry for my sloppy use of language. As with an earlier point, I am concerned with what happens when people make mistakes. If the cardinality of president is 1, and different sources say president(USA, Bush) and president(USA, SnoopDog), then you are saying we must infer that Bush and SnoopDog are the same individual. But this doesn't take into account the possibility of errors! Maybe one of the data sources was unreliable (I'll let you guess which one ;-). Or maybe the ontology that said the cardinality of president was 1 is wrong. There are many possible answers, and a machine probably can't successfully choose the right one. Therefore, I think some sort of warning would be useful in these cases. > > 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