[sc34wg3] Modularization

[Michel Biezunski]

*Kal Ahmed:

>I think that topic maps still needs at least one normative interchange
>syntax in order to be a standard that is taken seriously by those that
>develop the software to support it and in order to give the users of the
>standard the confidence that they will be able to exchange data between
>different implementations of topic map processing systems.

>Perhaps there is an argument for modularisation - making the interchange
>syntax(es) separate normative specifications , but I would be wary of
>having no normative interchange syntax specification at all.

I agree with Kal that the issue I have raised in the thread
"A new idea for the Topic Maps standard" leads to modularization.
I also recognize the need for a normative interchange syntax.


* Jim Mason:

>I think this is interesting, but then what would be left as normative?
(BTW,
>it's pretty hard to take something that's already normative [e.g., HyTM,
>XTM] and make it only informative: it amounts to withdrawing a standard.)

Yes, the existing syntaxes should still be normative.
But now I have a proposal of what could be done to move forward and
progress in the understanding of what needs to be done.

I think that we are really dealing with 2 different levels:

1) the quintessence of what topic maps are
2) the constructs built around it.

I consider 1) being the fact that there exists computer constructs
that make it possible to represent subjects of discourse. These
computer constructs are called "topics" and they have this oddity
that they merge if they are representing the same subject.
For us, this is now obvious, but it might not be obvious for
XML developers when they first discover topic maps!

This is what I see as the core of topic maps. The power
and appeal of topic maps come from this built-in merging
capability which has the effect of enabling connection between
various kinds of information units in a way which is
entirely original.

Now 2) comprise the fact that topics can have characteristics
attached to them (such as an undefined number of names), they
can be related to resources relevant to them (i.e.,
occurrences), they can be related to other topics, etc.

I propose a modularization strategy where we clearly
separate 1) from 2). It will make 1) clean, simple and
very powerful. It will make 2) as specific as we decide to
define it. 1) would be mandatory. Any topic map candidate
application should be able to be represented as 1), but 2)
could be replaced by any model that exists or will exist
and can be mapped to 1). In other words, 2) would be a
plug-in to 1) that could be unplugged and replaced by
another plug-in.

Currently, the SAM as written inherits from the confusion
resulting in a fuzzy separation between these 2 levels.
Which translates partially in the fact that concepts are
represented directly by syntactical constructs. We thought
when we did it that this was going to make it "easy" to
grasp, but now I see this as a severe limitation to
expansibility.

The part that corresponds to 2) should define conceptually,
abstractly, what we mean for example when we speak of an
occurrence or of a name in this representation. It's not
enough to give a list of element types. Because it's possible
that other applications will use the same notion of names,
and other element types. We need a description precise
enough to know if the model can be assimilated or not.

By doing that, we provide an example of what the documentation
of a topic map design should be, to prepare for merging with
others. This is useful as an example that users can follow
to optimize the merging capabilities of their own topic maps.

Last remark: it might be appropriate to change the name
"Standard" in the expression "Standard Application Model"
for a name more hospitable to coexistence with others. Because
if another standard organization publishes a standard that we
can consider Topic Maps-compliant, then there will be another
standard application model. I propose therefore to call it
tentatively the "TAO model" (if Steve P. permits that
we reuse the term he coined). That would make the goal of what
we are doing clearer. So, modularization as I see it for
now would lead to two levels:  the "Core Topic Maps", and
the "TAO model".

Michel
===================================
Michel Biezunski
Coolheads Consulting
402 85th Street #5C
Brooklyn, New York 11209
Email:mb@coolheads.com
Web  :http://www.coolheads.com
Voice: (718) 921-0901
==================================