[sc34wg3] a new name for the Reference Model

[Lars Marius Garshol]

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

Well, it's actually an open issue in the SAM whether we want to limit
conformance to interchange only. When we move on to TMCL and TMQL we
will have gone beyond that in any case, and the same applies if we are
to create a standard topic map API (like TMAPI).
 
| 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.

Actually, this is what the SAM is bringing. The combination of the SAM
with <URL: http://www.y12.doe.gov/sgml/sc34/document/0328.htm > does
this. 
 
| 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. 

Let's say that Ontopia were to abandon the ISO 13250 topic map model
and adopt the RM in its place. To do that we would have to ditch every
single piece of the OKS (except for the bits of the autogen product
that use RDF), redesign most of them, and rebuild the whole damn
thing. The same applies to TM4J, K42, Perl::XTM, ZTM, GNOWSYS...

So it's not just a burden, it means starting anew.

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

I don't see how that follows at all. If I declare in my TMCL schema
that email occurrences must be unique, how is that incompatible with
anything? It's not even an extension, it's just a specification of a
constraint. 
 
| Is the SAM intended to be the data model for what is currently ISO
| 13250?

That was my intention, and I believe I have fulfilled it.

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

Exactly.
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| 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 XTM 1.0 provides all this. I don't see any need for anything
more. If I did I wouldn't have been one of the founders of Ontopia; I
would have waited for the technology to be ready.
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| This is not a moral issue.

No, nor even a technical one.

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

Well, are there user requirements? If so, what are they?
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| 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.

Well, that's a reasonable point of view to assume, but we are actually
creating multiple semi-overlapping technologies here. SAM and the RM
are not the same technology; they are as different as XTM and RDF.
(SAM, XTM, and HyTM, however, are basically the same thing expressed
in different ways.)

If the Reference Model were only a reference model, intended to be
used for relating different technologies together and not as a
technology in its own right with its own syntaxes and applications
then the problem would go away. I've never been able to work out
whether that is the case or not.
 
* 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.)
 
* Michel Biezunski
|
| 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.

I used to think the same thing, but eventually gave up any hope of
achieving it. The Orlando compromise, enshrined in the roadmap (N278),
clearly separated the RM from everything I was interested in, and so I
felt that I was able to move on despite there being a group of people
who wanted to work on the RM. 

That's where things have stood for me ever since, basically. I felt
that rather than complete agreement we had a compromise people were
able to live with. 

If we *could* agree on what topic maps were that would obviously be of
enormous benefit to us all, but...
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| Good that you say that, because it's my understanding of what the RM
| is for that it's precisely NOT doing that. 

If it doesn't, that's good, but there has never been a straight answer
to that question. The answer I get when asking directly is that it
does not do this, but at other times the people working with the RM
say things about it that contradict that. 

One of the problems is that when reading what the people working on
the RM write it is obvious that for them the RM *is* topic maps. Some
of them have also said as much.

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

That's one thing that is being said. If that were the only thing it
was supposed to do I would feel much more at ease. Note that in this
case we would follow the roadmap and there would be no direct
interaction TMCL <-> RM, TMQL <-> RM, and so on. We would also need to
talk about the RM in a different way.

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

It's what I am trying to achieve, and it is what I started all this
yelling and screaming about models for way back in 2000 or whenever it
was. SAM + XTM + HyTM + canonicalization + test suite is all that is
needed to ensure that we have interoperable implementations.
 
| 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 now see what you mean, but how is this a threat to us? I agree with
all of this, except that I don't think merging rules are the heart of
the modularization question. Maybe that's what's confusing me.
 
* Lars Marius Garshol
|
| 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.
 
* Michel Biezunski
|
| 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. 

The new roadmap puts SAM and the SAM<->RM mapping into the same
document, and since the SAM<->RM mapping can't be finished before the
RM is finished, it follows that the SAM must wait for the RM.

That means that I'm unhappy with that part of the roadmap proposal,
but nothing more.

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

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

I agree with that.

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