Is a list of all SIPs ever received required? No text other than pointing to the single current sub-metric. Much of that text seems to apply to this metric rather than the sub-metric. Perhaps break into separate metrics: 1. Keep list of all SIPs a. if incorporated, say which AIP(s) it fed in AIP, note source SIP(s) b. if rejected, say why c. received, track when processing to start d. in process, track progress e. not rejected or incorporated, say why"
(In reply to John Garrett from comment #0) > Is a list of all SIPs ever received required? > > No text other than pointing to the single current sub-metric. Much of that > text seems to apply to this metric rather than the sub-metric. > > Perhaps break into separate metrics: > 1. Keep list of all SIPs > a. if incorporated, say which AIP(s) it fed > in AIP, note source SIP(s) > b. if rejected, say why > c. received, track when processing to start > d. in process, track progress > e. not rejected or incorporated, say why" Not clear which metric is being referred to - is it "4.2.3 The repository shall document the final disposition of all SIPs".? Or perhaps "4.2.3.1 The repository shall follow documented procedures if a SIP is not incorporated into an AIP or discarded and shall indicate why the SIP was not incorporated or discarded."?
Perhaps we can tidy up the metrics by changing FROM: 4.2.3 The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked. 4.2.3.1 The repository shall follow documented procedures if a SIP is not incorporated into an AIP or discarded and shall indicate why the SIP was not incorporated or discarded. TO: 4.2.3 The repository shall follow documented procedures including documenting, with rationale, the final disposition of all SIPs, whether or not a SIP is incorporated into an AIP or discarded.
I think additional points could be emphasized. FROM: 4.2.3 The repository shall document the final disposition of all SIPs. In particular the following aspect must be checked. 4.2.3.1 The repository shall follow documented procedures if a SIP is not incorporated into an AIP or discarded and shall indicate why the SIP was not incorporated or discarded. TO: 4.2.3 The repository shall follow documented procedures for processing all SIPs. In particular the following aspect must be checked. 4.2.3.1 The repository shall follow documented procedures if a SIP rejected or discarded. 4.2.3.2 The repository shall follow documented procedures to convert SIP components into AIP components. 4.2.3.3 The repository shall add provenance to AIPs detailing the conversion of SIP components into AIP components. Supporting Text FROM: This is necessary in order to ensure that the SIPs received have been dealt with appropriately, and in particular have not been accidentally lost. ADD: This is necessary to ensure that AIP content can be traced back to ingested SIP content. ADD to EXAMPLES: logs of conversions made to SIP contents while creating AIPs, Provenance Information within AIPs. DISCUSSION FROM: The timescale of this process will vary between repositories from seconds to many months, but SIPs must not remain in an unprocessed limbo-like state forever. The accessioning procedures and the internal processing and audit logs should maintain records of all internal transformations of SIPs to demonstrate that they either become AIPs (or part of AIPs) or are disposed of. Appropriate descriptive information should also document the provenance of all digital objects. ADD: Some repositories may assign or require unique identifiers for all SIPs, but they are not required to do so. Some repositories may maintain a list (or even a copy) of every submission. However, the documented procedures of other repositories may allow for rejection of submitted items that do not meet their requirements for SIP submission without assigning an identifier to it or maintaining a copy of it.
John's wording looks good to me.
On 20200630 the DAI WG agreed to the proposed wording. As the submitter of this Suggested Change, I concur with the change.