[topicmapmail] Any design guidelines for roletyping?

[Thomas B. Passin]

[Steve Pepper]

> At 20:42 01.01.2003 -0500, Thomas B. Passin wrote:
> >Agreed, but it is still a naming issue rather than a fundamental modeling
> >one.  I have started to make all my role topics types have lower-case
names,
> >and topic type names  (that is, topics I expect to be used primarily as
> >types) as upper case.  Then I can distinguish them at once (and avoid
> >name-based merging) even if the core word is the same.  This practice
seems
> >to be working well so far.
>
> That doesn't make sense to me. I call that going over the top, in terms of
> making explicit distinctions that are of no practical use and that will
> confuser end users. To take the example Marc cited: would you really have
> Puccini be a topic of type 'composer' and play roles of type 'COMPOSER'?
> What on earth is the difference between the two subjects that these topics
> represent?
>

Well, I would probably favor making "composer" an occupation of Puccini, who
would be of type Person.

Supposing, though, that I did model him as an instanceOf Composer,which in
turn is a subclassOf person. He could play the role of composer with regards
to a particular, piece and also the role of conductor with regards to a
performance of the same piece, and I would want to distinguish the two
situations.  So the role of composer still would have a place in this
scheme.

The question then would be, should the same topic (Composer, a subclassOf
person) be used for such a role or should there be a separate topic for this
purpose.  I think this is the gist of this part of the discussion, is it
not?

Composer, we know, indicates a classification, that is, a specification for
selecting elements of a class or set.  According to Wordnet, "role" has
several senses, of whch these two seem to be somewhat relevant -

-function, office, part, role -- (the actions and activities assigned to or
required or expected of a person or group; "the function of a teacher"; "the
government must do its part"; "play its role")

- role - (normal or customary activity of a person in a particular social
setting; "what is your role on the team?").

So I take it that a role declares the customary function of the role-player
(in an association, in topic map usage).

People frequently personify a role and use its name to stand for the
individual, as in "I bought this bread from the baker").  I suppose that
using Composer the subclassOf as the type of a role is more or less
equivalent to this.  I am just do not think that, in a formal or theoretical
sense, this is correct usage.

Sowa [1] covers this point.  Let me quote him (starting on page 80) -

"A _role type_ characterizes an entity by some role it plays in relationship
to another entity. ... An entity's appearance independent of context is
sufficient to classify it bya phenomenal type, but context is essential for
classifying it by role. ... In some cases, the form may be predictable from
the role... the role type Pet suggests the phenomenal type Animal.  Yet the
suggestion is not a strict implication, since a robot, a human, a plant, or
even a rock could serve as a pet."

Sowa also points out that some type classifications are monadic - they
classify an entity independent of its relationships to other entities.
Roles are dyadic classifications (they inherently involve the relationship
between two entities) , and there can be triadic ones as well.

It seems clear that in general, role types are not of the same nature as
common classification types.  A particular classification might be dyadic,
but this is not so in general.

I think it would be confusing if some topic types could be used as role
types (because they are dyadic), but others could not (because they are not
dyadic).  For me, then, it is more straighforward to create a role type for
each role, and have them be separate types from the topic-classifying
topics, like Person.  Thus, each of my role types is a subTypeOf a generic
top-level role type.

Because I follow this usage, I find it helpful to have visual clues when
looking through lists of topic labels, and that is why I find the lower-case
practice helpful.

Cheers,

Tom P

[1] Sowa, John F, "Knowledge Representation", Books/Cole, 2000.