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] TAO vs. ERA


Lars Marius


> The same applies elsewhere, so Norway would be "country", "container",
> "containee", "neighbour" (of other countries), "member" (of various
> organizations), etc etc. Clearly, this doesn't work. Norway plays all
> of these roles, but that is different from being an instance of them.

Wrong. You can't put all that in the same bag.
"country" can definitely be used as a class, whereas using "neighbour" as a
class does not make much sense.
If you say "Norway is a country" it makes sense by itself from everywhere in the
world. The role of "Norway" there is not "country", but "instance" in a
class-instance association.
If you say "Norway is a neighbour", that may make sense if you are in Sweden or
Denmark ... but does not in Japan. "neighbour" is definitely not a class by
itself, but a role in an association where you have to get other guys playing
the same role.

> This doesn't mean that one couldn't explictly assert that Mozart is a
> "composer", but I am kind of uneasy about it. It should be done with care.

Sure it should be done with care, but why being uneasy? Because it does not come
from some formal linguistic rule, but from real subtle human knowledge? "Mozart
is a composer" is a class-instance association because for most people, Mozart
is *essentially* a composer. He's not just involved once or twice in a
"composition" association with the role composer. Composition is his deep
nature. The same with interprets and musicians. Some just play notes, and the
role of second violin in unameit provincial orchestra, and some are *musicians*.
Hear the difference between a role and a class.

> | 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.
>
> Yep, mainly because "composer" is a special kind of role, in the sense
> that it's socially considered to confer a kind of identity onto the
> player of that role in a way that, say, "victim", or "containee", do not.

Not only. It depends to what extent the player plays that role. If I've composed
only a little song in my life, I'm not *a composer*, I'm just *the composer of
this song*. The concepts are definitely different, and you tend to say they are
the same because we use in English the same word (in French too - what about
Norwegian or Japanese?) But think about "author" and "writer". I am the author
(role) of that message, but I am not a writer (class) - for that only reason at
least ;-) - I suppose you won't merge "author" (role type) with "writer" (topic
class), or will you? In French at least, "auteur" is clearly not mergeable with
"écrivain".

> | 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).
>
> To me these seem to be the same. Why would you consider them separate?

For the reason above, the same way I consider "author" and "writer" separate.
What happens if someone wants to "translate" your topic map in a language where
really there are two different words for composer-role and
composer-social-class? And moreover it's always cleaner to manage topic types
and role types separately. Believe me, I've been through it many times. Having a
topic used as class and as role as the same time may bring messy situations. At
some moment inconsistencies will appear, and it will be too late. Merging topics
is quite easy, splitting a polysemic topic is a headache.

> | 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.
>
> Doesn't that match how we use the topic in a topic map? Composer is a
> concept. You can be an instance of it, or you can play it in relation
> to a piece of music. I being useful as a role does not stop you from
> being used for other things.

Yes it does stop me, when I acknowledge that this word is not "a" concept, but
is masking two concepts, hence two subjects, hence two topics.

> | 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 think 1 and 2 are the same here, while 3 is probably not...

Sure. 3 is definitely different. But 1 and 2 are different animals too.

Cheers

Bernard



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


Powered by eList eXpress LLC