[sc34wg3] Re: FYI: Yet another TMRM Formalization (well, not really)

[Robert Barta]

On Thu, Jul 15, 2004 at 01:52:12PM +0200, Jan Algermissen wrote:
> Just to clarify:
> Your names *provide* identity and the literals *have* identity - yes?

I quote:

"..objects have no other properties than being distinguishable..."

If this is for you 'identity', then the answer is probably 'yes'.

> > > - Why are the names in a special collection they are also just literals, or?
> > 
> > The trick is that members contain a pair < r, p >. r is a name, p is either
> > a name or a literal. < basename, "Jan" > would be an example.
> 
> Ok. Again, regarding the id (the identifier for assertions): is the set of ids
> a subset of N? IOW, do they share the same namespace?

The 'id' member is element of N x I, so the player is an element of I.

> > >   (which is the only difference from the TMRM assertion model)
> > 
> > No.
> 
> Why 'no'? Can you tell me what is different?

Yes, but not now. This is either done consistently or not at all. At
this stage I have only fragmentary notes on this and a proper answer
needs much more time than I actually have.

On the top-level, there are not HUGE differences in the assertion part
itself. Where there are differences are specific constraints on roles
(\tau has none, TMRM has the rule that a particular role can only be
used in a particular 'kind' of assertion[ or the roles define the kind]).

The big difference is that there is no SIDPs/OPs because there are no
properties.

> Note that the 'Assertion Type' in the RM is really just the group of
> roles.

Yes, this is a very convincing thing to me. Still, we left it out of
the model, because there is no need to put this in _at this stage_ and
if we want it later, we simply add it then.

> > This is NOT about efficient implementation. 
> 
> Ok, let's put it the other way round: What is it about? What I mean is
> that any model we develop can only be evaluated against its suitability
> for the purpose Topic Maps aim to fullfil. There is really no use in
> providing models that express interpretations of 'Topic Maps'. First
> we need a clear statement what the purpose of Topic Maps is (what
> problem do they solve) and then we can discuss what models is suited
> best. And at this point, implementation efficiency is of critical
> importance - or are we doing this as a <quote>scientific excercise</quote>?

Jan, I think this is just rubbish. :-))

Whatever the 'clear statement of what we want' might be, someone will
shoot it down. THIS is a completely academic exercise.

To develop a formal model on which I can base semantically query (or
constraint) languages is no academic exercise.

> > Again I stress that this is NO IMPLEMENTATION MODEL. It can serve as a
> > REFERENCE for other things.
> 
> For what things?

Maybe TMQL, maybe later TMCL.

> To me (personally!) the role of the reference model is that it provides
> an abstract, self-contained, logical definition of the objects, operators
> and so forth that together constitute an abstract machine with which
> users interact when accessing data.

What an academic statement. ;-)

> > Should this mean that you think that TMs should be based on RDBMs
> > theory?  
> 
> NO! But I resist the idea of a general datatype 'string'. Why not
> use the notion of typed literals? What do you think why values in
> the relational model are typed and not only opaque strings?

As someone who has ported applications between different relational
database products [spit] I am not so overly fond of data typing in
RDBs.

[ Without making reference to the tau model ] Strings are so powerful
BECAUSE they are opaque. And even if I choose to add 'data types' at
some stage, which should I use?

> > This is a fundamental trade-off:
> > 
> >    Speed vs. Flexibility
> 
> Ok, so why do we trade the speed for flexibility? (What are
> Topic Maps for that justifies this trade?)

It is the responsibility of the 'information officer' to figure out
what content is to be covered and what paradigm does it follow.
Tabular content is relational, objects are ...OO, tree-like data is
XMLish, weak-structured is RDFish/TMish, text is ...text.

Then someone has to decide about the modalities of access (how to put
data in and out) and whether all of the content should be squeezed
into one database (relational, .....) or whether it has to be kept in
different ones. THIS is where performance considerations kick in.

If you risk a glimpse at

   http://www.idealliance.org/papers/dx_xmle04/slides/barta/foilgrp03.html

you see that sometimes you can eat the cake AND have it.

> > >   In fact, the RM enables you
> > >   to write a mapping TMA between yours and the TMDM.
> > 
> > I cannot see this. I know that this was the intention, but the TMRM
> > never had any formalism, language, .... to actually express a TMA. 
> 
> Well, it has been left out on purpose. No problem to add it in. My position
> is that such a syntax depends on the overall technological environment
> that  Topic Maps are deployed in. If we deploy them in an HyTime/XML/Web context,
> markup is likely to be the syntax of choice, but the RM does not constrain
> Topic Maps to a particluar technological environment. So why should it
> include a syntax?

You _precisely_ characterize the problem the current TMRM has manoevered
itself in.

> It
> > had only the framework. As I had mentioned earlier, this is like
> > building houses without a roof.
> 
> Hmm.. will you proposal include such a mechanism in the end?

We _all_ will have to contribute to TMCL. How far that will get
depends on ALL of us.

> > For this argument I would see the \tau model at the same level as
> > TMRM. It does not predefine any 'application-specific' names and
> > also not a single rule.
> 
> Well, it defines Names and Literals.....note that the RM works without
> doing so! It is one level of abstraction below.

I cannot follow. Names are indistinguishable objects. How more fundamental
do you want to be?

> > My thinking is that a TMA is nothing else as than a proper TMCL
> > statement.  Here I would define
> > 
> >   - what kinds of things do I have,
> 
> Why 'kinds'?

I mean things like: "In my topic map I talk about coffee brands, chocolate
brands and its exorbitant prices downunder".

> >   - what app-specific rule must they follow....
> 
> ??? what do you mean by app-specific?

For instance "every student who has failed on an exam for a particular
course 3 times, is not allowed to continue the degree". This is not
structure, this is not about types. Such constraints can be
arbitrarily complex, how much TMCL will want to cover is a complexity
trade-off decision.

More 'constraints' you can find at

   http://astma.it.bond.edu.au/project-use-case.dbk

> > If TMCL is based on something which is compatible with the \tau model,
> > then that would cover the TMA relationship you, Patrick and Steve,
> > et.al.  envisioned.
> 
> Do you have any idea how that will look like? Can you sketch what you mean?

I think this was done a couple of times already on this list. I do not
want to preempt the work the TMCL people do.

> > But it would have a language and a sound formalism. That's the
> > difference for me. The TMRM, as it stands, is very difficult to digest
> > for outside people (withholding 3rd party comments here).
> 
> Yes, I agree that there needs work to be done on it.

I should add that it is not the phrasing or an inappropriate structure
of the TMRM document which makes it difficult to digest (and difficult
to 'sell' intellectually). I think that you (and Patrick and Steve...) 
tried something which is extremely hard, namely to provide a
parametrized identity framework based on properties without actually
saying how this is supposed to be done. This makes it hard, hard to
write and hard to read.

Once this is abandoned, you do not need properties at all in the model,
and then you maybe end up with something like the tau model :-)

> Yes. I hope you have the time/energy to continue this argument, it is
> (at least to me) very revealing.

I need another cup of coffee now :-)

\rho