[topicmapmail] What tools to use for colaborative topicmaps editing

Kal Ahmed kal@techquila.com
Mon, 16 Dec 2002 17:11:05 +0000


On Monday 16 December 2002 15:36, Marius OANCEA wrote:
> Kal Ahmed wrote:
> >On Saturday 14 December 2002 06:57, Marius OANCEA wrote:
> >>My question is:
> >>    What tools you sugest to use when the working environmis nent is:
> >>
> >>    * 40 editors editing the same topicmaps
> >>    * the 40 editors are domainexports to informatics experts
> >>
> >>The ideea is that I have a lot of books and I want to create a topicm=
aps
> >>to replace all this books.
> >>In a colaborative environment you neet tools to avoid conflicts. What=
 do
> >>you propose here?
> >
> >Question: Do the 40 editors really have to work *on the same topic map
> > file* ? Or do they simply need to be able to work on the same ontolog=
y ?
> > If it is the latter, then you can have the 40 editors work separately=
 and
> > merge the 40 topic maps they produce. If each starts with a topic map
> > representing the basic topic map ontology and with a set of editorial
> > guidelines (or other constraints such as the constraints you can expr=
ess
> > in Protege), then you should end up with mergeable and consistently
> > produced topic maps.
>
> Yes and no.
>     No,  if the topicmap designer split the topicmap in the right way
>     Yes, when you have to meke associations between topics in different
> XTMs.
>
>     If the ontology is changed, how to propagate the change in all XTMs=
 ?
>

That depends on the change. If the change is an addition of new terms int=
o the=20
ontology, then propagation could be either by changing the central ontolo=
gy=20
TM which all editors reference from their TM or by sending out an increme=
ntal=20
TM consisting of just the updates to the editors (which their application=
=20
would then merge with the existing ontology TM) - I think that the former=
=20
option is more robust. If the change would cause some of the existing wor=
k=20
done by the editor to become "invalid", then I think that the only way to=
=20
handle this would be to include a specification of the constraints of the=
=20
ontology (e.g. using OSL or AsTMa! or eventually TMCL) within/alongisde t=
he=20
ontolog topic map. That way authors could be guided by a TMCL/OSL/AsTMa!=20
aware editing environment to make the changes demanded by the change in t=
he=20
ontology.

Disclaimer: This is mostly theoretical - there is not AFAIK an applicatio=
n=20
which would do all of this for you. Although you may get a good deal of t=
he=20
way there with existing topic map engines.

Cheers,

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

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