Appendix D - Relationships
Few ontologies have tackled the modeling of actors relationships, understood to be an association between different E39_Actors, thus creating a network of makers. The CIDOC CRM ontology does not render those ties well, although other options have attempted to do so:
- The Agent Relationship Ontology.
- Bio CRM.
Both are worthy ontologies that have been seriously considered but ultimately discarded for reasons explained below.
The Agent Relationship Ontology
The Agent Relationship Ontology (AgRelOn), developed by the Deutsche National Bibliothek, is designed to describe complex relations amongst people and groups. It uses various properties and classes to render them and could answer the needs of Creators in Canada. Such a model would look like the following:
085_Pattern_AgentRelationshipOntology_p
However, a property-based ontology entails the modification of the Target Model and the creation of a corresponding property everytime a new type of relationship has to be represented. In addition, a model with so many properties will quickly become overly complicated and hard to manage
Bio CRM
Two unofficial extensions of CIDOC CRM can handle the relationships between E39_Actors: bio CRM and a separate module of CIDOC CRM devoted to properties of properties.
These extensions enable the representation of complex relationships such as that to biological parents in the birth event (see Birth), that to a group (see Group Belonging) and other relationships described below.
Bio CRM links bioc:Actor (a subclass of E39_Actor) to a relationship bioc:Event (a subclass of E39_Event) and specifies the role of the bioc:Actor in the relationship through bioc:Actor_Role (a direct subclass of E1_CRM_Entity) in conjunction with E55_Type. By using E55_Type with a controlled vocabulary it is possible to represent multiple relationship types without changing the model.
There should therefore be two events representing the beginning of the relationship and its ending:
However, this model may induce querying problems considering two events pertaining to the same relationship are not linked together. As a result, when querying for a list of the different relationships of a Person 1, the same relationship could appear twice:
087_Pattern_BioCrmPossibleResult_p
| Actor | Relationship | Actor related |
|---|---|---|
| Person 1 | Event of the beginning of the relationship A | Person 2 |
| Person 1 | Event of the Ending of the relationship A | Person 2 |
| Person 1 | Event of the beginning of the relationship B | Person 2 |
| Person 1 | Event of the Ending of the relationship B | Person 2 |
To connect the two E5_Events an remedy this problem, an E70_Thing has to be created at the beginning of the relationship as a stand-in for the relationship itself:
089_Pattern_BioCrmE70ThingResult_p
This would significantly complicate the model by creating for a single relationship both an E5_Event and an E70_Thing without the latter adding any information that is not already rendered by other entities. In addition, this pattern relies on a role to participate in events, which is problematic in and of itself.
The property of properties module of CIDOC CRM follows the same logic as bio CRM, but complies with CIDOC CRM semantics and structure:
090_Pattern_RelationshipCrmBio_p
091_Pattern_RelationshipPc14_p
CHIN has thus elected to use the Property of property module as it is consistent with the rest of the model, adequately represent every relationship in compliant patterns (parenthood, group membership, etc.), and is more sustainable considering it is widely used by the community and well documented.
Previous:Appendix C
Next: Appendix E