[sc34wg3] Re: Montreal meeting recommendations

[Steven R. Newcomb]

[Lar Marius:]
> I don't think you understand what my concern is. I
> probably didn't explain it very well, so I'll make
> another attempt.

You're right, I didn't get it.  Thanks to your
explanation, below, I think I get it now.  This is an
extraordinarily fruitful discussion, at least for me.
Lars Marius, both I and the community at large owe you
a great debt for your dedication to the common goal
while doing what seems necessary to purify us of
misunderstanding and suspicion.  In case anyone who
reads this not missed what you said, I reproduce it in
full below:

> Any non-trivial piece of software uses interfaces to
> separate the various modules it consists of from one
> another. The good thing about this is enables
> abstraction to be used as a scalpel to cut a huge,
> unmanageable project into manageable pieces.

> This scalpel is double-edged, however, because it
> makes the software on both sides of the interface
> depend on the interface. If the interface is very
> abstract it can be used throughout many different
> parts of the software, which makes the software
> consistent, easier to learn, reduces the amount of
> code, and enables code reuse, but at the same time it
> causes large parts of the software to depend on this
> highly reused interface.  If you change the interface
> you have to change all the pieces of code that use
> it.

> A plausible generalization of XML might be to remove
> the artificial distinction between attributes and
> elements. If you did this it would mean that the DOM
> interface would have to change quite dramatically in
> order to support this generalization. If you change
> the DOM radically it means that every DOM, XPath,
> XSLT, and XQuery implementation that uses it also has
> to change. Lots of packages like dom4j, JDOM, XML
> editors, web publishing tools, XML generation tools,
> validators, document comparison tools, document
> databases, and so on and so forth also have to
> change. (Even TM4J would have had to change.)

> It is very much the same with topic maps and the
> topic map model.  If we radically change the model it
> means that we have to change every topic map engine,
> and every piece of software built on those engines.
> That is a huge cost, and one that will have to be
> paid by the vendors, their customers, the open source
> developers, and everyone who's done work with the
> open source tools.

> If this discussion seems a bit vague the best thing
> you can do is probably to download TM4J and look at
> its javadoc. That should show you what the interfaces
> I am talking about look like, even if you may not be
> a Java programmer. tmproc, TM4J, K42, and the Ontopia
> Engine all have different interfaces, but they are
> roughly at the same level of abstraction, so this
> discussion applies equally to all of them.

> This doesn't mean that we should never change the
> model. Please don't think that that's what I'm
> saying. It just means that we should be very careful
> when we do it, and that we should take care not to do
> it any more often than what is absolutely necessary.
> There will be times when we have to, and I am
> resigned to that, but let us be careful, and let us
> make these changes knowing what their costs are.

(Note: I'm not proposing that we *change* the model.
I'm proposing that we *have* a single consistent one.
You acknowledge this below, of course.)

> | * None of our vendors is so naive as to think that the
> |   software it has already created will form the basis
> |   of its business forever.  Everyone knows that the
> |   maintenance of a technology product line is a
> |   never-ending effort that frequently involves "eating
> |   one's own children" in order to remain competitive.

> This is a truism, but it doesn't mean that model
> changes can be made at no cost.

You are right.

> | * No existing Topic Maps system vendor will lose the
> |   value of its name-recognition on account of the fact
> |   that the definition of Topic Maps becomes more
> |   generalized.

> I don't worry about the name "Ontopia"; I worry about
> the name "topic maps".

Me, too.  That's what this is all about.  (We agree!)

> | * I don't want to draw the conclusion that Ontopia's
> |   attitude about the standardization process is not
> |   oriented toward building the largest possible
> |   competitive arena for public and fairly-distributed
> |   private benefit, but rather toward freezing the
> |   dimensions of that arena in order to influence the
> |   distribution of benefit in a way that will unfairly
> |   favor Ontopia's existing product line.

> I don't see how Ontopia could do this, and even if we
> could I wouldn't be interested. I am sitting here way
> past midnight writing this email because I want a
> standard with no room for differing interpretations,
> and of which there will be as many interoperable
> implementations as possible.  If I didn't think that
> extremely important I wouldn't have bothered with
> this model work at all.

> |   Please reassure us that this isn't so!

> Frankly, I can't understand why you need this
> reassurance. I can't see why you need to ask for
> it. I don't think empolis is any more keen on the
> core model than we are, but that doesn't for a moment
> make me suspect that they are intent on some kind of
> monkey business.  Why the fact that I am concerned
> about this core model thing makes you so suspicious
> is a mystery to me.

