Formalise/record conventions for noting profile dependencies

[carlwilson]

In order to support hierarchical validation we need to record the dependencies between validation profiles. Consider a CITS profile that depends upon the base E-ARK IP specifications and the PREMIS CITS profile. Any validator would need to be able to determine the dependencies for the profile bieng validated. This could be achieved by using the related profile element in the METS profile schema. While this is already used, a formalised vocabulary and usage guidelines are needed. The current SIARD CITS declares that it extends the E-ARK SIP profile as follows:

<related_profile RELATIONSHIP="Extends" URI="https://earksip.dilcis.eu/profile/E-ARK-SIP.xml">E-ARK SIP METS Profile 2.0.4</related_profile>

This is a start, but there a couple of issues:

• There is no version number in the SIP profile URL (see It should be clear which version is a CSIP/SIP/AIP/DIP compatible with #703 for versioning solutions).
• There is no formal definition of the RELATIONSHIP attribute values, Extends may be enough but the vocabulary should be defined.
• Does declaring a dependency on the E-ARK SIP profile make sense? SIARD packages may also be DIPs or AIPs, these are simply IP lifecycle phases.

[karinbredenberg]

The issue is going to be discussed by the DILCIS Board

[jmaferreira]

I agree with @carlwilson. Some polishing work is needed here. Here are some suggestions:

1. There is no version number in the SIP profile URL - Solvable by setting the correct URL to the actual profile.
2. There is no formal definition of the RELATIONSHIP attribute values - I agree. A vocabulary should be created. It does not need to be a formal one, but something should be said in the documentation.
3. Does declaring a dependency on the E-ARK SIP profile make sense? - No It does not make sense and that dependency should be removed.

[karinbredenberg]

There is no objections in the DILCIS Board to move on with this suggestion, from the DILCIS Board meeting 2023-12-06.

[carlwilson]

OK, I will take a look at implementing these in a branch for February 2024. I'll ping this issue once it's ready.