[sc34wg3] a TM Application Definition example

[Steven R. Newcomb]

Lars Marius Garshol <larsga@garshol.priv.no> writes:

> * Steven R. Newcomb
> |
> | An example of a TM Application Definition, defined as required by
> | N0393 ("the TMM"), is now available at
> | http://www.isotopicmaps.org/TMMM/HTTPGET-latest-clean.html
> 
> Thanks much for writing this up and posting it. It really does make it
> clearer what a TMA might be and how one might look. 
> 
> However, it also does raise the question of what this is good for. I
> mean, you've now created a TMA. What could someone use it for? How
> would they use it? How would they be better off than they were before
> the TMA was created?

A Topic Map Application Definition is analogous to a Document Type
Definition.  Both can serve as a basis for interchanging information
between people who wish to interchange that kind of information.

SGML/XML serves as a foundation for a paradigm in which a single
parsing discipline -- variously implemented in various technologies --
allows information expressed in an unbounded number of syntaxes,
representing an unbounded number of semantics, to be interchanged in
conformance with that single parsing discipline.  The author of an
SGML/XML document that conforms to some SGML/XML syntax can reasonably
expect everyone in the world to get exactly the same results -- always
the same parse tree -- from any conforming parser.

Similarly, the TMM serves as a foundation for a paradigm in which a
single processing discipline -- variously implemented in various
technologies -- allows any topic map, expressed in any syntax,
representing an unbounded number of semantics, to be interchanged in
conformance with that discipline.  The author of a topic map can
reasonably expect everyone in the world to get exactly the same
results -- the same network of connected subjects -- from any
conforming implementation.

The answers to your questions...

* What is a TMA good for?

* What could someone use it for?

* How could someone use it?

* How would they be better off than they were before the TMA was
  created?

... are the same for any particular TMA definition as they would be
for any particular DTD.  The answer is always: "Well, that all depends
on the person, the situation, and the DTD (or TMA)."  In the absence
of a great deal of specific information about the person, the situation,
and the DTD (or TMA), it's not possible to answer your question.

The power to create and interchange TMAs, and the power to create and
interchange topic maps that are based on them, has at least as much
value as the power to create and interchange DTDs, and the power to
create and interchange SGML/XML documents that are based on them.  If
you accept that this kind of power has value for interchangeable
documents (SGML/XML), and if you accept that it's desirable to
interchange networks of subjects (Topic Maps), then I think you must
accept that the power to create and interchange TMAs also has value.
It is precisely because we cannot predict the full range of uses to
which this kind of power will be put that we find SGML/XML -- and the
TMM, in the case of topic maps -- so important.

In his book (I highly recommend it), *The Future of Ideas*, Larry
Lessig recounts the story of the development of AT&T's "intelligent"
telephone network.  It was a marvel; it was optimal for carrying
telephone conversations between A and B.  But the whole infrastructure
had to be written off when its competitors began to offer
packet-switching service.  Although the competing networks were
designed for a far more general set of purposes than just carrying
telephone conversations, the new networks actually worked better for
telephone conversations, too ("You can hear a pin drop").

The new packet-switching networks were designed to be a platform for a
mix of purposes and products that nobody could predict.  They were not
designed to cater to any particular business purpose.  The designers
adopted a doctrine they called, "End-To-End", or "E2E".  The network
was designed to move packets from any point (point A) to any other
point (point B), within parameters that were tunable to some extent,
but the reasons anybody might have for moving the packets were
deliberately ignored by the designers.  This approach maximized
opportunities for everyone, and it prevented a situation in which the
design of the network itself would later turn out to be an obstacle to
progress.  And the E2E design principle proved to be RIGHT!
Everything is packet-switching, now, and the public has benefitted
from improved services, from a much wider variety of service modes,
and from all the businesses that have sprung up to exploit them.

  Note: AT&T probably didn't want to be bothered with developing a
        different business model, one not based on its cash-cow
        operation of providing telephone service.  But it could not
        stop progress.  Even AT&T faced the Darwinian choice: 
        adapt or die.