Now that I understand the problem, at least as you
describe it, I am more reassured than I could possibly
be by any generalized reassurance.  (I'd rather not
rake up all of the reasons why I wanted your
reassurance.  The past is dust.  We *must* move
forward.)

> * Lars Marius Garshol
> |
> | As a person interested in topic maps and wishing them to succeed I
> | am worried that changing topic maps in a radical way (for the third
> | time) is something that has great destructive potential for the
> | community.
>  
> * Steven R. Newcomb
> |
> | Not true.  It is not a radical change simply to acknowledge that
> | what we've been doing is a special case of something that has a
> | wider scope.

> If you don't understand that it is you need to read
> what I wrote above again. Changes that mean just
> about every single piece of topic map software there
> is will have to change are radical changes.

OK.  Here we have (I think) the remaining residue of
our controversy.  I want to kill this controversy,
because I believe that it has no substance, and that
it's merely a misunderstanding.  Indeed, Graham Moore
was vehement about this at Extreme, when he presented
his model on posters there.  For that matter, so was
Eliot Kimber.  (Graham, Eliot, and all: please feel
free to jump in and correct whatever I say, as always!)

As I see it, the residual controversy is based on the
presumption that PMTM4 is intended to be, or is
being proposed as, an API, a proto-API, or anything
like an API.  

This presumption is FALSE.  

The PMTM4 model is NOT proposed as a standard API, a
standard proto-API, a standard meta-API, or anything
like an API, even though it is very possible to USE it
as the basis of an API, and several people have already
done so.

Let me try to borrow and adapt Eliot's excellent
explanation of what's going on here, even though, when
Eliot first explained it, I myself found the
explanation utterly baffling.  (I'll try to do it
better.  Wish me luck.)

First of all, let's make a distinction between
"Meaning" and "Utterance".  

   (Eliot used the word "Syntax" instead of
   "Utterance".  My use of the word "Utterance" here is
   an experiment.  Let me know whether it works for
   you.  Eliot's use of the word "Syntax" was what made
   it so difficult for me to understand what he was
   trying to say.)  

   (I'm using the word "Meaning" rather than
   "Semantics" on the general principle that there is
   no general agreement about what "Semantics" means.
   (:^) )

Meaning is whatever is referenced or invoked by any
Utterance.  Meaning can't be talked about, except by
means of Utterances.

Here are some examples of Utterances:

* something spoken or written in some natural language 
* an XML document
* a bunch of C++ objects in memory somewhere
* etc. etc. etc.

  (Eliot insisted that C++ objects in memory somewhere
  have "Syntax".  I never thought of them that way
  before, and I still don't, so I'm using "Utterance".)

What I'm trying to say is that PMTM4 describes a very
abstract Utterance which it calls a "Topic Map Graph",
It describes such Utterances in terms of a set of
strongly typed edges (arcs), one of which is a
hyperedge.  

   ("Hyperedge" is a new term for me.  Did I use it
   correctly?  I'm under the impression that it means
   "edge with more than two ends".)

These "Topic Map Graph" Utterances are still Utterances
(because meaning is inutterable without utterance), and
this is what has caused a serious failure of
communications between us.  The whole purpose of
devising the idea of the Topic Map Graph was NOT to
establish the form of Topic Map Graph Utterances as a
standard.  It was to refer, in the most minimal and
rigorous possible fashion, to the Meaning of a topic
map, and to establish the precise nature of that
Meaning, and to make that meaning as simple, as
understandable, as naked, and as internally consistent
as possible.  Again: The purpose of the Topic Map
Graphs formalism (if we can even call it a formalism)
is NOT to establish the one-and-only Utterance of the
Meaning of a topic map, except perhaps as just one more
possible type of Utterance with equivalent meaning to
any of the syntaxes used for interchangeable Topic
Maps, or any expression of a topic map as a set of C++
objects, or any API to a topic map, etc.

What I'm trying to say is this: No matter what are the
exact details of an API to a topic map, that API is not
necessarily inconsistent with PMTM4.  I suspect that,
except possibly for some relatively minor details, the
APIs that already exist are utterly (you should excuse
the expression) consistent with PMTM4.

So, what's the point of PMTM4, if it's not to constrain
APIs?  The vital contributions that PMTM4 makes are
these:

* Maximally simple expression of the Meaning of a topic
  map.  There are very few primitives.  As far as I
  know, no more primitives are needed, and no fewer are
  possible.

