Re: [topicmaps-comment] TAO vs. ERA

[Bernard Vatant <bernard.vatant@mondeca.com>]

Robert

> I try to interpret the role in an association NOT as a type.

That is very interesting and controversial. At Mondeca, we have had a moving
viewpoint for that matter.

In the first software version (2000Q4, at the time I joined Mondeca team) there
was no classification of topics *except by roles*.
We did not deal at the time with murderers, but with musicians: compositors,
interprets ... It was the first full-scale Mondeca data base, made for a
classical music directory.
The viewpoint at the time was the opposite of yours. Mozart inherited the type
"composer" because he had the role of "composer" in a "composition" association.
A composer is someone who has composed something, it's not an "essential" type.
We figured rapidly that this viewpoint was consistent, but limited, and we added
of course "absolute" classifications, hierarchical classes and all. The tricky
thing is now to make the two viewpoints coexist, and there is no general rule. I
agree considering "murderer" as a type is controversial. I'm uneasy myself to be
classified as "webmaster" because I maintain a website, "teacher" because I've
been through that for quite a while, "consultant", "chair", "speaker" because
now and then I assume those functions, "customer" because I buy products and
services, and so on. Inheritance of all types defined by those roles leads to
heavy multi-classification with no real interest.

But it remains a certain number of cases where role and type are very difficult
to sort out. I think "composer" was indeed such kind of example in the scope of
classical music. The difficulty comes when you have to decide if the topic used
for the role specification (composer-as-role-type-in-a-composition-association)
should be merged or not with the topic used for classification
(composer-as-subclass-of-artist). You can do it when you create a topic map from
scratch, with explicit different names and topic ids for "composer-role" and
"composer-type" for example.
But if you try to import a classical database or thesaurus or whatever
classification, you will have hard time to make a parser figure which is which,
since the same term "composer" or tag <composer> will have either semantics ...
depending on context.

It can be worse. Consider "documentation" that can be considered as a topic type
(a set of documents), as a role (in a subject-documentation) or as this latest
association type itself (the fact of documenting something) ... There again, you
should define three different topics:
1. documentation-as-topic-type
2. documentation-as-role-specification
3. documentation-as-association-type

I deal at the moment with the importation of a thesaurus (GEneral Multilingual
Environmental Thesaurus) http://www.mu.niedersachsen.de/cds/webpages/Pdfs.htm
Where "documentation" appears, with the following information:

documentation
DEF: The supplying of documents or supporting references. (Source: AMHER)
BT information
NT document, film, photograph, video, CD-ROM
RT indexing of documentation

The definition tends to make me consider documentation there like 3. or 2.
whereas the given "narrower terms" go rather towards 1.
What shall my parser do ??

Suggestions welcome ...

Bernard

-------------------------------------------------
Bernard Vatant - Consultant
Mondeca - "Making Sense of Content"
www.mondeca.com
bernard.vatant@mondeca.com
-------------------------------------------------