Do we need a family relationship pattern? And what to do with parents?

[chin-rcip]

In the v1.5 Target Model, the relationships, both family and other ones, are all modeled with the same pattern. Nonetheless, some differences exists between those two kinds of relationships, especially concerning the part of intention and performance of being in that relationship. In the non-family relationship, one or both actors intentionally perform some kind of activity, like if an actor is the student of a teacher, two lovers, or someone influenced by someone else (this last example is at the limit of intention and performance aspect of the relationship, but the influenced actor may be seen as been active in that influenced state). On the other hand, family relationships are non-intentional and non-performed. For the example, a child may have never seen his great grand aunt, but is still in a relationship with her, and maybe even without knowing this relationship exists.

Therefore, two viewpoint of a data model exists:

• Either the consistency is more important, and therefore every actor to actor should be modeled with the same pattern
• Either the semantic is more important, and then a new pattern for the family relationship should be modeled.

Going with the same thoughts, in the v1.5 of the TM, the biological parents of an actor (and founders in the case of a group) are modeled within the birth pattern and not within the relationship one. Therefore, should we model those relationships like any other and so in the relationship pattern, going against CIDOC CRM (that does not model family relationship well anyway) or stick to CIDOC CRM and have a different pattern for the biological parents and founders?

[KarineLeonardBrouillet]

I find the question of intentionality tricky here as even for the teacher-student relationship a professor may never know of their students or not remember them, yet remain intentional in the way they relate to the students. How would intentionality in a relationship be represented regardless of family ties? Because there are several instances of not knowing someone personally yet acting intentionally towards them (e.g. on social media, when applying for jobs, etc.).

[stephenhart8]

The question of intentionality has to be seen in a more broad sens, that at least someone within the relationship have acted towards this relationship. In the example of the teacher-student, the student have been to the lessons, listen to the professor, therefore the relationship. It's the same for influence, that the one influenced by a famous painter will act consciously or unconsciously in this relationship. The cases of social media is the same, the fact of not knowing them personally doesn't change the intentionality. I'm not sure if I'm clear enough

[Habennin]

Could you put up the diagram here of the patterns under discussion? (or a link to an editable draw.io form?)

[stephenhart8]

There's a link to an editable draw.io form of the relationship model: https://drive.google.com/open?id=1E8IlmmfUG1x7N7h11wML3Aafr-7MZkjU

[eecanning]

I wonder if we could look to the Art Tracks provenance LOD work for working through this? http://www.museumprovenance.org/reference/standard/#linked-data Would it be of value to check in with the Provenance Index team at the Getty (as David Newbury went there after this work at the Carnegie) to see how they are using this model in the work there, as the last update for this standard seems to be from 2016?

[VladimirAlexiev]

• I think SARI also uses the PC14 pattern, but this CRM way of reification is one of the worst.
• At least the names "has domain" and "has range" are wrong, should be "has subject" and "has object"
• DNB AgRelOn is the best agent relation ontology I've seen. (AgRelOn- An Agent Relationship Ontology, MTSR 2012). See image below.
  1. It abstracts smartly over gender, reducing combinatorial explosion and opportunities for data inconsistency. Eg it has "hasAuntOrUncle" (inverse "hasNieceOrNephew") instead of 2+2 combinations
  2. It has a very useful prop hierarchy, culminating in branches like "familial" vs "professional" relation.
• If you decide to go with PC14, at least design your P14.1 thesaurus according to AgRelOn. But this won't give you any sub-prop inference.
• PC14 is only useful if you need this reification node because you often need to record provenance/probability information of the relation.
• I'd record parent/child also as a relation (AgRelOn or PC14) even though it's redundant with Birth.(from father|by mother): this provides uniformity to be able to fetch all person relations easily.

[stephenhart8]

@VladimirAlexiev We have looked at AgRelOn, but we have ruled out this ontology for several reasons:

• We wanted to have more expressivity with the relationships, especially to be able to date them, which needs the involvement of an event.
• We also decided in our model to rely more on vocabularies than on the ontology (similar to what linked.art are doing), which means that instead of having multiple properties, we use the E55_Type class to specify the kind of relationship.
• With the PC14, we can have more flexibility with the relationships (for example, we can have a teacher -> student relationship, but also a master -> student)

The downside with our approach is that it complicates the queries

[VladimirAlexiev]

If you have dating or other info for the reified node, that's a good decision. Then please take care to model the relation type thesaurus following some principles form AgRelOn.

BTW GraphDB supports RDF* (to be released very soon) which allows you to annotate any relation.

Cheers!

[VladimirAlexiev]

https://github.com/swiss-art-research-net/reference-data-models/issues/8

[illip]

I would like to come back to the initial question of this thread concerning the necessity of creating a new pattern for familial relationships. The issue is about the intention because currently our pattern uses E7_Activity to bind the actors together. So in theory, the familial relationships should be:

actions intentionally carried out by instances