* Maximum consistency.  Every essential aspect of topic
  maps is accounted for, using only the very few
  primitives.  Everything makes perfect sense, and the
  number of special cases has been reduced to
  essentially zero.

* Basis for rigorous definition of Applications.

* Basis for assessing the differences between
  Applications.

* Basis for assessing the degree to which
  Implementations support interchange and the potential
  for merging of disparate topic maps.

* Basis for expressing parsing models for different
  syntaxes.

PMTM4 is not about software.  It's about rigorously
establishing the Meaning of a certain kind of
information, regardless of its Utterance.  Because of
the Wittgensteinian dilemma that is woven into the
fabric of our existence as human beings, PMTM4, too,
describes a type of Utterance, but describing a type of
Utterance is not its purpose.

As you know, the whole topic maps paradigm turns out to
be based on the Platonic idea that *ideas* are the
fundament, and all utterances are pointers to ideas.
PMTM4 is an attempt to precisely define the edge of the
abyss that separates Utterance from Meaning.  It is
intended to help people safely create many diverse APIs
that will be as useful as possible in many diverse
Applications, by outlining for them exactly where the
edge is.  That's all.

Our current situation is analogous to having lived all
our lives in a kind of Ptolemaic universe, in which we
see information moving around with incomprehensible
complexity, so that we have had little hope of ever
figuring out how to manage our infoglut problem.
Recently, though, we've had a Copernican revelation.
We are disoriented by the realization that Platonic
Forms are essential to rational information management;
that the center of the information universe is not
information (the Utterance) itself, but, instead, What
The Information Means.

But What The Information Means is intangible and
unspeakable.  We have nowhere to stand.  God is not to
be found in heaven any more, there is no up or down,
and what we had thought was firm and solid is now
understood to be entirely dependent on Human Intuition,
which is notoriously variable.  We need to refer to
Meaning, but only Utterance is available, and Utterance
is not what we Mean.  We open our mouths, intending to
speak Meaning, but no words come out.

It's no wonder that we are disoriented.  It's no wonder
that when we try to apply our knowledge to the
identification of the boundary of Unspeakability (as we
*must* do in order to explain and use Topic Maps), we
stop being able to understand each other.  In that
region of our universe, Utterance doesn't work
reliably.  For example, practically everyone who looks
at PMTM4 thinks it's talking about just one more new
kind of Utterance for topic maps.  What it really is is
an attempt to devise an Utterance for topic maps that
*has absolutely nothing extra or misleading in it*, so
that it can be used as a guide when attempting to
understand the ultimate essence of What Topic Maps
Mean.  That's all.

*********************************************************

> This is not a problem with existing topic map
> documents, but with existing topic map software. And
> don't think that breaking software is just a problem
> for the vendors. Several of our customers have much
> greater investments in software built on our software
> than they do in topic map data. So the fact that the
> documents are not broken is of little help to them.

If you feel you have understood what I have tried to
say above, do you still think that PMTM4, applied in
the way that it is intended to be applied, will break
existing software beyond practical repair by minor
adjustment?

> I would expect this to be true in general throughout
> the topic map world.  Some mainly have data, and for
> them this is not so serious.  Others have mainly
> software investments, and for them this is much more
> serious.

Do you still think so?

> I can't believe you're even asking this question!

> Who is that has been crying out for a formalized
> specification with a model for the past twelve
> months?

You.

> Who was upset that XTM 1.0 was far
> too vague long before it was finalized?

You, and many others, including me.

> Who even put together an XTM canonicalization
> proposal in order to make it possible for anyone to
> do automatic comparisons of XTM implementations?

You.

> The fact that ISO 13250 and XTM 1.0 are fuller of
> holes than a swiss cheese executed by a firing squad
> armed with shotguns has been driving me absolutely
> nuts for the past year (as should be richly evidenced
> by various list archives), and I have been foaming at
> the mouth trying to get this community to do
> something about it.

Your passionate work toward a good outcome is a matter
of record.

> What more reassurance could I possibly give? What
> more could I possibly DO?!?

I dunno.  Continue to engage in a very difficult and
tedious e-mail conversation with me, perhaps?  Please?

I, for one, give you full credit for many vital
contributions, Lars Marius.  You have carried water for
all of us, including me, and I'll say that to anyone,
anytime.

> In addition, you are suggesting that I am severely
> lacking in professional integrity, which is an
> obvious insult.

