search

DILCISBoard / E-ARK-CSIP

E-ARK Common Specification for Information Packages
http://earkcsip.dilcis.eu
Creative Commons Attribution 4.0 International
11 stars 5 forks source link

CSIP91 and CSIP92 - what about SUPERSEEDED xml:IDs? #650

Closed PhillipTommerholt closed 2 years ago

PhillipTommerholt commented 3 years ago

CSIP91 and CSIP92 states that all of the <amdSec>/<dmdSec> identifiers are listed in a single @ADMID/@DMDIDusing spaces as delimiters in the metadata div-element in structMap. Strictly speaking this means that metadata files with the @STATUS='SUPERSEEEDED' also need to be described. Is this the case we want? CSIP80 states that "The <structMap> in the CSIP describes the highest logical structure of the IP." which might mean that we want to only list the relevant metadata files?

A suggestion could be: "Metadata division administrative metadata referencing mets/structMap[@LABEL='CSIP']/div/div[@LABEL='Metadata']/@ADMID When there is administrative metadata and the amdSec is present, all administrative metadata with @STATUS="CURRENT" MUST be referenced via the administrative sections different identifiers. All of the <amdSec> identifiers with @STATUS="CURRENT" are listed in a single @ADMID using spaces as delimiters."

karinbredenberg commented 2 years ago

Looking at this, yes both statuses needs to be described in the two attributes so it is connected to the package described in the structMap. This might need to be moved forward and a new discussion to be had regarding having superseded information in the package, when does it occur, is it when it is an AIP?

carlwilson commented 2 years ago

I've read and thought about this and believe I get the intention. The most likely use of @STATUS='SUPERSEDED' would be within an AIP to denote metadata that was no longer current. It's possible that a DIP might contain the same status if the user accessing wanted a full history of the item requested. I think that @PhillipTommerholt's point:

CSIP80 states that "The <structMap> in the CSIP describes the highest logical structure of the IP." which might mean that we want to only list the relevant metadata files?

probably wins here. Restricting the value list to @STATUS='CURRENT' would stop the list from growing ever longer. If the history is to be recorded it should be as PREMIS events with the appropriate "audit" style metadata, e.g. date, etc.