Open VladimirAlexiev opened 4 years ago
That would however imply the existence of a list of social relationship to encode, however we noticed that we have very specific social relationships between people which do change based on context. We would have to do a constant curation to include all the possible relationship that exists, which is an endless and probably unachievable task. That is why we chose to go with such construct which link to a vocabulary.
I do agree on the problem on possible misuse and the problems with reification, but I think for the user's perspective the advantages surpass the advantages! :-)
The CRM reification relations are straightforward enough to use, but they could certainly be better documented. In what way are the property names wrong? (This by the way is an issue to raise with the SIG not with SARI!)
We have the unrefined situation:
E7 Activity p14 carried out by E39 Actor
p14 carried out by Domain E7 Activity Range E39 Actor
Then we have the need for a reified property.
It is declared in this rdfs: http://cidoc-crm.org/sites/default/files/CRMpc_v1.1_1.rdfs
It is called PC14 carried out by
The PC14 carried out by is a reification of p14. p14 has a domain E7. It has a range E39. Therefore it is connected to those properties as:
E7 Activity P01i is domain of (n.b.: the inverse of p01 has domain) PC14 carried out by p02 has range (n.b.: has the inverse p02 is range of) E39
This is a correct representation of the situation and then allows to carry on with the construct:
E7 Activity P01i is domain of (n.b.: the inverse of p01 has domain) PC14 carried out by p14.1 in the role of E55 Type (some role here)
The property names are fine.
Again though, the appropriate forum for contesting the CRM reification properties would be the CRM SIG, as it is not the remit of SARI.
Regarding using Agrelon properties, again, it is missing the scope of SARI models. SARI models do not aim to support a specific data integration for some specific cultural reason, but to provide best practice models for implementing the CIDOC CRM on relatively universal documentation patterns. Adopting Agrelon might be a great solution for use within a very limited western cultural context, after that it would not be appropriate. Since the SARI models can in principle be adopted in China, the Middle East, and by indigenous communities (who can express different kinship models), inter alia, limiting to this set is not a good idea. Of course, within a specific cultural context, being able to implement the specific logic would be great. It would be a great task to work with anthropologists and derive a superset of a kinds of kinship relation and use it to create an uber set of cultural neutral abstract relations, but that would be another research project.
Consider using AgRelOn relations directly, rather than with a reified CRM node.