Open kerstarno opened 5 years ago
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.
Conversations so far also included the idea to consider adding an otherRelationType option for EAC-CPF.
Summary of today's conversations:
<*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 experimentalVia email from Daniel to Kerstin:
Today's conversation:
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
For reference see also https://github.com/SAA-SDT/eac-cpf-schema/issues/35.
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.