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

[Kal Ahmed]

At 15:31 09/02/2003 -0500, Dmitry wrote:
> > | [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".
>

In addition, it would be useful to have a property which is a list of all 
external topic map resources referenced from the topic map through 
<topicRef> elements.

These two properties would be especially useful in processing in an 
internet environment where one or more resources may be temporarily
unavailable.

Cheers,

Kal