[topicmapmail] Any design guidelines for roletyping?

[Marc de Graauw]

* Marc de Graauw

| When I have role types in an association there are two possible approaches:
|
| 1) Use topic types as role types.
|     [e.g. "composer" and "composer"]
|
| 2) Keep topic types and role types separate.
|     [e.g. "person" and "wife"]
|
| ...
|
| Does anyone have any design guidelines they follow themselves?

* Steve Pepper

| No ready answers, but a few pennyworth:
|
| 1. In my experience, there are often superclass-subclass relationships
| between topic types and role types. To take your example: 'wife' is a
| subclass of 'person'.
|
| 2. Often the role type is a subclass, but sometimes it is a superclass, e.g.
| a topic of type 'composer' playing the role of 'person' in a 'born-in'
| association.
|
| 3. Your 1) (topic type = role type) is just the special case of these two.
|
| 4. None of this should surprise us since class hierarchies are defined
| precisely through differentiae that can usually be alternatively expressed
| via (roles in) associations.

Robert has shown in his reply how one can derive subclasses from role types:

* Robert Barta

| Yes, the "perfect" solution would be to simply state
|
|    susan-smith is-a person #instance-of
|
| and to _derive_ only the fact that she is a wife as well in the
| ontology:
|
|    forall [ (is-married-to)
|             wife : $w ]
|       => derived exists [ $w is-a wife ]
|
| This means that in the ontology - whenever there is an association
| where there is a wife role played by $w - this $w also should be
| regarded as an instance-of $w. The fact will be automatically added by
| the TM processor instead of letting the author do it.

Maybe TMCL will support this. It does mean the entire class hierarchy is
expressed on two levels: topic types and roles in associations.

| 5. To illustrate this, ask the question:
|       Is Benny Goodman
|        - a topic of type 'clarinettist'; or
|        - a topic of type 'musician' (or even 'person') who plays a role of
|          type 'player' in a 'player-of' association with the instrument
|          'clarinet'?"
|
| 6. The answer, I think, depends largely on the domain you are modelling and
| the needs of your application. In the Italian Opera topic map, the
| distinction between, say 'composer' and 'librettist' is quite fundamental,
| so it makes sense to express it directly in the class hierarchy. In another
| topic map, Puccini and Illica might both be topics of type 'person'.

So your design guideline would be:

If some classifying aspect of a topic is fundamental, express it in the class
hierarchy with a subclass, and use that subclass a role type in an association
(i.e. make 'composer' a subclass of 'person' and use 'composer' as role type).
If it is not fundamental, express it only as role type (i.e., make a 'person'
topic type and use 'composer' only as role type.)

Another consideration for this choice would be the ability to express
incomplete knowledge. If I want to be able to store the fact 'Illica is a
librettist', even when I do not know which libretti he wrote, I must make
'librettist' a topic type, not a role type.

I must say this ability to express a classifying aspect as either a topic
subclass or a role type makes me feel uneasy. It makes it all too easy to make
the wrong design choices. Suppose I model 'Verdi' as person, and use
'composer' as a role type because the 'composer' aspect only seems relevant in
relation to particular operas Verdi wrote. When I later decide the 'composer'
aspect merits a place in the topic type hierarchy after all, this means
serious maintenance (make 'composer' a topic type which is a subclass of
'person', make every person who plays a composer role an instance of this
type, and remove the 'person' topic type for all composers since they are now
an instance of 'composer' which already is a subclass of 'person').

Maybe this just means good design is hard work, which is no news :-)

Marc