DILCISBoard / E-ARK-SIP

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

Agents indistinguishable from each other #100

Closed jmaferreira closed 1 year ago

jmaferreira commented 3 years ago

Original post from @koit. Issue #98 was broke apart into 3 individual issues.

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:

jmaferreira commented 3 years ago

@karinbredenberg Could you add your comments here?

karinbredenberg commented 3 years ago

Some observations on this issue: SIP10 might need the addition of the required value "ARCHIVIST". (Not backward compatible, its expected by the name of the agent but have not been stated)

Submitting agent don’t have requirements looking like the example so SIP15 needs a required "OTHER", a new requirement regarding using the attribute OTHERROLE and an addition to the vocabulary for agent roles.

Suggestion is therefore to move this issue into the work with the next version. Changes in presenting the examples will be made in this update.