Re-structuring with sub-requirements: Section B1

A general observation: there seem to be three ways of formulating many of the requirements:

  1. "Repository does X"
  2. "Repository has procedures for doing X" (which can be checked)
  3. "Repository has evidence that it is doing X" (which can be inspected)

It could be that (b) and (c) are both simply evidence for (a), which should be the stated form of the requirement.

ALERT! Currently the following just shows a proposed hierarchy of requirements, without any of the "This is necessary", examples and discussions, but that might make it easier to follow the logic.

B1. Ingest: acquisition of content

B1.1

Repository identifies properties or information content it will preserve for digital objects.

Supporting Text

B1.1.1 The repository has a statement of the range of digital objects it will undertake to preserve.

B1.1.2 The repository has a procedure(s) for identifying those properties or information content that it will undertake to preserve for the whole range of objects.

B1.1.3 The repository has an explicit record of those properties and information content for all digital objects for which it has responsibility.

This is necessary ....

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Discussion

B1.2

Repository clearly specifies the information that needs to be associated with digital material at the time of its deposit (i.e., SIP).

Supporting Text

B1.2.1 The repository has a defined procedure for translating the identified properties and information content that it preserves to information needed at the time of deposit (as part of the SIP).

B1.2.2 The repository can show that the information received at deposit is sufficient to allow the preservation of the identified properties and information content.

B1.2.3 The repository demonstrates that the specification of the SIP is communicated to the content provider.

ALERT! May need some reworking to allow for case of no content provider, e.g. Web harvesting

This is necessary ....

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Discussion

B1.3

Repository has mechanisms to validate the source of all materials.

Supporting Text

B1.3.1 The repository ensures that the source of all material submitted as a SIP comes from the expected content provider.

B1.3.2 The repository verifies the provenance of the SIP prior to submission, to an appropriate degree. [This might need another sub-requirement to clarify what is ‘appropriate’.]

This is necessary ....

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Discussion

B1.4

Repository’s ingest process verifies each submitted object (i.e., SIP) for completeness and correctness as specified in B1.2.

Supporting Text

B1.4.1 The repository verifies that the SIP contains items corresponding to all the specified information required of the content provider. [This is meant to check that ‘everything is there’, not that it is necessarily valid/correct.]

B1.4.2 The repository has procedures for verifying that each required item is usable, meaningful and valid, to a defined degree [the terminology might need tightening up here].

B1.4.3 The repository has defined procedures for action in case any of the items fails to pass the above tests.

This is necessary ....

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Discussion

B1.5

Repository obtains sufficient physical control over the digital objects to preserve them.

ALERT! Requirement possibly to be subsumed into B1.2.

B1.6

Repository provides producer/depositor [terminology cf. "content provider"?] with appropriate responses at agreed points during the ingest processes, including when preservation responsibility is accepted for the contents of each set of submitted digital objects.

Supporting Text

B1.6.1 The repository must ensure that the point at which it has accepted responsibility for preservation of a digital object is clear to producers/depositors.

B1.6.2 For each producer/depositor, the repository has a record of what subsequent responses are expected and when, and that this is agreed with the producer/depositor.

B1.6.3 The repository has procedures for generating responses at the agreed points and transmitting them to the producer/depositor.

B1.6.4 The repository responds to communication from the producer/repository in the case that there is a problem with a response [better wording needed].

This is necessary ....

Examples of Ways the Repository can Demonstrate it is Meeting this Requirement

Discussion

B1.7

Repository has written policies that indicate when it accepts preservation responsibility for the contents of each set of submitted data objects (i.e., SIPs).

ALERT! Requirement subsumed into B1.6.

B1.8

Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Ingest: content acquisition).

Supporting Text

B1.8.1 The repository must identify events relevant to Ingest: content acquisition.

B1.8.2 The repository must document those events in a timely fashion.

B1.8.3 Where community or international standards are used, the repository must demonstrate that all relevant actions are carried through.

This is necessary ....

-- SimonLambert - 20 Nov 2008

Topic revision: r1 - 2008-11-20 - SimonLambert
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback