[sc34wg3] Look Ma! No Properties!

[Robert Barta]

On Fri, Jul 16, 2004 at 10:58:12AM +0200, Jan Algermissen wrote:
> Robert Barta wrote:
> > 
> > On Thu, Jul 15, 2004 at 08:08:11PM -0400, Patrick Durusau wrote:
> > 
> > > Ok, the \tau model has no properties.
> > 
> > The \tau model is based on assertions only. Properties are seen as
> > only a special form of an assertion, yes.
> 
> Ok, I am beginning to see what you want. 

/me dancing on the table!

> An instance of student is something that appears as p in an (instance,p)
> member, yes?

The name of it, yes.

> > Remarks on identity:
> > 
> > If I would further indicate that the "SID property" is inducing
> > equivalences and that should trigger merging, then I would say
> > something like
> > 
> > forall [ $s1
> >          SID: $sid1 ]
> >    => not exists [ $s2
> >                    SID: $sid1 ]
> 
> Wow....you are the first person I see to come up with a purely declarative
> merging rule, which is (warning: implementation issue ahead :o) extremely
> important in order to get efficient merging. To make it possible at all.

What the above only indicates to the machinery is that there cannot be
two things in a map with the same SID. If I were asked to implement this
then it is similar to what people do in the SQL world:

create table (
   bla bla,
   SID varchar(101), # argh
   KEY id (SID)   <---- this is a 'uniqueness constraint in disguise
);


> At least if you want to have 100% generic merging rules.  (Note:
> IMHO, a merging rule is simply a constraint. In the case of tau, it
> is a constraint on the set of all members.

I think there are two aspects:

  (a) when to trigger merging, and
  (b) actually perform the merging

(a) can be controlled by having statements like the above, the merging
(b) itself can be always the same, or I could even imagine that an
application DEFINES EXACTLY how it wants things to be merged. This
could be handled by TMQL, btw.

> What I do not understand in the above is what $s1 iterates over? 
> Is it I? Is it the set of all members?

There is no 'I', that is a square bracket.

$s1 is iterating over 'every thing' in the map. If I do not want that
and I only want to have this rule applied to 'students' then I relax
it a bit:

forall [ $s1 is-a student
         SID: $sid1 ]
   => not exists [ $s2 is-a student
                   SID: $sid1 ]

> > The machinery would conclude - trivially - that it is the SID property
> > alone that signals an identity.
> 
> You say 'SID property'....that is actually the SID role, yes?

On the high-level it is a 'property', on the TMRM 'assembler level' SID
is a role, yes.

......
> > So the SID AND the shoesize and the first letters have to be different
> > and - together - induce identity.
> > 
> > Many more bizarre concepts of 'identity' are possible.
> 
> Well, the cool thing is that you can load them into an engine in the
> form of *constraints* on literals that play certain roles, that you
> can really implement such an engine and (biggest +) that you can 
> *communicate* the constraint to others.

EXACTLY.

> This is, BTW, conceptually not different from the schema definition part
> of SQL. Define a schema and load it into your engine. Then load the data.

EXACTLY.

> I wonder if merging will cause a form of multivaluedness that will
> cause problems, because you would need to hide it in opaque literals?!?!

At the low level this should not be a problem, as members remain in
exactly the same way after merging. It is a set, so only completely
identical pairings are 'thrown out'.

> I might give it a try and do some prototype implementation for tau
> for evaluation purposes. I am having this itch that there are
> problems induced by merging (which you exclude for now :o) and/or
> having assertions as role players....

Please do that, although \tau is not really meant to be implemented 1:1.

> but besides that, I am quite impressed.

I have printed out this mail :-)

\rho