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

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 MULTIPLE RANGE CONSTRAINTS TO ONE PROPERTY. 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? 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).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
*