[sc34wg3] Look Ma! No Properties!

Robert Barta sc34wg3@isotopicmaps.org
Fri, 16 Jul 2004 17:27:55 +1000


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.

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

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 ]

The machinery would conclude - trivially - that it is the SID property
alone that signals an identity.

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.

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

Does this make things clearer?

\rho