- From: Wolfram Conen <conen@gmx.de>
- Date: Tue, 01 May 2001 11:50:15 +0200
- To: www-rdf-logic@w3.org
- CC: horrocks@cs.man.ac.uk, sean@mysterylights.com, ljonas@acm.org, phayes@ai.uwf.edu, kenb@ccs.neu.edu, jbroeks@cs.vu.nl, akam@aidministrator.nl
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