[sc34wg3] Re: Montreal meeting recommendations

[Lars Marius Garshol]

* Steven R. Newcomb
|
| You're right, I didn't get it.  Thanks to your explanation, below, I
| think I get it now.

Very good. Then we've made another step forward.

| This is an extraordinarily fruitful discussion, at least for me.

Oh, I can say that as well. This has been very useful indeed.

| (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.)

This is a complicated statement. Let me try and unravel the different
threads, so we can be sure we agree.

At the moment we have PMTM4, which probably is consistent with itself.

We also have the infoset model, which also is consistent with itself.
It is not fully consistent with PMTM4, but I do believe we can work
out the disagreements.

We have the implicit models of ISO 13250 and XTM 1.0, which are
inconsistent with each other. I believe consistency between the
infoset model and ISO 13250/XTM 1.0 is very nearly achieved. I would
assume that PMTM4 is also consistent with them.

We also have the models implemented by each of the topic map
implementations out there. These models are almost certainly not
consistent with each other, but most are consistent with the XTM 1.0
model (which is not very hard, given how vague it is). (To me, a topic
map implementation is any topic map processor, whether special-purpose
or generic. TM4J, tmproc, K42, the Mondeca engine, and the Ontopia
engine are all implementations, as I use the term.)


The next issue is: to what extent does adoption of the two proposed
models require changes to existing implementations? 

If the infoset model is adopted as it stands it will require changes
to many of the implementations, simply because ISO 13250 and XTM 1.0
were not very strict, and so implementations are guaranteed to differ
in ways that they should not.  I don't believe that many API changes
will be required (if indeed any at all). Any changes made, however,
will be beneficial, as they will be interoperability bugs, and would
have been necessary anyway.

With PMTM4 things are much more complicated, because PMTM4 is more
than just a single model. The topic map model defined in PMTM4 (the
Standard Application) is probably not noticeably more disruptive than
the current infoset model, although we seem to agree that it is
lacking in rigor. In other words: adopting this would not be a problem
in that it would break implementations.

The really problematic issue, however, is the core PMTM4 model itself,
with nodes and arcs. (Let's call it the notion assertion model (NAM),
for want of an agreed name.) This model is completely at odds with the
models of all the current implementations. If we were to make that
model normative it would require _all_ implementations to change.

The reason it would require this is that the NAM is lower-level than
topic maps(ISO 13250), and so one could model things in NAM that are
not in topic maps(ISO 13250), for example by giving topics properties
that they do not have today, using new association templates. An API
that cannot represent all the possible structures that can be built
using a model does not conform to that model. No topic map
implementation could support this kind of extensibility without API
changes.

It is difficult to over-emphasize the importance of this. NAM is not
the same as what XTM and ISO 13250 call topic maps. It is a model with
clear similarities, but it requires separate implementations.


The question then becomes: what is it we want to make normative? If we
make the PMTM4 topic map model normative we beg the question of what
we need the NAM for, as we could model the same thing more directly
using the infoset approach (see below). If we use NAM without making
it normative we run the risk that someone will implement it (indeed,
someone has already started), in which case we will have two
non-interoperable classes of topic map implementations.

If we make the NAM normative we break all existing implementations.

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

PMTM4 is not an API, nor is the infoset model. Both have strong
implications for APIs, however, and these implications cannot be
escaped. (That is the whole point of having them as standards. If they
don't constrain implementations it is the same as not having them at
all, since implementations will in both cases be free to do exactly
what they want.)
 
| [...] (I'd rather not rake up all of the reasons why I wanted your
| reassurance.  The past is dust.  We *must* move forward.)

Exactly!

| 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 can see why "syntax" had the wrong connotations. So does
"utterance", however, since it leads one to think in general
philosophical terms. This makes it sound as though you are explaining
the general transmission theory of communication, while you are in
fact trying to do something more specific.

I think the term you are looking for is "representation". We have
meaning, and we have representations of meaning.
 
|   (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".)

I would agree. They certainly possess structure, but to me syntax is
the rules that control the allowed form of character based
serializations. C++ objects are neither character-based nor serial.
Representation, however, would work for C++ objects as well.
 
| These "Topic Map Graph" Utterances are still Utterances
| (because meaning is inutterable without utterance), 

Every decoding is another encoding.

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

An ISO text is either informative or normative. If it is normative it
constraints implementations. If it is informative it does not. From
what you say here it sounds as though no parts of PMTM4 are intended
to be normative. Am I right? 

If I am not right, how can PMTM4 be normative without constraining the
form of implementations? To put it another way, what would not be
conformant with PMTM4?

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

It depends which part of PMTM4 you mean. I can assure you that no
topic map implementation is consistent with NAM. I would assume that
they are all mostly conformant with the PMTM4 topic map model.

| 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. [...]
| 
| * Maximum consistency. [...]
| 
| * Basis for rigorous definition of Applications.
| 
| * Basis for assessing the differences between Applications.

Now my name collision alarms are blaring. What is an application, in
your terminology? Things like topic maps(ISO 13250)? Things like the
Italian Opera topic map? Things like the Ontopia Omnigator? Things
like the topic map-based source code management system built by
Starbase?

| * Basis for assessing the degree to which Implementations support
|   interchange and the potential for merging of disparate topic maps.
 
Uh - doesn't this mean that PMTM4 has to constrain implementations?

| * Basis for expressing parsing models for different syntaxes.
 
Why not do this with the infoset model instead?

| PMTM4 is not about software.

Doesn't this contradict the two previous points?

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

Well, what can I say?  You certainly know how to apologize.  The
apology is accepted, of course, so let us move on.
 
* Lars Marius Garshol
|
| 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.

* Steven R. Newcomb
| 
| Do you still feel this way about what I'm trying to do?  

I do, but now that I have presented more clearly in what way PMTM4
makes me concerned you may be able to do something about it.

| Can you suggest a different, more effective, less divisive way to
| proceed?

Not yet. I need to understand better what you want to do with PMTM4.
 
| 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 agree that we need a core model. I am not convinced that NAM is the
best core model for our purposes, however.

NAM is lacking in rigor and in simplicity. NAM has 7 primitives plus
numerous and complex rules regarding their composition, and it leaves
undefined the structure of the nodes. The only thing it does define is
the structure of the arcs.

The infoset model is based on something that is rigorous and simple,
however. It has three primitives: items, item types, and properties.
Every item has identity, an item type, and a number of named
properties containing its values. The model defines completely the
structure of its instances, leaving nothing undefined.

Given this, can you explain why you prefer NAM to the infoset approach?
(I mean the general approach common to the XML Infoset and SC34 N 242,
not SC34 N 242 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.

I agree completely, but this is not an argument for NAM or PMTM4.
 
| 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.

I think so.
 
* Lars Marius Garshol
|
| 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.
 
* Steven R. Newcomb
|
| Ah.  I'm not concerned, for the moment, about the interoperability
| of applications.

How are you using the term 'application' here? Is it the same as the
way you used it before? 

In any case, I am not talking about applications, either, but with
_implementations_ of topic maps. That is, topic map processors. If
they are not interoperable you can't make a topic map conforming to
the standard and be sure that any topic map processor will interpret
it correctly.
 
| 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.

Good. We have a long way left to go before we are ready to start on
that project, though.
 
| 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.

Amen!

--Lars M.