This was not my intent, but I abjectly apologize for
any insult.  Please forgive me for my intemperate
words.  Please understand that I mean well, and that I,
for one, rate your contributions to the cause at the
highest possible level.

> I don't really care about that, I'm just saying it to
> make it clear to you what you're doing. What upsets
> me is that what I've been doing for the past year
> does not in itself constitute reassurance. When it
> doesn't I don't see how any statement I make now
> could reassure you, so why are you even asking about
> this?

I admit it: it's because I need to clear the air.  Feel
that wind blowing?  It feels good to me.  I hope it
feels good to you, too.

> This is what I hope we can achieve by creating a
> solid model-based standard free of holes. This is
> what has been my goal with this model work for the
> past year. I'm not convinced that PMTM4 can do this
> (which is why I've been so opposed to it), but now
> that I see where you want to go I am willing to join
> the effort to try and get there.

I have high hopes that we're going to make it, thanks
be to God.

> In the meantime I still think we need the infoset
> model, which I believe has the potential to achieve
> this.

(In my own defense, I would like to point out I have
never opposed your infoset model, and I have publicly
admired it.  I hope you believe, as I have always
believed, that the basic intent of PMTM4 is not
inconsistent with the basic intent of your model, nor
with an API based on your model.)

> I fully agree. If you think this discussion is about
> Ontopia's desire for a greater share of the market
> you need to think again.

I hereby humbly thank everyone who has spanked me for
suggesting this.  These words come from the pain of
being so misunderstood for so long, and from being so
helpless to correct the problem.  I'm feeling better,
now that we're both fully engaged in this conversation.

> | I have been saying for some time that all of our controversies have
> | been about the meaning of the "Topic Maps" brand name.  You seem to
> | want to keep the scope of this brand small and specific.  Many of us
> | want to make the scope as large as necessary and practical in order
> | to maximize the total public and private benefit.

> I understand that that is what you want, but I am
> concerned that if you do it the way you are currently
> doing you will do great damage to the topic map
> community as a whole.

Do you still feel this way about what I'm trying to do?
Can you suggest a different, more effective, less
divisive way to proceed?

> I'm not sure you understood what I meant. What I
> meant was that we should go ahead and make two
> models, one core model and one based on the infoset
> model, with a mapping between them.

Agreed.

> ... every piece of topic map software implements _a_
> model, and those of the engines that I have looked at
> seem to be very similar.  In fact, their models are
> very close (although not identical) to that of the
> infoset model. The work on the infoset model (and
> subsequent conformance testing efforts) should be
> enough to deal with the incompatibilities there are
> bound to be.

The Standard Application is alive and well, and it is
very likely to remain so for a very long time.  A good
thing, too!  All we need to do is to express it
rigorously.  All we need, in order to do *that*, is a
core model.

> I see (now) why you want to work on a core model, but
> the core model is not needed in order to solve the
> interoperability problems arising from the current
> lack of a standardized model. The infoset model can
> do that, and other models also could.

Not by itself.  We need the core in order to have the
possibility of modeling the different possibilities.  A
difference that can't be expressed can't be detected,
either, with potentially serious consequences.

> That I am concerned about the core model does NOT
> mean that I don't want a model. What it means is that
> I am concerned with that particular model. In my
> opinion what topic maps(ISO 13250 meaning) need more
> than anything else is a model. I wrote the infoset
> model in my non-existent spare time specifically to
> deal with that omission, and because I was thoroughly
> dissatisfied with the available alternatives.

This is a matter of record.

> One of the many problems I have with PMTM4 is that it
> is by no means formal enough to serve as a firm basis
> for implementation.

Advice I've collected from various experts suggest
several ways (some of which I never imagined) to
enhance the rigor.  In order to make the necessary
investments prudent, though, we first need consensus
(1) that these investments should be made, and (2) that
they would not be wasted.  I'm hoping we're getting to
where we have that consensus now.

> The fact that there are implementations does not mean
> that these will be interoperable. There are
> implementations of XTM 1.0 as well, and I am just as
> concerned about the interoperability of those.

Ah.  I'm not concerned, for the moment, about the
interoperability of applications.  

An API for Topic Maps will be a whole new standard, and
it will be a very exciting project.  One or more of you
implementers can edit THAT sucker!  And I'll be very
happy to cheer you on.

For now, I'll be VERY happy if we can just nail down
exactly what a topic map means, six ways from Sunday,
in 13250.

-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