[sc34wg3] Modularization

[Lars Marius Garshol]

* Michel Biezunski
| 
| I believe both the SAM and the RM need to be revisited as well as
| their boundaries. This requires a particularly big effort for those
| like you who are directly involved in one of them and have a view
| that privilege one of the aspects of the whole game. But it's
| particularly important to take the perspective one level up in order
| to make the various pieces work *together* instead of considering
| that they work *against* each other. 

Well, the first thing it requires is to understand what you are
proposing. I'm afraid I still don't get it. Can you be more specific?
Do you want the RM to change? If so, how? Do you want the SAM to
change? If so, how? Should we take out some sections? Add some new
ones? Remove a document? Add a document? Change the formalism used?
Not use a formalism at all?

It seems to be clear in your mind what you want, but I can't for the
life of me work out what it is. I'm afraid you'll have to be very
concrete and specific for me to understand what you mean.

| [the 4 main aspects] should be defined in a modular way, so that we
| know which are the ones which are being referred to and implemented
| in certain application models and certain applications.

What does this mean? How do the current drafts fail to do this? 

| There is no necessity to have them all implemented in all
| applications.  But at least we need to know what is where. This will
| help topic map users to choose the application they need depending
| on their requirements.

So you are saying implementations should be allowed to not implement
parts of the SAM model, or parts of the XTM syntax?
 
| This situation is potentially risky because the more we add layers
| (TMCL for example) the more sophisticated and complex the
| applications will become, the more difficult it's going to be to
| de-intricate what's fundamental from what's specific, and we are
| going to create a situation where we will only be able to process a
| narrow universe because the model is too much defined [...]

So what do you propose that we do? Without knowing what you want to
fix I can't say I even understand your concern.
 
| A standard can not be built like a software application. Yes, there
| is a need to support existing software applications and I don't
| think anybody denies that. We need to make sure that the existing
| software applications that are able today to define themselves as
| topic maps compliant will still be able to do so in the future even
| if it requires perhaps some minor adjustments.

This isn't what the SAM is about at all. I am not sure why you are
saying this.

| The difference is that a standard must be enabling, i.e. it must
| accommodate some space for applications which are not necessarily
| following the models used by today's existing applications. This is
| I think a necessary condition to ensure long-term viability for the
| standard. The level of abstraction of the standard must be higher
| than the level in which applications are being designed.

Well, Michel, this is a tricky question, I think. The whole purpose of
a standard is a draw a line between conforming and non-conforming, so
that one can have interoperability of data and applications. I am not
clear on exactly what you mean here. Do you mean that we should
require applications to support a differerent model? That we shouldn't
require them to support anything at all? Or what?

I should probably make it clear that in my opinion conformance in the
new 13250 should go something like this:

 - software may conform to any subset of the parts they wish,

 - SAM conformance means to expose an API that contains all the
   information in the SAM with an equivalent structure, and providing
   more information is explicitly allowed,

 - XTM conformance means being able to import and export XTM documents
   in conformance with the syntax spec,

 - HyTM ditto.

Does that fit what you are thinking?
 
| On the one hand, one of the problems I see with the SAM as currently
| defined is that it's too precise in the sense that it implies a
| given type of API.

What do you mean by this? Do you think it should be changed to allow
other "types of API", whatever that may mean? Do you think we
shouldn't have a precise definition? Come on, Michel! Obviously there
is something you want to say. Please say it!

| I do not deny the interest of having had to do so in order to
| understand what we are doing and we have to be very grateful to the
| current implementers who are sharing technical information about the
| way they have implemented things. This is extremely useful but we
| should use this to build the concepts in a way that takes some
| distance from what has been made available.

You've got this backwards. Current implementations are the way they
are because XTM 1.0/ISO 13250:2000 required them to be that way. The
SAM simply reflects what was in XTM 1.0/ISO 13250:2000, not how
implementors want other implementors to do things.
 
| On another hand, the approach taken by the RM has also its
| drawbacks. The RM doesn't distinguish clearly enough the "subject
| location uniqueness objective" which is the basic principle that
| underlies the very nature of what topic maps are from the assertion
| structure mechanism (all the business about the types of nodes and
| arcs). For that reason, the RM looks like a big monolithic set of
| stuff that looks entangling and extremely constraining (why the hell
| do we need to go through all this ordeal?), and it has the effect
| that some of the software implementers see it as something
| astronomically costly in terms of guaranteeing compliance. I believe
| that this problem could be overcome by separating what the reference
| model brings to topic maps in several parts that need to be
| integrated at completely different levels in the forthcoming new
| version of the standard.

This is the only part of your posting I can understand. It's vague,
but still understandable.
 
| What I propose therefore is to redefine the building blocks that
| will facilitate building the kinds of applications the market is
| looking for. So now to answer your question, what I am proposing is
| not different from anything that has been developed both as part of
| the RM and the SAM, but I propose to organize the building blocks in
| a clearer, more harmonious, better integrated, way. 

Great. Which way?

| [extensibility]
|
| It is the possibility to regard as a TM application some application
| which is not in XTM (I am not speaking of XML namespaces here). For
| example, it's possible to regard HTML documents as topic maps if the
| meta tag contains information that can be used to derive base names.
| If we enable that, the Web becomes a gigantic, already existing,
| topic map.

Now you've really confused me. If you build a tool that maps existing
HTML documents to topic maps isn't that all you need? Why do you have
to write the standard in such a way that HTML documents can be seen to
conform to it? I don't see that the standard has any role to play
here, except to define clearly what structure and semantics topic maps
have. 

| [xxxML -> SAM mappings] 
| 
| Yes, but what about a mapping between XFML and another one (XIL?).
| There is no reason a priori why the SAM should be at the center.
| Especially if the applications invent concepts which have no
| equivalent in the SAM. Then what would you do?

If someone wants to map XFML to XIL they are not dealing with topic
maps, so I don't see any reason why we should concern ourselves with
what they do.
 
* Lars Marius Garshol
|
| Yeah, but it won't be topic maps. When you write software you'll
| have to either implement the SAM, or not implement it. If you
| implement RDF you've implemented RDF, not topic maps. If you
| implement the RM you've implemented the RM, and not the SAM.
 
* Michel Biezunski
|
| This is where we differ fundamentally. 

I think you are right about that.

| For me, it can still be topic maps, at least in certain
| circumstances. For example, an RDF application as such doesn't mean
| anything except for the fact that it is represented with the RDF
| syntax. 

Wrong. It means it follows the RDF model. There are many RDF syntaxes,
and you don't have to use any of them. I use RDF quite often, but
hardly ever touch the syntax.

| There is for example a calendar application using RDF. This one has
| not a direct relation with topic maps (not even sure but let's say
| temporarily it doesn't). Other applications of RDF are annotation
| managers, topic-based navigation systems, graphs of associations
| between subjects, these are genuine topic map applications. They
| just happen to be expressed with a different syntax, but what they
| are doing is exactly the same kind of thing we are describing as
| topic map applications. Why should we prevent ourselves to regard
| them as actual topic map applications?

We don't. If you construct a mapping from RDF to topic maps (as I have
indeed done and implemented and use very often) you can use RDF data
in your topic map system. You don't have to construct the standard in
such a way as to make RDF a conforming topic map application. The role
of the standard is to define what topic maps are, and those building
solutions can then work out various ways to get to topic maps from
other information standards. 

The standard itself can't possibly do that job for all other
information standards, and it doesn't need to, so long as it clearly
defines what topic maps are.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >