Review the categorisation of relations

[kerstarno]

While EAD3 only includes the general element of <relation> with the attributes of relationtype (restricted to the values "cpfrelation", "resourcerelation", "functionrelation", "otherrelationtype") and otherrelationtype, EAC-CPF distinguishes between <cpfRelation>, <functionRelation> and <resourceRelation>. All three of these elements come with their own - optional - *RelationType attribute with a set of predefined values.

[kerstarno]

It might be worth investigating the possibility/suitability of aligning the approaches in both standards/schemas.

Furthermore, and in terms of using predefined values, it would be worth following up on further developments of RiC (once published/available) and potential definitions of relationships there.

[kerstarno]

Conversations so far also included the idea to consider adding an otherRelationType option for EAC-CPF.

[kerstarno]

Summary of today's conversations:

• Further and more detailed discussion of this topic needs to take context/history of <*relation> into account - for EAC-CPF it was kind of early days / EAD3 picked up on what existed in EAC-CPF, but the revision process tried to accommodate opposing ideas/approaches with the result of the <relations>section in EAD3 being experimental
• Mark to check with Mike if there's more detailed documentation about the previous discussion around this point
• Kerstin to check with Bill along the same lines
• Kerstin and Regine to look at RiC-O and to share relations approach thereine (as far as possible given the confidentiality clause for RiC-O evaluation)
• Kerstin and Regine to keep aspect of relations in mind in the context of the Related standards subteam (i.e. how are others doing this?)

[regineheberlein]

Via email from Daniel to Kerstin:

1. "Where EAC-CPF did not go far enough was in not including place, subject, and any attributes that have as values controlled names or terms, as these should also be modeled as 'holds between' relations", i.e. relations between one entity and another.
2. "Relations among the entities will necessarily not be binary, that is, you want to be able to "say something about" each relation. For example, a relation may have a beginning and end date. Or may be qualified by existing in a particular place."
3. "There was one development, if my memory serves, with which I agree wholeheartedly: not to explicitly identify types of relations in element names as was done in EAC-CPF: cpfRelation, resourceRelation, and functionRelation. Instead, a relation that can be made more specific through an @type. (Well, actually @relationtype = "otherrelationtype", @localtype). This is a better design, I think."

[regineheberlein]

Today's conversation:

• relations may need to be handled via element rather than attribute due to cardinality constraints
• mandatory type attribute, requires additional local type if set to "other"
• discussion of placement of such an element: nested or standalone. Favoring standalone for streamlining the data
• this approach would need alignment between standards
• Link to discussion in EAC-CPF team notes: https://github.com/SAA-SDT/TS-EAS-subteam-notes/blob/master/eaccpf-subteam/working-documents/proposal%20redesign%20by%20G.%20M%C3%BCller
• Evaluate other standards for relations, might there be an option of having an extension point where relations described by another standards is used. This in combination with a simple relation element.

[regineheberlein]

Homework for next week: read through Google docs: https://docs.google.com/document/d/1B7dSPDbE2DKurXFkMTsgtuM5ASN0Sm8FYOHD3z11tIU/edit?usp=sharing
https://docs.google.com/document/d/1iwov1MdGqBOEfp9hGJM7L2FC2NIRIPBlofimZcnbF1w/edit?usp=sharing
https://docs.google.com/document/d/1qi8RSZlg4dqXYH53waQSmy0Ko0qGpND9oXIbQU1ynlI/edit?usp=sharing

[kerstarno]

For reference see also SAA-SDT/eac-cpf-schema#35.