TWiki> Main Web>AvailabilityMatrix>WorkingDocuments>MandatoryReqts>MandatoryReqtsB (21 Jan 2008, HelenTibbo) EditAttach

Identification of mandatory requirements: Section B

Please choose an option under your initials for each requirement. Comments may be added to the table below each requirement, by adding a row to the table.

At the Megameeting on 26th November 2007, it was agreed that the following definitions would be used:

  • Mandatory means it is a critical requirement that must be done in order to either be doing preservation adequately or demonstrating the same
  • Marking with Y means accepting the requirement as mandatory as it is now expressed; N means considering it is not mandatory as it is now expressed; ? means that it needs clarification.

B1. Ingest: acquisition of content

B1.1 Repository identifies properties it will preserve for digital objects.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y Y Y Y Y Y Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
JohnGarrett Preserved properties may vary by Producer-Archive Project
RobertDowns A repository could offer different levels of preservation services for each collection.
DavidGiaretta The granularity certainly could be finer than just a blanket statement - could be at a dataset by dataset level
DonaldSawyer Our NSSDC does offer different levels of service, and there are different significant properties (such as filenames - yes or no) to be preserved for each collection. I think this level of variability is covered by the 'evidence'.
MarieWaltz These properties may change over time, so it is important that the language state the need to continually identify new properties.

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

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y ? Y Y Y Y Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
JohnGarrett Information needed may vary by Producer-Archive Project.
RobertDowns A repository could have different deposit requirements for each collection.
DavidGiaretta This is important BUT may well be implied by other metrics.
DonaldSawyer I recommend updating the title to address 'the primary digital material', and changing 'SIP'to 'SIP content and interrelationships'. Related to David's note, perhaps we should identify the categories of info and compare with later requirements.
MarieWaltz This may need some work "the information that needs to be associated with digital material" its a bit loose. I like Donald's "SIP content and interrelationships."

B1.3 Repository has mechanisms to authenticatevalidate the source of all materials.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y ? ? Y ? Y Y ? - ? Y Y Y

Who Comment (add a row to the table for your comment)
HTib I would say the ability to authenticate the source is not the same as authenticating the object itself, i.e, the repository needs to know from whence a digital object comes but can they ever be sure it is what it purports to be? The repository can, however,ensure that over time that object remains authentic, however that is defined.
JohnGarrett I want to say Y, if we can just believe the Producer is who they claim to be without a formal "authentication" process. Also text as opposed to the checklist item also talks about verification of the objects and provenance so I'm not sure if we are talking about "authentication" of Producer or of processing to create SIPs.
RobertDowns A repository could have informal mechanisms for authenticating a source if the source is known by the repository. For example, a telephone conversation, a reply to an email request, download from the author's website, or deposit from a staff member on behalf of the author.
DavidGiaretta The repository must maintain the evidence of authenticity - I don't think that is is necessary to insist on proof of authenticity at the start e.g. Web archiving - however the metric talks about mechanisms being available so is rather looser than that. In the sense that it is fairly loose, it is probably a less fundamental requiremnet.
DonaldSawyer The title, and part of the text, address the 'source' as the entity providing the information. It then goes on to address provenance more generally. I recommend this requirement just address the source entity. A separate requirement can address the desirability of supporting information that helps ensure the submitted information is what it purports to be.
MarieWaltz For the good of those who are using the material in the future, there is a need for a standard authentication process for the source of the material. Phone calls, etc. are fine but the way they are documented by the repository is what must be standardized by the institution. The repository might run into a situation (maybe a law suit, congressional hearing) where they will have to prove what they have is authentic.

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

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y Y Y Y Y Y Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
JohnGarrett Amount of checking may vary from vary thorough checking of some SIPs and spot checking of others. Also each SIP may not be verifiable as a stand alone object. So would like to see word "each" removed in checklist item.
DonaldSawyer I think B1.2 says repository needs a written specification of what is to be submitted and/or expected, and B1.4 says to check that this is the case for each SIP. I think this is o'k. B1.2 could use some improvement, however.
DavidGiaretta John makes a good point - one may only be able to verify a group of SIPs, although presumably it may be possible to do some verification an each individual SIP

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

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - ? ? - Y ? ? ? - ? ? ? Y

