[sc34wg3] a new name for the Reference Model

[Michel Biezunski]

Lars:

> You do need to know what the XML Infoset is to understand the name,
> and that is a drawback. It is a small one, however.
>
> | The only problem with "Topic Map Model", which I like is that it
> | tends to deny the possibility of creating other Topic Maps-based
> | models.
>
> To some extent that is true, but
>
>  - adding "Standard" in front of "Model" is not going to help.  Any
>    other model we might create will also be a standard.

I do not think we should create other models at the same level
than this one. Because instead of having a standard, we would have
an infinite number of applications that will not interoperate
at the user level. But it's possible that I still agree with
what you say, it looks to me that the use of the term "model"
is still too extensive.

>  - we do not plan to create any other such models, so coming up with
>    names that will help us distinguish the model we have now from ones
>    that we may one decide to create is not going to be possible.

Yes, that's true. When you say "we" I understand the ISO working group.
The question is, as Steve N proposes, should we provide for the
creation of alternative models based also on the RM but using it in
a different way than the SAM? I don't know yet the answer to that
question. I also think that if we anticipate and we consider that
TMCL exists, then we'll end up having subsets of topic map applications
that will be _VALID_ within some subset of the SAM context. We might
even see software that will only will work with such subsets. I don't
have a problem with that if the standard defines well enough what is
what, so that we know that we should expect a given level of software
interoperability. I would call that level of interoperability "shallow
interoperability". On the other hand, thanks to the SAM for one level,
and thanks to the RM on another level, we are still preserving deep
interoperability because all this information is sharing a common
background, and can be seen with common "microscopes".

To simplify and to illustrate the parallel with XML:
- shallow interoperability is like HTML. At one point, we'll need something
like an HTML for topic maps.
- SAM level is like the DOM. Is it the HTML DOM or the XML DOM?
- RM level is like XML. It's the metalevel that allows us to create other
models.
- TMCL is like Schemas (or DTDs).

What is still not clear to me is: do we consider that SAM is the
HTML DOM level or the XML DOM level? If it's the XML DOM, then it should
be meta, if it's the HTML DOM, then it should be prescriptive, precise,
and closed.

My understanding of the current state of the discussion is that
the RM is considered (at least partially) meta, while I am not sure
that the SAM is considered meta as well, or as meta as it should be.
SAM is also meta in the sense that it stills give much flexibility to users
to define their own topic map models.

If we arrive to a common understanding of how the various layers
articulate with each other, we will end up with a situation where
everybody here will get what (s)he wants. I do not think that what
appears today as contradictory positions is as conflicting as it
looks now. We just need to get to the bottom of these issues, and
I suspect this might lead to revise the proposed division between
the parts or the new standards that are now being discussed. As long
as we are not modifying the existing standard, I think we should
allow ourselves enough flexibility in the discussion about the
design of the future standards to be sure that what we are doing
corresponds to existing or foreseeable requirements, that we are
strengthening the existing investments in topic maps, that we are
not excluding anybody from the process, and that we are not heading
to a short term solution that will break in a couple of years
because it was not strong enough to survive evolution.

>
>  - if we do create entirely new models that are not later versions of
>    this one it would seem rather strange to call them "Topic Maps", so
>    we might then call it the "Foo Model" and thereby solve the
>    problem.
>
> | (See my comment on Names as an example where this could be useful).
>
> This is essentially the same as saying the SAM is not the data model
> of topic maps, but that the Reference Model is, and that any
> implementor who wishes to implement topic maps must implement the RM
> rather than the SAM. This approach is essentially a form of suicide,
> though admittedly a quick and relatively painless one.

There are 2 forms of suicide which are possible:
1) Killing ourselves because we impose constraints that are such
that nobody will ever be able to fully comply (looks to me that this
is the one you are describing).
2) Killing ourselves because we impose constraints which are so
restrictive that anybody who will have a new idea will have to switch
to another standard because ours will not provide what's needed.

I believe that standards, like scientific theories, or human beings,
are mortal. What I am interested in is to provide principles on how
to maintain good health in order to survive tough times and possible
future turbulence. We need to combine these two obstacles, and I
don't think we should neglect one rather than the other. As long as
they seem contradictory to us, it means we're still not there yet.

For me, it's critically important at the stage where we are to
identify where the problems are and try to solve them together,
as a group. It's good that we have several directions to deal with.
We need to make pieces work together, because their rationale is
justified.

> | I believe we should further explore exactly what we mean by a topic
> | map model which would not be the standard one, try to find concrete
> | examples, then the name will come naturally. Anybody who can help
> | trying to figure that out, please do.
>
> Why would we want to do something like this?

In order to gain a longer time perspective. Steve N. insists that
there are some tm-applications that are not covered by the SAM model,
I am not sure yet I understand what they are, but I am open to hear
what he has to say about them, because I suspect he has a point, even
if it's not crystal clear now (at least to me) what it is.

>
> | I also agree with Steve P. that using the word "models" to describe
> | the 2 levels might be another factor of confusion. But I am not yet
> | convinced we have the solution now.
>
> I think we do. We call the lower level a "model" and the upper level
> used to create it a "metamodel".

I hope will will eventually be able to say that. But I think we
are still balancing between different interpretations of what that
means. In general, it's good to leave time for the discussion to
take place until all communication obstacles that remain are solved.
As long as we don't have a common understanding within the ISO group,
how are we going to tell the story to the world?

Lars, please, be patient. Steve's, Sam, and all, please be patient.
The things we are discussing are complex, important, we all want
to create something that is going to be a major step forward.
Let's not consider everything cast in iron before it is. Let's give
us the time to clarify the points until everybody recognizes the
value brought by the other approaches and how we can make all
of them fit together.

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