Re: slotted notation -summary

Chris Welty <cawelty@gmail.com> wrote:
> 
> 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.

But I don't understand why do we need to worry about it.

We don't need to have such an axiom in the core.
In your favorite dialect, you decide if you want CWA (in which case the
above behavior is ensured, but you can always add new knowledge and make x
a member of P) or OWA. In the latter case, the above behavior cannot be
simulated except at a very basic level (e.g., if P is specified
extensionally rather than by rules).

In either case, people can add whatever axioms they want to the dialect of
their choice to make it mimic their favorite notion of a class.


	--michael  

> 
> >> 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 22:22:19 UTC