[topicmapmail] Merging associations
Joril Andersen
jorilandersen at hotmail.com
Fri Sep 15 05:14:07 EDT 2006
Hi Murray and Lars,
yess, this was what I was thinking also! You only need to check the
mergeTable(where all the new topics are put) because if the associations
references the same topic it must exist in the mergingtable. And in the
table where the merged topics now should reside, will have one objectID, it
should be easy to just check this id?
1.One can either check for duplicates and add the association or don't or.
2. Check merging potential, going from bart has a child Bart--> he has also
Lisa as a child.See the example from the TMAPI.
I have implemented the first one so far. Do you consider that solution much
poorer than nr 2?
This is impemented in a topic map engine for mobile devices (MTV)and any
resource-saving method is a bonus; )
Joril
Joril Andersen
Helgesens gate 3
0553 Oslo
Mobil: 95256088
>From: Murray Altheim <murray06 at altheim.com>
>To: topicmapmail at infoloom.com
>Subject: Re: [topicmapmail] Merging associations
>Date: Thu, 14 Sep 2006 15:29:52 -0700
>
>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
>
>_______________________________________________
>topicmapmail mailing list
>topicmapmail at infoloom.com
>http://www.infoloom.com/mailman/listinfo/topicmapmail
More information about the topicmapmail
mailing list