Relation between subject and `linked_subject`

[bussec]

Within a subject record, the keys linked_subjects and link_type are used to describe the relation of the record's subject to other subjects. However, these relations are often directional, therefore it needs to be specified how to interpret this information.

For expample, the information <subject>, <father>, <linked_subject> can be either interpreted

• <subject> IS <father> OF <linked_subject>

or

• <subject> HAS <father> <linked_subject>

but this describes reciprocal situations.

Is there any standard whether to use HAS or IS?

[ssnn-airr]

I have a question re pedigrees. Is the current schema able to capture relationships that are not possible to infer from data available, but that are relevant? Example, we have samples of a child and the four grandparents. The parents died. But you want to be able to keep track of the grandparents being maternal or paternal. Would you (a) use a relationship has_maternal_grandmother instead of has_grandmother, or (b) would you use has_grandmother and attach the description maternal to the link?. I am not sure (b) can be done with the current schema. Also, is there and ontology for pedigree relationships we can follow (for human and other species, there might be differences?)?

[ssnn-airr]

I found this ontology in Bioportal (http://bioportal.bioontology.org/ontologies/FHHO), and realized that also half-sibling relationships need to keep track of being maternal of paternal.

[schristley]

<subject> IS <father> OF <linked_subject>

Regarding implementation, this interpretation implies that <subject> <father> maintains a list of its children as presumably <subject> can be <father> to more than one <linked_subject>

<subject> HAS <father> <linked_subject>

While this interpretation implies that <subject> only needs a single <linked_subject> data element as presumably <subject> can only have one <father>. This interpretation follows the schema better.

However that might not be true for all relations, and in the general case it can be an n-to-n relationship. An n-to-n relationship generally implies in the database world that you need a separate entity (table) to record multiple relations.

[bussec]

Note that a more complex annotation scheme was discussed by MiniStd (see #308 ) but shelfed.

[scharch]

closing as stale/moot