[sc34wg3] Re: Montreal meeting recommendations

[Lars Marius Garshol]

* Steven R. Newcomb
| 
| 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.

I think that is a bad idea. I think PMTM4 is a good idea (now that I
know what it is), but I think we should consider the relationship
between it and topic maps very very carefully.

As a vendor I'm concerned that this seems to mean throwing away
everything we've done so far (as vendors), and I'm not very keen to do
that. We changed our internal model when we went from ISO 13250 to XTM
1.0, and although it was a lot of work it wasn't so bad, because no
customers were using our APIs. Things are different now, however.
(Of course, this is also an argument _for_ the new core model.)

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.
How can we ensure confidence in the standards we make when we keep
changing them all the time? (SGML has made, and kept, a vow never to
break valid documents.)

By all means, let us go forward, but let us do so carefully.

My thinking now is that PMTM4 should have a different name from topic
maps, since to me it is not the same as topic maps, but seems more
like something more basic than topic maps. (My paper on topic maps and
RDF that will be presented in Orlando and Copenhagen will probably
make it more clear what I mean.)

I think we should stick to the plan agreed to in Montréal for the time
being, and only revise it when we've learned enough about the core
model and its relationship to topic maps to know what best to do with
the core model.
 
| This is NOT a proposal to downgrade the importance of the topic
| naming constraint

If only it were... :-)

| Consider the difference between saying "SGML" and "The Reference
| Concrete Syntax of SGML". 

This is a very misleading analogy. Syntax is not the foundation of
entire product suites the way models are. If you change the syntax of
comma-separated files RDBMS vendors won't care much, but if you change
the relational model it's something else completely.

| Similarly, very few people are going to worry about the distinction
| between "Topic Maps" and "The Standard Application of Topic Maps".

Well, I am one of the people worrying about it.
 
| 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.

That is true, and yet on the other hand they were also smart enough to
wait for SGML to gain some traction before they went and changed it.
Not only that, but when they changed it they gave it a new name.

In any case, XML is not an application form of SGML in any practical
sense. It is possible to work with XML data in some SGML systems, but
by no means all, and many of the features of XML (like namespaces) are
not supported in SGML.

| Let me use this "perimeter wall" metaphor again.  [...]

This I didn't get at all. What is the context here? Who is the enemy?
What is it we are defending ourselves against? What kind of a siege?
It would probably help if you abandoned the metaphor and were more
direct.

* Lars Marius Garshol
|
| 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.
 
* Steven R. Newcomb
|
| *vehement agreement*

Then I suggest that you and Michel take the task of maintaining this
document. I think it should probably be a separate document from
PMTM4.

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

I agree.
 
| If anyone feels threatened by the idea of enlarging our perimeter
| wall, now is a good time to explain why.

I tried to explain this above. I would like to add, though, that
although I am worried I would not like to see us stop this work.
There is only one direction, and that is forward.
 
| In any case, we certainly have a lot of talking to do.

Amen. :-)

Now that I have verified that my understanding of your intentions I
think I can answer some of the questions I originally posed. Please
note that what I write below is just my suggestions.

* Lars Marius Garshol
|
|  - which model should the XTM and ISO 13250 serialization and
|    deserialization be described in terms of?

The infoset model.
 
|  - how do we agree on (and document!) our common terminology?

We discuss the issues on this list. SRN & MB maintain a terminology
document. 
 
|  - how many documents should we maintain as part of this work?

Infoset-requirements, infoset-model, PMTM4, terminology document.
 
|  - what should the mapping between the two models look like, and which
|    model document should contain it?

The infoset-model document, perhaps? An argument could also be made
for the opposite, however.

|  - to what extent should the models go into descriptions of the
|    meaning of topic map information? which of the models should do
|    this?
| 
|  - which of the two models should TMCL and TMQL build on top of?
|
|  - what is the relationship to the XTM 1.0 and ISO 13250
|    specifications to be? how much of these two specifications should
|    be replaced by the new model-based ones?
| 
|  - where should the models go, once they are complete? Are they ISO
|    13250 2nd edition? Should they be a normative technical report?
|    Or what?

These questions I feel we still need to discuss.

--Lars M.