Integrity constraints in DAML-O (was: Chainsaw?)

Sorry for crossposting, I believe this topic is directly related to
DAML-O.

Graham Klyne wrote:
> 
> Folks,
> 
[...]
> I'm still having problems with finding a sufficiently flexible
> mechanism to bind "prototype" statements into an instance of some
> class.  The solutions I've seen posted so far assume that the statements
> apply directly to an instance of the class in which they are defined.  I
> think this is too restrictive for defining complex relationships and
> prototyping structures;  e.g. Tom (if Iunderstand correctly) has proposed
> something like:
> 
>     [FordEscort] --rdf:type---> [rdfs:Class]
>     [          ] --bodyStyle--> "HatchBack"
>     [          ] --fuelType---> "Petrol"
> 
> and
> 
>     [MyCar] --rdf:type--------> [FordEscort]
>     [     ] --bodyColour------> "Red"
>     [     ] --engineCapacity--> "1600"
> 
> to create a description meaning something like:
> 
>     [MyCar] --bodyStyle-------> "HatchBack"
>     [     ] --fuelType--------> "Petrol"
>     [     ] --bodyColour------> "Red"
>     [     ] --engineCapacity--> "1600"
> 
> This simple approach works only when the properties defined in the
> [FordEscort] prototype are applied *directly* to an instance of that
> prototype.  In some of the modelling work we have tried to do, this kind of
> direct linkage of all properties to an instance of a type is too
> constraining to be practically useful.  This is one of my motivations for
> trying to use contexts, so that I can create a high-level description of
> MyCar and subsequently refine the parts:
> 
>     [MyCar] --rdf:type--> [FordEscort]
>     [     ] --asserts--->
>       {
>       [TheBody] ----colour----> "Red"
>       [TheEngine] --capacity--> "1600"
>        :
>       (etc.)
>       }
> 
> (Using here the notation "[<context>] --asserts--> {<StatementSet>}" to
> capture the idea of a collection of reifications of statements that are
> asserted to be true in the subject context.)
> 
> This structure allows us to make statements about entities that may be
> directly or indirectly related to [MyCar], without necessarily having to
> know up-front the nature of that relationship.  It allows us to make
> statements about what we know, without having to make up arbitrary (and
> probably flawed) statements about what we don't know.  It is my conviction
> that enabling such an incremental approach to information modelling will be
> extremely powerful for dealing with complex relationships.
> 
> So, what's missing?  It comes back to defining ways to relate prototype
> statements to a specific instance of a class.  Brian has made an
> imaginative proposal, based on a "logic" of type matching between the
> prototype and the instance context.  I feel this is still to restrictive.
> 
> I am thinking about the discussion of "anonymous" resources, and also
> comments made by Pat Hayes on the RDF-logic list
> <http://lists.w3.org/Archives/Public/www-rdf-logic/2000Oct/0112.html>,
> <http://lists.w3.org/Archives/Public/www-rdf-logic/2000Oct/0122.html>.  I
> think Pat has it right:  that what is required is a way to introduce
> "proper names" that have a common (but unspecified) referent within some
> range of use (not lexically defined), and which may be bound to different
> globally unique names (URIs) in different contexts.
> 
> This would lead to my example becoming something like this:
> 
>     [FordEscort] --rdf:type---> [rdfs:Class]
>     [          ] --rdf:Type---> [Context]
>     [          ] --asserts---->
>       {
>       [Body] ----style-----> "Hatchback"
>        :
>       [Engine] --fuelType--> "Petrol"
>        :
>       (etc.)
>       }
> 
>     [MyCar] --rdf:type--> [FordEscort]
>     [     ] --asserts---> [FordEscort]
>     [     ] --asserts--->
>       {
>       [Body] -------bindTo----> [TheBody]
>       [Engine] -----bindTo----> [TheEngine]
>        :
>       [TheBody] ----colour----> "Red"
>       [TheEngine] --capacity--> "1600"
>        :
>       (etc.)
>       }
> 
> (The presentation is clumsy;  at this time I am merely trying to illustrate
> the idea of binding proper names used in one context to specific resources
> described in another.)
> 
> Here, the property 'asserts' with a context as its object is used to state
> that all statements asserted in the object context are also asserted in the
> subject context.  The 'bindTo' property is used to assert an equivalence
> between two names (within the context containing that assertion).
> 
> All this presupposes the introduction of a resource identifier form along
> the lines of "proper names", which may be regarded as a departure from
> conventional RDF/WEB thinking.
> 
> #g
> ------------
> Graham Klyne
> (GK@ACM.ORG)

