[Tm4j-developers] Re: [TM4J-users] Design question concerning the TopicMapFactory

[Kal A. <ka...@te...>]

On Thursday 12 December 2002 11:48, mo...@gm... wrote:
> Hi again,
>
> > 1) It goes against the standard topic map containment model. Every to=
pic
>
> map API I
>
> > have worked with has a containment model in which topics, association=
s
> > and all the other topic map objects are contained in one and only one
>
> topic map.
>
> I understand the fact why you do not want a Topic to be an element of t=
wo
> different TopicMaps. But there are other ways to ensure, I think. I do =
not
> like the fact that if a TopicMapObject is created it is automatically p=
ut
> on a TopicMap. I just saw that a TopicMapObject like an Association or =
a
> Topic already know their parent. One could use that aspect to ensure th=
at a
> specific TopicMapObject has only one parent.
>
> You could say Topic.attach(TopicMap). If there is already a parent, the
> Topic would deregister there and register at the TopicMap given as a
> parameter. Moreover it would save the new TopicMap as its parent. If yo=
u
> want to have a "stand-alone-Topic" again, you could say Topic.detach().
>
> The benefit I see is that you can create single containers and componen=
ts
> (can be containers as well) which you can put together and apart the wa=
y u
> need it. It would be similar to Java-Swing-Components. At the moment I
> would need something like a "CacheTopicMap" to hold Topics I do not nee=
d
> right at the moment in a specific map. At the same time you could retai=
n
> the feature, that there is only one container for an TopicMapObject.
>

I can see the advantages of that approach, and it was the reason why I ha=
d=20
originally structured the API in that way. However, the detach()/attach()=
=20
methods would be somewhat more complex than you suggest as they would hav=
e to=20
deal with objects contained by the Topic object and objects referenced by=
 the=20
Topic object.

Using the mechanism of a "cache" or "scratchpad" topic map and then using=
=20
TopicMapFactory.copy() methods, you can approximate this behaviour as you=
=20
have already suggested.

> > For example, under
> > TM4J's dynamic merging model, your code could lead to myTopic being
> > merged
> >
> > with one topic from myTopicMap1 and one from myTopicMap2, but I think=
 it
> > would be messy if the API getMergedTopics() had to take a TopicMap as=
 a
> > parameter or if it returned a set of topics from different topic maps=
=2E
>
> This problem would not remain any longer if you can be sure that there =
is
> only one container for an TopicMapObject.
>

Thats true.

I cannot argue that there are not advantages to structuring the API as yo=
u=20
suggest. As is often the case, there are two equally good ways of approac=
hing=20
this, each with strengths and weaknesses depending upon your application.=
=20
Refactoring the code to support the structure you suggest is not a trivia=
l=20
operation (especially as it would have knock-on effects on the different=20
implementations and on the relational database schema). So I would have t=
o be=20
convinced by a show-stopper problem to change it at this stage...or by a =
lot=20
of people shouting at me ;-)

> I will also have a look at other TopicMapAPIs to see what the ideas the=
re
> were. Maybe you could tell me 1 or 2 you are refering to. But I still t=
hink
> TM4J is the best solution for our project and i am looking forward to y=
our
> next releases.
>

I am thinking of the TMAPI API (which TM4J also supports) -=20
http://www.tmapi.org/ and the Ontopia OKS API (I don't think that the API=
=20
documentation is public for that though).

> By the way: Shell i write such discussions in the public mailing list o=
r do
> you want me to write directly to you email address?
>

Lets keep discussing this, but on the tm4j-dev mailing list - that is the=
 best=20
place to discuss API issues I think; and it would be good to have some=20
thoughts from anyone else interested in this area. I have posted this rep=
ly=20
to that list.

Cheers,

Kal

--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy

e: ka...@te...
p: +44 7968 529531
w: www.techquila.com