Who Comment (add a row to the table for your comment)
MCon The text accompanying this bullet is so contradictory as to render the requirement meaningless.
CFen I agree that the accompanying text is not clear.
HTib I have no idea what this requirement actually means...
JohnGarrett I suggested an update in main working document that may help to clear up the text.
DonaldSawyer Should be mandatory but needs revision. The intent, as I recall, was to address the need for control of the bits that holds the information to be preserved. References may, or may not, point to such information bits. Cooperating repositories may provide sufficient control of the bits, and I think this should be addressed in the text.
MarieWaltz This is not well worded it is an important requirement. It addresses any supplemental material that accompanies or is cited in the particular SIP. The supplemental material must be accounted for or it will lead to a degradation of the content of the SIP. In some cases, not having the supplemental material will render the SIP's data meaningless. There is an implied problem here with relying on other repository's to preserve some of the cited works. Also, having to identify where these cited works are kept may be an issue for the repository, though in truth, library's have relied on one another for this type of information exchange for centuries.
SLam This certainly is important, but I agree needs revision. A crucial word is "sufficient".

B1.6 Repository provides producer/depositor with appropriate responses at predefinedagreed points during the ingest processes.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- N - N N N N N ? ? - N N N Y

Who Comment (add a row to the table for your comment)
MCon "Repository responses can range from nothing at all to predetermined, periodic reports of the ingest completeness and correctness, error reports and any final transfer of custody document." This is such a wide range of "appropriate" responses as to render the requirement meaningless.
HTib This does not seem to be a requirement for preservation. If the ingest is not complete, etc. then the materials should be rejected or embargoed and if all is OK they should be ingested and it would be nice to tell the producer the disposition but it does not seem critical to preservation itself.
JohnGarrett Archive could just make status of ingest available as a web page for example and would never directly respond to producer. However, some interaction is probably required when total set of objects is finally accepted.
DonaldSawyer Important for engendering trust. I agree with change of 'predefined' to 'agreed' as proposed.
MCon The proposed changes to B1.6. still do not address my concern listed above. i.e., Repository responses can range from nothing at all to predetermined, periodic reports of the ingest completeness and correctness, error reports and any final transfer of custody document." This is such a wide range of "appropriate" responses as to render the requirement meaningless. A mandatory requirement to do nothing does not make sense.
BarbaraSier In the discussion "websites"were mentioned as an exception to this requirement. Dependent on the archive there might be other exceptions (is there an agreement with publishers if you store books as a result of your deposit legislation?, voluntary or not). The archive itself should be able to deliver this information, technically. It depends on the relation with the producer/depositor whether you exchange that information.
MarieWaltz The depositor needs assurance that the material is being acted upon. I agree it engenders trust. This may put some of the responsibility for quality control on the depositor.

B1.7 Repository can demonstrate when preservation responsibility is formally accepted for the contents of the submitted data objects (i.e., SIPs).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - ? ? Y N N ? ? - ? ? Y Y

Who Comment (add a row to the table for your comment)
MCon I do not understand what is meant by the phrase "can demonstrate". The text accompanying this requirement does not seem to shed much light on this topic either. Isn't this a Y/N question? Presumably at some point at or after ingest the answer to the question switches from no to yes. Shouldn't the repository record when this change takes place - regardless of how they notify the depositor?
JohnGarrett B1.5 already requires sufficient control to preserve. I also don't understand "can demonstrate". Text simply talks about reporting back to producer when they've gained sufficient control, but nothing about how that is demonstrated other than Archive deciding they have control.
RobertDowns Perhaps this should be restated as "Repository records date when preservation responsibility is formally accepted for the contents of the submitted data objects (i.e., SIPs)." This could be date of ingest, for example.
KatiaThomaz I think it must be discussed in section A5.
DonaldSawyer Should be mandatory when properly written. I believe the intent of this requirement is for the repository to show both the criteria it uses to determine when it accepts information preservation responsibility AND when that happened. If so, we should make these separate requirements and discuss.
BarbaraSierman The repository owner should have a vision on this, but it may not be the case that it is always possibly to formally accept the content, for example webarchiving

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

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y ? Y Y Y Y Y - ? Y Y Y

