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

[Jan Algermissen]

Robert Barta wrote:

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

Sorry, my question was wrong. I meant if the preefined identifiers are
elements of N or of the set of Literals?

You write:  "For practical purposes we assume that I also contains predefined
             identifiers, id, instance, class, sub- class, superclass."


So, which set is id in?


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

This is over my head....

We (all) are working on a paradigm (Topic Maps) and have no precise statement
about what problem the paradigm solves (or aims to solve)! How can we
ever evaluate the quality of any of the models (including the current RM)?

I'll rephrase my question: What do Topic Maps (aim to) achieve for
data owners that cannot be done with technology/paradigms that already
exist?

Based on the answer to that (which IMHO we all MUST agree on in order
to proceed in a productive way) we can then argue which model achieves
the goal and which does not.

As an aside: I must confess, that I (personally) currently cannot
justify why the current RM's assertion model should be like it is. It
could well be different (like the one of the older PMTM4) without
any impact. I just do not know yet.
But to have something in a proposal/draft/standard that is not derived
from principles (from a mission statement if you want) is a very
uncomfortable situation.


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

I (obviously) completely disagree on this.

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

It is, as long as you do not state the purpose of what you (an me and all)
do (even if we don't agree on the purpose).

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

Yes :-)  It's of course a quote. OTH, I wanted to hear what you think
about Topic Maps fullfilling this role.

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

Ok, there you have a portion of the answer to my overall question. You say
here (implicitly) that doing application integration accross RDBs is
a pain, because the data types do not integrate well. Opaque strings
will help.

What do you think (as a simple example) about this:
"The tau model aims to enable easier data integration accross RDBs and
 therefore uses opque strings to represent values."

Based on such statements, we'd have a basis to evaluate the decision
to use opaque strings (which might in fact be good). But we need the
statement of what is being tried to solve in order to reason about
design decisions.


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