- From: Chris Welty <cawelty@gmail.com>
- Date: Fri, 05 Jan 2007 12:00:03 -0500
- To: Michael Kifer <kifer@cs.sunysb.edu>
- CC: Dave Reynolds <der@hplb.hpl.hp.com>, RIF <public-rif-wg@w3.org>
I snipped all the stuff we agree on: Michael Kifer wrote: > Chris Welty <cawelty@gmail.com> wrote: >> Dave Reynolds wrote: >>> Michael Kifer wrote: ... >>> Further in some object oriented notations the signature is regarded as >>> closed so that if you have: >>> p(slot1=>typ1, ... slotn=>typn) >>> and then later see >>> p(slotz->valz) (where z not in 1 .. n) >>> that is an error unless you modify the signature to include slotz. >>> In RDFS it is perfectly legal (and beneficial). >>> >>> I don't know enough about F-logic to be sure whether it is identical to >>> RDFS in these regards but in any case it seems that even within the >>> object-oriented slot notion there is some variation of semantics possible. >> This closed signature actually causes a genuine incompatibility >> between FOL and OO semantics, when (using Michael's syntax here) we >> allow the predicates to have a taxonomic structure, ie p:q means that >> p is a subclass of q and "inherits" its signature, then if you have: >> >> q(slot1=>typ1, ... slotn=>typn) >> p(slotz=>typz) >> >> in both semantics, the signature of p becomes (by "inheritance") >> essentially: >> >> p(slot1=>typ1, ... slotn=>typn, slotz=>typz) >> >> BUT, in FOL semantics, since all p's are q's, it is perfectly >> reasonable to have some q with a slotz, in fact there are a bunch of >> them (all the instances of p), but in OO there would be no way to >> express the rule that any q with a slotz of typz is a p. > > I am not sure what exactly you mean here, but in F-logic you can write > exactly this: > > ?X:p <- ?X:q and ?X[slotz=>typez]. > > This does what (I think) you want both under the first-order semantics and > under the LP semantics of F-logic. My point was not that you can't do it in every system, just that there are those OO systems that work this way. In this case, *I'm not really talking about your slotted syntax for rules*, rather, a difference between the object oriented notion of class (in some systems) and the FOL one. It impacts this discussion, though I may not have made it clear how. Let me try to be sure the basic point is clear, excuse the tutorial tone: Conventional OO programming language semantics (as well as for several frame systems) for classes and slots works with an idea of "attachment" (an older term, bear with me): slots are attached to classes and when you create an instance of a class, it (the instance) gets memory allocated for each slot in its defining class, as well as all the slots defined in the transitive closure of all the superclasses of its defining class. This is all kindergarten level stuff, I know, but still bear with me. So if I have two classes, P and Q, and P subclass Q, and Q defines slot s1 and P defines slot s2, then an instance of P will have slots s1 and s2. So, for this one example, we might say that the FOL translation of such a class structure is: (forall (x) (if (Q x) (exists (y) (s1 x y))) (forall (x) (if (P x) (exists (y) (s2 x y))) (forall (x) (if (P x) (Q x))) However, and here is the crucial point, if I create a (direct) instance of Q, it will only have slot s1 and, in fact, CANNOT have slot s2. In most of these systems you cannot "add slots" to an object. In a real sense, the class you use to create an object has a very important impact on its existence. So that a more faithful FOL rendering would be the three axioms above plus: (forall (x) (if (and (Q x) (not (P x))) (not (exists (y) (s2 x y))))) (instances of Q don't have slot s2 unless they are instances of P) But this is a translation nightmare - akin to accounting for negation as failure in FOL, but not quite the same. >> Since the signature of q is closed, you cannot have an instance of q that >> has a slotz, unless it is *already* a p. > > Not sure what you mean here. There are object-oriented languages with > somewhat strange semantics. But these languages typically are not > logic-based and they don't have a concept of derivation rules. Is it clear now? I am talking about non logical object oriented semantics, but the cases I am talking about are very typical of the most widely used OO systems (like Java) and although it is extremely difficult to understand what the semantics are of UML in this case, I believe what I have sketched is the default interpretation of UML as well. I agree I have not made it clear how this impacts RIF. I just want to be sure this subtlety is understood before I try to address that. -Chris
Received on Friday, 5 January 2007 17:00:26 UTC