Closed koit closed 2 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.
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?:
Dear @koit,
This issue was broken into 3 new issues to simplify its distribution. See #100, #101, #102.
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.@ROLE
@TYPE
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"
andnote/@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..1SIP12
metsHdr/agent/name
is defined as 0..* MAY, but METS defines it as 1..1 (mets.xsd, lines 247-263):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 theirmetsHdr/agent
. According to mets.xsd,metsHdr/agent/name
cardinality is 1..1, a "conditional MUST," i.e. if ametsHdr/agent
exists, it MUST have exactly onemetsHdr/agent/name
.metsHdr/agent
metsHdr/agent/name