Who Comment (add a row to the table for your comment)
MCon I believe it would be useful to rephrase this requirement slightly to make it clear - as the explanatory text does - "related to actions taken during the Ingest: content acquisition process." I would remove the reference to PREMIS. PREMIS often does not list what the "relevant action" should be.
JohnGarrett Agree with Mark. Also, this should focus on actions being captured and not on verifying that standards are followed.
DonaldSawyer Should be mandatory when properly written. I agree with Mark and John's comments.
BarbaraSierman Yes, but it is important to stress that this informations should also be saved for long term preservation, like other events as new software, new versions of virus scans etc.

B2. Ingest: creation of the archivable package

B2.1 Repository has an identifiable, written definition for each AIP or class of information preserved by the repository.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y ? Y ? Y Y ? - ? Y ? Y

Who Comment (add a row to the table for your comment)
MCon Shouldn't this requirement read "or class of AIP" rather than "or class of information?"
DonaldSawyer Mandatory when expressed more cleanly. Currently addresses both definition and implementation
JohnGarrett If "class of information" were changed to "class of AIP" I would think it mandatory. As it is with "class of information", I think it is not. Also evidence list should not include the last sentence. Might move that up into text, but explanations should not be in list of evidence items.
RiccardoFerrante As stated, "each AIP" might be taken to mean each individual AIP, yes? If "each AIP or class of information" were replaced with "class of AIP," I think the true intent of the requirement would be more consistently understood.

B2.2 Repository has a definition of each AIP (or class) that is adequate to fit long-term preservation needs.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y ? Y Y N ? ? - ? Y Y Y

Who Comment (add a row to the table for your comment)
MCon This requirement is extremely context sensitive. It is unclear how you would determine if an AIP was adequate without knowing what the repositories preservation plans and community requirements were.
HTib It would seem that this is also a requirement that involves evaluation of the entire system and its success/failure. I guess that is what Mark is saying. However, just because it is of necessity context sensitive doesn't mean that it shouldn't exist. Perhaps we are asking here for documentation as to how the AIP definition was determined and if it is adequate. Not sure how the adequacy is tested in the short-term beyond seeming reasonable.
KatiaThomaz It seems that B2.1 could be combined with B2.2
DonaldSawyer Mandatory when expressed more cleanly. Address how significant properties are incorporated.
JohnGarrett I think this is important, but text needs to be cleaned up. It doesn't need to talk about 2 different archives. Needs to be clear that intended use of data needs to be documented well. In case discussed, definition of TIFF wouldn't need to change, but intended use and significant properties of data need to be well documented.
DavidGiaretta Overlaps with B2.1
MarieWaltz I think B2.2 is subordinate to B2.1. The additional need to define long-term preservation criteria only occurs some of the time, when a class of AIP has additional requirements. The example given in TRAC is that if you have a repository that stores medical x-rays for computer analysis, you would want it to be preserved (long term) in a different way than you would preserve a photographic image, despite their both being defined as the same class of AIP. So, when this crieteria is important, its very important, but often it isn't relevant.

B2.3 Repository has a description of how AIPs are constructed from SIPs.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y - Y Y Y Y Y Y Y - Y ? Y Y

Who Comment (add a row to the table for your comment)
JohnGarrett However, I do not think that transformation/normalization are more common than just capturing data as is as is implied by text. Also under evidence, I think the descriptions of the processes should be part of the evidence of B2.1 and B2.2. The evidence here should be logs that the process was followed.
SLam Does this relate to B1.8: "Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Ingest: content acquisition)."

B2.4 Repository can demonstrate that all submitted objects (i.e., SIPs) are either accepted as whole or part of an eventual archival object (i.e., AIP), or otherwise disposed of in a recorded fashion.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y Y Y Y Y Y Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon The text accompanying this requirement seems to set forth several other requirements (e.g., "Appropriate descriptive information should also document the provenance of all digital objects.")
HTib The descriptive information sentence here seems to relate to B1.3.
JohnGarrett I agree with Mark that the last sentence of text adds requirements that should not be included here. Drop that sentence.

