Re: Validating daml+oil-ex.daml

From: Peter F. Patel-Schneider (
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.


This archive was generated by hypermail 2.1.4 : 04/02/02 EST