From: Jeff Heflin (heflin@cse.lehigh.edu)
Date: 11/01/01
"Peter F. Patel-Schneider" wrote: > > The question here I think is whether, and where, ``soft'' constraints are > checked. (By ``soft'' constraints I mean things that are not forbidden in > the (current) model theory, but that might be modelling problems.) > > There are several options, which I will try to present in an absolutely > neutral fashion. :-) > > 1/ The big brother approach: > > The spec requires that all tools (UIs, reasoners, etc.) check all > ``soft'' constraints refuse to accept any input that violates a ``soft'' > constraint, or even has a modified MT where the ``soft'' constraints > cause inconsistencies. > > 2/ The hand-holding approach: > > The spec allows violations of ``soft'' constraints and does not require > that reasoners signal an error. However, UIs are required to signal > errors or warnings when soft constraints are violated. > > 3/ The UNIX approach: > > The spec is silent with respect to ``soft'' constraints. Reasoners are > required to behave correctly wrt the MT in the presence of violations of > ``soft'' constraints. UIs can, at their option, signal warnings or even > ``errors'' when ``soft'' constraints are violated, but it is made clear > that this is not something that the spec is concerned with. > > You can guess which option I prefer. > > The harm that I see in being too restrictive (options 1 and 2 above) is > that it can rule out some useful things. For example, suppose that there > is an rdfs:Class in some RDF KB and we want to provide a DAML definition > for it. This would be forbidden in option 1 above, and signalled in option > 2 above. Actually, this is not necessarily true. If you want to provide a DAML definition for an rdfs:Class from some other source, you can include a DAML statement that says it is a daml:Class in your own KB and then continue with your DAML definition. Since all daml:Classes are rdfs:Classes, this is still consistent with the model theory, while allowing the software to be sure that you really meant to treat this object as a DAML class. Therefore, the restrictions of options 1 and 2 still allow you to do what you want, they just require you to write one more RDF statement. > Another problem with ``soft'' constraints is that their status can depend > on ``fragile'' properties of the network such as the order that information > is received or the grouping of information. I think that it is reasonable to place certain constraints on the ordering of information. For example, I believe that in order to "understand" a resource that commits to an ontology, you must access all of the ancestors of that ontology. I don't think this is unreasonable, because each ontology explicitly identifies its parents, and a system can walk up the chain of imports to gather all of the relevant ontologies. As for ordering of access to resources, I agree we can't predict or enforce an order here. That's why I tend to fall on the "warning" or even "no message" side for things like violations of cardinality constraints, and on the "error" side for things like using an undefined class. I see the later as more of a "syntactical constraint" than a "soft constraint." Sure, RDF muddies things because in RDF metadata and data are all jumbled together, but I think some sort of distinction is still necessary, if for no other reason than to provide us with some additional syntactical constraints that help distinguish good DAML from bad DAML. > All that said, I have absolutely nothing against UIs providing > hand-holding, as long as such hand-holding is clearly mentioned as being > outside the spec, and there is a mode to turn off the hand-holding. > > peter
This archive was generated by hypermail 2.1.4 : 04/02/02 EST