[sc34wg3] Look Ma! No Properties!

[Jan Algermissen]

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. 

> 
> > I am assuming that even though you don't have properties in the \tau,
> > you are not saying that at some less abstract level you would not have
> > properties? Or are you?
> 
> It is perfectly possible, reasonable and to be expected that higher
> abstractions define properties. In fact, in TMQL we will have to do
> that for 'basenames, occurrences,...' just to be compatible with the
> world of TMDM.
> 
> Just to make an example to avoid a too abstract discussion: Lets
> assume we model students with their names, their shoesize and their
> student ID (SID). In the 'assembler-like' tau model we would only have
> assertions:
> 
>  { < name-haver:     jack-learner >, < name     : "Jack Learner" > },
>  { < shoesize-haver: jack-learner >, < shoesize : 1234 > }
>  { < sid-haver:      jack-learner >, < SID      : 12345678 > }
> 
> On a higher level a language (TMCL or whatever) might define (I am
> paraphrasing AsTMa! in the absence of a better alternative):
> 
> forall [ $s is-a student ]
>   => exists [ $s
>               name     : *
>               shoesize : /\d+/
>               SID      : /\d{8}/ ]
> 
> [ Omitting some technicalities like name mapping and multi-valuedness. ]
> 
> This will signal to a generalized TM processor (so not one which
> 'only' understands TMDMish things) that there are new properties
> 'name', 'shoesize' and 'SID' only applicable for things which are
> direct or indirect instances of 'student'.

.......................................
Hmm...just playing around:

CREATE TABLE Students
	name     VARCHAR(1024),
	shoesize VARCHAR(1024),
	SID      VARCHAR(1024),
        + the constraints
);
.......................................

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


> 
> Remarks on types above:
> 
> As we are ignorant on types (yet), I am simply using syntactic
> measures (in this case regular expressions like /\d+/ and /\d{8}/) to
> characterize what I want. That is good enough for many things, but
> other people might need real data types.
> 
> 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.
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.

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

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

> 
> If - for some weird reason - the shoesize and the first letter in the
> name are involved, then we would write (brrrrr):
> 
> forall [ $s1
>          name     : $name1
>          shoesize : $shoesize1
>          SID      : $sid1 ]
>    => not exists [ $s2
>                    name     : $name2 =~ /^$name1[0:1]/
>                    shoesize : $shoesize1
>                    SID      : $sid1 ]
> 
> 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.

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.

> 
> > What is puzzling to a degree, assuming you have the time to address the
> > first issue, is where are topics/subjects, etc.
> 
> The \tau model does not mention topics (= subject proxies in your
> diction) because these collapse into identifiers. These identifiers
> are involved in assertions.

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

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 but besides that, I am quite impressed.
> 
> Does this make things clearer?

Yes, perfectly clear now.

Jan


> \rho
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org