DEMOGRAPHIC model: does it make sense to have contacts and identities for ROLE?

ROLE inherits from PARTY, PARTY has identities and contacts, which seem reasonable for a PERSON, ORGANIZATION or AGENT, which inherit from ACTION which inherits from PARTY, but I can’t see what’s the use of those fields for ROLE. Those fields seem to be more suitable for ACTOR than for PARTY IMO.

Does anybody have a use case for ROLE that uses identities or contacts?

The usual reason is that a person having a ‘Role’ (= available to act in a certain capacity) has contact info and sometimes even identifying info specific to the role. E.g.

  • Juan Lopez (a PERSON) lives at ‘calle Lobo 51’ (home), phone number 111111111;
  • he is a Nurse (a ROLE), and relating to that, can be found at ‘Bulevar Artigas 1590, Lord Ponsoby 2410, 11600 Montevideo, Uruguay’, plus a work phone 222222222
  • he is also a part-time sound-stage designer, and for that purpose, the address is ‘5Q36+XP9, Triunfo, 11900 Montevideo’, and he has another phone for that 3333333333

A different identity for a ROLE is not that common, but it happens - writers and rock stars for example, with performance names and so on.

I’ve been reviewing the demographic model, and working on a new version known as an ‘entity’ model, which for the moment may serve only to indicate how to improve the current one. Other parts of that new model should address some long-standing requirements about modelling resources as well (see the sibling packages in the UML).

It’s not complete, and anyone who is interested should comment - initially on this thread, but we can talk about it in SEC if there is interest.

1 Like

Thanks @thomas.beale I get the idea. I wasn’t considering the ROLE has exactly one performer. That way each nurse will have an instance of role, then for that it doesn’t have any issues to have contacts or identity. I was thinking of defining each role with one instance of ROLE (the “nurse” being one instance of role, the “doctor” being one instance, and so on, in that context it doesn’t make sense to have identities or contacts).


If I understand correctly, you mean something like ROLE = role type, i.e. the class ‘nurse’ (in the ontological sense), rather than some specific individual nurse (a ‘particular’ in the ontological sense)?

This is a different concept, and also a useful one, which we need in places like Task Planning where you want to state within a plan what kind of performer is needed on a task.

1 Like

Exactly, I realized that after I send the message and continued working with the model, then I found the performer [1..1] then what you mentioned on your first answer was totally clear :slight_smile:

@thomas.beale what do you think about identities being 1…*?

Do we need an identity for each role?

1 Like

Generally not, and it should be 0…*, which I will fix in the Entity model. The way it should work is that most of the type, the Agent (i.e. real Person, Org etc) will have identity/ies, and occastionally a Role of the Agent (what is called ‘persona’ in the new model) will have an identity, which for that role, overrides the Agent’s ‘real’ identity. E.g. a stage name, nickname etc.

EDIT: indeed, it might be argued that there should only be 1 identity for an Agent, and maximum one per Persona, but it’s always risky to over-constrain…

Yep, I thought requiring an identity for Role was kind of too much, since it might have that in some contexts, but not in general. So it’s messy to add just a dummy object there to comply with the specs. Also that makes identities required in the JSON/XML schemas based on the RM. I do prefer less constraints there in the RM, specially because those could be constrained more in archetypes and templates (I’m working right now with demographic archetypes and templates for the conformance verification).