SIP9-31 agent ambiguities

[koit]

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:

• mets/metsHdr/agent/@ROLE = CREATOR | EDITOR | ARCHIVIST | PRESERVATION | DISSEMINATOR | CUSTODIAN | IPOWNER | OTHER
• mets/metsHdr/agent/@TYPE = INDIVIDUAL | ORGANIZATION | OTHER

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]

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]

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?:

• Archival creator agent
• Submitting agent
• Contact person agent
• Preservation agent
• Creator software

[jmaferreira]

Dear @koit,

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