Re: slotted notation -summary

Chris Welty <cawelty@gmail.com> wrote:
> 
> Dave Reynolds wrote:
> > 
> > Michael Kifer wrote:
> > 
> >> Object-oriented slot notation:
> >>           This semantics is used in F-logic, RDF, etc., and can also be
> >>           simulated by choosing the appropriate constraints for OSF.
> >>           Again, there are two things that one might say about slots in
> >>           F-logic (and RDFS):
> >>
> >>       p(slot1->val1,...,slotn->valn)
> >>             Here p is an object (as opposed to relation) and
> >>         slot1(p)=val1, ..., slotn(p)=valn.
> >>
> >>       p(slot1=>typ1,...,slotn=>typn)
> >>             Again, p is an object and this says that
> >>         typeOfSlot1(p)=typ1, ..., typeOfSlotn(p)=typn.
> 
> I would call this the signature (of p), and I want to be sure we mean 
> the same thing by that.


Yes, it is called a signature in F-logic. I was trying to be neutral with
respect to the terminology and not give any names to these things.


> >>         Similarly to the relational notation, it means that the
> >>             values in p(slot1->val1,...,slotn->valn) must conform to
> >>             the type spec in p(slot1=>typ1,...,slotn=>typn).
> > 
> > In RDFS/OWL that "must conform to" is not quite the same notion as in 
> > many object oriented notations, in RDFS/OWL it effectively means "does 
> > not contradict". The semantics license a deduction that vali is of type 
> > typi and only if one of vali's types is disjoint from typi is there a 
> > contradiction. Many object oriented systems have a stronger notion of 
> > type conformance.
> 
> I wouldn't use the word "stronger" here, I've heard some argue that it 
> is weaker, even though they are talking about the same thing.  What 
> you are trying to get at is that the OO notion is syntactic, and the 
> RDFS (indeed, the FOL) notion is semantic.  To have a value that is an 
> instance of a type disjoint with the slot signature is a syntax error 
> in OO and a contradiction in FOL.  In the latter, you can at least 
> *say* it, even though it leads to contradiction, in the former you 
> cannot say it in the language at all.
> 
> The closed world assumption comes into play here as well, as types in 
> most OO systems (but not all!) are assumed disjoint unless there is a 
> subclass relation between them.  FOL (and thus RDFS and OWL) semantics 
> make no assumptions.

It is not only disjointness of the tiles, but also the closure with respect
to knowing whether some object belongs to the type or not. For instance, 
in FOL, if you have

p(foo->a) and p(foo=>b) then a:b (a is a member of b) is derived.

In OO, DBs (or whenever closed world is used), p(foo=>b) acts as a constraint
so if it is not derivable that a:b then not(a:b) is assumed and so
{p(foo->a), p(foo=>b)} is inconsistent.


> > 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.


> 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.

> I thought this is what psi-terms 
> were for, but I'm currently confused about that.
> 
> Another peculiarity here, that I'm not sure what to make of yet, is 
> that in what Michael is calling the OO slot notation, all the types 
> are themselves relations.

Now we have to be very precise. What exactly do you mean by a "type".
Do you mean the names of the classes (to the right of =>)?

If so, then they are not relations, but terms that denote objects. The
relation (membership) is denoted by ':'. A class is not really different
from an object unless you introduce a sort of class objects (a subsort of
object) that are not allowed to have members (and others don't). Then you
can define the sort of ':' to be <object,class>. You can also define the
sort of :: (subclass relationship) to be <class,class>.

Note that under this arrangement classes can still be members of other
classes, but those symbols that are not classes cannot have members.

> This is normal in FOL style semantics, but 
> NOT normal in OO style semantics, where classes have a special status.

Some OO languages introduce this distinction, but not all. For instance,
Smalltalk doesn't.


	--michael  


> Again, I think it's useful to point out these differences, but I'm not 
> sure how important they are.
> 
> -Chris
> 
> -- 
> Dr. Christopher A. Welty                    IBM Watson Research Center
> +1.914.784.7055                             19 Skyline Dr.
> cawelty@gmail.com                           Hawthorne, NY 10532
> http://www.research.ibm.com/people/w/welty
>

Received on Thursday, 4 January 2007 15:36:40 UTC