[topicmapmail] Regarding (COMPOSER v. composer example)

[MARK DRAGAN]

Regarding  (COMPOSER v. composer example), hierarchies, classes, 
sub-classes, and instances of, etc. I'd like to take a step back for a 
moment and look at the big picture. Like early attempts at programming in 
the OO paradigm, it took a while for programmers to "think" in terms of OO. 
They initially used OO tools and constructs, but thought in Structured 
Programming terms. There is a fundamental paradigm shift that is going on, 
of which TM can serve as a fundamental enabling tool. I call it Attribute 
Oriented Programming, which could be called Association Oriented Programming 
because the association of attributes is the focal point of the paradigm. 
Just as objects were the focal point of the OO paradigm, the attributes 
within objects and their associations to other attributes of other objects 
becomes the focal point of this emerging paradigm.

A major mathematical tool/approach that TM can heavily leverage is Set 
Theory, as you know (just getting us on the same page). Topic Map solutions 
must deal with set theory because, in my opinion TMs ARE sets. Therefore 
their problem domain is more closely aligned with set manipulation than 
hierarchy manipulation. Though there can be embedded hierarchies within 
sets, hierarchies are not necessary. I contend that practical Set Theory is 
fundamentally about establishing associations between groupings (which can 
be viewed as the function of Topic Maps.

When one keeps in mind that each TM implicitly defines a context (frame of 
reference) (point of view) within which topics are defined, it becomes 
possible to map one TM to another, as you know. TMs are Sets. Sets are 
points of view. The call is to be able to work and think at a level that 
defines, works with, and utilizes points of view. When mapping TMs (sets), 
you can establish parallel relationships, associations, roles, and 
hierarchies, etc. That is, the hierarchical structures within two separate 
TMs (sets) can parallel or mirror each other. This, I believe, provides the 
direction for finding solutions to the class-subclass, instance-of, 
important association (COMPOSER - Beethoven) - less important association 
(composer - John Doe) relationships.

The approach here is to define small, but whole TMs, for each parallel 
hierarchy or association set say (Important composer TM vs. Lesser composer 
TM) and allow the word composer to be cross indexed/mapped. The word could 
also be weighted and contextualized, that is, defined relative to a larger 
TM. I agree that this is a complicated process, but it does permit 
associations, topics, and context's to be created without the need to name 
them. This may seem alien, but it has many benefits, least of which is their 
ability to enable automatic or implicit TM definition. It allows TMs to 
serve as unnamed links in a chain, nodes in a hierarchy, stages within a 
process through which one gets from one TM to another.

One of the prerequisites for Knowledge Engineering is having the ability to 
determine semantic likenesses and differences. When comparing whole, 
weighted TMs it gets EASIER to determine the semantic likenesses and 
differences of a term such as "composer", because you also get the context 
(Topic Map) within which that usage of the term occurred. Notice that this 
can include temporal markers and/or links. Also notice that "EASIER" means 
'easier to determine semantic similarity", not ease of processing or CPU 
usage. It makes clarity easier, which requires more processing effort. TMs 
can compare maps, no? This ability can apply to their contents and 
associated weights.

To me, dealing effectively with TMs requires a paradigm shift in thinking 
toward Set Theory as applied to Knowledge Research. This, however, points 
out that the real problem is that knowledge research is barely in its 
infancy.

Mark






_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail