[sc34wg3] a new name for the Reference Model

[Michel Biezunski]

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


This is really a central issue. The question is what is the limit to
interchange we want to settle on? What does it mean to interchange topic
maps?
What does it actually mean to interchange?

Do we want to allow low-level parsers to "explode" the information
into its elementary components so that tools can take benefit from them
(regardless of their specific semantic). I believe that this is what
the RM is bringing to the table. It doesn't provide with full
interoperability
in the sense that nothing such as a name or an occurrence will be
recognizable
as such but at least we would have some kind of low-level common background
against which we can build systems.

The real issue is how much of a burden is this for "high-level topic
map implementations?", such as the ones currently based on the 13250 high
level concepts. If it's too much of a burden it won't fly. If it's a small
burden, it might end up being helpful because this is the way how we are
going to actually see whether interchange works or not, but we have to
incorporate it. If it can be ignored, then we are back to the current
situation,
which might be OK if one uses always the same set of tools, but we might
be facing some interoperability issues that finally will cause problems
to topic map users if they are willing to change systems. And the purpose
of the standard is to enable users to become vendor independent.

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

Yes but now that the name-based merging rule is considered as
being removed from the Sam, the issue of where merging rules
intervene is becoming a crucial one. We might want to allow (or not)
applications to be build by adding rules to the ones defined
by the SAM, and then by doing that we are opening the way to potentially
incompatible extensions of topic map applications. The thing which is
not yet clear to me is whether this is a good thing or not. If it's a
good thing, we need to find the way to "validate" and to express the
mechanisms in abstract terms. If it's not a good thing, then we have
to define how close the standard should be, and advertize it within
its known boundaries.

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

Is the SAM intended to be the data model for what is currently ISO 13250?
If yes, then it embodies the very same concepts which are described by
the 2 existing syntax representations. Even if the formalism differs,
the meat is the same (hopefully).

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

I don't see why.

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

We'd better try to if we want to have something that looks
like a standard.


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

Why wait? Let's put these as priority issues from now on, and discuss
those right now.

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

Yes a standard has to be well-defined, but it also has to ensure that
it's going to last over the long-term. If the standard ends up to be
only useful because it's fashionable and be replaced in a couple of
years by yet the new hot stuff, then I'm not sure that big corporations
and industries are going to be willing to take the risk investing in
something that looks limited in its lifespan because its perspective
is limited. We need to build in the abstraction that will let the
standard survive for a reasonable number of years to be appealing.

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

This is not a moral issue. It depends on whether there are urging
user requirements to do so. If there are and if these people are making
claims loud enough to be heard, we need to incorporate them. If it's just
because it would just satisfy technical purists, let's not worry about it.

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

This is only interesting for technical fundamentalists. I believe
information users want information to be interchanged with other
information users and that if they find one technology that performs
it, they won't go any further. Playing between multiple overlapping
standards for me is a losing proposition.

* Lars Marius Garshol

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

The issue is what do we call topic maps? We need to get past this
idea that it is whatever we want, regardless of what others think. We
need to have a common vision of what topic maps are, what they are for,
what is their scope (in the sense of span), what are the boundaries,
and what are the various components. I see it as an absolute priority
these days to arrive to a common understanding of these. Frankly,
I don't see how we can make progress on any of the sub-issues if
we don't have a shared understanding of how it all fits together.

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

Good that you say that, because it's my understanding of what the
RM is for that it's precisely NOT doing that. Or at least it should
not. My understanding of the RM is that it should provide a sound
foundation to the SAM itself, not to the software applications that
implement the SAM. However, the RM could be used to detect the
possible incompatible interpretations of one given concept. I
think we need to offer our users some guarantee that a topic map
model which is being processed by a given software package will be
interpreted the same way if used with another software package (even
if the features will obviously be different). Isn't it what we are
trying to achieve here?


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

We need to be aware that the concepts below ISO 13250 (commonly
referred as TAO) is one representation of knowledge among others.
It looks pretty efficient, but it has its own Weltanschauung
built-in. There are some cases where for example merging rules can
be defined differently. I admit that this is not necessarily outside
of the scope of the SAM, because it can be user-defined. But this
is really at the heart of the question of modularization.

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

SGML is being "replaced" by XML. XML is facing some threats for its
future due to potential inconsistencies of derived standards, lack
of unifying principles, etc. XML is becoming an add-on to programming
languages, an API for document handling, it's less and less a technology
for document modeling. Whether this is a good thing or a bad thing is
another issue. In Topic Maps, we are also subject to the same evolution
than the other standards. No exception. We just have to consider
what is the world we live in.

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

Yes, and you have done a tremendous job. Let's make it real
now and try to make it fit the big picture that we need to
agree upon. It's true that we do everything in reverse order
(starting with the pieces and then trying to see how they fit).
But sometimes I am wondering if there is any other way to do
things (especially as a group).

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

No. That's not true. As Jim said in a recent posting, the
thing you need to be relying on is the current standard.
Anything else is tentative, it will happen or not.
Also, the RM has gone through several steps of development,
and the recent version out there could be considered near final
if everybody would be happy with it. My point is that it's not the
RM that is late, it's the fact that it's not clear yet how pieces
fit together and what any of them brings to the table. Let's nail
that down now.

> 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 foundation is not so much unstable than undecided. Let's decide
what the foundation should be.

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


Yes, this is all true. But please also consider what the others
care about. A standard can only be the result of a compromise
between competing interests. This is a fact of life, this is all what a
standard
is about. Otherwise, it's purely academic.

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

Again, let's discuss whether yes or no others have the need for
it, what is the nature of the threat you see, because it's not
clear for me that there is a threat. This amounts probably to
the core of all things to be discussed.

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

I see my role as one of the editors of ISO 13250 to constantly
raise issues as long as the standard is living. There will not
be a moment where we will be able to say: no more issues (only
when the interest for the standard will have faded).

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