Re: slotted notation -summary

Michael Kifer wrote:

> Possible approaches
> -------------------
> 1. At some point, Hassan proposed to use one syntax and give it different
>    semantics in different dialects. This has a problem that it might create
>    confusion and has a big drawback in that it becomes awkward to have > 1
>    kind of slots in the same dialect.
> 
> 2. Harold is trying to unify Psi-terms and relational slots (see below) by
>    adding special syntax (of rest-variables), but this has no good model
>    theoretic underpinning and (as far as I can see) so far his proposals
>    failed to capture both semantics correctly.
> 
> 3. Gerd proposes to have one slotted syntax in the core and give it one of the
>    known semantics, which we as a group will identify as the most important one.
> 
> 4. This approach is not to have slots in the core and let dialects add
>    their own slotted syntax. This way > 1 slotted syntax (with different
>    semantics) is possible within the same dialect. 
> 
> 5. This approach is two have several different syntaxes and several different
>    semantics.
> 
> Personal opinion (sorry for taking the liberty of injecting it here)
> ----------------
> I favor the 4th approach.

+1

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

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.

Dave

Received on Thursday, 4 January 2007 09:21:01 UTC