slotted notation -summary

Guys,

Here is a summary of the issues with slotted notation.


	cheers
	  --michael  




Summary of the issues for the slotted notation in RIF
=====================================================

The issue
---------
A slot is a named function from objects/types to objects/types.
Depending on the formalism, a type can be represented as a class (which in
turn may [or may not] be treated as an object) or an entity separate from
classes. All slot notations more or less agree with that.

The problem is that there are many ways to give semantics to the same piece
of slotted syntax, and all these ways have their own proponents and uses.
As a result, inferences that one draws from the same syntax may differ.

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.
#5 is also a logical approach, which I could support. Its disadvantage is
complexity, since we would have to define at least 3 syntaxes.
I could also support Gerd's or Harold's approaches.
Gerd's (#3) would be ideal, since it gives us the simplest core.
But it requires that in this group we all agree on which semantics should be
the canonical one.
Harold's would have the advantage of being the most general and reasonably
small (more syntax than Gerd's but less than having 3 different syntaxes).
But I doubt that it is possible to capture 2 or 3 semantics using a single
syntax and semantics (which is required for Harold's).

Different slotted styles
------------------------
We can distinguish at least 2 styles of slotted notation: relational and
object-oriented. Then there are Hassan's OSF (order-sorted feature) terms,
which is syntax whose semantics can be changed by specifying different
types of constraints. At the level of atomic formulas, OSFs can mimic
different semantics: relational, object-oriented, and others (some of which
may or may not be useful). This mimicing is also going to hold true for
Horn. Beyond that (e.g., negation, inheritance, variables), things diverge,
but we don't need to worry about this, since they will be taken care of in
the dialects.

I am going to use the same syntax for all types of slots so that we will
have the same point of reference.

Relational slotted notation:
	   This semantics basically comes from the relational model in
	   databases. It is also used in RuleML.
	   OSF terms can simulate this semantics as well.
	   There are two things one might want to say using the relational
	   semantics:

	   p(slot1->val1,...,slotn->valn)
		p is the name of a relation. The fact here says that there
		is a tuple in this relation which has value val1 in the
		column labeled slot1. There are n columns and in column
		slot2 the component of the  tuple is val2, etc.

           	In the above, each tuple has an implicit Id, which depends
		only on val1,...,valn, and each slot is a function from
		this set of implicit Ids to the set of values (which
		doesn't include those Ids).
		

	   p(slot1=>typ1,...,slotn=>typn)
	        Similarly, but this tuple is supposed to represent the type
	        of the relation p. It says that the column labeled slot1
	        has the type typ1, etc.

		Here typeOfSlot1(p)=typ1, ..., typeOfSlotn(p)=typn.


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

		But p here can be an object or a class, which in the
	        relational notation p is a relation (which can be loosely
	        thought of as a class).
		We will see that different inferences are supported in each
	        case.


Without getting into the details of the different semantics, here are
examples of the differences. For instance, the following 
inferences are supported by F-logic but not by the relational notation:

     p(s1->1, s2->2) |= p(s1->1)

     p(s1=>foo), foo::bar |= p(s1=>bar)

         where foo::bar means thatfoo is a subclass of bar.

There is also a difference in the meaning: in the object-oriented case,
p(s1->1, s2->2) is a statement about the object p, while in the relational
case it is a statement about some unidentified object that belongs to the
relation p.

Received on Wednesday, 3 January 2007 22:15:19 UTC