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

[Sam Hunting <sam_hunting@yahoo.com>]

Daniel, thanks very much for your reply.

[sam]
> 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,..."

[daniel]
> 
> 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).

I like both the terms "node" and "graph". What I am trying to figure
out is if the specification will use the terms, or if they are only for
internal use by the AG. 

Personally, I'm for them, since graphs are a well understood formalism
(like hedge automata in RELAX). Does the graph formalism in fact "fall
out" of the restricted subset of UML used by the CMS? (Great work, by
the way. The 11/07 effort is very impressive. "As simple as possible,
but no simpler" -- Einstein)

> 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.

Uh, the "cheat sheet" you sent says, for the relationship between the
box labelled "human" and the box labelled "shelter" that the relation
is labelled "home" indicating that the type "Human" has an attribute
named home whose value is a single "shelter" object.

    "Human" -------- +home -----> "Shelter"

What you write and what the cheat sheet says don't sound quite the same
to my untutored ear. I take it that by establishing a (typed) relation
(arc) ebetween two objects (nodes) I am also giving values to
properties of one (both?) object(s) (node(s)) in the 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...

I would be happy to be assured that the imperfections are not material
for XTM -- but even more happy to have that demonstrated.

> 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"

I understand that a topic map engine does not operate directly on the
topic map markup, but only on a graph that contains properties (some
emergent) that derive from the markup. (This is why the graph is not
isomorphic to the topic map document, which is counter-intuitive to
someone brought up on the DOM, for example.) 

So far, so good -- but what is "closure" (on a postcard, please) and
what is the test to pass that tells me that I have achieved it?

> 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

Sorry, I understood the result of a merge to be a topic map *graph*
(from which markup that was a topic map document could indeed be
derived, although this would [????] suppress properties that emerged
from the merge -- nice sound to that -- although not those *added* to
the merge via <mergeMap>.)

> topic map that results from the operations of merging and querying 
> (and perhaps other operations to be defined), will exist in memory

In memory? When topic maps can be gigabyte-sized? Surely this is
dangerously close to implementation...

> in exactly the same form as the original one or ones

I'm not sure how to test this. For example, from dabbling in graph
theory, my understanding is  no one knows a simple method for taking
two graphs and determining quickly whether or not they are isomorphic.
So how do I know that the forms are exactly the same?

> 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 

Super. Great news -- I hadn't heard that said before (even if it was
said ;-)

> 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)

This is certainly good at least from a marketing standpoint.

My primitive understanding of UML, at least from the ebXML world, had
led me to believe that although *a* DTD can be derived from a UML
model, it is not so easy to derive *a particular* DTD, and in any case,
a DTD doesn't "fall out" of the model. (In other words, DTD creation
has its own integrity as a design process.)

But maybe you guys know something I don't. More than likely!

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/

-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973789557/
---------------------------------------------------------------------_->

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

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