B2.5 Repository has and uses a naming convention that generates visible, persistent, unique identifiers for all archived objects (i.e., AIPs ).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - Y Y - N Y ? ? - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon The text accompanying this requirement appears to list a number of separate requirements (e.g., naming conventions, linking/resolution services, traceability of changed identifiers, etc) I believe these should be broken out in to separate requirements. It appears that some of these requirements would be implementation specific.
HTib Clearly the repository must be able to keep track of its content and find digital objects easily. If not, they are lost for all practical purposes. It would appear that in order to do this, at least with today's technology, several things should occur, e.g., naming conventions, persistent ids, etc. We could include these as sub-requirements that would add clarity and make checking easier, but it is unclear to me why some of the requirements such as B2.2 are so encompassing with no sub-requirements and others such as this one spell out more details and/or specify more sub-requirements. This seems to me to be a failing of the document unless we (and before us, TRAC) have a rationale for this. It may be that the more specified requirements are not context sensitive while the other vaguer ones are. I think we should consider this explicitly for each requirement.
JohnGarrett Although useful, I'm not totally sure an identifier is a requirement for preservation and I'm even less sure that a visible or persistent one is required. An identifier may or may not help with discovery or access. Data mining techniques can allow us to find items without identifiers. A sufficiently long CRC code could be an identifier as well as a fixity item, but will likely not help at all to discover the object.
BarbaraSIerman I have some trouble with the "visible", however I'm quite sure the object needs a persitent identifier in the repository. But Johns argument seems also valid: there are enough ways to find an object. However, for example for versioning, a persistent identifier might be very helpful
MarieW I think it would be a mistake not to require repositories to use a naming convention. Even if it possible to trace an AIP in other ways, it is easier to trace and track by the name.
SLam I agree with much of the above. Having names/identifiers of some sort seems very fundamental, even if there may be other ways of tracking items.

B2.6 (Removed)

B2.7 Repository demonstrates that it has access to necessary tools and resources to establish authoritative semantic or technical context of the digital objects it contains. These tools and resources can be held internally or can be shared via, for example, a trusted set of registries.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y ? - ? Y ? ? - ? ? ? Y

Who Comment (add a row to the table for your comment)
MCon It is unclear what is being required here. What is meant by the "authoritative semantic or technical context of the digital objects?" Is this just the format information contained in registries? Will the required information vary from one repository to another? from one AIP to another?
HTib I agree with Mark. Here is an example of one of the unspecified requirements as opposed to the one above. Certainly semantic and technical context are different things. Most of the text talks about format registries then metadata, representation data, and persistent identifiers are thrown in for good measure. If there are types of data here shouldn't they be broken out?
RobertDowns I also agree that this seems ambiguous.
KatiaThomaz To be clearer it must include only OAIS terms, i.e., semantic information and structutal information
DonaldSawyer It appears this is a detail of an approach to satisfying part of B 2.2.
JohnGarrett I agree with Don the B2.2 (and B2.1) is a requirement to define what is needed and this should then be a requirement to show we actually do what was defined (for rep information). Seems like this is focusing too much on way to do it rather than that we are actually doing it. Access to tools, i.e. the registries, doesn't mean that have the information required to support your AIPs.
BarbaraSierman Is not this requirement to early in time, as the repositories with this kind of information are still "under construction" more or less
DavidGiaretta It seems to me that this is mandatory although needs work on the wording, and perhaps it is a sub-set of B2.2, since the RepInfo should be packaged in the AIP. I agree that OAIS terminology would be better. The reason that registries are mentioned is to allow for the case where the archive does not have all the RepInfo needed, but can share RepInfo from somewhere else.
RiccardoFerrante In response to David, use of shared registries to clarify the requirement raises a concern that a repository's successful certification would be rendered void if the trustworthiness of an external resource was called into question after implementation by the repository. Would the language "access to the necessary tools and resources to establish authoritative technical context of the digital objects it contains" communicate the same intent while also allowing the repository to have some of its objects with all the RepInfo needed, and the remainder including RepInfo referencing shared resources. The explanation might recommend use of redundant shared resources to guard against one of those resources becoming proven untrustworthy in the future. I also find "semantic" to be unclear.

B2.8 (Removed)

B2.9 (Proposed Revision) Repository has documented processes for acquiring preservation metadata (i.e., PDI) for its associated Content Information and acquires preservation metadata in accordance with the documented processes.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y ? Y Y Y Y ? - Y Y Y N

Who Comment (add a row to the table for your comment)
DonaldSawyer It appears this is a detail of an approach to satisfying part of B 2.2.
DavidGiaretta AGree with DOn - but also note that having a documented process is does not mean that the process is carried out, so perhaps this needs re-wording
MarieWaltz I'm not sure why this needs revision, or why B2.8 was deleted

