[sc34wg3] Re: FYI: Yet another TMRM Formalization (well, not really)
Robert Barta
sc34wg3@isotopicmaps.org
Fri, 16 Jul 2004 20:25:39 +1000
On Fri, Jul 16, 2004 at 09:48:26AM +0200, Jan Algermissen wrote:
> 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?
Jan,
Hmm, 'predefined identifiers' are .... identifiers. Since they are no
literal (do not start with a number and are not quoted) they must be
from N.
> 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?
Again, I think that different content should be hosted in different
kinds of databases. This, because we DEFINITELY want to use the speed
of relational databases (I mean, how old are they now? 40 years?), but
I also want to be able to host quite variable content. And for this
variable content I think the TMs (and RDF) paradigm can help.
> 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.
I feel quite comfortable with the assertion model. It is a highly
'relativistic' model in that it concentrates only on the relationships
and it completely ignores the objects themselves. I find this very
good, I never trusted objects.
> > > 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.
Given enough alcohol I would even subscribe to that statement.
> > [ 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.
I did not claim that strings help with integrating application integration.
I would never subscribe to that, regardless the amount of alcohol.
> 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."
Hmmm, maybe, maybe not.
> 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.
Again, my claim is that there is a class of content which is NOT
relational in structure and which is NOT tree-like in structure, but
graph-like. For the latter TMs can play a role.
\rho