[sc34wg3] Topic Maps land and SAM land

Nikita Ogievetsky sc34wg3@isotopicmaps.org
Sun, 9 Feb 2003 22:43:37 -0800

* Lars Marius Garshol
> * Nikita Ogievetsky
> |
> | As I have mentioned in the other thread,
> | I often tell people upon reviewing their implementations:
> | "You know, your architecture is very close to topic maps."
> | I do not mean that they have occurrences and basenames explicitly
> | out.
> | I mean that they have some indexed material, subjects, structured
> | relationships between subjects, defined structures, etc.
> | Something that is representable in RM.
> Well, would it be any easier for them to use the RM than to use SAM?
> Let's, for the sake of the discussion, assume that there were as many
> RM tools as SAM tools. Would it make any difference? How could they
> use the RM more easily than the SAM?

If you read my messages again, I was only trying to say
that SAM API (not necessarily the SAM in the form that it exists now, but
SAM 4.7, or whatever)
is the most convenient one for TAO Topic Maps (sorry, Martin, it is just
very convenient to say this way).
Also note that SAM tools are by definition RM tools - so I do not understand
the distinction.

> The RM people keep claiming that the RM can be applied more easily to
> data in other models/formats than XTM, and that this cannot be done
> with SAM, but that claim makes no sense to me.

Oops, I am not an RM person. I am an RM&SAM person.
(Talking about names: I used to work with an Indian guy whose name was
Ramasami :-))

> Quite a bit of the paid
> work I've done over the last months has involved mapping existing
> information to topic maps[1] using our autogeneration toolkit. I've
> mapped information in ordinary XML documents, in HTML documents, in
> CSV files, thesauri in textual formats, glossaries in XML format, and
> bibliographic databases in XML format, and it has all been *easy*.

Excellent! Surprisingly I have also done this for leaving (and I liked it).

> So I would really like to know what basis people have for claiming
> that the RM simplifies anything in this regard. Have you even done
> this, or are these claims simply conjecture?

Are you talking to me? :-)
Where in my messages did you find these claims?
I think that "simplifies" is a wrong word. See bellow.

> | And here they are invited into the SAM land, if they choose to.
> | But they do not have to. Sorry, dear vendors.
> | But do not get upset: as times goes they may come back.
> | If they have a clear picture of how their knowledge representation
> | is mappable into RM, the easier will be migration into the SAM land.
> |
> | But lets welcome everybody who speak Topic Maps :-)
> Nikita, I don't see the difference. It's not that I object to any of
> what you say, or think that it's all wrong. What I don't buy is the
> "they are already using a form of the RM"-bit. You have to do some
> kind of mapping and conversion regardless of whether you use the RM
> or the SAM, and I can't for the life of me see that there is a real
> difference.

I think that the confusion comes from the notions of SAM and RM.
When I am using them, I am referring to the future versions of SAM & RM,
they may even have different names then.
I agree that SAM may be THE API for XTM, HyTM and any structures directly
mappable into XTM.
(I actually liked Michel's "TAO model" naming suggestion.)
But lets try to embrace other knowledge structures.
You, Lars, said that you had mapped arbitrary structures into XTM (or SAM)
and it was easy..., -
what exactly have you done? What had driven you to map those structures to
one topic map construct or another?
I think that you had implicitly (without admitting that - almost
unconsciously) parsed those constructs to the RM level and then reassembled
them on the TAO level, decided on the ontology, etc.

All I am saying is: lets make hidden explicit.
It is not diminishing the value of the SAM.
But it expands the Topic Maps territory.

I would say "we are saying" here if I were absolutely sure that Michel,
Patrick and others share this view.
I think that our vision is very close.



Nikita Ogievetsky, nogievet@cogx.com;
Cogitech Inc.        http://www.cogx.com
Topic Maps Tutorials and Consulting.
phone:  1 (917) 406 - 8734