B2.10 Repository has a documented process for testing understandability of the information content and bringing the information content up to the agreed level of understandability.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y Y - N Y ? ? - ? ? ? Y

Who Comment (add a row to the table for your comment)
CFen 'Understandability' needs to be defined
HTib Understandability needs to be defined and also the notion of whether the repository needs to update this information overtime. As we move further from the time of digital object creation what is needed to "understand" changes.
KatiaThomaz There is already a proposition for "understandability" in the glossary.
MCon It is unclear what is being required here. The bullet talks about documented processes for testing understandability, I am not sure what the the explanatory text is talking about, and the evidence is talking about means for carrying out testing.
JohnGarrett This checklist item talks about having a defined process. The evidence seems to be proof that a particular implementation of a process is being done. We often have need to define a process and then need to show process was followed. Sometimes both are in one checklist item as in B2.9. Other times the two are in two separate items as in B2.2 and B2.11. We should be more consistent. Also, if information is often used, tests of understandability may not be required.
DavidGiaretta This metric omits mention of the Designated Community, without which the term "understandability" becomes too vague
RiccardoFerrante I agree that a reference to Designated Communities is needed.
MarieWaltz I do think this criteria could benefit from "designated community" being added into the main text.
SLam I presume the "bringing the information content up to the agreed level of understandability" refers to a one-time operation on ingest (as we are in B2). There should be a corresponding requirement for ongoing updates.

B2.11 Repository verifies each AIP for completeness and correctness at the point it is generated.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y - Y Y Y Y Y Y Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
RobertDowns This should allow a repository to create an AIP in stages, and in such cases, verify the completion of each part of the AIP at the end of each stage.

B2.12 Repository provides an independent mechanism for audit of the integrity of the repository collection/content.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - ? N - N ? ? ? - ? ? N Y

Who Comment (add a row to the table for your comment)
HTib The text here seems to have many sub-requirements and the example given does not clarify the term, "integrity."
RobertDowns I agree, the text needs to be improved for clarification.
MCon I believe this should be a mandatory requirement, but the text is not clear and at the same time seems to imply particular implementation methods for meeting this requirement.
DonaldSawyer B2.4 seems to imply the use of a SIP registry. Not sure what else B2.12 adds that is not already implied elsewhere, unless it is to compare results with agreements made with the Producer.
MarieWaltz This criteria is really about having a complete history for the content in the repository. That is, the history behind the content that is stored in the repository. A SIP registry shows you what you have, but not what you never had because it did not exist. Most often with a collection of material, a date range may have been skipped for a holiday, or a volume of a journal was incorrectly numbered and so the material never existed. For future researchers and auditors, this information is really useful so they know not only what is not in the repository, but that it never existed so they don't have to go look for it. It also ensures the auditor knows that material was not lost by the repository.

B2.13 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (AIP creation).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y Y Y Y Y ? Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon It is not clear what types of actions and administrative processes are to be documented. The text refers to PREMIS. The evidence section specifically mentions preservation metadata, but neither the text or the evidence section make it clear what other types of data need to be recorded to satisfy this requirement. Can someone explain what the original intent of this requirement was?
JohnGarrett Archives need to record what they are doing to information through entire life-cycle. AIP creation processing is only one part where contemporaneous records are required.

B3. Preservation planning

B3.1 Repository has documented preservation strategies.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? Y Y - Y ? Y ? Y - ? ? N Y

Who Comment (add a row to the table for your comment)
MCon The text for this requirement seems to actually encompass several different requirements. B3.2 further defines one of these requirements, but the others (e.g., media degradation, hardware obsolescence, etc) are only mentioned here. Should these be spelled out as individual requirements? If not, should B3.2 be incorporated into B3.1?
BarbaraSierman Agree with Mark; an institution that prepares itself for the audit does not get enough specified information from the Evidence explanation, the requirement is too broadly phrased
DavidGiaretta The wording is very broad but the intent is surely mandatory - the repository surely must have preservation strategies which are documented otherwise how can an audit be performed. It may be that this is a high level metric in some hierarchy
RiccardoFerrante Addressed more fully in B4.1.
JohnGarrett I agree with the intent, but this item is so broad it can't be checked. This should probably be broken down into several different types of individual preservation policies.

