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

[Dmitry]

> | [Dmitry]
> | 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.

>[Lars Marius Garshol]
> 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?

I think that topic map represented in XTM, for example, has "hidden" dynamic
information in "mergeMap" element and in implicit references to other topic
maps. When we represent this topic map in SAM we "lose" this information.
More accurate, SAM enforces to load ALL maps and merge them in "one big
step". So at the beginning we have empty model (no topic map item). We do
deserialization as "one big step" and we get  internal data model at the
end. In this case we do not lose information. But the price is - "ONE big
step". Is it compatible with  "open world" assumption (which I think is
extremely important for Topic Maps)? So I think that topic map item in SAM
should have a property which is equivalent of (or better say is internal
model for) "mergeMap".


> | [Dmitry]
> | 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.
>
>[Lars Marius Garshol]
> 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

I think we need some clarification what these extensions could be. How it
can be done? Any analogy with Java "extensions"? I think it is important to
describe extension mechanism because very often "extensions" become standard
in next generation.



> | [Dmitry]
> | 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.
>
>[Lars Marius Garshol]
> 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.

Invariant? I like that... But question is what  invariant is and what
operations we take into consideration. I think that basic operation is "load
and merge one topic map with what I have already in SAM". My suggestion is
to add my favorite properties to existing SAM invariant. So we have existing
SAM + "HasToBeMergedWith" + "AlreadyMergedWith". Operation (Load and Merge)
updates SAM and my favorite properties  I have all information in extended
SAM (SAM+ ?) to support process. Take topic map from "HasToBeMergedWith",
load and merge it with SAM, delete from "HasToBeMergedWith" add to
"AlreadyMergedWith".  It reminds me Dijkstra's loop invariants...


> | [Dmitry]
> | 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.
>
>[Lars Marius Garshol]
> 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?

Now, we can extend SAM+  (SAM++ ?) and  assume that each item in SAM  has
"IsSupportedBy" property which keeps list of  IDs of topic map-"supporters"
.  We can introduce operation "Update one of the topic maps loaded in SAM
with new version". SAM++ has enough internal information to perform this
operation. SAM does not have enough information to do it efficiently, SAM
has to do loading and merging from the beginning.  BTW, "HasToBeMergedWith"
can be updated by this operation. We can combine our two basic operations
and keep invariant.

That is what I have so far...

Dmitry