From: Deborah McGuinness (dlm@ksl.stanford.edu)
Date: 11/01/01
I endorse option 3 below but want to make clear that my interpretation of option 3 means that it is a strong feature of the bbn validator and of chimaera that they check for "soft" constraints. I have found with almost all of our passes over ontologies that soft constraint "violations" are a source of issues that need human cycles to look at them to either fix them or confirm that they are meant. Chimaera has the option to run particular tests so for example, you can not run cycle detection (which is another soft constraint - it is not incorrect to say A is a subclass of B and B is a subclass of A but it is usually not something one wants in a kb). That said, when i create knowledge bases, i try not to leave in uses of terms that are not defined. As everyone points out, it is not an error but it can be a source of evolution problems especially in a case where there is distributed ontology evolution going on. I understand in a pedagogical tool, it can be useful to maintain one example of this and to point out in text that this is a feature of the language, but i would not intentionally put in more than one of each case of this example. Deborah "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. > > 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. > > 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 -- Deborah L. McGuinness Knowledge Systems Laboratory Gates Computer Science Building, 2A Room 241 Stanford University, Stanford, CA 94305-9020 email: dlm@ksl.stanford.edu URL: http://ksl.stanford.edu/people/dlm (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 0941
This archive was generated by hypermail 2.1.4 : 04/02/02 EST