Re: Range interpretation question.

Thank you all for the interesting comments. In short, my impression is
that both interpretation can be useful, but that ONE range construct in
RDFS can not support BOTH interpretations. Ian was so kind to mention a
previous discussion that I will give a pointer to below. After
re-reading most of the discussion, I would like to maintain my
impression that this discussion was not conclusive (some reasons below).
What is your opinion on this? Which additional arguments may support
interpretation (a) or (b)? Should there be two constructs in RDFS?

Below, the pointer to the previous discussion and a few comments on
non-monotonicity can be found.

Thanks, and enjoy Labour Day!
	Wolfram Conen
	conen@gmx.de


Ian Horrocks wrote:
> 
> On April 25, pat hayes writes:
> > >Wolfram Conen <mailto:conen@gmx.de> wrote:-
> > >
> > > > (a) P may be applied to any resource that belongs to class C
> > > > (b) If P is applied to a resource r, r will belong to C
> > >
> > >I'd say that it depends on the application;
> >
> > It can't depend on the application. The language needs to have a
> > clear meaning. If we want both meanings, then the language should
> > provide two different constructions for saying each one unambiguously.
> >
> > I also want to know which is meant.
> >
> > Pat Hayes
> 
> As far as RDFS is concerned, this was discussed some time ago (on this
> list and/or rdf-interest) and it was widely agreed that both range and
> domain should have (b) style semantics, that is:
> 
> Range(P,C) and P(x,y) -> C(y)
> Domain(P,C) and P(x,y) -> C(x)
> 
> In fact, as I recall it, persons who could best be described as
> "influential in W3C" stated that these are the "correct" semantics for
> range and domain and that the semantics/restrictions expressed in the
> current RDFS specification are simply a mistake.
> 

I guess Ian refers to the email of TimBL
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0107.html

He argues that (starting with the decree that (b) is the "correct
semantics" of the range "constraint" in RDFS) more then one range
constraint should be allowed (because the y from Ian's rules above will
not only be in C, but also in all superclasses of C, and thus,
range(P,Superclass_of_C) should not be forbidden (this is as I
understood it. Note: this argumentation depends on a decision for
interpretation (b)) 

The following discussion was a mixture of arguments for multiple range
constraints, for and against disjunctive or conjunctive interpretation
of multiple range constraints and (very few) remarks on the semantics of
the range constraint. A position of an (a)-proponent can, for example,
be found in 
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0148.html
(Lee, I hope it is ok to call you (a)-proponent?)

So, I am not sure if it was really "widely agreed" that the
interpretation is (b), especially because most of the discussion was not
even related to this issue.

Actually, in the RDFS-CR (e.g.,in the Section on constraint properties
or the example 7.1), most of the descriptions/arguments support
interpretation (a), and a few can be interpreted as supporting (b)(well,
this is only my point of view, you don't have to agree (detailed
arguments upon request)).


> I'm not sure that (a) style semantics really expresses anything - by
> default we may apply P to any resource we like, so a statement of the
> form (a) doesn't place any additional restriction on the set of valid
> domain models. 
> If you mean that P may ONLY be applied to a resource
> that belongs to class C, ...

Well, the preciseness of the words I used to give the interpretations
above could have been better - of course, (a) should constrain the usage
of range, however, ONLY would not generally be the correct word,
because, with multiple constraints, MAY ALSO BE (disjunctive) or MUST
ALSO BE (in addition to other range constraints, conjunctive) may be
correct too.

> ... then this is rather problematical as it can
> lead to non-monotonic reasoning (in a 2 valued logic). e.g., if in my
> current KB I am not able to infer that that C1->C, then I can't apply
> P to instances of C1, so C1 will be classified as a subclass of the
> class "Restriction onProperty P toClass Nothing", i.e., the class of
> things that don't have any P property. 
> Now if I add a fact to the KB that allows me to infer 
> that C1->C, then I have to withdraw my
> inference that C1->(Restriction onProperty P toClass Nothing).

The problem with the example is that with interpretation (a) you do not
"classify" any class C1 depending on the absense or presense of range
constraints (because you do not infer any type from a range constraint).
(This is not to say that it might not be useful to have such
"complement" class of P's range (though it will usually be rather
large)).

> Now if I add a fact to the KB
> that allows me to infer that C1->C, then I have to withdraw my
> inference that C1->(Restriction onProperty P toClass Nothing).

In fact, with interpretation (a), nothing harmful can follow from
discovering that an instances belongs not only to a class C1 but also to
some other class C2 (be it a superclass of C1 or any other class).
Reason: If a set of statements does not violate a range constraint (that
is, all P's are only applied to resources of the allowed type), you may
add further type information (with the (a)-interpretation, this can be
done with rdf:type, with rdfs:subclassOf or, a little more indirectly
with subproperties of type /subclassOf and rdfs:subpropertyof), without
ever invalidating the range constraints. [End of stuff directly related
to Ian's mail]

There is, however, a nasty problem related to the fact that ZERO or ONE
range constraint is allowed. It may happen that you happily apply an as
yet unconstrained property P (no range constraint known so far) to a lot
of resources that are of a more specific type then rdfs:Resource or
rdfs:Literal and later discover that P is range-constrained. That,
indeed, will leave you with a bit of a problem (which could be avoided
if zero range constraints would be disallowed (the default could be
expressed with a class that is a superclass of Resources and Literals)).

More problems (in both interpretations, with different consequences) may
arise, if "knowledge" is deleted/changed. The ability to deal with the
dynamics of knowledge will often be part of the requirements (so, we
should probably face this challenge instead of avoiding to discuss it)? 

A note in this context regarding the problem of multiple range
constraints: with interpretation (a) (i.e, validation), with conjunctive
semantics, the same problem as mentioned above will occur: a number of
range constraints allows a certain set of classes to be used as a range
of a property P. One additional range constraint may dramatically shrink
this set, ex-post invalidating some of the decisions (such as related
inferences/ consequences for the application) that have been previously
taken. With interpretation (b), conjunctive semantics are nice, however,
because it allows to infer that a thing that is used in the object
position of a property P has all the types of the previously known
constraints plus one additional type. It seems as if with a clear cut
decision for one of the interpretations (a xor b), some of the
range/domain constraint related discussions could be concluded much more
easily.

Furthermore, one may argue that, with reasonable 
- type/subclassOf/subpropertyOf axiomatization 
- representation of the RDF triples in a suitable host formalism 
- a mechanism to check the validity of the range constraints
(interpretation a),
the interpretation (b) follows from validity as a consequence.

I would be happy for any more feedback because, in our applications of
RDF/RDFS, quite a bit depends on the correct interpretation. 

Thank you again. 
	Wolfram.

(PS: most of the above results from discussions with Reinhold)

Received on Tuesday, 1 May 2001 05:49:01 UTC