From: Peter F. Patel-Schneider ([email protected])
Date: 11/01/01
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
This archive was generated by hypermail 2.1.4 : 04/02/02 EST