[sc34wg3] SAM,SAM+,SAM++ Or how to extend SAM

09 Feb 2003 18:19:54 +0100

(Thanks for writing this, and also for posting it to the list. This is
a repeat of my original reply.)

* dmitryv@cogeco.ca
| 
| I just finished reading last threads in ISO sc34wg3 discussion group
| about SAM/RF/TMCL/TMQL and have some questions/ideas about SAM.

That's hard work. :-)

| After reading several times SAM for Topic Maps and playing with SQL
| server test implementation I am really surprised that standard data
| model does not have built-in support for merging and that it is
| limited by representing only one topic map. There is detail
| description of merging process in SAM, but I could not find any info
| items or properties supporting merging.

Well, the model describes SAM instances as consisting of a single
topic map only, but there's nothing to keep you from storing multiple
SAM instances in the same database. In fact, the OKS does just that,
and I would expect every other implementation to do the same. The
reason the model is limited to a single topic map is that there is no
need for anything more _in_the_specification_.

As for merging that comment surprises me a bit. Merging is a process,
not information, so how *could* there be items/properties for
describing it?

| The first thing which came to my mind when I was playing with SQL
| was concept of "lazy deserialization and merging". When I do
| deserialization of topic map, I probably would like to load into
| database only "main" topic map and to specify somehow that this
| topic map has some explicit or implicit merge-requests. Later, I can
| load and merge some additional topic maps. This process can again
| request some new explicit or implicit merges.  I am not saying that
| all topic map processors have to work this way. But I think SAM
| should support this type of functionality by reserving some data
| properties.

I agree with you that this functionality may be desirable in some
contexts, but if we put it in the SAM we'll require *all*
implementations to have it, which I think is exactly what you don't
want. The SAM explicitly says that implementations are allowed to
maintain additional information beyond what the SAM requires, and I
think this relationship is an example of that:

This is fine, but this falls into the category of what I would call
"system-specific information". You need it to make your implementation
approach work, and that's fine, but the SAM already allows you to do
it. 

| I also have temptation to add something like: "LastTimeUpdated",
| "NextTimeToUpdate". 

We've been there. :)  We chose to represent that as explicit
occurrences, but you can certainly make it system properties outside
the SAM-specified constructs. Again, this is something that is
explicitly allowed by the specification.

| So, it looks like I am looking for a way to standardize some
| important dynamic processes within topic maps. SAM does not define
| how topic map processor can update individual topic map. OK, we can
| guess how it can be done. But I think it is important to define what
| happens with merging results when one of the participating topic
| maps is changed. 

The best way to think of the SAM is as an invariant, if you are
familiar with that concept. At the beginning and end of every
operation you perform on your topic map it must conform to the SAM,
including the merging and duplicate removal rules. So long as you meet
that criterion you can implement any dynamic behaviour you want.

If you write an application that reads a CSV file into an already
existing topic map as a set of topics, names, occurrences, and
associations, that's fine. Similarly, if you have a script that goes
in and removes every instances of the class "river", plus the class
itself, that's also fine.

| Look at XFML!  In several phrases they "define" most important
| dynamic process within their maps. We can easily "see" how this
| distributed system works.

Now I'm curious about what you think the difference is. Could you
explain in more detail?

| Next thing that I really would like to have in my SQL-based
| implementation is ability to know for each item where it came
| from. After merging I still would like to know that topic T came
| from topic map A and topic map B (or: topic maps A and B support
| topic T).

This is something I have been thinking about myself. The question is
whether we should leave keeping track of this to implementations, or
whether we should standardize it. To be frank I am not sure what to do
about it. There does seem to be a need for this, so maybe
implementations should be required to do this.

(BTW, please feel encouraged to post this to the sc34wg3 list. I think
you are making valuable comments, and it would be useful to hear what
others think of them as well.)

| If I have this "support" information, I can easily implement updates
| for participating topic maps. It does not matter how (and why)
| specific topic map is updated. Important is defining standard way to
| propagate modification within set of topic maps connected with
| explicit or implicit merging requests. 

I think you can build that on top of the current SAM, but I may not
have fully understood what you are thinking. What are the problems you
have in mind that won't be solvable with the current SAM?

| And, I think, with this concepts we can replace mailing lists
| software with topic map based solution :-)

Would be a very nice thing to see. :-)

| Anyway, may be my thoughts are more suitable for "Best (I hope :-)
| practices" than for standard. But I really appreciate if you can
| share your ideas about "dynamic" aspects of SAM.

They fall somewhere near the border, I'd say, but they are definitely
useful. 

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >