[sc34wg3] RM: role type

[Patrick Durusau]

Greetings,

This post differs from the other comments. It is in part a rely to a 
post Steve Pepper posted last week but I have been unable to answer 
until today. It also frames the issues around role-type with the text as 
it appears in ISO 13250, the SAM as well as other material on the notion 
of classes and instances. This will not be a quick read but comments and 
suggestions would be greatly appreciated.

Patrick



REF: parid2259

TXT: role type

FIX: Strike.
 
COM: Role players have roles in assertions, they do not have role types. 
see comments under parid2260 for details.
 
END:


REF: parid2260

TXT: A kind of participation that a subject can have in an instance of 
an assertion.

FIX: Strike.
 
COM: The notion of role type as explained by Steve Pepper (posted 
2/19/2003 to the sc34wg3 list) reads in part:

***Quote from Steve Pepper***
In 13250, an association role (represented by an <assocrl> element) 
represents the involvement of a certain topic in a certain association. 
It has a 'type' attribute which represents the class to which the role 
belongs. There is thus a kind of type-instance relationship between the 
role type and the (individual) role. A role type can be thought of as 
the set of all similar involvements in associations. Thus "husband" (for 
example) is a *role type*, not a *role*.
***End Quote from Steve Pepper***

In prose, 13250 mentions role type in the following paragraphs (ignoring 
it in the syntax productions):

***ISO 13250 passages on role type***

The optional occurrence role type (type) attribute references a single 
topic link. The subject of the
referenced topic link is a class of occurrence role of which the 
occurrence role expressed by the
occurs element is an instance. The class-instance relationship 
established between the subject of
the referenced topic link and the referencing occurs element could 
alternatively be established by
making the occurs element an occurrence of the referenced topic link, 
within the scope of an
occurrence role whose meaning is that the occurrence role is an instance 
of the subject of the topic
link.

If the occurrence role type (type) attribute is specified, and if the 
topic referenced by the type
attribute has a name characteristic that lies within a scope that is 
appropriate to the topic map user's
context, the referenced topic's name characteristic is used to 
characterize the occurrence role for the
user. Otherwise, the value of the occrl attribute (or, if the occrl 
attribute is not specified, the generic
identifier) is used to characterize the occurrence role for the user.

....

The optional association role type (type) attribute references a single 
topic link. The subject of the
referenced topic link is a class of association role of which the 
association role expressed by the
assocrl element is an instance. The class-instance relationship thus 
established between the subject
of the referenced topic link and the referencing assocrl element could 
alternatively be established
by making the assocrl element an occurrence of the referenced topic 
link, within the scope of an
occurrence role whose meaning is that the association role is an 
instance of the subject of the topic
link.

NOTE 43 If the topic links whose subjects are association role types 
specify identity attributes, and if the subjec
descriptor(s) referenced by those identity attributes describe the same 
subject, the assocrl elements that are instances of those association 
role types can be universally recognized as specifications of equivalent 
association roles. Depending on the nature of such association roles, 
the use of public subject descriptors to define association role types 
may significantly facilitate the process of merging topic maps, even 
when they emanate from disparate sources.

If the association role type (type) attribute is specified, and if the 
topic referenced by the type
attribute has a name characteristic that lies within a scope that is 
appropriate to the topic map user's
context, the referenced topic's name characteristic is used to 
characterize the association role for the
user. Otherwise, the value of the anchrole attribute (or, if the 
anchrole attribute is not specified, the
generic identifier) is used to characterize the association role for the 
user.

***End 13250 passages***

At Steve Pepper's suggestion, I also consulted the latest draft of the 
SAM, which reports:

***SAM passages on role type***

(3.9 Association role items)

An association role connects two pieces of information within an 
association: the subject participating in the association, known as the 
association role player, and the subject defining the nature of its 
participation, known as the association role type.

Association role items represent association roles, and may have the 
following properties:

....

2. [type]: A topic item. This is the topic item that represents the 
association role type.

***End 3.9***

The other place I found role type was under open issues:

***SAM open issues***

Issue (assoc-role-player-type):

Must both [role playing topic] and [role type] have values?

***End SAM open issues***

The open issue in the SAM is as good a jumping off point as any.

The SAM issue illustrates the confusion that is caused by treating a 
role as a class rather than an individual instance. But for that 
conflation of role (as in John as the husband in an assertion) and the 
class of being a husband, the suggested reading for role type, then the 
open issue of the SAM would not have arisen. When those two ideas are 
pushed together, it becomes a real practical question of why would 
"husband" be repeated?

In RM terms, I read the attributes in 13250 as being assertions about 
the role and hence, the idea of class being something that is asserted 
about a role and not conflated with the role itself. With that reading, 
the answer to the open issue resolves to Yes, [role playing topic] must 
have a value, [role] must have a value and, if you wish to make an 
assertion about the role, such as class, then [role-type] must have a value.

The problem of conflating instances and classes is not unknown. It is 
termed the "assumption of inherent classification" in *Emancipating 
Instances from the Tyranny of Classes in Information Modeling* by 
Parsons and Wand, see 
http://citeseer.nj.nec.com/parsons00emancipating.html for the full 56 
page paper which I won't try to summarize here. It may also be of 
interest to look at: *Coordinating Heterogeneous Work: Information and 
Representation in Medical Care* by  Reddy, Dourish, Pratt, who favorably 
cite the work of Parsons and Wand in designing information systems for 
an actual heterogeneous environment, see 
http://citeseer.nj.nec.com/reddy01coordinating.html for that paper.

The final problem with the suggested usage is that it results in fairly 
awkward English. I would not describe myself as playing the role-type of 
husband in an assertion about Carol (my wife) and myself. I would say 
that I play the role of husband. If I want to make assertions about the 
role of husband as a class, then I should make a separate assertion, 
with which others could disagree, ignore, etc., that the role of husband 
is a class.

Sorry to go on at such length but I felt I owed both Steve's, Pepper and 
Newcomb, a fairly detailed explanation about why I am suggesting a 
departure from what is apparently one reading of 13250.

END:

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps