W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2001

Re: Domain/Range: conjuntion or disjuntion??

From: Wolfram Conen <conen@gmx.de>
Date: Thu, 22 Nov 2001 00:45:30 +0100
Message-ID: <3BFC3C9A.A70AB20D@gmx.de>
To: Arjohn Kampman <akam@aidministrator.nl>
CC: www-rdf-interest@w3.org
Hello Arjohn,

allow me to briefly point out why I think that the issue of
discuntive/conjunctive interpretation of domain/range is only loosely
attached to the subProperty consideration (is, in fact, somewhat
orthogonal to it).

You wrote (with the correction applied)

> Marc,
> One of the reason for changing RDF Schema on this issue is that using
> the conjunction view can lead to inconsistencies when combined with
> multiple inheritance. A small document that we wrote about this in
> April of this year can be found at:
> http://sesame.aidministrator.nl/doc/rdf-interpretation.html
> Chapter 4 is about the rdfs:domain and rdfs:range properties.
> I hope this will convince you that conjunction is the way to go, even
> though it has some drawback from a modelers point-of-view.
> Cheers,
> Arjohn

Assume the following situation:

p1 and p2 are properties, the range of p1 is restricted to the Class
C1, the range of p2 is restricted to the class C2. Now, p is a
subproperty of both properties:

 p1 -range-> C1                     p2 -range-> C2
  ^                                 ^
   \                               /
    subpropertyOf- p -subPropertyOf

Now, if s --p--> o is added, the subproperty-rules force us to add
s--p1--> o and s-->p2-->o as well. 

Now, let us split our considerations - first, we will assume that the
range is meant as an integrity constraint. Then: if o is not a member of
the intersection of C1 and C2 (determined from some type/subClassOf
information elsewhere related to o), the range constraints of one or
both of the properties p1 and p2 will be violated - which is a
consequence of, for example, the subProperty/range violation rules in
our old "logical interpretation" paper. This, I think, is also the
behavior that should be expected if one adopts the "integrity constraint
view". In so far, it is quite justified to speak of a "conjunctive
interpretation" of the range constraints WITH RESPECT TO MULTIPLE
SUPERPROPERTIES -- however, this is not immediately related to ATTACHING

Here is why: Let us examine this based on the above example. Assume that
you attach two range constraints to p, let's say: p -range-> D1 and p
-range-> D2. Now, with any interpretation (let me list some potentially
reasonable: D1 n D2 [conjunctive], D1 u D2 [disjunctive], (D1 u D2) /
(D1 n D2) [exclusive]), the questions for a triple [s p o] remain the
    (1) (upward-propagation of o): is o in C1 and in C2?
and (2) is o in D? (where the "class" D denotes the result of the
intended class expression)

Note that this does not imply that it is required that D is a subset of
C1 and C2. It is only required that every object of a triple with p as
predicate is a member in all classes, C1, C2 and D (The former would be
a sufficient condition but it is not necessary). This is independent of
the way C1, C2 or D are formed. That is to say that, no matter which
interpretation is given to multiple range constraints, the "implicit"
constraint for the range of a subproperty with multiple superproperties
(also with one superproperty, of course) remains unchanged, or, in other
words, one may follow an argumentation for disjunctive range constraints
in perfect accordance with the requirement of the implicitly conjunctive
range constraint for subproperties. Does that sound reasonable to you,


PS: If we look at the "type inference" interpretation, the following
happens: if we add  s -p-> o, we have to add s -p1->o and s-p2->o again,
forcing/allowing us to infer that o is of the type C1 and of the type
C2. (the same information that we would have above about o if no range
constraints is violated, only this time, nothing could ever be violated
so no integrity could be checked).
Received on Wednesday, 21 November 2001 17:41:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC