[sc34wg3] Topic map view

Patrick Durusau sc34wg3@isotopicmaps.org
Wed, 18 Aug 2004 17:40:31 -0400


For those of you who were unable to attend the Montreal reference model 
workshop meeting, be aware that a new term has sprung into being!

"Topic map view"

My personal recounting of the meaning of that term follows. Other 
participants should contribute corrections/additions/etc. so that we cna 
reach a consensus on what we will mean by this term.

The term came about due to the realization that "topic map" has been 
overloaded in terms of its usage.

For example, does "topic map" mean an instance of HyTM, XTM, LTM, or 
other syntax only? Or does it include an internal representation of the 
TMDM, whatever syntax was used for input? Or does it include viewing 
information within a specific environment as a subject-centric environment?

This is more than a theoretical question since it is one thing to do 
data conversion on small (relatively speaking) data sets to build web 
portals, but quite another to ask the New York Times, LexisNexis, 
Boeing, the European Parliment, United Nations, any governmental body 
really, to convert their data sets in order to use topic maps.

The answer that makes the topic maps paradigm scale to such uses, is 
that of the "topic map view."

Newcomb suggested the following formulation of topic map view:

(a representation of a topic map of type X)
+ (a set of rules for interpreting topic maps of type X)
= (a topic map view) -- an interpretation in which everything has
                         become explicit as a set of subject-centric
                         information environments.

In other words, a "topic map view" is a particular way of seeing some
particular data as a particular topic map.

So what's the exact nature of a "topic map view"?  What distinguishes
a "topic map view" from anything else?

      (1) In a topic map view, you can always detect when two
          subject-centric information environments have the same
          subject, and

      (2) When subject-sameness has been detected, the two information
          environments can be merged, becoming a single,
          more-comprehensive information environment, with the same
          subject as its invisible heart.
**/end Newcomb**

Note: Read "subject-centric information environment" as subject proxy. 
That is to say, each instance of a subject proxy has its rules for 
subject sameness and what happens when that is detected (these rules are 
specified for classes of subject proxies) such that it creates what 
Newcomb calls a "subject-centric information environment." A topic map 
view consists of a set of subject proxies and should not be confused 
with the database or set of RDF statements that are being viewed as a 
set of subject proxies. (Databases, sets of RDF statements, etc., are by 
definition not topic maps nor are they topic map views.)

I disagree with Newcomb's #1, but only to the extent that it claims the 
"same subject" can be detected. Perhaps, perhaps not, but what is 
detected is that two or more subject proxies are found to be the "same" 
under the rules for that environment. May or may not have the same 
subject, that judgment is beyond the pale of the topic map processor 
and/or the topic maps paradigm. No doubt that is the intent of most 
topic map authors, but whether that has happened or not, is not really a 
concern for ISO 13250.

Same problem with #2. Yes, two subject proxies can be merged based on 
the rules that detected they are the "same" under some set of rules, but 
has little or nothing to do with their respective "invisible" hearts.

Personally I find it confusing to talk about "subjects" as "invisible" 
hearts and at the same time know that what is being compared is based on 
a rule for a particular topic map view, which may or may not result in 
the same "invisible" hearts being gathered together. Mistakes happen 
both in data entry, rule construction and the like. Can't we simply say 
that when specified rules are meet, subject proxies can be merged and 
let it go at that? The better your rules, the closer your outcome will 
come to being acceptable for your purposes.

Note that from a "topic map view" standpoint, any instance of what we 
now call topic may syntax, HyTM, XTM, LTM, AsTMa, is subject to being 
viewed through a "topic map view."

Hope everyone is having a great day!


Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!