[sc34wg3] Re: Montreal meeting recommendations

[Steven R. Newcomb]

[Lars Marius:]
> What seems to have happened is that what you call
> topic maps is no longer the same as what ISO 13250
> and XTM 1.0 calls topic maps.  Instead, ISO 13250 and
> XTM 1.0 are now what you call "topic map
> applications", while PMTM4 is what you call "topic
> maps".

Almost right.  We do *not* propose to make PMTM4 the
*exclusive* meaning of the brand name "topic maps".  We
propose to *extend* the meaning of the brand name
"topic maps" to *include* the "core model" (some
successor to PMTM4) and, at least by implication, *all*
of the core model's applications.  We propose to make
the ideas, assertion types, and syntaxes that are
currently documented in 13250 and XTM

           THE STANDARD APPLICATION

of Topic Maps.

This is NOT a proposal to downgrade the importance of
the topic naming constraint and the notion of
occurrence-ness.  Consider the difference between
saying "SGML" and "The Reference Concrete Syntax of
SGML".  Nobody worries about that distinction; it has
hardly ever been an issue, and, today, with XML and
Unicode, it's absolutely not an issue at all.
Similarly, very few people are going to worry about the
distinction between "Topic Maps" and "The Standard
Application of Topic Maps".

I would also like to point out that almost nobody uses
the Reference Concrete Syntax of SGML, and that SGML's
survival, now that it is known as "XML", has *depended*
on its ability to accommodate syntaxes OTHER than The
Original Reference Concrete Syntax.  Smart as they
were, the people who created the ISO SGML standard
weren't smart enough to foresee the XML phenomenon, and
they knew it.  So, they made it possible for SGML to have
variant Concrete Syntaxes.  In the same way, and for
the same reasons, we must make Topic Maps able to
accommodate variant Applications.  

I observe that the companies that supported SGML long
before XML came along have, at least in notable cases,
leveraged their core SGML competencies in such a way as
to remain dominant in the new, much larger world of
XML.  We must put the early adopters of Topic Maps in a
similar position to leverage their core competencies
when, at some future time, Topic Maps become a mass
market phenomenon.

> That is, to you topic maps consist of subject
> identity points, associations, and scope, and nothing
> more. Base names, occurrences, and variant names are
> all just application-specific constructs built using
> the more fundamental model, and these constructs have
> no special status compared to other constructs that
> might be built with the same model.

Not *no* special status.  On the contrary: *very*
special status.  Just not *exclusive* status.

>   c) that we need to be careful about how this is
>      represented to the outside world, and

Yes.  I agree with you.  To optimize our activities for
success, we must all work hand in hand, clearly
understanding, agreeing upon, and religiously
respecting not only the perimeter of our common
defense, but also the *appearance* of that perimeter
wall as we intend it to be perceived by the public.

Let me use this "perimeter wall" metaphor again.  If we
erect the perimeter wall only around what we're
proposing to be "The Standard Application" (this is the
perimeter wall that both XTM and ISO 13250 currently
specify), then we will have left our water supply
outside our defensive perimeter.  In order to withstand
a protracted siege, we must have our water supply (our
core model) *inside* our perimeter.  If our core model
is outside our perimeter, then Topic Maps will not be
able to survive a long siege, because we will not be
able to grow fresh crops within the safety and comfort
of our perimeter wall.  Fresh crops (i.e., Applications
adapted to current conditions) can't grow without water
(i.e., a core model that can support the development of
new Applications).

If Topic Maps succeeds at all, a major and protracted
siege of our Topic Maps citadel is inevitable.  We
would all prefer that Topic Maps, and all businesses
that depend on Topic Maps, survive and thrive in spite
of any and all attacks, competition, changing
conditions, and other pressures.

> Given this new understanding (providing it is
> correct) it seems to me that our first objective must
> be to agree on and document a common terminology. It
> seems to me that we will keep banging our heads
> against the wall as long as we continue to violate
> the topic naming constraint.

*vehement agreement* (I get your point about the topic
 naming constraint.  Your use of this term in the above
 paragraph is a nice application of our common
 vocabulary, and, for me at least, it is exactly
 correct and very compelling.  I wish I had said what
 you just said.)

The basic challenge we face is to achieve consensus on
what we mean when we use the term "topic maps".  I
believe that our unmet need to face this question
together has been at or near the root of every single
one of our troubles.  We *must* achieve consensus on
this point, first, last, and everywhere in between.

If anyone feels threatened by the idea of enlarging our
perimeter wall, now is a good time to explain why.  We
can mitigate (and perhaps even eliminate) these threats.
The proposal to privilege "The Standard Application" --
the inner perimeter wall inside the big new outer
perimeter wall -- depends on the whole question of what
constitutes a definition of an Application.  As my last
note indicated, the answer to the question, "What's an
Application?" needs considerable refinement.  I believe
that, in the process of doing the work that confronts
us, we will have many opportunities to minimize
negative consequences for those who have already
invested significantly in the inner perimeter wall --
the historical definition -- of "Topic Maps".  Unless
there is good reason to do otherwise, we should act
favorably on such opportunities.  After all, the
fundamental goal of standards-making is to protect the
interests of the adopters.  They are our customers!  We
will defeat ourselves if we create a precedent in which
any significant adoption of topic maps turned out to be
a DISadvantage for the adopter.

In any case, we certainly have a lot of talking to do.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

1527 Northaven Drive
Allen, Texas 75002-1648 USA