Re: slotted notation -summary

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