[topicmapmail] Any design guidelines for roletyping?

[Robert Barta]

On Wed, Jan 01, 2003 at 03:09:13PM +0100, Marc de Graauw wrote:
> When I have role types in an association there are two possible approaches:
> 
> 1) Use topic types as role types.
....
> 2) Keep topic types and role types separate.
> 
> Sometimes solution 1) is unnatural. I have a lot of topics of type 'person'.
> The persons can be married, and this is modelled with a 'marriage' association
> between two topics of type 'person'. I.e. 'Susan Smith' is-married-to 'John
> Smith'. Now the types of the roles in the association naturally become
> 'husband' and 'wife'.

I think this is the 'intended' way of doing things. Roles might be
regarded as _local_ things:

   (is-married-to)
   wife : susan-smith
   husband : ....

This could be more explicit:

   (husband-is-married-to-wife)
   wife : susan-smith
   husband : ....

>                     Making 'Susan Smith' a topic of type 'wife' and make
> 'wife' a subclass of 'person' is unnatural, since Susan is only a wife by
> virtue of her participation in the 'marriage' association, so when the
> association is deleted we would have to change Susan's topic type from 'wife'
> to 'person' (or 'unmarried person').

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.

As long as we do not have this nifty software manual maintenance is
possible, while cumbersome.


> My question: is it preferable to use approach 1 only, or approach 2? Approach
> 1 seems to make it easier to build user interfaces, since we could make a user
> interface which allows only topics of type 'composer' to be used as the
> 'composer' role in in the composed-by association. If I want to do that with
> approach 2, I need to record somewhere which topic types are eligible as
> 'wife' in the 'marriage' association. On the other hand, playing a role in an
> association and being a topic of a certain type seem different things, so
> mixing the two seems wrong. Is mixing the two approaches harmless or is it
> better to avoid this?

Well, user interfaces might be a short-term motivation of building a
map, but maybe in 2 years this map will be part of a, say, CRM "big
brother" and will use the information for something else than
displaying. I think (guilty myself) it is a dangerous path to look at
a possible usage.

I think it is better to avoid it, although in some places it is
EXTREMELY difficult to come up with a good role name. Types are an
easy way out.

> Does anyone have any design guidelines they follow themselves?

We should throw all our notes to form a BCP (best current practices)
document for TMs.

I treat this here as a part of 'association granularity', i.e. how
specific an association actually is. Compare the following:

(is-married-to) is-reified-as A
thing : a
thing : b

(is-married-to) is-reified-as B
person : a
person : b

(is-married-to) is-reified-as C
spouse : a
spouse : b

(is-married-to) is-reified-as D
wife    : a
husband : b

Obviously D is the most specific which makes sense here. Given that in
some countries homosexuals can have legal 'married' status, D is
overspecific and C will have to be used.

\rho

PS: I did not invent this world ;-)