[sc34wg3] The Norwegian National Body position on ISO 13250

[Mason, James David (MXM)]

WG3 Crew:

I have been out of the loop for a couple of weeks, working on a special
project not related to SC34. I've just started catching up with the =
list.
Now I think it's time to make to the whole list an observation I've =
made
privately to a couple of you: Observing WG3 at the moment is somewhat =
like
listening to Strauss's Salom=E9. There are a lot of characters on the =
stage.
They're all talking, some of them quite passionately. And they're all
talking past each other, rather than to each other. (To be sure, I'm =
not
accusing anyone in WG3 of espousing any of the opinions of the =
characters in
that opera, nor am I asking for anyone's head on a platter -- yet.)

But I was disturbed by the degree to which this discussion heated up. I
think we're being too excitable and missing the point of what we're
chartered to do. Some of the people who were getting heated at each =
other
actually seemed to me, in my perhaps shallow reading, to have started =
out
close to agreement, but they continued to talk just past each other's =
ears
until they got to the point where they couldn't communicate any more.

I'd like to take Michel's questions (copied below) as a starting point. =
He
offers two directions for standards development: (1) open, flexible,
responsive to vendor needs, and (2) closed, restrictive, taking an =
almost
punitive view on what's allowed to claim support of Topic maps. I sense =
that
Michel is inclined more to (1); at least I hope he is because that's =
what
we're supposed to be doing.=20

SC34, back in the early 80s, was unusual because it was driven mostly =
by
users, not vendors. It was sort of like an open-source software =
development
project. Vendor-driven standardization was seen as evil. We had to =
create a
standard and convince people to implement it. However, we're not in the
environment that we faced in 1982, where the vendors were seeking
proprietary solutions. SGML/XML has triumphed, and the vendors are =
(mostly)
interested in how to interchange data. WG3 doesn't have to create the =
Topic
Maps software world from scratch, the way the old SC18/WG8 had to =
create the
SGML world. We're only a couple of years into TM time, and we already =
have
at east three commercial vendors and several open-source products =
supporting
TMs. Our job is primarily to create an environment in which more
vendors/software writers can compete, with some secondary emphasis on
encouraging the user community to use TMs so that the vendors will have =
a
reason to compete.

Steve P got this thread going be remarking that vendors are out there
starting to say they supported TMs when they clearly didn't understand =
what
they were talking about. We need enough conformance in the standard to
filter out the ones that are misleading customers, but more than that =
we
need the standard to help the serious vendors interoperate. (This =
situation
reminds me of the SGML world in the mid 80s, when all sorts of things =
were
claiming to support SGML whether they could really do that or they just =
had
a canned filter for the CALS DTD.)

I've heard a few people complain that the SAM is oriented too much to
vendors' needs. To that I can only reply, "What's wrong with that?" =
This
thread has shown that there are people who need interoperability =
solutions
that are related to the TMCL/TMQL complex of projects, and that seems =
to be
tied to the SAM. Given the economics of standards development today, we =
have
to go where the money is. This is what I hear coming not only from =
Steve P
but also from Mary and others.

I've also heard (elsewhere) assertions that "the SAM is not Topic =
Maps." I
am not certain what all that charge implies, nor do I have time to =
examine
it in detail. It is, instead, the obligation of those who make that
assertion to document it. Until they do document it, the assertion is =
not in
and of itself sufficient cause to slow down development of standards
development.=20

Nonetheless I want to pursue a couple of possibilities related to the
assertion.=20

One possibility is that the SAM is not sufficiently clear on some =
useful
points. Last week, someone remarked to me that there's a point related =
to
uniqueness of topics and the impact on merging that he thought might be
implicit in the SAM but wasn't explicit. If it's a useful idea and the =
SAM
can be tweaked, then let's get that on the table. If it's a fix worth =
doing,
let's get it done and get on to other work.

Another possibility is that there are whole areas of potential TM
application that the SAM doesn't cover. We obviously can't know all the
things that people will be doing with TMs five years from now. I've =
tried to
do some pretty odd things with TMs myself. Certainly we hadn't thought =
of
all the things that could be done with SGML in 1981 when I got involved =
or
even by 1986 when the standard was published. It therefore behooves us =
to
create solutions that are sufficiently open ended that we don't have to
change them two years from now. But we also can't wait until two years =
from
now to finish our current projects. If there are glaring holes in the =
SAM,
if there are obvious areas where the SAM won't work, we need to have =
them
identified. Otherwise, we need to work with what we know and =
standardize on
that basis.

Something else that came out of Steve P's messages is a reminder that =
it's
not enough to conform to XTM or HyTM. You can make an XML document that
conforms to XTM and is nonetheless nonsense. More seriously, some piece =
of
software that claims to support TMs might export a file that validated
according to XTM but was useless to another piece of software that =
imports
XTM and claims to support TMs. Correcting this problem is the most =
serious
task before the TM standardization community today.

There is a semantic component to TMs in addition to the syntactic. =
Somewhere
that standard has to provide sufficient semantic specifications to =
support
interoperability. It does not matter to me where that happens. Although =
my
quick view of the SAM is oriented towards the syntactic side of TMs, I =
could
conceive of the semantic side's being there, too.=20

I would have thought, however, that the RM should have been the =
appropriate
place to extablish that semantic layer. I do not sense that the March =
16
text of the RM does this in a usable way. Although the March 16 RM =
cleans
out a lot of unnecessary verbiage that was in the previous text and
approaches an almost algebraic brevity in places, it still doesn't tell =
me
WHY I should want any of these constructs or HOW to use them to =
construct
TMs. The RM is itself still a syntactic construct (though at a highly
abstract level), not a semantic one. In other words, it does not =
achieve the
semantic standardization that must complement the existing concrete
syntactic standardization. Almost all of the current content of the RM =
could
be reduced to a couple of tables and a diagram or so to handle the =
abstract
syntax. That would leave sufficient space for useful text for semantic
standardization. If the RM cannot perform the semantic standardization =
of
what it means to be a TM and what it means to merge TMs, then the SAM =
will
have little choice other than to become self-sufficient.

One thing the TM standardization program does not need is a purely =
academic
exercise in advanced hypertext. If we can't tie it to the immediate =
problems
of TM interchange and interoperability, then it probably belongs in a =
paper
for Extreme and not in an ISO/IEC standard. JTC1 has already been =
burned
enough by academic standardization: that gave us OSI, MHS, and ODA. =
That's
why there's no longer anything of the original JTC1/SC18, just the =
former
WGs 8 and 9 that didn't want to be in SC18 in the first place.

We have a little over two weeks before we meet in London. In that time =
we
need to sort out what's useful, and what's better left for future =
study.
Let's stop talking past each other and start communicating amongst
ourselves.

Jim Mason

James David Mason, Ph.D.

Y-12 National Security Complex
Bldg. 9113, M.S. 8208
P.O. Box 2009
Oak Ridge, TN 37831-8208 U.S.A.
+1 865 574 6973

Chairman, ISO/IEC JTC1/SC34
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm




-----Original Message-----
From: Michel Biezunski [mailto:mb@coolheads.com]
Sent: Saturday, April 12, 2003 11:14 PM
To: sc34wg3@isotopicmaps.org
Subject: RE: [sc34wg3] The Norwegian National Body position on ISO =
13250


Steve Pepper:

>A bigger problem is that new tools are appearing claiming to
>support topic maps. What we see, especially in Norway, is that
>the increased interest for topic maps is leading to the
>development of "topic map" software by people who have not
>participated in the standards process. In itself this is
>obviously very welcome. The trouble is that the lack of
>guidance in ISO 13250 is leading to systems that are severely
>non-conformant.

Can you please be more specific here? What do you mean
by severely non-conformant? How many such examples do you
have?=20

We need to study this in very much detail knowing
that there are 2 possible fixes to such a problem:

1) Make the standard hospitable to software currently
   considered non-conformant. The standard needs to
   be apparently more flexible and open.

2) Make the standard close so that it would exclude
   all software which is not strictly conformant to
   whatever the conformance clause will eventually
   be.

This is a really important strategic choice to be made.

Please give us all the elements to document the
problem you are mentioning.

Michel  =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3