Re: slotted notation -summary

Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>
> 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.


Yes, you are right. It depends on whether the open-world or the closed-world
assumption is applied to the meaning of these signatures.


	--michael

Received on Thursday, 4 January 2007 10:52:56 UTC