Lessig goes on to say that the World Wide Web and the HTTP protocol
were also based on the E2E principle: Nobody knew the range of things
that the Web would be used for, really, but everybody knew that it
would be useful for a great many things.  Again, the intent was always
to make it as transparent as possible, and to keep it from becoming an
obstacle in the future.  And, again, the E2E design principle was
right!  The Web's sudden ubiquity speaks for itself; it is the
wonder-story of the decade.

With Topic Maps, we are now approaching a similar crossroads to the
one that AT&T faced, decades ago.

Analogously to the AT&T "intelligent" telephone network of past
decades, we already have a topic map standard that is very well
adapted to being used in certain ways for certain things, namely,
indexes, thesauri, glossaries, and the like.  In that limited world,
everyone agrees that Topic Maps are marvelous.  We have nothing to
apologize for, here.  (And neither did AT&T, just before it was forced
to write off its investment in its "intelligent" telephone network.)

Now the possibility exists to provide something that's better than the
current generation of tools can provide.  Topic Maps, too, can adopt
the E2E design principle, and get out of the way of its future
would-be users.  The TMM shows a way to do it.  The business
opportunities that TMM-based technologies can afford will be far
broader than the business opportunities for today's TAO-oriented
technologies.

Remember that the E2E idea is to make the endpoints free to be in
whatever businesses they want to be in, unfettered by the network
designers' preconceptions about those businesses.  Unlike the service
provided by a packet-switching network, the "service" that the Topic
Maps paradigm is one of knowledge integration.  It facilitates the
achievement of a state in which, in a semantic network, every reified
semantic is reified in a single "place", by a single reifier.

  Note: I'm using the term "semantic network" in its normal sense,
        here -- please don't confuse what I'm saying with "The
        Semantic Web", even though its relevance to the Semantic Web
        is obvious.

Under the TAO idea, the Topic Maps paradigm only knows how to
integrate information about subjects only in accordance with certain
types of relationships:

(1) the type of relationship that exists between a topic and one of
    its subject indicators, and

(2) the type of relationship that exists between a topic and its name
    (if the name-based merging rule is enabled).

But different people have different ideas.  Different people have
different ideas about syntaxes and vocabularies for interchanging
their ideas, so they use XML.  Similarly different people have
different ideas about the identities of their ideas, and about whether
one idea is the same as another.  They will need to use Topic Maps,
with its ability to support definable Topic Map Applications (TMAs).
The TMM defines the Topic Maps paradigm and standard as empowering
these diverse people with their diverse ideas.  The TMM encourages the
development of new kinds of statements that identify the subjects
they're talking about.  Perhaps more significantly, the TMM allows us
to exploit all of the old ones that we already know, too.  The TMM is
about extending the franchise of subject-based information integration
as widely as possible.  It's about respecting and honoring the
diversity of ways of thinking about things, and it's about exploiting
them, both separately and in concert.

Modularity is the key.  The TMM requires TMAs to be defined in such a
way that they are all modular: any TMA can be included in any other
TMA.  

  * TMA modularity allows us to replace and enhance parts of the logic
    that supports subject-based integration without having to build a
    whole new implementation.  For example, a TMA originally developed
    for a web-based situation, where the HTTPGET TMA is appropriate,
    can be adapted to other situations by replacing the HTTPGET module
    with some other TMA module, or by simply adding another TMA
    module.  All of the rest of the logic -- the software that
    supports the other modules of the TMA -- can remain in place.

  * TMA modularity enables different TMAs to be included in TMAs that
    harmonize them, thus allowing topic maps that are expressed in
    terms of one world-view to be merged with topic maps that are
    expressed in terms of others.

Making the modules self-describing is also key.  The TMM is designed
to allow TMAs to be self-describing, by allowing them to "build-in"
their self-description facilities into every topic map they govern.
(Which is exactly where their self-descriptions can do the most good.)

> This is the sort of thing I really need to understand to understand
> what the RM is and what its value is. (I could give you feedback on
> the TMA itself, but that seems sort of pointless when I don't know
> what it's *for*.)

Needless to say, I'm interested in both kinds of feedback.

-- Steve

Steven R. Newcomb, Consultant
srn@coolheads.com

Coolheads Consulting
http://www.coolheads.com

voice: +1 540 951 9773
fax:   +1 540 951 9775

208 Highview Drive
Blacksburg, Virginia 24060 USA