Graham,

I completely agree with you that having a schema-based mechanism for
specifying default values for class instances (similar to static
variables in languages like C++ and Java) is extremely useful. In fact,
DAML-O has a limited facility for expressing that.

Your first example could be addressed in DAML-O by defining a
hasValue-Restriction on property bodyStyle for class FordEscort (this
roughly corresponds to declaring a static final variable for a Java
class). However, in my understanding, the more complex examples that you
mentioned can be tackled in DAML-O only in a relatively clumsy way.
You'd have to define classes like FordEscort_Body and FordEscort_Engine,
require that every FordEscort has exactly one FordEscort_Body and
FordEscort_Engine, and attach corresponding hasValue-Restrictions to
FordEscort_Body and FordEscort_Engine.

Moreover, there are a lot of situations where it gets even clumsier and
specialized subproperties are required to express schema constraints.
For example, imagine we want to make sure that every car has exactly
four wheels and that every wheel has a wheelID that identifies the
location of the wheel (e.g. "FL", "FR", "RL", "RR"). Furthermore, a car
must have at most one front left, rear left etc. wheel.

As far as I can see, the only way to express it in DAML-O would be to
create 4 subclasses of Wheel (WheelFL, WheelFR, WheelRL, WheelRR) with
corresponding hasValue-Restrictions and 4 subproperties of hasWheel
(hasWheelFL, hasWheelFR, hasWheelRL, hasWheelRR). Obviously, this
approach is far from elegant. (Is there another one?)

Another option would be defining rules in logical constraint language
(DAML-L?) to handle cases like that. The wheel example could be
specified as

[Car] --rdf:type--> [rdfs:Class]
[Car] --damlO:restrictedBy --> [R001]
[R001] --rdf:type--> [damlL:Expression]

whereas R001 would represent a conjunction of primitive existential
expressions like

X  rdf:type Car
X  hasWheel W1
X  hasWheel W2
X  hasWheel W3
X  hasWheel W4
W1 wheelID "FL"
W2 wheelID "FR"
W3 wheelID "RL"
W4 wheelID "RR"
 
Combined with cardinality restrictions on wheelID [1, 1] and hasWeel [4,
4], the above constraint would help to avoid creating 8 unnecessary
language elements (4 classes and 4 properties). Your second example

>     [FordEscort] --rdf:type---> [rdfs:Class]
>     [          ] --rdf:Type---> [Context]
>     [          ] --asserts---->
>       {
>       [Body] ----style-----> "Hatchback"
>        :
>       [Engine] --fuelType--> "Petrol"
>        :
>       (etc.)
>       }

could be expressed similarly as

[FordEscort] --rdf:type--> [rdfs:Class]
[FordEscort] --damlO:restrictedBy --> [R002]
[R002]       --rdf:type--> [damlL:Expression]

with R002:

X rdf:type FordEscort
B rdf:type Body
B style    "Hatchback"
E rdf:type Engine
E fuelType "Petrol"

(As you suggested, the relationship between the car, its body and its
engine is not made explicit).


The eternal problem with integrity constrains is the complexity. It
should be trivial *both* to check the consistency of models with respect
to a given set of schemas *and* to support graphical editing tools that
could, for example, automatically instantiate objects whose existence is
implied by the schema.

It looks to me that cardinality and conjunctions of existential
statements is both relatively expressive and easy to deal with.

Would it make sense to have this capability in DAML-O? Should this go
into DAML-L?

What should implementors use right now in their ontologies?

Sergey

Received on Thursday, 2 November 2000 21:06:07 UTC