RE: [xtm-wg] Reification of topic map constructs

["Daniel Rivers-Moore" <daniel.rivers-moore@rivcom.com>]

At last I think we're getting close to the bridge we need between the work
of the syntax group and the work of the conceptual modelling group.

Sam says: "Part of my confusion is that I am used to believing that the
topic map
graph is isomorphic with the <topicMap> markup. But this is not so,..."

and in a private email to me (I hope you don't mind me quoting you, Sam), he
says: "I searched the November 7 CMS proposal for the string "graph" and
found nothing. So I'm experiencing cognitive dissonance.  Is the CMS in fact
going to explain how to create a topic map graph? If so, how?"

Daniel responds:

The CMS is creating a formal description of the objects that must exist in a
system that is processing one or more Topic Maps. These objects are the
"nodes" (if you like that term) in a "Topic Map graph" (if you like that
term). The boxes in the UKL diagrams represent types of object (types of
node ...) that will exist, and the lines between them represent types of
relationship that will exist betwen objects of those types, or between the
types themselves.

The lines with hollow triangle arrow-heads are subtype relationships between
types of object. They say "every object of type x is also of type y, where y
is the box pointed to by the white triangle and x is the box the arrow
starts from.

The lines with black diamonds say "Objects of this kind 'contain' (in some
sense) objects of this kind (perhaps with some cardinality constraints)".

The lines with no end-blobs represent relationships between objects of the
types represented by the boxes at either end, and the words beside those
lines represent the roles those objects play in those relationships.

The lines with a simple v-shaped arrow head at one end also represent
relationships between objects of the types represented by the boxes at
either end, but they are only "traversible" in the direction of the arrow.
In other words, the object of the type pointed from, knows it has that
relationship with the object of type pointed at, but the inverse is not the
case.

These then are the objects and relationships that will form what Steve calls
the "Topic Map graph".

We happen not to be using the term "graph". We happen to be using a
graphical syntax rather than a text-based syntax to express the model. But
what we are developing is precisely a formal description, in a widely-known
syntax (an imperfect one, but nonetheless one that thousands of developers
out there use and are familiar with), of the objects that will result from
having parsed an XTM document and interpreted its semantics.

Operations, such as merging, or query resolution, can then take place on
those objects, and the result will be (if we are successful in achieving
"closure") other sets of objects that also conform to the structures and
constraints of the model (in other words, a merging of two topic maps will
itself be a topic map, and - hopefully - the result returned by a topic map
query will itself be a topic map). The topic map that results from the
operations of merging and querying (and perhaps other operations to be
defined), will exist in memory in exactly the same form as the original one
or ones, and can be serialised for storage or for interchange as XTM
documents that will conform to the XTM syntax.

There is a barrier to understanding that arises from the fact that the
syntax group is using DTD syntax and the modelling group is using UML
syntax. This is one of the reasons why it is the intent of the CMS, once the
UML model and the DTD are stabilised, to express the conceptual model as a
property set (in other words, use a textual formalism that is familiar to at
least some of the XML community, and can be expressed as an XML/SGML
document so that those not familiar with property sets will at least be able
to read it and feel "at home"), and also to express the sytactic model (the
DTD) in UML (thereby making it accessible to non-DTD-savvy developers who
are familiar with UML). Furthermore, we intend to add to the pair of UML
models - the "conceptual" model and the "syntactic" model - appropriate
arrows, blobs or whatever else UML syntax requires - to express precisely
the relationships between the syntactic and the conceptual model. This
"mapping" will enable developers to see clearly what bits of syntax in an
XTM instance have to result in the creation of what types of node, arc or
whatever in the Topic Map graph, (or, if you prefer a different vocabulary,
what kinds of object and association between objects in the in-memory
representation of the topic map).

Before Dallas I shall be preparing a further release of the UML model, which
will include some additional diagrams and some additional and reworked
explanatory prose. Between Dallas and Washington we may or may not have time
to develop the property set and/or the UML syntactic model, and we may or
may not have time to develop the UML representation of the mapping between
the syntactic and conceptual models. Whether we can achive these things or
not will depend in part on whether Eliot and/or Peter can find time to
contribute ... But at the very least we should have a clear, formally
expressed syntactic model (the DTD) and a clear, formally expressed
conceptual model (the UML diagrams) and appropriate amounts of explanatory
prose clarifying the meanings of these models and the relationships between
them.

Daniel

-----Original Message-----
From: Sam Hunting [mailto:sam_hunting@yahoo.com]
Sent: 08 November 2000 16:49
To: xtm-wg@egroups.com
Subject: Re: [xtm-wg] Reification of topic map constructs


> Note 1: "Reification" herein means "The creation of a topic node in a
>         topic map graph...

What does the term "topic map graph" mean?

The best definition I have been able to find is "the set of
interconnected topic nodes, etc., that result from processing a topic
map document."

(1) The term "node" is a little overloaded right now.

One thinks of DOM nodes, even nodes in dynamic HTML, and therefore one
thinks, wrongly, that standard XML tools are sufficient to process
topic maps. (They are necessary, but not sufficient.)

Part of my confusion is that I am used to believing that the topic map
graph is isomorphic with the <topicMap> markup. But this is not so,
given that the creation of topic nodes in the topic graph can be
"demanded by" the presence of elements in the <topicMap? document that
are not <topic>s.

Perhaps, in the context of TM documentation, "pnode" (for "processed
node")?

(2) Are all the pnodes in a topic map graph of type "topic"?

(3) Are the interconnections between pnodes typed?

Lots of other questions but these will do for now.

S.

=====
<?-- "To imagine a language is to imagine a form of life."
     - Ludwig Wittgenstein, Philosophical Investigations -->

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com


-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/1/_/337252/_/973783907/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com