[sc34wg3] a new name for the Reference Model

[Lars Marius Garshol]

* Lars Marius Garshol
|
| [arguing that "Topic Map Model" is the right name for the SAM]
|
|  - adding "Standard" in front of "Model" is not going to help.  Any
|    other model we might create will also be a standard.

* Michel Biezunski
| 
| 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.

Exactly. That's precisely what worries me about this whole RM thing.
 
* Lars Marius Garshol
|
|  - 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.
 
* Michel Biezunski
|
| Yes, that's true. When you say "we" I understand the ISO working
| group.

That's what I meant.

| 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 think if we do we'll find ourselves in the mess you refer to above:
we'll have other models that don't interoperate with topic maps. So
we'll have topic maps, RDF, XNS[1], and New Model X. I fail to see why
we would want to put ourselves in that position, unless, of course we
should decide to say that the RM *is* topic maps and that all
implementations should be based on the RM. If we do that I think we
should just ditch the SAM, because there will be no need for it.

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

Note that the roadmap says that TMCL will be specified in terms of the
SAM. In other words: it won't modify the SAM, so TMCL doesn't affect
this. 

| 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).

I don't think this analogy works. The DOM is a direct reflection of
the XML syntax; they correspond extremely closely and are on precisely
the same level, which is not true of the SAM and the RM.
 
| What is still not clear to me is: do we consider that SAM is the
| HTML DOM level or the XML DOM level? 

This seems like a better fit, but it implies that the SAM is not
needed and that we should kill it.

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

The SAM is like XML in that it allows you to create your own languages
to represent anything you want. The RM is more like ASCII in that it
is much more low-level and allows you to create models that are not
directly compatible with the higher level. So they both have
application levels, but the SAM is at the RM's application level. This
is not to say that the SAM has limited expressitivity, however.
 
| 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. 

It would be wonderful if we could do that. We've appeared to be close
to that state at times, but I'm not sure we'll ever get there.

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

That could be true. We might die waiting, though.

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

I don't understand this talk about a flexible design, actually. A
standard isn't supposed be changing all the time. It has to remain
stable, otherwise implementations and data will have a hard time
tracking the moving target. That's part of the purpose of a standard.

I think the real issue here is that some people, for whatever reason,
want a model that is more generic than topic maps[2] are. I don't mind
that, but I don't think something that doesn't have topic names,
occurrences, and scope in it deserves to be called topic maps.

If people were to go off and create such a technology (and keep it
clearly separate from topic maps) that would be fine by me. Users
could then choose between topic maps, RDF, and Generic Model Y the way
they now choose between topic maps and RDF. They could even model
topic maps in Generic Model Y the way you can model topic maps in
RDF[3] or they could map information back and forth between Generic
Model Y and topic maps the way we now do it between topic maps and
RDF.

I think the real problem here is that people confuse the Reference
Model with topic maps. If we stopped doing that I think we would have
no further trouble. (Apart from having created yet another identity-
based technology that is similar-to-but-different-from the others.
But we've done that already, anyway.)

So we do have a solution to our problems (which, by the way, are not
technical in nature), but for reasons that have nothing to do with
technology I do not think we will apply it. I've learned to live with
that realization, and I can only continue to hope that it will not
kill us.
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| 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).

No. What I was describing was the old problem of invalidating every
single piece of topic map software in existence by making the RM be
topic maps instead of the SAM.

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

What do you mean? And that question is seriously meant. What's the
problem? Can you give examples of it?
 
| 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.

I don't understand what you mean by this. Where's XML's or SGML's
response to this threat? What *is* the threat? Why do we have to face
it now? How *can* we face it now?
 
| Lars, please, be patient. Steve's, Sam, and all, please be patient.

I'm patient. I've waited for the SAM to be completed since XTM was
published, and I'm now nearly there. The only thing that remains is
ironing out the last few details, working out the new roadmap, then
implementing it.

What the new roadmap does is to chain the SAM to the RM in such a way
that it can't possibly be finished before the RM is finished, which
means everything else (TMCL and TMQL) has to wait for the RM. I don't
think that's a tenable position for us to remain in for very long.

I've been promising customers standards for TMCL and TMQL since May
2001 and so far neither has gotten further than the requirements stage
simply because they've had to wait for a proper foundation. I think if
we put ourselves in a position where the foundation has to remain
unstable for even longer we will cause ourselves serious grief, and
we'll be outraced by RDF (which is about to make serious progress on
their TMCL (OWL) as well as their TMQL (no name yet)).

| The things we are discussing are complex, important, we all want to
| create something that is going to be a major step forward.

Look, from my point of view we've made one major step forward: we now
have a proper model for topic maps, and (nearly) a proper
specification for the syntax I care about. The next step that's needed
is the query language and the constraint language, plus the
conformance work.

What you are effectively doing is to ask us to wait with moving TMCL,
TMQL, and the conformance work forward while we wait for something
that I have no need for and consider to be a serious threat to
everything that we're doing.

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

You've had since May 2001 to raise issues with the SAM. SRN has said
that he'll post his issues in March(?) this year. That's late (for
reasons I understand), but I can live with it, I hope.

[1] Yes, someone has created yet another identity-based technology.
    Isn't it great?

[2] In the ISO 13250 sense of the word.

[3] <URL: http://psi.ontopia.net/rdf/ >

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