[sc34wg3] RE: Thoughts on the RM

[Steve Pepper]

At 18:01 24.04.2003 -0400, Patrick Durusau wrote:
>The comments by the UK were particularly helpful in regard to Section 4 
>that you indicated gave you some difficulty. Was there any particular part 
>of it that seemed unclear? Or incorrect? It is easiest to respond if 
>comments are specific to and cite specific passages in the text.

The problem is that it is *all* unclear, so there's no point in citing 
specific passages. I could quote almost any sentence at random, but it 
would be wrong to do so because that would suggest that only those parts I 
have singled out are problematic. The language as a whole is dense, 
unreadable, and unclear, which indicates to me that the thinking behind it 
is also unclear.

>It would be helpful if you could be more specific about which parts you 
>found "impenetrable." I am sure that was a common reaction to ISO 8879 or 
>even ISO 13250 upon a first read for many readers.

Thank you. This was not my first read and I am immodest enough to count 
myself among those readers with the greatest chance of understanding what 
it is all about. If I don't understand it, I doubt there are going to be 
many that do. (Of course, if it turns out that the rest of the committee 
has no problem understanding it, I will accept that everyone else is 
smarter than me.)

>I don't necessarily have a brief to carry for SLUO but "collocation 
>objective" is from another domain and has a meaning that is different from 
>what I think we are in agreement on as being the primary objective of 
>topic maps.
>
>Since, hopefully, topic maps will be used in library contexts, as well as 
>others, it seems like a poor strategy to use a term with an established 
>and different meaning from the one we wish to convey. Suggestions for a 
>better name, but different from terms from other domains that have an 
>established meaning I am sure would be welcome.

The term "colocation objective" (it can be spelt with one or two 'L's) is 
from a domain concerned with organizing knowledge. How different is that? 
It is about making everything that is known about a given subject (be it a 
work, a subject area, an author, or whatever) available from a single point 
of access. How different is that? To me the "SLUO" is the *exact* same 
objective; it is only the means of achieving it that is different (largely 
because Topic Maps offers a more robust approach toward establishing 
identity in a digital environment).

I think these are precisely the arguments for reapplying the term rather 
than rejecting it: We will be saying that we are continuing a tradition, 
building on previous experience, and extending it into new terrain. 
Inventing a new term is simply inviting the reaction that we seem to be 
reinventing the wheel in blissful ignorance of all previous efforts. 
(Sometimes I think that's just what is going on, but that's another issue.)

>>Everything else is a dense fog: SIDPs, OPs, and SDDs; topic
>>demanders, situation features, and castings; built-in and
>>conferred. I ask myself: What does any of this have to do with
>>topic maps as defined in ISO 13250? It's all new and goes far
>>beyond today's standard.
>All of the things you mention here are in the assertion structure that you 
>mention earlier as recognizing from prior work on the RM. It is different 
>terminology than used in ISO 13250 but it is hardly something "beyond 
>today's standard."

Well, yes, it is part of the assertion structure, but to me it is a 
meaningless and unnecessary part. We have managed fine without all this 
terminology up to now and I see no reason to introduce it ... unless you 
want to go beyond today's standard.

>>I gave up completely on Clause 4 after several hours of
>>effort, thinking: Why should I submit to this?
>Well, you are submitting to it now, only in the guise of less specific syntax.

I meant: Why should I submit to the pain of being forced to try and read 
prose that is impenetrable in order to understand something for which I see 
no use? It's true that 13250 was not a model of understandability, but I 
made the effort to understand every aspect of that because I saw the value 
it had. Having made that effort I was then able to explain the concepts to 
others in ways that made sense to them. Since I am not yet convinced of the 
business case (or the industry requirements) for the RM, I am not able to 
summon up the same degree of motivation.

>>I really don't see why we should be
>>talking about "multiple Topic Map Applications" at all. It
>>makes about as much sense to me as talking about multiple
>>Extensible Markup Languages.
>But there are multiple Extensible Markup Languages. Well, at least only 
>one metalanguage known as Extensible Markup Language but there are many 
>XML based languages. XML, like SGML, is a metalanguage that allows the 
>definition of multiple languages that share a common syntax.

Oh really? I never knew that. Thank you for enlightening me.