which is not the case for every familial relationships. I might have an uncle that I've never met and who even doesn't know that I exist. Like @KarineLeonardBrouillet pointed out, this could also be the case of a teacher that doesn't know all of his students, however we might argue that he is intentionally participating to the relationship by teaching to a group where the person is a participant. Like @stephenhart8 mentioned, we have the same issue with influences where one of the "participant" the influencer isn't participating intentionally in the relationship.

I think we all agree, that we need a node for the relationship itself. This will allow us to add information to this node like the time-span of this relationship like @stephenhart8 and @VladimirAlexiev agreed on. So for this reason, we won't be using the AgRelOn patterns because it would be impossible to document the dates. In addition, we would have to manage a long list of relationship types that we don't want to maintain in the model per se. CHIN prefers to give the opportunity to the community to build the proper vocabularies they want to use to describe the relationships. Engineering-wise, it's also probably easier to manage those types in an external vocabulary. That said, I think we should reuse AgRelOn vocab whenever it's useful to ease eventual reconciliation processes.

So I guess we have 3 options:

1. So first option would be to have a distinct pattern with a n-ary construct. As I understand, Linked.Art, SARI and MuseumProvenance model (mentioned by @eecanning) are using this kind of construct. This would be something outside CIDOC CRM. SARI uses a new class SRPC3 in social relation which, I think, isn't a sub-class of a CIDOC CRM class. At the beginning, I wasn't a huge fan of this option because we were giving better semantics to a "descriptive process" instead of revealing the "true" semantics behind the relationship. However, maybe it's the best way to do it since our pattern can only represent intentional relationships. My only concerns is how we would manage the inverse. We will need to automatically add the inverse information in the other person's node? What do we do when the inverse is not necessarily the same type (e.g. I can be a student of a teacher or a tutor)?

2. It would be nice to have a PC11_had_participant class with P11.1_in_the_role_of property but @Habennin will probably tell me that you cannot have a role if you don't intentionally participate in the event. ;)

3. We keep our construct as a non-ideal workaround for non-intentional relationships.

[VladimirAlexiev]

Here's our RDF* implementation: http://graphdb.ontotext.com/documentation/9.2/standard/devhub/rdf-sparql-star.html

[illip]

Currently, we model family with a relationship pattern, which I think it's relevant. That said, we explicitely state in the Target Model that we are not modeling families as groups:

Families are not represented as groups.

I think this is something we would like to review in order to manage several use cases where a family is doing something. Family X meets every summer at Place Y. If we don't know each member, we have to represent the family as a group.

Obviously, this shouldn't replace the relationship pattern. We need both to express the relationship between two family members and to describe the family's activities.

[marielmat]

Reflections for the 9th meeting of the committee.

I find this a sensitive issue. I see three elements:

• the way family relationships are described in official documents (birth certificate where it says x (female) is "the daughter" of y (male) who is "the father" of x)

• the way one describes his own family (one can deny being the child of y - even if biologically speaking it is true; one can say that her father's best friend is her "aunt"; the terms ""cousin, uncle, aunt"" can have a rather broad connotation...)

• how others describe themselves in relation to the family (x may recognize himself as the "father" of y when he is actually the "stepfather" and y perceives him as such)

Am I going too far? :|

But I think it would be better if the model was rather flexible.

For the Family group, I find the idea interesting. In our data, it is a concept that comes up often, for archives or even at the level of donors. But we still need to be able to make sure that we distinguish between two "Thompson families". On what criteria is the family defined? What causes a family to form? Leads to its end?

We have many artifacts associated with religion: does baptism represent entry into the "family" of God? - Is being member of a religious community is defined, at least by the members of the community, as being part of a family?

[Christian-McCord]

The Museum Systems, le logiciel de base de données que nous utilisons, permet d'enregistrer des relations familiales entre "Actors". Nous commençons à peine à exploiter cette avenue qui nécessite une importante rétroactivité. Nous le faisons surtout pour établir des liens familiaux qui ne sont peut-être pas évidents à première vue (noms de famille différents, etc.). Nous n'avons pas encore créé une terminologie qui permettrait de nuancer les liens familiaux entre individus, nous contentant de spécifier s'il s'agit d'un enfant ou d'un parent (la même dichotomie est utilisée pour des objets présentant une parenté, ex: matrice et épreuve).

Les liens ainsi établis aident beaucoup à la recherche mais essentiellement à l'interne.

[stephenhart8]

The Semantic Committee has decided on 2021-05-06 that:

• The distinction between biological parents and parent relationships is relevant as they are two different kinds of information (for example, a person can be the biological parent of another individual, but have no social relationship with them, or a relationship of a different nature). It had been decided that the biological parents would be documented through the birth event, while social relationships would be documented by the Relationship pattern. It has been specified during the meeting that it will be important to document the distinction between those two patterns in the TM, so that data experts don't struggle to identify the appropriate pattern for each kind of information.
• The creation of a Family Group is also needed in the TM. This will be modelled with a joining and leaving event, similarly to the Identity patterns.