Re: Validating daml+oil-ex.daml

From: Jeff Heflin (
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