Well, actually I did know that - and it was precisely my point, which you 
seem to have missed. I am comparing the notion of "multiple TMAs" with the 
idea of having more than one XML (note: *NOT* with the idea of having more 
than one markup language defined in XML, but with the idea having more than 
one XML).

I believe 13250 offers all the flexibility we need. The attempt to 
generalize topic maps still further will not make Topic Maps more 
pervasive, it will kill it.

Imagine this:

Someone has just invented XML and it doesn't seem to be doing too well; it 
certainly isn't pervasive yet. That person notices that lots of people are 
using a syntax based on backslashes and curly brackets instead of pointy 
brackets:

    \author{Jane Doe}   instead of   <author>Jane Doe</author>

So he goes off and invents a Reference Model for XML which allows them to 
claim that well, actually, LaTeX *is* XML (although its users don't know 
that). The few people that took any notice of such a preposterous claim 
would simply find it laughable.

>Don't understand the benefit of having only one TMA.

You've been brainwashed, Patrick. There is no such thing as a "TMA". There 
is Topic Maps, defined in ISO 13250, albeit it in a less-than-rigorous 
manner that makes it hard to implement consistently and therefore also hard 
to build other things (like a query language) on top of. We need to fix that.

In my opinion, Topic Maps provide the flexibility to do anything you want. 
Please tell me if there is anything you want to do that you can't do with 
Topic Maps. Consider that a challenge! I don't believe you need the 
Reference Model. I don't believe you need alternative "TMAs". I don't 
believe all the SIDPs and SDDs *buy* you anything at all.

>Particularly if there is no interoperability that I can see, no topic maps 
>can be exchanged between applications, if I follow Lars' latest reasoning.

Of course topic maps can be exchanged between applications... at least they 
will be exchangeable once we define 13250 clearly enough so that people can 
build systems that conform. You have exactly the same degree of interchange 
as you have with XML. Any generic XML processor can process any XML 
document, just as the Omnigator can omnigate any topic map.

Does that mean that any XML "application" (= piece of software implemented 
to perform specific business logic) can process any XML document in 
accordance with the author's full intent? No, not in the general case. If I 
send the XML document that governs our local nuclear power plant to the app 
that runs my fridge and orders my groceries, nothing of much use is going 
to happen.

It's the same with topic maps: The OperaMap application 
(http://www.ontopia.net/operamap) is not going to make a lot of sense out 
of your topic map on biblical literature. But that doesn't mean we can't 
combine those two topic maps usefully: There are a number of common 
subjects, including the characters Ishmael, Queequeg, Ahab, the countries 
Egypt, Israel, and Palestine, etc.

>>I no longer believe the RM should be part of ISO 13250.
>Well, we all have opinions about various possible parts of a future ISO 
>13250 but simply stating them without more, does not give anyone a chance 
>for a meaningful response.

Without more what? Is it not abundantly clear that my opinion that the RM 
does not belong in ISO 13250 is based on two key points:

(1) It has absolutely no use.
(2) It has nothing to do with topic maps as defined in 13250.

>You have responded, despite limitations of time, to various comments on 
>the SAM and on HyTM. I think we could move towards a consensus in SC34 on 
>the RM and various other matters if you have the time to assist with 
>technical comments on the latest RM draft.

This has a lot to do with motivation and readability. The more unreadable 
something is, the more motivation I need to provide detailed comments.

I also believe there is little point in providing detailed comments when my 
primary concern is with the thing as a whole.

Demonstrate to me a real business need for the RM and I will make the 
effort. I have repeatedly stated what would be most likely to convince me 
(one way or the other): a SAM->RM mapping, a TMA2->RM mapping, and a 
demonstration of how those two mappings increase interoperability between 
the two "TMA"s.

All we have been given so far is the HTTPGET application. This could in 
theory be considered TMA2, although it is really just a tiny, tiny subset 
of the SAM (that models the subject/subjectIndicator and 
subjectIndicator/subjectIdentifier relationships). What it shows is the 
incredible amount of detail required to map even something simple to the 
RM. We still lack the SAM->RM mapping, and most of all, we lack any 
indication at all as to how these "TMA Definitions" are of any practical 
use to anyone.

Show me how the RM improves interoperability between Topic Maps and RDF and 
you stand the best possible chance of winning me over. I don't believe you 
can do it.

Steve