[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