[sc34wg3] a new name for the Reference Model

[Michel Biezunski]

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

I think this is a misunderstanding. The purpose of the reference
model as I understand it is not to prescribe how implementations 
should work. Instead, it should analyze the result of what gets 
interchanged in XTM (and probably HyTm as well) and explicitly 
declares what is what. It actually declares the list of nodes
and arcs which result from what gets interchanged. I don't see
how this impacts the existing implementations at all.


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

I would like to revisit this statement because I feel that
TMCL has a central role to play in distinguishing what is a
user-defined topic map application and what is the standard
application (as opposed to other "non-standard" applications).

It looks to me that the starting point is once we start
with the topic map model, we create a set of constraints to
define a particular application. The question is whether the
SAM itself should be understood as an application of the RM
with specific constraints (such as pre-defined semantics of
assertion types) in the same sense that TMCL would define
what an application is.

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

It depends how you want your application to behave when merging
with other topic maps that have the same characteristics but have
been created with other sets of constraints. Understanding how topic
maps merge when they come from different environments is really
central to what we're doing. This is where the value of topic maps
is. If what we do is just a way to merge databases that have an
identical schema, I don't see why we are wasting our time. We can
just use existing, well-established technologies to do exactly that.

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

Ontopia is not the only company which is developing topic maps. It's
respectable that you have developed an approach where you know what
you are doing, you know where you're going. I am convinced that this
is what ensures your success as a company. This is not the issue here.
The issue is to take into account what others are doing. The standard
can not be reduced to what one particular person or company wants. 
Even if the consequence is that Ontopia might end up implementing 
only part of the standard.

Nothing is ever permanent in technology. Technology has to go forward.
Even standards have to be adjusting to evolution. I believe that it
is of common interest of all parties here, including Ontopia, to have
a long-lasting standard which is built on a perspective which is
powerful enough to survive various technological steps of 
implementation.

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

This is a question that the Reference Model authors should
contribute. This looks like a basic question that has not
been discussed enough and needs to.

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

This is not the case. Topic maps have been created from a document
modeling perspective (part of the SGML/HyTime family of standards)
and not from a programmers' perspective. The concepts that are at the
basis of topic maps (and are incorporated in the SAM) are fundamentally
the same that the ones that are being developed as the Reference Model.
The notion that a subject should have a unique location in the topic
space is fundamental and is a key to information management. The way
it's implemented (APIs, properties of objects, etc.) is not what
topic maps have been designed for. We have tried to leave wide open
the creativity of implementers so that we can have many products which
are doing things which are completely different (for example search 
engines, document management systems, annotation editors, databases,
etc.) and have all a common substrate. I strongly believe that we
should stick to the principle of keeping the field of applications
wide open. And this is what the Reference model offers, by explicitating
the generic layer above the way the topic map concepts appear.
The problem with the Reference model (one of them) is that it's probably
not generic, not abstract, enough. So it seems like a set of arbitrary
constraints, while it actually is not, or should not be.


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

This is why I believe the current status is not enough mature
to go to publication. We -- all of us -- have to make a particular
effort to try to understand what the others are doing, and not
considering a prioris such as "they get in my way, let's get rid
of their stuff". We need a strong standard, supported by various
people and by various approaches. If we don't do that, we might
have something that will work for a year or two, and then will
rapidly become obsolete. It's worth taking the time to preserve
the future, even if it delays publication during a few months.
(I don't believe that new users are prevented to use topic maps
as they are now, because the standard exists now and has proven
to be stable, even with the addition of XTM.)

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

And I hope it will still be the case in the future. I don't think
anybody wants to prevent anybody else to go forward. We have to
get rid of this negative misconception. If we want to act as a group,
we have to tune our agendas. That should be doable. Everybody can
evolve, and I see much more cooperation in the last period that since
a long time. The political process to make a standard happening is
like hell. It looks like nothing is happening, that we are spending
time on stupid details, it's exceedingly frustrating. But by doing
that, we strengthen the technologies incorporated in the standard
to resist to current of future user torture tests. It just makes
things stronger.

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

I am not sure this holds. Because in Baltimore I also thought
we had reached a compromise. We have not, obviously. So let's
just look forward.

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

Examples?

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

Everything which is currently developed under ISO 13250 *is* topic maps.
Unless we decide otherwise. Which we have not done yet.

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

Let's try to achieve something that makes you feel less uncomfortable.
 
> | 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.

>From a developer's point of view, you may be right. From a
conceptual point of view, it might be helpful to get the 
common foundation explicit. It looks to me that the work done
of the RM is getting pretty close to that.


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

I am not 100% sure about this. But at least I would like
to see it discussed.

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

That may be solvable as a purely editorial issue. When we'll know
what are the different pieces, we can assemble in a way which makes
it practicable for the publication process. I don't think we should
create deadline dependencies once we'll have the various parts
well defined.

Michel

  opic       aps
T          M 
  rouble     aker

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