B3.2 Repository has mechanisms in place for monitoring and notification when Representation Information (including formats) approaches obsolescence or is no longer viable.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y - Y - Y Y Y Y ? - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon Shouldn't the evidence section include written policies and procedures for these monitoring activities?

B3.3 Repository has mechanisms to change its preservation plans as a result of its monitoring activities.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y - - ? Y Y ? - Y Y - Y

Who Comment (add a row to the table for your comment)
HTib The text says, "The repository should be able to show that it can revise long-range plans in light of changing circumstances." While a repository may have long-range plans for organizational sustainability (let's hope so), are "long-range" plans, beyond the notion of constant technology watch, etc. appropriate for the technical side of preservation? Surely we want repositories to be learning organizations so that they carry materials forward in the best way possible, but can there be a long-range technology implementation plan?
MCon I believe there is a typo in the evidence section. Should "formal" be "format"?
JohnGarrett I agree in principle with this item. I find text a bit confusing and evidence statement that frequent changes in policy is good evidence for this is disturbing. Frequent changes in policy would make me question the abilities of the archives rather than encourage me to trust it. Evidence for me would be that the document policies would also document how changes could be made to those policies in a considered and controlled manner.

B3.4 Repository can provide evidence of the effectiveness of its preservation activities.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y - Y ? Y ? ? - ? Y - Y

Who Comment (add a row to the table for your comment)
CFen Evidence of effectiveness cannot be supplied until after the event.
HTib Repository should keep detailed and accurate evidence about past success rates with preservation through in-house audits of samplings of data, etc.
MCon The text is not very clear - especially the second paragraph. The requirement refers to providing evidence, but the second paragraph of the text talks about an auditor testing the usability of digital objects in the repository. Is the requirement for the repository to maintain evidence or is it to define a testing requirement for the auditor? In the evidence section what is meant by "appropriate" preservation metadata?
DavidGiaretta Surely this is the real test - i.e. "prove you have preserved something". Clearly a new archive cannot do this but one would not expect a new archive to be certifiable without any track record.
JohnGarrett This item also seems too broad to me. It seems to me to almost ask the same question as "can we certify this archives?", which is the overall question we are asking in this document.
SLam Might fit better in B4?

B4. Archival storage & preservation/maintenance of AIPs

B4.1 Repository employs documented preservation strategies.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y - Y - Y ? Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon I am not sure I understand the distinction being made between these requirements and the requirements under B.3. The text for this particular requirement seems like it would be more appropriate under B.3.
DavidGiaretta Overlap with B3.1

B4.2 Repository implements/responds to strategies for archival object (i.e., AIP) storage and migration.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - Y - - - Y Y Y - Y Y ? Y

Who Comment (add a row to the table for your comment)
MCon I believe this requirement should be split out into 2 or more requirements for clarity/simplicity.
DavidGiaretta Perhaps should be a sub-metric to B4.1 in a hierarchy
RiccardoFerrante I suggest this be a submetric to B4.1 and migration clarified

B4.3 Repository preserves the Content Information of archival objects (i.e., AIPs).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? Y Y - Y - Y ? Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon It is not clear what is meant by the phrases, "the AIPs faithfully reflect what was captured during ingest" and "will continue to preserve that aspect of the repository’s holdings."
BarbaraSierman As human errors may occur, is it wise to state that "AIPs cannot be deleted at any time"? Or should a phrase like "without qualified procedures" be added?
DavidGiaretta The metric is clearly mandatory but the supporting text needs review

B4.4 Repository actively monitors integrity of archival objects (i.e., AIPs).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y - Y - Y - Y ? Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
HTib Katia made lots of good comments in the working text of this item but it doesn't look like we incorporated these. Discussion?
MCon Helen, There has been a great deal of discussion of Katia's comments. See the minutes of previous web meetings. That discussion led to the efforts to define authenticity. Integrity and authenticity are different concepts. I believe the consensus was that authenticity was not appropriate for inclusion in this requirement.
MCon The text seems to list at least five separate requirements -
1.must have Fixity Information for ALL? AIPs
2.must make "some use" of the fixity information
3.must keep or protect the fixity information separately from the AIPs
4.must ensure that the repository has all of the AIPs it is supposed to have
5.must ensure that the repository does not have AIPs it should not have.
I would say that 3-5 should be mandatory. 1 should be mandatory if it is revised to make it clear that the repository must have fixity information for ALL AIPs it holds. 2. is meaningless as a mandatory requirement.
The evidence section does not include evidence for 4 or 5.

B4.5 Repository has contemporaneous records of actions and administration processes that are relevant to preservation (Archival Storage).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y - Y - Y ? Y - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon t is not clear what types of actions and administrative processes are to be documented. The text refers to PREMIS. The evidence section specifically mentions preservation metadata, but neither the text or the evidence section make it clear what other types of data need to be recorded to satisfy this requirement. Can someone explain what the original intent of this requirement was?

B5. Information management

B5.1 Repository articulates minimum metadata requirements to enable the designated community to discover and identify material of interest.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y ? - Y - Y Y ? - Y ? ? Y

Who Comment (add a row to the table for your comment)
MCon The evidence section refers to "descriptive metadata" while the requirement bullet refers to "metadata". The bullet or the evidence section should be modified to make the requirement internally consistent.
DavidGiaretta Agree with point about "metadata". Also the phrase "articulates minimum..." seems odd.
RiccardoFerrante B5.1 might be better placed as a submetric under B5.2.

B5.2 Repository captures or creates minimum descriptive metadata and ensures that it is associated with the archived object (i.e., AIP).

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y - Y - Y Y ? - Y Y Y Y

Who Comment (add a row to the table for your comment)
DavidGiaretta B5.1 and B5,1 go together - B5.2 says archive captures or creates descriptive information and B5.1 should say the descriptive information is available to the DC. Note that OAIS terminology would be better i.e. not "metadata"

B5.3 Repository can demonstrate that referential integrity is created between all archived objects (i.e., AIPs) and associated descriptive information.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - ? - Y - Y Y ? - Y - Y Y

Who Comment (add a row to the table for your comment)
DavidGiaretta ? because presumably the Descriptive Info can be re-created from the SIP/AIP
BarbaraSierman David, that would assume that all Descriptive Info (I deliberately say here all) is in the AIP. Descriptive info might be enriched in a separate system without adding this info in the AIP. May be it should say the Descriptive Info the producer sent
HelenTibbo The repository may supply or supplement or edit descriptive information but there should be referential integrity between the objects and all all their descriptive information, whether that originated with the producer or the repository or both.

B5.4 Repository can demonstrate that referential integrity is maintained between all archived objects (i.e., AIPs) and associated descriptive information.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - ? - Y - Y Y ? - ? - - Y

Who Comment (add a row to the table for your comment)
MCon There is a need for at least one additional requirement concerning the referential integrity between an AIC and its associated AIPs.

B6. Access management

B6.1 Repository documents and communicates to its designated community what access and delivery options are available.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- Y Y Y - Y - Y Y ? - Y Y Y Y

Who Comment (add a row to the table for your comment)

B6.2 Repository has implemented a policy for recording all access actions (includes requests, orders etc.) that meet the requirements of the repository and information producers/depositors.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - N - N - ? N N - ? N N Y

Who Comment (add a row to the table for your comment)
MCon The only thing that this requirement requires is that the repository has a policy, but there are no minimum standards for that policy. Making this requirement mandatory is logically meaningless.
DavidGiaretta This is more a performance issue than one of preservation
HelenTibbo In fact, in light of laws such as the US Patriot Act, it may be better for repositories not to keep such records. For example, many US libraries only keep check out records until the books are returned, thus they cannot fill governmental requests that might constitute an invasion of privacy as the records are erased. This doesn't, however, serve to build user profiles, etc. for selected dissemination of information services and the like. This makes the statement as written appropriate and indeed it may be important for the repository to have evidence of such a policy, esp. when it is not keeping access transaction data. This is not, however, mandatory for preservation.

B6.3 Repository ensures that agreements applicable to access conditions are adhered to.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- ? - ? - Y - ? ? ? - ? - - Y

Who Comment (add a row to the table for your comment)
MCon The text for this requirement lists at least two requirements -
1. The repository must be able to show what producer/depositor agreements apply to which AIPs
2. must validate user identities in order to ensure that the agreements are satisfied.
If the repository is also the records creator and the repository has an open access policy neither 1 or 2 would be mandatory.
DavidGiaretta I guess this may come down to whether preserving but giving possibly illegal access is still preservation?
HelenTibbo If no records are kept (B6.2) then it would be hard to prove if the repository is or is not giving illegal access although some mechanism wherein the user is validated should be able to show the process if not the outcome of such transactions or rejection of transactions. Isn't this fundamental to IRP agreements and can't this be accomplished while maintaining privacy?

B6.4 Repository has documented and implemented access policies (authorization rules, authentication requirements) consistent with deposit agreements for stored objects.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - ? - - - Y ? ? - ? ? - Y

Who Comment (add a row to the table for your comment)
MCon The text is very confusing. It begins by talking about possible implementation scenarios for access controls, then states that these may not be necessary for all repositories, goes on to say that, "access and delivery policies are reflected in practice and that the level of validation is appropriate to the risks of getting validation wrong. Some of the requirements may emerge from agreements with producers/depositors and some from legal requirements." and finally talks about a totally separate requirement to protect the data from inadvertent or intentional harm by staff.

B6.5 Repository access management system fully implements access policy.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - ? - - - Y Y Y - Y - - Y

Who Comment (add a row to the table for your comment)

B6.6 Repository logs all access management failures, and staff review inappropriate “access denial” incidents.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - N - - - Y ? N - ? N N Y

Who Comment (add a row to the table for your comment)
MCon There appear to be several different requirements here. I am not sure what is meant by "access management failures." It is not clear how one would determine what constitutes an "inappropriate" access denial. The text says,"This requirement does not apply to repositories with unrestricted access." I would think that access denials in a repository with unrestricted access would constitute inappropriate access denials.

B6.7 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is completed in relation to the request.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - ? - - - Y ? ? - ? - - Y

Who Comment (add a row to the table for your comment)
MCon It is unclear what is being required here vs under B6.8. Much of the text under B6.7 seems to have to do with whether or not the DIP was generated correctly which would seem to me to fall under B6.8.
DavidGiaretta Unclear what this means e.g. all DIPs and how complete?

B6.8 Repository can demonstrate that the process that generates the requested digital object(s) (i.e., DIP) is correct in relation to the request.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - Y - - - Y ? ? - Y Y Y Y

Who Comment (add a row to the table for your comment)
MCon I have trouble with the phrase, "the conversion should be shown to be correct to whatever standards seem appropriate." Shouldn't the standards be spelled out in the agreements between the repository and its users?
DavidGiaretta The wording of course needs work but the fundamental idea is tha one can trust what the Consumer actually gets - otherwise what is the point of preservation?

B6.9 Repository demonstrates that all access requests result in a response of acceptance or rejection.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - - N - - - ? ? N - ? N N Y

Who Comment (add a row to the table for your comment)
MCon It is unclear what is being required here. The bullet talks about a response of acceptance or rejection of a request while the text talks about whether or not the request succeeded or failed. It is unclear what the measurements are for success or failure, but the text suggests that all failed requests should result in an entry in an error log.
DavidGiaretta THis is a performance issue rather than preservation

B6.10 Repository enables the dissemination of authentic copies of the original or objects traceable to originals.

Mandatory requirement?

BAmb BSie CFen DGia DSaw HTib JGar KTho MCon NMcG PInn RDow SLam RFer MWal
- - Y Y - Y - Y ? ? - ? - N Y

Who Comment (add a row to the table for your comment)
MCon I have a number of problems with the text for this requirement. Listed below are some of them.
1. In many cases a perfected transcript would still not be considered an authentic copy of an audio stream. Too many of the essential characteristics of the original (e.g, voice inflection) are lost.
2. The last paragraph talks about authentication as opposed to authenticity. These are two very different concepts.
3. "This requirement is meant to enable high levels of authentication, not to impose it on all copies, since it may be an expensive process." Clearly the intent is not for this requirement to be mandatory for all copies.
DavidGiaretta This seems a fairly fundamental metric. I also assume that a copy does not include a transcription as in the comment above - so we should perhaps be more explicit about "digital copy"

-- SimonLambert - 23 Dec 2007

Edit | Attach | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | More topic actions
Topic revision: r7 - 21 Jan 2008 - HelenTibbo
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2012 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback