OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: Topic Maps - current state of the art?

Hi Steve,

I've re-read chapter 3 of http://www.aw-bc.com/samplechapter/0201749602.pdf.

Maybe that is my Rosetta Stone after all, this passage in particular strikes me as such!

"Historically, the overwhelming majority of markup applications have been basically batch-typesetting jobs, which start at the beginning of the document and process each data segment in more or less the same sequence in which it appears in the document. The rendering of HTML documents by Web browsers is one example. The use of the word document to denote a class of information objects appears to have the connotation that all such information objects are intended to be rendered and used in the same order in which they are interchanged.

Currently, significant investments in the marketing of XML technology are directed at business-oriented information technology professionals. Such professionals are urged to regard XML as an opportunity to represent relational databases as interchangeable documents. All such documents, regardless of their schemas, are parsable by a single standard parsing technology, without reconfiguration. It’s obvious that a relational table is exportable and importable as a sequence of named or numbered rows, each of which is itself a sequence of named or numbered fields.

The Document Object Model (DOM) recommended by the World Wide Web Consortium (W3C) provides a convenient application programming interface (API) to the syntactic structure of information being interchanged in the form of XML documents. The DOM is extremely useful, but it has been oversold as the ne plus ultra API to interchangeable information. The DOM does provide applications with random access to every part of an interchangeable document, so it makes many applications much easier to develop than they otherwise would be. However, the DOM cannot provide direct access to the semantic components of what a document means; it can only provide direct access to the syntactic components of how a document is represented for interchange. Fortunately for the widespread acceptance of XML technology, which is basically a tremendous step toward global knowledge interchange, there are many popular kinds of information whose interchange is required for many kinds of economic reasons, including virtually all of the billboards on the information highway, for which the interchange structure can quite usefully be the same as the structure of the API. The DOM is a great all-purpose API for all of these kinds of information. Topic maps are another matter, however. As in the case of music information, the structure of topic map information is not the same as the structure of interchangeable documents.

Topic map documents can point to other topic map documents, saying, in effect, “The referenced topic map must be merged with the current one before the current one can be understood as its author intends.” If any single subject is represented by <topic> elements in both topic maps, the topic maps paradigm requires that the result of processing the two documents must be, among other things, exactly one resulting topic (represented in some application-internal form) that has the union of the characteristics (the names, occurrences, and participations in associations with other topics) of the two <topic> elements. Therefore, the only way to understand an interchangeable topic map document is to process it fully, performing such merging and redundancy-elimination tasks as the paradigm requires.

The element-containment structure of a topic map document, even in the absence of any requirement to  merge it with another topic map document, bears no resemblance to the structure of the relationships between topics that are expressed by that document. In other words, the API to topic map information is not, and can never be, the same as an interchangeable topic map that conveys that same information. From this interesting fact the question arises, “What is meant by an element type name, such as <topic>, in an interchange syntax like the interchange syntax of topic maps, in which there is no direct correspondence of the element structure to the structure of the information being interchanged?” The answer is that the meaning of such a tag name is, like all other tag names, exactly what the designers of the interchange syntax intended it to mean. For example, for every <topic> element, a conforming topic map application must have an application internal representation of that topic (that is, a topic whose subject is the same as that of the <topic> element). If there is no such internally represented topic, the application must create one; if there is already such an internally represented topic, the application must add to it (union it with) all the information about that topic that is represented by the <topic> element. The meaning of the <topic> tag name is still quite clear and rigorous; the only difference is that the meaning has to do with the creation of an application-internal form of the interchanged information—a form with its own API that must be used by conforming applications."

[Somewhat ironically, copying that passage from a PDF "batch-typesetting" device was not as 'sequential' an experience as one might have expected!]

Steve Cameron

On Tue, Oct 22, 2013 at 12:06 AM, Steve Newcomb <srn@coolheads.com> wrote:
I must admit that many say, as you are now saying, that they have found
the TAO article very helpful to them.  I guess the lesson is: We never
know in advance what the effects of our actions will be.  The one thing
we can be fairly sure about is that, as John Lennon famously put it,
"Life is what happens while you are busy making other plans."   (:^)

From my perspective, the "TAO" article by Steve Pepper permanently
confounded topic mapping, in the public's mind, with a single model,
which was later codified as the so-called Topic Maps Data Model (TMDM).
 It changed the meaning of "Topic Maps" from what I expected it to mean
into something that is fundamentally opposed to the agenda I was working
on when I coined the term, and both long before and long since then, too.

I wish I had a nickel for each of the times I've been asked, "Isn't
there an RDF vocabulary for Topic Maps?", as if topic mapping could be
boiled down to a specific syntax.  From the very beginning of Topic Maps
in 1991, that was exactly what I hoped Topic Maps would NOT be.  The
larger vision that I was pursuing was also the primary goal of the
precursor ISO 10744 HyTime standard, which I also co-drafted and
co-edited, and of HyTime's precursor, the now-long-neglected drafts of
ISO 10743 Standard Music Description Language.  I was a founding
co-editor of that one, too, starting in 1986.  (It has been a long and
weirdly eventful journey.)

Honest, capable, and respectable persons can have very serious
differences.  Here I'll paraphrase something Graham Moore once said to
me, "You can't make a useful industrial standard your way!  An
industrial standard has to boil down to something much smaller and more
concrete."  In vital respects, he was deeply correct, and I've always
been grateful for his candor.  But if it's true, then the *reasons why*
it's true are not good reasons, because those reasons oppose the
increase of human understanding, global prosperity, and the public

On 10/21/2013 07:26 AM, Stephen Cameron wrote:
> So, I have bought the book (found it in Australia cheaper than postage
> from the US) and am looking forward to a good read on an interesting
> subject.
> But having browsed the subject today, this article below seems to be the
> best introduction I came across, the analogies to familiar things (like
> book indexes) being very helpful to my understanding.
>   The TAO of Topic Maps
>   <http://www.ontopia.net/topicmaps/materials/tao.html>


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS