Thanks @chunlan.ma the reason for that is that if relationships would be “weak”, then the relationships would need to be created when, for instance, a person is created, like what I described for the roles. I think having the relationships to be created individually from the other entities they point to, adds flexibility.
Though it could be accepted that you create person1 then create person2, with a relationship embedded, that points to person1 in it’s target (I preferred not to do it that way). Then if the system supports reverse_relationships, the system needs to set the relationship inside person1. In terms of resource management, I think modifying a resource because another resource reference them, is not a good. I prefer each endpoint to modify the resource for that endpoint, that is also why PARTY_RELATIONSHIP is in it’s own endpoint, when that is created or modified, the PARTIES it points to are not modified at all, not even for the relationships. So in the API and internally both are independent (PARTY and PARTY_RELATIONSHIP).
Another point is to make the demographic model as tree-like as we could, that simplifies modeling, API and storage handling. The problem is with ACTOR.roles / ROLE.performer, and PARTY_RELATIONSHIP.source/target and PARTY.relationships/reverse_relationships, when you look at the data you really have a complex graph, not a tree like in a COMPOSITION structure. REF Demographic Information Model
Having graphs is more difficult for managing data and for querying data, than having just trees.