search

DILCISBoard / E-ARK-SIP

E-ARK SIP specification
https://earksip.dilcis.eu/
Creative Commons Attribution 4.0 International
7 stars 6 forks source link

SIP9-31 agent ambiguities #98

Closed koit closed 2 years ago

koit commented 3 years ago

SIP9 - SIP31 specify four types of metsHdr/agent but their distinction is insufficient to create useful tests.

Issue 1: Agents indistinguishable from each other

There is no explicit category identifier for these four SIP agents and no unique signature can be combined from @ROLE and @TYPE values.

Requirement Cardinality @ROLE @TYPE
SIP9 Archival creator agent 0..1 MAY /full vocabulary allowed/ ORGANIZATION, INDIVIDUAL
SIP15 Submitting agent 1..1 MUST /full vocabulary allowed/ ORGANIZATION, INDIVIDUAL
SIP21 Contact person agent 0..* MAY CREATOR INDIVIDUAL
SIP26 Preservation agent 0..1 MAY PRESERVATION ORGANIZATION
CSIP10 Agent (creator software) 1..n MUST CREATOR OTHER

For instance, an agent with @ROLE = "PRESERVATION" and @TYPE = "ORGANIZATION" could be considered SIP26 Preservation agent, but the same combination is also valid for SIP15 Submitting agent. For comparison, CSIP10 agent has a much clearer signature: @ROLE = "CREATOR", @TYPE = "OTHER", @OTHERTYPE = "SOFTWARE" and note/@csip:NOTETYPE="SOFTWARE VERSION".

A more serious problem is that any of these SIP agent attribute values are also valid for custom agents the user has added. In order to do meaningful compliance tests we need an explicit way to identify the E-ARK SIP agents.

One (not too elegant) way out of it might be to add a custom attribute: metsHdr/agent/note/@sip:AGENTROLE = CREATOR | SUBMITTER | CONTACT | PRESERVER.

Note: mets.xsd vocabularies for @ROLE and @TYPE are:

Issue 2: metsHdr/agent/name is not 0..*, but 1..1

SIP12 metsHdr/agent/name is defined as 0..* MAY, but METS defines it as 1..1 (mets.xsd, lines 247-263):

<xsd:element name="metsHdr" minOccurs="0">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="agent" minOccurs="0" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="name" type="xsd:string">

Issue 3: Inconsistency in cardinality of metsHdr/agent/name

The cardinality requirements for metsHdr/agent/name do not follow a consistent logic in relation to the cardinality of their metsHdr/agent. According to mets.xsd, metsHdr/agent/name cardinality is 1..1, a "conditional MUST," i.e. if a metsHdr/agent exists, it MUST have exactly one metsHdr/agent/name.

metsHdr/agent Cardinality metsHdr/agent/name Cardinality
SIP9 Archival creator agent 0..1 MAY SIP12 0..* MAY
SIP15 Submitting agent 1..1 MUST SIP18 1..1 MAY
SIP21 Contact person agent 0..* MAY SIP24 1..1 MUST
SIP26 Preservation agent 0..1 MAY SIP29 1..1 MAY
jmaferreira commented 3 years ago

Hi,

This issue will be analysed towards June/July. If we are able to tackle it in a way that doesn't break the current structure of the package it will be released as a minor update by November 2021. If the issue implies incompatible changes to the structure, it needs to be addressed under the development of version 3.0.0 of the SIP specification.

jmaferreira commented 2 years ago

Dear @koit,

We are now looking into these issues. Sorry for the delay. Issue 2 and 3 are being addressed. No problems there. Thank you for pointing these out.

Regarding Issue number 1, we would like to know exactly which agents you are willing to encode in the package. Is this the complete list?:

jmaferreira commented 2 years ago

Dear @koit,

This issue was broken into 3 new issues to simplify its distribution. See #100, #101, #102.