METS Profile Requirement SIP2

[stephenmackey]

SIP2 requires that the value of mets/@Profile MUST be set to “https://earksip.dilcis.eu/profile/E-ARK-SIP.xml”. Certain of the CITS (Geospatial, eHealth1, SIARD) also have METS profiles and so also have the requirement for mets/@Profile to be set with the profile URL. If validation is to take place in the way planned; i.e. as a layered approach, then all Geo, eHealth1 and SIARD CITS will fail SIP validation (and DIP). If validation is to be sequential from CSIP to SIP to CITS then the @Profile requirement will need to be conditional on the @CONTENTINFORMATIONTYPE of the package.

[jmaferreira]

Hi @stephenmackey,

That particular requirement has changed a bit. It now points to the correct version of the profile. See https://github.com/DILCISBoard/E-ARK-SIP/blob/rel/v2.2/profile/E-ARK-SIP-v2-2-0.xml#L108

To support the layered validation approach I need to consult our technical team, however, I wonder if this proposal will have an impact on more than the SIP spec. Maybe it should be addressed at the CSIP.

I'll get back to you on this.

[jmaferreira]

Hi @stephenmackey,

Taking a closer look at the common package specification one can see that it contains both the information about the METS profile that it should follow (or be validated by) and also the CITS that it should adhere to (controlled vocabulary):

1. PROFILE="https://earkcsip.dilcis.eu/profile/E-ARK-CSIP.xml"
2. csip:CONTENTINFORMATIONTYPE="SIARD2"

In my view, someone that wishes to develop a package validator already has all the information that it needs to perform the hierarchical validation that you propose.

Am I missing something in your original issue?

Full example:

<mets:mets 
    xmlns:csip="https://DILCIS.eu/XML/METS/CSIPExtensionMETS" 
    xmlns:mets="http://www.loc.gov/METS/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:xlink="http://www.w3.org/1999/xlink" 
    OBJID="csip-mets-example"
    LABEL="Sample CSIP Information Package" 
    TYPE="Datasets" 
    csip:CONTENTINFORMATIONTYPE="SIARD2"
    csip:OTHERCONTENTINFORMATIONTYPE="FGS Personal, version 1" 
    PROFILE="https://earkcsip.dilcis.eu/profile/E-ARK-CSIP.xml"
    xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/mets.xsd
                        http://www.w3.org/1999/xlink http://www.loc.gov/standards/mets/xlink.xsd
                        https://DILCIS.eu/XML/METS/CSIPExtensionMETS https://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd">
</mets:mets>

[stephenmackey]

Hi @jmaferreira, doesn't this mean that somehow the contentinformationtype has to resolve to the current version of the mets profile? Contentinformastiopn type says what kind of CITS it is but it doesn't say where the profile is or what the rules in the profile are.
Stephen

[jmaferreira]

Yes. You are absolutely right. There is a location and versioning issue that needs to be addressed.
However, I believe this an CSIP issue, and not a SIP issue. @karinbredenberg Would you agree?

[karinbredenberg]

CSIP6 states: "The URL of the METS profile that the information package conforms with."

And it needs to be that general and then given by the specification that extends CSIP +SIP to say what it exactly should be. Version comes with the path following how that was updated during the spring.

So yes it can't just be the SIP profile it needs to be the CITS profile which in its turn extends SIP which in its turn extends CSIP.

[jmaferreira]

Humm.. are you suggesting that for each CITS version we need to have 3 different profiles - CITS-SIP, CITS-AIP and CITS-DIP?

@stephenmackey Isn't this the real issue at stake here?

[karinbredenberg]

In the extending profiles you have the element (from SIP version 2.0.4):

<related_profile RELATIONSHIP="Extends" URI="https://earkcsip.dilcis.eu/profile/E-ARK-CSIP.xml">E-ARK CSIP METS Profile 2.0</related_profile>

That gives the parent profile. You can repeat the related_profile element. So its a need to check that the CITS adheres to all SIP/AIP/DIP.

[jmaferreira]

Dear @stephenmackey, does Karin's suggestion resolves your issue?

[stephenmackey]

Dear @jmaferreira, @karinbredenberg not quite. The wording of CSIP6 is good as it says that the METS/@Profile should be set to the url of the profile that the package conforms with. SIP2 says that "The value is set to "https://earksip.dilcis.eu/profile/E-ARK-SIP.xml". which alters CSIP6. SIP2 is not required as is any subsequent requirement in the CITS, the value should always be that which the package conforms with according to CSIP6, maybe "the highest level profile that the package conforms with" would be more accurate. The CITS profiles can state that the profile MUST be for example "https://citsehealth1.dilcis.eu/profile/E-ARK-eHealth1-ROOT.xml". But this does create a validation problem unless you create a validation/requirement hierarchy. It may be easier to grandfather in CSIP6 and to deprecate the profile requirements in the package specifications and the CITS. I will check if DIP and AIP profiles exist and reference them in my CITS profiles as suggested.

[stephenmackey]

@jmaferreira @karinbredenberg AIP does not seem to have a profile at: earkaip.dilcis.eu/profile but it does exist in GitHub. DIP does have a profile at: earkdip.dilcis.eu/profile. I will raise an issue on eHealth1 to add the DIP profile reference.

[karinbredenberg]

Just to note, the METS Document needs to state which METS Profile it is following so it should if its following only the SIP point to the SIP METS-profile, eHealth1 the eHealth1 and so on. If we just point to the CSIP profile we loose the infromation of which profile is used since the value list in type is not the determinator of the profile.

[karinbredenberg]

@jmaferreira @karinbredenberg AIP does not seem to have a profile at: earkaip.dilcis.eu/profile but it does exist in GitHub. DIP does have a profile at: earkdip.dilcis.eu/profile. I will raise an issue on eHealth1 to add the DIP profile reference.

Not sure about the status for the AIP profile. I know one was going to be created.