[sc34wg3] Modularization

[Michel Biezunski]

Recent postings confirm me in the idea that we
really need to be clearer about what is the main
objective of the Topic Maps standard.

For me, Topic Maps is primarily a way to connect
units of knowledge organized in various
ways, including lists, catalogs, ontologies,
taxonomies, vocabularies, etc. Lots of
people are currently doing precisely that,
and most of those who do that are using, creating,
proposing, inventing, designing new approaches.
Some of them have heard about topic maps, but
I bet that most have not.  

What we are offering with Topic Maps is a 
way to describe the interconnection of 
these units in a way that is independent
of any particular implementation or syntax, 
and makes knowledge interchangeable and mergeable.

We need to make topic maps able to 
provide the glue between these various
kinds of ways to organize knowledge.

The more specific we are about a particular
information model, the closer we are to
a given implementation, the most "efficient"
it seems at first sight, but ... the more we lose
the ability to become an encompassing
standard able to get things done (i.e connected)
regardless of the specific design it
was first authored in (provided of course
Topic Maps remain generic enough to be
able to consider the other approaches
as specialized instantiations).

The API nature of the SAM and related
proposed approaches is fine in the sense
that it provides a background for some
applications built on the very same
preconceptions, but it is limitating in
the sense that it won't encompass a number
of applications built on different principles
but with the same objective. For that reason,
it can't be at the center of the revamped
topic map standard without putting us 
in a place where we will not be able
to provide for the glue between other stuff.
I am not happier with the way the RM is
done until now. It contains both an abstract
description of organization of knowledge and
a set of constraints about implementations
and these 2 aspects ought to be separated.

The more I think about the discussion SAM vs. RM, 
the more I consider it as misleading. The real issue 
I believe is to separate the knowledge description 
from the constraints on applications and software. 
We need to change the level of abstraction we are 
using at both levels. Or rather, as I have proposed
before, to extract what's needed from the work
already done and organize it in a different way.

I consider it potentially more of a problem
to have a standard that is so constrained
that it can -- and will -- only be implemented
or implementable by a handful of companies 
than having a standard which is not constrained 
enough and needs extra layers
to ensure full interoperability. We actually
need both. We need one abstract standard, and 
an example of an implementation.

I propose to start considering distinguishing
the interoperability at 2 levels: knowledge
and application. When I say knowledge, I mean
I want to be able to retrieve, decipher, possibly
integrate, merge, knowledge produced elsewhere
in a completely different environment. Everything
can not be completely integrated automatically
of course, and the whole purpose of the Topic
Maps paradigm is to determine until which point
we can safely consider mergeability as an automatic
process. Controlling and mastering this is a big
deal, and if we are able to achieve this, I think
it's worth to have a standard just for that.

The interoperability of topic maps application
that exploits all the constructs built-in in the
Topic Maps standard (such as multiple names, scopes,
topic types, associations, etc.) is another story.
It's a better level of interchangeability than
the first one. I would like to see this become
an incentive for adoption not because it is all
what topic maps do, but because it is the most
advanced, the better implemented, the most efficient
among the models that can be derived from 
the Topic Maps standard. Instead of saying:
you have to use this because otherwise you are
not using Topic Maps, we could be saying: if
you use Topic Maps, this is currently the best 
and fastest way to get what you need.

What really I see this discussion being about is
to separate the existing topic maps standard into
2 levels: one level that would enable basic connectivity
for knowledge units, and one level that would enable
a richer connectivity because of a higher level of precision
in the constructs used to describe information.

I do not believe that these 2 levels are contradictory.
They are (should be, must be) complementary, the first 
is useful and is the guarantee for long-term operation, 
the second is attractive, and the second can't 
work without the first.

This is different from what I hear being said currently:
the first is mandatory or superfluous (depending who is
speaking), the second is all what there is or just one
possible way to do things (again depending who is speaking).
I believe as long as every one of us will stay with this
attitude and tries to determine to which camp he or she
should belong, we are going to go nowhere. Because everybody
is convinced to be right, and the other guys are wrong.
The reality is: everybody is right in his/own perspective.
Most of us fail to see what the others are trying to
bring. That's the problem. The technical problems can
be easily solved if only people would accept to open
their mind to the others' points of view. And this is
true for all of the protagonists. Please, for the sake
of the Topic Maps standard, make an effort, please.

If we continue in what I am starting to see as 
a rather childish war of position, we take the risk 
to isolate ourselves from the mainstream
of where applications are heading to, i.e., to invent
ways to describe semantic connections between information
items, by many different -- and unfortunately incompatible --
ways. Unfortunately the history of the topic maps standard
is paved with noisy fights, and I am not sure we can
still affoard to have a public fight without losing
credibility and leaving space for other, alternative
approaches (which might not be so good technically or
intellectually, but just would seem to do the job, and
people would just adopt them because that's all they
will find there is). 

We have something at our disposal that can help
decrease a little bit the maze of languages proposed
for ontologies, vocabularies, taxonomies, catalogs, indexes,
etc. We have a decision to take: either use it or not.

I propose we use it.

And I think this objective is important enough
that it's worth the detour (i.e., it costs us
to think twice about what we have been doing during
the last months).

Again, please consider what's at stake before
continuing discarding one or the other of the
approaches which are currently proposed for 
discussion.


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