[topicmapmail] Merging associations

[Murray Altheim]

Quoting Lars Heuer <heuer at semagia.com>:
> Hi Joril,
>
> [...]
>> I was wondering why there is not mergIn method for associations in TMAPI? I
>> know some implementations simply add the associations from the otherTopicMap
>> to the new topicMap.
>
> Well, the question is: Where to stop?
>
> I.e.: If the assoc-type AT is an instance of an other topic OT. Is OT
> added to the other topic map or not?
> Same with the players and role-types. Are all relationships between
> them and other Topic Maps constructs are copied to the other topic map
> or not?
>
> You see, there is no "simply add" for associations.

Lars,

It seems you're making this more complicated than necessary.
There are admittedly a lot of operations that could be construed
as recursive, but it's also within any designer's options to
limit those. A mergeIn operation for Associations would be a
very welcome addition -- I had to write my own, as would anyone.

The "where to stop?" question is in this case relatively simple:
don't merge any Topics when you've been asked to merge an
Association.

Since in XTM we don't embed Topics within Association, but
references to them, it would be a relatively simple question of
checking to see if any of the Topics referenced within the
Association (as association types, players or role types) are
part of the incoming TopicMap, and if so, making the reference
local to the merged TopicMap, if not, a reference to the Topic
in its original TopicMap. It's a bit of a chore simply since
Associations are a more complicated than Topics, but this doesn't
require any recursion and doesn't seem particularly onerous.

The one danger of leaving out a fundamental feature such as
this is that implementors, when left to their own devices with
no guidance, may make different decisions in their own
implementations (such as deciding to recursively merge in all
referenced Topics, which is another option). The other danger
is that leaving out somewhat fundamental features from an API
means that implementors using it have to build their own versions
of those features, which makes the bar to entry a bit higher.
And with Topic Map processing not the easiest to grok (a lot of
people think you can treat an XTM document as XML), the chance
of error is also higher.

This isn't meant as any sort of tirade -- just my 2c having
recently had some experience working with TMAPI rather than
the native TM4J interface (which I've been using for years).

Murray

...........................................................................
Murray Altheim <murray06 at altheim.com>                              ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

        In the evening
        The rice leaves in the garden
        Rustle in the autumn wind
        That blows through my reed hut.  -- Minamoto no Tsunenobu