[sc34wg3] to advance Topic Maps

[Mason, James David (MXM)]

This thread, too, seems to be degenerating into the Salom=E9 condition.

My responses to the whole thing:

1. It doesn't matter, per se, whether we're doing CS, IT, KE, or =
whatever.
You can get both good and bad out of any of them. SGML was written by a
bunch of amateurs. It offended the formally trained CS types. It has a =
bunch
of dumb things in it (some of which I happily take blame for) But it =
took
over the world. XML fixed some of the dumb things (only to have a bunch =
of
sharp people try to reinvent them), then it fell into the hands of the
database people, who messed it up again. ODA was written by (1) =
academic
researchers and (2) vendors trying to lock out the end users. Both led =
to
disaster. (see note at bottom)
=20
But if what we're doing can't be implemented by CS types who write =
software,
our standards aren't going to sell.
=20
It may be important to some NBs that we look like we're doing IT, no =
matter
what we believe ourselves. (The scope of JTC1 is "Standardization in =
the
field of Information Technology".)
=20
2. I'm tired of ad hominem arguments about vendors. Even if you see a =
vast
conspiracy in the case of Micro$oft, that kind of argument shouldn't =
play
here. Of course most vendors are going to try to work things to their
advantage: they're in it for the money. But the ISO framework is =
designed to
protect somewhat against that. Graham finally came out and said it: =
empolis,
Mondeca, and Ontopia are competitors. They'll cooperate when they can =
for
mutual benefit, but none of them is looking to let the others gain a =
unique
advantage. Open source is welcome, too. There is no intrinsic reason to
fight against either commercial or open-source software in this =
environment,
nor against pure research either. I see myself as an end user, as do =
some
other folks like Mary. I just want someone to write software so I don't =
have
to. I'm grateful to both commercial and noncommercial sources (and I'll =
make
decisions about what I choose to employ outside the context of the
committee).
=20
3. Stick to the topic. I know that some folks in this group have a hard =
time
resisting a sarcastic jab from time to time. I know that others are
sensitive and quick to go on the defensive. Both conditions tend to =
push
things off the track. I hope I've actually learned some technical stuff =
in
the past 22 years of working in standards, but mostly I've learned to
develop a thick skin. We don't have time for arguments about "you were
supposed to do X and you did Y instead." If you've got a list of =
details of
unanswered questions, post 'em. If you need clarification on a specific
point, say so. But broad, sweeping assertions about either the RM or =
the SAM
are a waste of time.
=20
4. Until SC34 votes on it, there is no such thing as the TMM. It's the =
RM or
it's nothing. (I think we have names that are too politically charged. =
I'd
rather decide what's in the next edition of 13250 and what's not, then =
drop
the names for the models.)
=20
5. Nobody in this group has an exclusive right to say what is a topic =
map
and what isn't. Only the standards that come out of the voting cycle =
define
that.=20
=20
Jim Mason
=20
=20
Note: ODA began as Wolfgang Horak's Ph.D. dissertation in electrical
engineering at the Univ. of Munich. It was a nice idea, but it wasn't
grounded in practice. In the end, the only people working on ODA were
academic researchers, who killed many trees writing existence proofs =
for ODA
without ever creating working software. The vendor participants in ODA =
were
all "standards professionals," not the folks who have to make products. =
The
IETF and W3C are smart to demand working code; they learned from =
watching
ODA. WG3 has working code for at least some parts of the TM business, =
so
we're over that hump.=20