OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [topicmaps-comment] skills to create topic maps


Hi,

jean delahousse wrote:
> 
> Dear Tony and all,
> 
> I like harsh talking and I will be happy to have some time to talk with you
> at Orlando and drink a beer.

I'll join you :-)

What Jean has written about their TM project approach and their tool
match with our experiences we made at empolis (of course not with the Mondeca
tool but the empolis k42 ;-).

But I would like to add some issues:

- Topic Maps are not only XTM. Topic Maps are also a paradigm for graph-like
data structures (like knowledge networks). They can be seen as a new database
paradigm. And when you look at topic maps from the database perspective
then you have to ask yourself: how to I design and develop and maintain 
a RDBMS application incl. user interfaces? You can map all design principles
from RDBMS to TMMS (Topic Map Management Systems); you just have a more
powerful design paradigm at hand (compared to tables, rows, and columns).

- Another aspect is the user interface. Again compare this with RDBMS 
applications. No user will accept an interface where she sees tables, 
columns, and rows. The user expects an interface that reflects the language,
thinking, and processes of the application domain. We have XML editors
that allow us to edit any XML document of any DTD with one common interface,
but editing topic maps is not about creating topic X of type/class Y in scope Z.
It is about a certain business logic that will be solved by applying the topic
map paradigm to the business problem. The same is true for topic map 
visualisation. And because of these facts the k42 interfaces you get out-of-the-box
are *not* the end user interfaces! They are showing the power of the k42 
server and they could be used as starting point (by re-using the underlying
servlets) for the real application dependent interface(s).

- I also would like to communicate my experiences gained from discussions at
the Knowledge Management Europe 2001 exhibition (which took place the
last three days in The Hague, Netherlands). Nearly everybody there who saw
k42 (or topic maps) asked immediately how do I get this great knowledge
map created automatically. These guys are heavily influenced by all the 
marketing bla bla of companies like Autonomy which promise that all knowledge
in your documents can be extracted by magic (= Autonomy's software) and it
will satisfy your quality requirements. But, hey, I don't believe in magic.
You get what you pay for. If you want to rely on mathematical algorithms
which 'see' the knowledge in your documents, fine, go ahead with it. I 
would be very sceptical about the results I retrive from such a system.

- And finally (I couldn't resist) about TMs and XML. XTM is the 
interchange syntax and I would never ever edit or tweak a TM in XML.
Same as you would produce an ASCII dump out of Oracle, edit it in emacs
and load it again into Oracle. Sorry to say, but XTM could also have been
ASN.1-based, which is somehow unreadable binary stuff - it would fulfil
the same purpose of a standardized interchange (!) format. We selected
XML because it is hype and it makes some sense to have XTM (one of these
senses was the marketing effect!), not because it is a readable format 
you can edit TMs in.

Regards,
--Holger

 
> We start to accumulate some experience with professionnal clients on
> building topic maps and I like to give you a feed back
> 
> 1) we use our Topic Maps repository to gather the information, publish it
> and navigate on the organised content
> 
> 2) the repository accept manual inputs of information used espacially to
> build and maintain the taxonomy or for experts that gather information
> "manually" ("M.Coates works for Reuters", for example)
> 
> 3) the repository accept XTM file inputs so we were able :
> 
> - to take information from data bases (project organisation, financial links
> between companies)
> - to input existing taxonomies, thesaurus, ontologies
> - to input summary, index and links between documents coming from large
> legal documentation and to index the content
> - to input informations coming from automatic tagging tools ("Reuters
> acquired Diagram and now controls 43% of the french market of financial
> software" automaticaly transformed in topics, associations and occurences)
> and build economic intelligence repository
> - to input metadata from RDF DC documents
> 
> 4) before to populate the Topic Map whith information we have to choose a
> set of association templates and types of occurence. We had at the beginning
> a lot of back and forth work trying to adjust the templates but we now have
> more experience and the corporate vocabulary is finally not that large.
> 
> We still have a lot of work to do to get a full set of templates for
> corporate fields. For that work we get inspiration from standardisation
> works and exiting ontologies
> 
> 5) concerning taxonomy to organise and classify subjects and documents, we
> sometime rely on exiting vocabulary (legal and financial documentation) or
> by building a first simple taxonomy and changing it when it is needed.
> 
> We start a work of automatisation of the taxonomy creation using a
> classification tools from a partner. It will give a first proposition of
> taxonomy that the users may modify and complete.
> 
> 6) Conclusion :
> Topic Maps gives enough flexibility to use various organisation methods for
> a content (ontology, taxonomie, semantic links between topics,
> class/instance relationships, links to organise piece of documents,
> reification...) which is quite nice.
> 
> Professional content editors have hundreds years of experience on content
> organisation for books, memento, encyclopedia, thesaurus so they can tell
> the result they want (at least as good as what they had in the paper
> publication).
> 
> So flexible repository (mondeca's one obviously), TM standards and existing
> organised content on the client side make all together the work feasable,
> interesting, fun, professional, extremely valuable and gives very good
> results and a good ROI for the clients.
> 
> Sincerely
> 
> Jean Delahousse
> CEO
> www.mondeca.com
> 
> -----Message d'origine-----
> De : Tony.Coates@reuters.com [mailto:Tony.Coates@reuters.com]
> Envoyé : mercredi 28 novembre 2001 13:19
> À : webindexing@optusnet.com.au
> Cc : topicmaps-comment@lists.oasis-open.org
> Objet : Re: [topicmaps-comment] skills to create topic maps
> 
> On 28/11/2001 07:49:45 Jon Jermey & Glenda Browne wrote:
> 
> >What skills are needed/held by people creating topic maps. I understand the
> >linguistic/conceptual side of it, but I am wondering about the technical
> >creation. Eg, do you need XML, programming skills or whatever?
> 
> I'll add to what the other respondents have written by saying that in the
> long term, knowing how to work with XML directly should not be a
> requirement.  However, given the immature state of topic map tools (which is
> complicated by the lack of an agreed processing model), I would not expect
> anyone to make sufficient progress without a knowledge of XML.
> 
> To be more concrete, you might be able to settle on one of the available
> topic map editors, and just edit away happily without understanding XML.
> However, at some stage you will want to do something with that topic map,
> and that is the stage where you might have to look at the XML and make some
> sense of it.  If you stick to one vendor's toolset you might be lucky enough
> to avoid this, but I would be less confident if you are trying to build a
> topic map that can be used equally by any tool (leave aside one you can use
> with XSL-T or other generic XML tools).
> 
> Topic map tools vendors are welcome to comment if they think this evaluation
> is too harsh, and/or to buttonhole me at XML 2001.
> 
>      Cheers,
>           Tony.
> ========
> Anthony B. Coates
> (1) Content Distribution Architect - Project Gazelle
> (2) Leader of XML Architecture & Design - Chief Technology Office
> Reuters Plc, London.
> Tony.Coates@reuters.com
> ========
> 
> -------------------------------------------------------------- --
>         Visit our Internet site at http://www.reuters.com
> 
> Any views expressed in this message are those of  the  individual
> sender,  except  where  the sender specifically states them to be
> the views of Reuters Ltd.
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
Dr. H. Holger Rath
- Director Research & Development -

empolis * GmbH
Bertelsmann MOHN Media Group
Havelstr. 9, 64295 Darmstadt, Germany

phone :  +49-172-66-90-427
fax   :  +49-6151-380-488

<mailto:holger.rath@empolis.com>
http://www.empolis.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC