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

[Dmitry]

I sent email to Lars several  days ago with some ideas about SAM extensions.
He encouraged me to post my email to the sc34wg3 list...
So I am posting my original email...and I hope we will post two other old
emails which we have in this thread soon.

Dmitry

-----------------------------original email to Lars----2003-02-05----------
....
I just finished reading last threads in ISO sc34wg3 discussion group about
SAM/RF/TMCL/TMQL and have some questions/ideas about SAM.

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.

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. To support this scenario I defined relationship, something like
that:
hasToBeMergedWith(factID,TopicMapItemID,TopicMapItemID,Explicitly|Implicitly
,MergingStatus)

I also added property "LoadingStatus" to topic map item. Now topic map item
can be created before loading full map and full map can be loaded and merged
later any time.

I also have temptation to add something like: "LastTimeUpdated",
"NextTimeToUpdate". 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. Look at XFML!
In several phrases they "define" most important dynamic process within their
maps. We can easily "see" how this distributed system works.

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). 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. And, I think, with this concepts
we can replace mailing lists software with topic map based solution :-)

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