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

Re: Domain/Range: conjuntion or disjuntion??

From: Arjohn Kampman <akam@aidministrator.nl>
Date: Thu, 22 Nov 2001 10:29:33 +0100 (MET)
Message-Id: <200111220929.KAA00448@spa.aidministrator.nl>
To: conen@gmx.de
Cc: www-rdf-interest@w3.org
> 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
> same: 
>     (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,
> Arjohn?

I think so. I'll try to summarize for my own understanding:

- On a 'local' level (i.e. disregarding super properties) both conjunction
  and disjuction interpretations are possible. So the range of a property p
  can be restricted to e.g. D1 u D2.
- The range of a property is >*implicitely*< restricted to the conjunction of
  the range-restriction of the property itself and of its superproperties;
  e.g. p --range--> (D1 u D2) n C1 n C2

Is this what you were saying?

> Best,
> 	Wolfram
> 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).

Sure, but the type inference interpretation for RDFS, as specified by the MT,
was introduced long after we've written the document. Integrity constraints
were the way to go back then.


Received on Thursday, 22 November 2001 04:30:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:33 UTC