The RIF-CS Advisory Board on 26 July 2011 agreed in principle with this new party type, subject to more discussion of the label for the type and some discussion of best practice issues. I have provided more information and a revised proposal for discussion here.
An example record in Research Data Australia is at http://services.ands.org.au/home/orca/r ... e.csiro.auName for new type:
1. The name will need to be appropriate for roles filled by either individuals or organisations.
2. The name needs to reflect the nature of the thing being described by the type. We have 'a party in a role', but we are not really specifying the party (i.e. the actual human person or organisation that is in the role). All we have is the generic name of the role itself e.g. Data Manager.
If it is important who is in the role, that would not be described using this type, but a party person or group record should be used instead, see best practice discussion below.
3. I think 'role' is correct as the name of the thing we are describing, even though it is not really a kind of party of course (see 2 above).
4. But I can see that if we use this word it may lead to the undesirable result of people trying to describe roles and then link them to party records. We don't want this, it is not relevant information for the ANDS Registry, and to the extent it is needed the related object element caters for it already.
5. For one discussion of party modelling see http://www.tdan.com/view-articles/5014/Best practice issues:
a) Parties with this type would not be expected to be related to other parties. This type should not be used to specify a role for a party.
b) This type is only for use when a generic functional position with its own generic name exists and needs to be included as a related party to a collection, to an activity or to a service. Some redundancy may be apparent when generic names are used but is not really a problem e.g. Data Manager, party of type [TBA] isManagerOf / manages [some collection]
c) If there is a need to describe the role of a party further than the existing related object types allow, use a user-identified related object type and describe the relationship in the description area of the relation.Revised suggestion:
Create new party type of 'administrative position':
Administrative position: a kind of party where the position name and contact information are present but the identity of the party filling the role is not specified.
a) Use when describing a generic administrative role such as 'Data Manager' or 'Data Custodian' where no other party information is to be provided.
b) Do not use for describing the relationships between named parties (people or organisations) and collections, activities or services.
c) Do not use for describing a role filled by a named party (person or organisation); there should not be any related object links from a party of type 'administrative position' to any other party.
'Administrative function' might be an alternative as it makes more sense for organisations than 'position' does. Or even 'Generic party'.
Better ideas welcome, please post your thoughts.
Australian National Data Service
W. K. Hancock Building (#43)
The Australian National University
Canberra, ACT, 0200, AUSTRALIAhttp://www.ands.org.au
P:+612 6125 1176
M: 0466 579 618