[sc34wg3] Thoughts on the RM

[Michel Biezunski]

Steve Pepper writes:

> I have earlier promised to provide feedback on the latest
> version of the Reference Model (N393). Here it is.
>
> During the last couple of days I have made a serious effort to
> try and understand N393 and I am sorry to report that I have
> failed.

Good for you to have tried.

> To be frank, I find most of it totally impenetrable. I am able
> to understand the basic model of assertions, but that's
> probably only because I have followed previous incarnations of
> the RM: I don't think I would have stood a chance otherwise.
> Understanding the usefulness of assertions when we already
> have binary associations is another matter.
>
> The one thing I do like is the emphasis on what to me is the
> primary objective of Topic Maps: To provide a single point of
> access to everything that is known about a given subject.

Good.

> (However, I would much prefer to call this the "colocation
> objective", the term traditionally used in knowledge
> organization for this goal. Why invent an ugly term like
> SLUO?)

This is a good subject for discussion in London.

> Everything else is a dense fog: SIDPs, OPs, and SDDs; topic
> demanders, situation features, and castings; built-in and
> conferred.

These are key concepts to understand what topic maps
do. It's important that the authors of the TMM have
enough time to explain it in detail in London so that
everybody can understand what it means

> I ask myself: What does any of this have to do with
> topic maps as defined in ISO 13250? It's all new and goes far
> beyond today's standard.

It's not new in the sense that it has always been there,
but in a way it was hidden. In any case, even if it was
new, it's not a bad thing to do new things from time
to time. Everything rusts, including standards. We can't
hope preserving the model we designed
and pretty much finished in 1995 (except for scopes) for
the eternity. FYI, the topic map model embodied in the
current version of the standard came out after 4 years
of intense brainstorming (1991-1995), where at each meeting we tried
new stuff and played with it. Then it was much worst than
now, nothing was considered stable. Without this brainstorming
sessions, we could never have achieved building a model
that is now considered useful by important organizations
and industries (which at that time regarded this attempt
as futuristic and not relevant to their needs).

> I gave up completely on Clause 4 after several hours of
> effort, thinking: Why should I submit to this?
>
> If only I understood what benefits the RM could bring, I might
> be motivated to try and penetrate the fog, but even that
> understanding eludes me. I really don't see why we should be
> talking about "multiple Topic Map Applications" at all.

There are many existing Topic Map applications which are
not compliant with the current standard. You have mentioned
some of them in a previous mail (without describing which was frustrating).
There are new approaches, new standards out
there, which have similar goals than topic maps and that
we could regard as topic maps if we adopt a welcoming
approach, rather than an exclusivist approach. The whole
purpose of the TMM is to make this possible. The key issue
is the aggregating power of topic maps. This is the core
aspect of the proposed TMM.

> It
> makes about as much sense to me as talking about multiple
> Extensible Markup Languages.
>
> Biezunski's Principle[1] states that "there is no point in
> creating a standard that nobody can understand." Well, I
> certainly agree with that, especially for a technology whose
> very purpose has yet to be justified.

I have another principle:

There is no point in creating a standard that is not
the result of a consensus.

To achieve consensus, the members of the standard group need to understand,
discuss, review, and dissect at length not only the text proposed as
standards, but also their consequences on the
decision makers, the users, the implementers, etc.
For those of us who are lucky enough to have understood
the issues being discussed, this whole process is boring.
But for those of us who don't understand, it can be
enlightening.

When something is difficult to understand, it doesn't
mean it's invalid. It means that it needs to be explained
and tweaked until the moment where everybody feels comfortable
about it and vote for adopting it as a standard.

The first step is to give an opportunity to the
members of this group to make their own opinion
about what is proposed.

The step where we are now is that we have had to
face attempts in previous meetings to discourage
exposure and discussions about what used to be
called the Reference Model, and the method used
to do that was instead of enabling the discussion
on the technical issues involved, orient the
discussion on whether the RM should be part of
the standard or not. We have now a roadmap which
says that this model is part of the standard.
The authors have delivered. We have a new text
which has been proposed for
discussion and we need to discuss this text.

The thing we don't want is to waste our time
once again in a meeting where discussion will
be devoted on "Do we really need this?" instead
of "Tell us what it is". Organizing such a
discussion would be a waste of time for the
attendees that travel from all around the world
and expect a productive meeting.

I want the team that has prepared the TMM proposal
to have all the time they need to expose their work,
so that we can all understand what they mean, why
they have done what they have done, what is the
connection with the existing topic maps standard,
what relations it has with the current text
of the SAM, what is a topic maps model, what is
a topic maps application, what is a standard application,
what is a standard application model, what other
applications there are.

When reviewing the proposed agenda for the meeting,
I think we will not have enough time to cover
these issues. As you said, the effort to understand
the text as written is too big to let participants
be confident that they know what to do about.
I, personally, don't. Since I am one of the editors
of the standard, I find it extremely important
that we take the time to carefully study the issues
that are being brought before us, because I believe
they have important effects on the future of the
standard. I propose therefore that we
review the agenda to make all the space necessary
so that we can actually get out of London knowing
that everybody is on the same page and understands
what are the design issues for the topic maps standard,
and has enough information to make an opinion
in case there are decisions to be made.

I feel very confident that we are not in
such a position today.

I urge you, as the convenor of WG3, to think really
seriously about this and come with a proposal to
modify the agenda accordingly. Thanks for considering
my request.

> I'm sorry. I really do believe there may be some useful
> insights in there somewhere, but either I am stupid, or they
> are so well hidden that a LOT more work needs to be done
> before the RM can be offered to the world.

Nothing to be sorry about. This is work in progress.
Nobody has said that the text as it stands now is
identical to the future standard. It is the result of
a considerable amount of valuable work done by a team of
talented people that we are lucky to have on board. Let's use
what they have done and study carefully to see how
it can be fit into the standard we are building.

> I have always had great respect for Steve Newcomb's vision and
> for that reason alone I am prepared to support further work on
> the RM in the hope that it might one day lead to something
> useful.

Me too.


> But I do not believe that it has anything to do with
> topic maps; I do not believe the ideas are anywhere close to
> mature; and I no longer believe the RM should be part of ISO
> 13250.

I don't believe it either. Why? Because the Reference model
is gone. It's now called "Topic Maps Model". And I think
that there are good reason for this change of name. I may
even agree with you that this model should not be part
of ISO 13250. We should discuss instead whether it should not
*be* the new ISO 13250.

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