Appendix 1: Glossary XXXXXX

Many of these terms are taken from the glossary of OAIS (2002). Archival Information Package (AIP): An Information Package, consisting of the Content Information and the associated Preservation Description Information (PDI), that is preserved within an OAIS.

  • Backup: The periodic capture of information to guard against system or component failure or against accidental or deliberate corruption of the system or system metadata. It is separate from the actions that most repositories will take of holding multiple copies of AIPs. Backups should ensure that lost or corrupted metadata can be restored, or that a failed system can be rebuilt and reintegrated into the repository with minimum loss of information. Backups are not expected to prevent all information loss. They are intended to restore a system or a component to a known state in a manner consistent with other system components, where this is applicable.
  • Content Information: The set of information that is the original target of preservation. It is composed of the digital object and its Representation Information.
  • Copies: Different logical or physical instances of the same object. Usually this will mean bit-wise identical copies stored on different file systems, on different media, and/or in different locations. Most, but not all, repositories will have more than one copy of each AIP to guard against media failure or system failure. Some may choose to protect against certain software failures by using two different mechanisms to store the same object—for example, by using both a TAR and a ZIP file containing the same collection of files. In this case, the bitstreams are different because the encapsulation format is different, but there is no question that they represent the same digital object. “Copies” can also be taken to refer to different forms of the same entity that a repository may choose to hold for operational reasons. One trivial example might be the storage of TIFF and JPEG versions of an image to speed the production of DIPs in JPEG format. Here one form is clearly derived from the other, but it is important that changes in one form are propagated to the other in a predictable way.
  • Descriptive Information: The set of information, consisting primarily of Package Descriptions, that is provided to Data Management to support the finding, ordering, and retrieval of OAIS information holdings by users. Designated community: An identified group of potential Consumers who should be able to understand a particular set of information. The designated community may be composed of multiple user communities.
Digital repository / Digital archive: These two terms are often used interchangeably. OAIS uses archive when referring to an organization that intends to preserve information for access and use by a designated community(ies). Trusted Digital Repositories: Attributes and Responsibilities prefers the term digital repository. Digital archives and digital repositories should not be confused with either digital libraries, which collect and provide access to digital information, but may not commit to its long-term preservation, or data archives, which do commit to long-term preservation but limit their collections to statistical datasets.
  • Disaster: Any event that threatens or interrupts the operation of the repository and that, without corrective action, threatens the long-term preservation of its holdings. Disasters can include things that threaten the physical environment such as fire, flood, and explosion. They can also include the loss of facilities such as protracted network outages or the inability to gain access to a building for prolonged periods due to severe weather or other contingencies.
Dissemination Information Package (DIP): The Information Package, derived from one or more AIPs, received by the Consumer in response to a request to the OAIS.
  • Open Archival Information System (OAIS) Reference Model: Developed by the Consultative Committee on Space Data, a conceptual framework and reference tool for defining a digital repository. It provides a model of the environment, functions, and data types for implementing a digital repository. The OAIS is an official ISO standard (14721).
  • Preservation Description Information (PDI): The information that is necessary for adequate preservation of the Content Information; it can be categorized as Provenance, Reference, Fixity, and Context Information.
  • Representation Information: The information that maps a Data Object into more meaningful concepts. An example is the ASCII definition that describes how a sequence of bits (i.e., a Data Object) is mapped into a symbol.
Submission Information Package (SIP): An Information Package that is delivered by the Producer to the OAIS for use in the construction of one or more AIPs.
  • Users: Consumers of archived digital objects. Some digital repositories have human end users and will need to have auditable documentation and access mechanisms to support their needs. For other repositories, “users” may be restricted simply to other machines, and the repository will have associated requirements only to meet those needs.
  • Versions of an object: A relationship between objects. Some objects can be considered later or alternative forms of other objects, such as the director’s cut of the originally released version of a film compared, or different editions of the same book, or draft and final versions of a given document. A repository will usually choose to identify, through descriptive metadata, this type of relationship, but the relationship does not impinge on the preservation requirements of each object. This phrase will not apply to all repositories; it appears here to avoid possible confusion, as section C does not stipulate how versions of an object are handled.

Appendix 2: Understandability & Use

OAIS states that the “Repository must ensure that the information to be preserved is independently understandable to the Designated Community.” In other words, the community should be able to understand and use the information without needing the assistance of the experts who produced the information. A repository and a producer must communicate and commit to a shared definition of “understandable” in the context of the repository. The definition may lie somewhere between “reproduce the bitstream as deposited,” in the case where the bitstream by itself is always usable by the designated community, and ensure the Information Content is rendered or performed, intelligible, and usable to the Designated Community given, at whatever time, its knowledge base, tools, and practices.

As a part of the process of submitting material to a digital repository, the repository must address the issue of the submission’s information content and the extent to which this content is understandable to its designated community. The repository’s responsibility should be defined in its charter, and it may be further elucidated in the submission agreement negotiated between the repository and the producer. The extent of this responsibility can vary widely. If the repository is only tasked to preserve bits, not information content, for a submission, then this responsibility is not relevant. More complex cases requiring information preservation can be viewed from two extremes. When a repository has minimal responsibility, the repository may be assured by the producer that the information submitted is understandable to the designated community. The repository must have a clear definition of the designated community that includes the extent to which the repository needs to ensure the information content can be used by the community’s application tools. For example, if a designated community is defined as readers of English with access to widely available document rendering tools, the repository must ensure that the submitted information meets these criteria at the time of submission and that the corresponding information it delivers continues to do so (see B3 on preservation activities).

When a repository takes maximum responsibility, the repository cannot rely solely on the producer’s planned submission and must take additional steps to ensure that the information it receives for preservation can be understood by the designated community and is sufficiently usable. Again, the definition of the designated community should include the extent to which the repository needs to ensure the information content can be used by the community’s application tools. The steps taken may include consulting with outside sources to evaluate the degree to which the information is understandable, and efforts by the repository to gather the additional Representation Information needed. This enables the repository to perform information preservation as well as bit preservation, and to do so long after the original producers of the information are no longer available. The two major categories of information that must be understandable to the designated community are the Content Information and Preservation Description Information (PDI). This discussion addresses only the Content Information, but it applies to the PDI too as that will have its own Representation Information.

Once the Primary Digital Object, its Representation Information (i.e., Content Information), and a definition of “understandable” have been determined, it is possible to ask whether what the repository disseminates is understandable to the designated community. In other words, it must be possible to apply the Representation Information to the Primary Digital Object and have the result be understandable to typical members of the designated community. This application process could take place within the repository, with only the result disseminated to the designated community in some new encoding with appropriate Representation Information, or it could be left for the designated community to accomplish. If the process takes place within the repository, the repository must maintain its ability to perform it. If it is left to the designated community, the repository must also maintain the Representation Information so that it is “understandable” to the designated community, and it will need to periodically verify that most of the designated community can still perform the process, or the designated community must formally commit to this responsibility.

For example, the repository may maintain software that uses, or even partially or fully embodies, the Representation Information to render the Primary Digital Object in an informative visual or auditory manner for human consumption. Alternatively, the repository’s software may present all the information through an interface acceptable to designated community applications. Or the repository may provide the Primary Digital Object and Representation Information, including their relationships, directly to the designated community with the understanding that the designated community(ies) can apply the Representation Information to the Primary Digital Object to obtain understandable information. Scientific datasets often fall into this last category. In short, the repository must maintain whatever is agreed to constitute the Content Information and its understandability requirements for the designated community. For certification, it is important for the repository to make clear its criteria for determining the Content Information and for determining the understandability requirements of its designated community so that a third party can evaluate them in specific cases and with respect to the repository’s charter.

Some examples can clarify the relationships among Representation Information, the needs of the designated community, and the repository service that makes the information available to the designated community:

2. Digital object type: Microsoft Word version 3 binary file from a government agency.

  • Representation Information: Identifier of the format being “Word v3” and being proprietary.
  • Content Information: Information from a government agency in a Word document.
  • Designated community: General public with access to widely available document rendering tools.
  • Definition of “understandable”: The Content Information is in a format currently renderable with widely available document rendering tools.
  • Repository access service: Provides a binary file in a format currently renderable with widely available document rendering tools along with a unique identifier of the format type and the PDI. Upon request, may send the original binary file with its unique Representation Information identifier, assuming these are different. Note that for this proprietary format, the full Representation Information may only be available in the form of “embedded within the rendering software.”

3. Digital object type: Binary file produced by the PDF application.

  • Representation Information: Identifier of PDF-A format, described in a registry.
  • Content Information: Document describing a medical procedure.
  • Designated community: English readers having a knowledge base typical of second-year medical students.
  • Definition of “understandable”: Visually rendered exactly like visual rendering of original submission.
  • Repository access service: Makes available the binary file, PDI, and PDF-A rendering application.

4. Digital object type: Binary file containing observations from an instrument on a satellite.

  • Representation Information: Binary file format definition and the definition of the meaning of the fields in the format (including detailed sensor characteristics of the satellite instrument), all given in an EAST (a formal syntax language) description with associated Data Dictionary.
  • Content Information: Data from an instrument on a satellite.
  • Designated community: English readers having a third-year graduate school education in the associated scientific discipline.
  • Definition of “understandable”: Original binary file is accompanied with sufficient Representation Information to allow a member of the designated community to understand how to access all the fields in the binary file, to understand what each field means, and to understand the relationships among the fields, and, using the PDI, to understand the context in which the field values were obtained.
  • Repository access service: Provides the binary file, the Data Dictionary, EAST description, PDI information, and an identifier referring to the standards document that is the definition of EAST description language.

5. Digital object type: Software source code to perform simple function “A.”

  • Representation Information: Identification of the language the code is written in, and a pointer to a definition of that language. If available, a natural language description of what function ”A” does. Also, a description of the inputs and the expected outputs, all understandable to the designated community.
  • Content Information: Understandable and usable software source code.
  • Designated community: Software developers who may have an interest in code for functions like “A.”
  • Definition of “understandable”: Fully documented source code is delivered with references (pointers) to primary technology dependencies such as language definition, system call, operating systems dependencies, build system, software environment requirements, relevant data standards, etc. All text is delivered in a currently usable character set. Information is sufficient to allow a member of the designated community to either compile and use the code correctly or to successfully transform the function to another language.
  • Repository Access Service: Provides the software source code, Representation Information, and PDI upon request.

6. Digital object type: Software executable code.

  • Representation Information: Identification of the platform environment in which the software can run, possibly including pointers to full descriptions of that environment and perhaps to an emulation of that environment. Hopefully, a natural-language description of what function the code performs. Also, a description of the inputs and expected outputs, all understandable to the designated community.
  • Content Information: Usable software executable.
  • Designated community: Software developers who may have an interest in code performing such functions.
  • Definition of “understandable”: Binary object, executable in the environment specified in the Representation Information, with Representation Information and PDI that may be read and understood by members of the designated community.
  • Repository Access Service: Provides the software executable code, Representation Information, and PDI upon request.

7. Digital Object Type: Musical score in a nonproprietary binary format.

  • Representation Information: Description of the format in PDF-A, with a pointer to the PDF-A description in a different registry/repository.
  • Content Information: Musical score for a synthesizer.
  • Designated community: German readers who wish to generate music using a computer and synthesizer from a digital representation of the score.
  • Definition of “understandable”: Binary bitstream reproduced as delivered, Representation Information and PDI delivered in German.
  • Repository access service: Provides the binary file, Representation Information, and PDI upon request.

Appendix 3: Minimum Required Documents XXXXXX

Requirements throughout this checklist refer to documents (policies, procedures, plans, etc.) that a repository should keep current. This list identifies the documents that are stipulated by one or more requirements, so a certified repository should have and keep under review at least these documents. Some repositories will provide evidence of their compliance to certain requirements using documents that do not appear on this list. Review cycles will vary by institution. Repositories should be prepared to demonstrate that their review cycles are appropriate to their activities and requirements.


Appendix 4: A Perspective on Ingest

“Ingest” is a generic term used by OAIS to describe the processes that take place from the receipt of the digital objects through the final, preserved form of that object in the repository. The object or objects that arrive at the repository are termed Submission Information Packages, or SIPs. By a set of processes that will inevitably be highly repository-specific, one or more SIPs are transformed into preservable digital entities called Archival Information Packages or AIPs. For some repositories there will be a one-to-one relationship between a SIP and an AIP (that is, one SIP results in the creation of one AIP) but for others the relationship will be more complex.

For instance, if a repository receives the contents of a database without the schema that allow it to be interpreted, it may choose to class that as a SIP that cannot, on its own, be preserved. If it later receives the schema, that is another SIP that, when combined with the first, allows the repository to create an AIP according to its standards. OAIS uses the terms SIP and AIP primarily as a convenient shorthand to distinguish the digital objects that are received (which are often messy and incomplete) from the things that are preserved, which will generally have some structure. There is no standard format for a SIP, although individual repositories may well have such standards. Similarly, there is no standard format for an AIP, although OAIS is specific about different types of information it expects to appear in an AIP.

The digital objects a repository accepts for preservation should reflect both its mission statement and its designated communities’ spheres of interest. Users should clearly understand the relationship between a repository, its mission statement, and its collections. As a part of the ingest process, the repository must gain both physical and intellectual control over the digital objects. Documentation associated with the primary digital objects of a collection must be submitted and should be just as logical. The information to be transferred with specific digital objects (primary and others) will generally be enunciated in the specific transfer agreement for those objects and should be the information and items necessary for Consumers to use the objects without resort to the Producers, to other experts, or, hopefully, to subject matter experts in the repository itself. In a general statement, it is impossible to enumerate the documentation required for each digital object being preserved by a certified repository. Complete documentation may include various types of metadata such as codes, sample forms, record layouts, codebooks, schema, explanations of the universe, minimum and maximum values, and related studies and results. The documentation is collected both to ensure completeness of the collection and to help the Consumer determine the accuracy or correctness of the data itself. That determination is normally made jointly by the Producer and the repository, with the repository acting for the Consumer.

Fundamentally, the repository is tasked to preserve information, which means digital objects together with their Representation Information. This is the primary information to be preserved and is called the Content Information in OAIS terminology. (This is also applicable to the Preservation Description Information— Provenance, Context, Fixity, and Reference.) A fundamental decision, to be taken by the repository together with the Producer, is the definition of what constitutes the information to be preserved, or Content Information.

The OAIS recommendation is to start by deciding what is the Primary Digital Object and then to address the extent of the Representation Information that needs to accompany this digital object. The extent of this Representation Information is not predefined and may vary widely from one submission to another even within a given repository.

To better identify the Representation Information needed, a repository may, depending upon its mission and goals, need to consult with the producer/depositor/rights owner and systems managers, assess the digital object and determine which of its properties are significant for preservation. Other repositories and digital archives may assess needed Representation Information using automated tools that compare the digital objects against expected and/or acceptable formats or other mechanisms that analyze the content systematically as material is deposited into the repository. To ensure long-term preservation, digital repositories need to decide what level of preservation is appropriate for each digital object or class of objects. The significant properties of a digital object (i.e., the acceptable level of functionality) dictate the underlying technical form that needs to be documented and supported to ensure preservation of those properties and the amount of metadata, including detailed technical agreed-on level.

Once the necessary Representation Information and other metadata have been submitted to the repository, it must be verified and, as necessary, enhanced to support the object’s long-term maintenance as well as continuing access. The creation and maintenance of the detailed metadata associated with the object’s significant properties are critical to the repository’s preservation function—the detailed descriptions and the technical information necessary for interpreting the bitstream as a meaningful digital object ensure current usability by the contemporaneous designated community and form the basis of long-term preservation. How continuing access is provided over time can and should be kept separate, conceptually, from this basic preservation function. Digital repositories can store a digital object and its associated metadata as a single bitstream, as multiple separate bitstreams, or as both. For practical reasons, repositories may prefer to store the digital object within the repository and provide only pointers or references to the associated metadata in other systems, such as bibliographic data stored in the library management system. Such “virtual encapsulation” avoids duplicating metadata, but separating a digital object and its metadata may present problems in the future. Some experts think long-term preservation may be best served by storing the digital content and as much as possible of its relevant metadata as a single file.

The Metadata Encoding and Transmission Standard (METS), MPEG-21 Digital Item Declaration Language (MPEG-21 DIDL), and the XFDU standard (the extensible data packaging format) are examples of potential AIP encapsulation structures. The METS standard (2005) was created by the cultural heritage community for encoding descriptive, administrative, and structural metadata. Depending on its use, a METS document could take the role of SIP, AIP, or Dissemination Information Package (DIP). The XFDU standard (2006) is similar to METS and can serve the same “packaging” functions as METS. Other communities may use different, community-generated packaging or encapsulation structures. The only requirement for packaging structures is that they are well documented and, if not openly accessible, the documentation can be produced on demand for auditors. For useful examples that demonstrate the types and extent of metadata that should be collected for various types of data objects and archival information collections, see:

  • Annex A of Consultative Committee for Space Data Systems, Reference Model for an Open Archival Information System (OAIS) (www.ccsds.org/publications/archive/650x0b1.pdf) (ISO 14721).
  • US National Archives and Records Administration Electronic and Special Media Records Services Division, Accessioning Procedures Handbook (College Park, MD, loose leaf June 2000). Cooperative efforts include:
  • The Data Documentation Initiative (www.icpsr.umich.edu/DDI/org/index.html), formally established in 2003, which is promoting an XML Document Type Definition that has been widely adopted in some disciplines.
  • The Council of European Social Science Data Archives (www.nsd.uib.no/cessda/), which promotes the preservation and exchange of data and technology and the establishment of new organizations to do the same through the use of metadata standards, common thesauri, and standardized rights management, as well as standardized cataloging of data object entries.
• The CCSDS Producer-Archive Interface Methodology Abstract Standard, 2003, (ISO Standard 20652) (www.ccsds.org/publications/archive//651x0b1.pdf), which promotes greater standardization and formalization of the pre-ingest and ingest relationships between the producers and the repositories.

Appendix 5: Preservation Planning & Strategies

A trusted digital repository must have documented preservation strategies. However, a trusted digital repository cannot simply say what it will do; it must demonstrate its policies, practices, and procedures. The repository must be able to demonstrate:
  1. Relevant decisions about acceptable formats: For example, standalone or portions of policies that restrict, define, or stipulate formats that may be accepted by the repository.
  2. Comprehensive automated and/or manual workflow for bringing in appropriate digital objects: For example, protocols for transfer, including roles and responsibilities of the producer and the repository; explicit evidence of conversions that occur in AIPs that are generated from SIPs; quality assurance mechanisms and measures for assuring the completeness and correctness of resulting AIPs.
  3. Anticipated and/or applied preservation actions pertaining to individual and classes of AIPs: For example, preservation plans—planned, tested, and/or applied; preservation action logs; policies that address preservation strategies.
  4. Archival storage policies, procedures, and practices that ensure effective capture, ongoing and reliable archival storage, and responsiveness to inevitable technological change. For example, storage management investment and planning documents, comprehensive security plans to enable the workflow, measures and monitoring protocols for stored AIPs.
  5. Independent means to verify expected repository content based on a secure trace of digital objects received. For example, an auditable acquisitions register, an inventory that cannot be altered. This is a key set of activities for collecting those things that make the information available and usable for future generations. The preservation strategy lays out a plan for carrying this out within an evolving environment (social/technological, etc.). The strategy must provide for:
  • A process for monitoring change that might affect preservation.
  • An understanding/expertise for interpreting the impact/implications of these changes.
  • A planned response to these changes.
  • An implementation of this response.

Potential strategies are:

  • Transform data upon ingest of the format.
  • Keep the original format and wait for others to produce a solution to the support of the software.
  • Produce a supportable emulation environment to enable the proprietary software to continue to run.

Strategies may be needed for each class (e.g., format) of digital data held by the repository.

A strategy would also be expected to have special checks on AIPs over and above those performed as part of the normal robust infrastructure. These would include packaging the various components of the AIP—Content Information, Representation Information, Preservation Description Information, Packaging Information, and Package Description—and fixity checks on access to or movement of data, e.g., checksums, digests, error correction encodings, etc., including random sampling of holdings to monitor possible degradation of media.

Updates are allowed to AIPs, e.g., to incorporate additional PDI. These must produce a new edition/version of an AIP. Other transformations may be applied to SIPs and AIPs to generate further AIP versions. For example, the repository may wish to keep a more easily preservable format for a particular type of data—making life easier for the repository and more suitable for the community. It is important that contemporaneous records (e.g., logs of processes, history, etc.) be kept of these transformations as well as at least the receipt of SIPs and creation of AIPs. It is difficult to specify the level of detail of this recording. This logging may be detail enough to allow one to regenerate one version from the next or vice versa in a reversible way. In this case, the repository would be able to generate versions of AIPs as required. Alternatively, if the logging is not sufficiently detailed for such regeneration, then each AIP version has to be kept or the deletion of intermediate versions recorded. The original AIP should never be deleted unless allowed as part of an approved strategy.

Appendix 6: Understanding Digital Repositories & Access Functionality

The range of capabilities and degree of sophistication of a repository’s access system will vary, depending on the nature of its designated community(ies) and the repository’s access mandates. Repositories that are committed to providing external access, repositories must produce Dissemination Information Packages (DIPs) that meet the needs of users or are appropriate to the specified levels of access being offered. In other cases, repositories may operate as “dark archives,” holding material safely for access by future generations; some archives (such as national archives) may have mandates that access to information be restricted for a certain number of years. In these latter cases, most DIPs produced by the repository will be for internal use (such as performing migrations). Consequently, all repositories must be able to produce a DIP, whatever its level of sophistication or intended use. Repositories may also note that certain elements of an access system may be positioned beyond the boundary of what constitutes the trusted repository system. A preservation repository may not need to be able to provide “advanced” access options. Users of a preservation system may be other machines. If a repository provides a rich, complex set of access mechanisms, it may be more straightforward to view a significant portion of the access system as external to the trusted repository; the focus of an audit would be the interface between the repository and its rich access system. This approach is only effective if the internal interface is simpler than that provided to the repository’s end users.

It is important to understand that repositories are not required to have rigid service levels to which they must always conform, although this is appropriate in some cases. Guarantees may be expressed to users in terms such as, “We will always ship your order within 48 hours, or we will inform you by e-mail if that is not possible.” If such guarantees are provided it is important that the repository can demonstrate that they are adhered to. Where repositories are unable, due to scale or demand, to provide such assurances, it is quite acceptable for them to adopt a less strictly defined approach. For instance, repositories may say that order processing will depend upon one or more stated factors, but that users can check an order’s status via the Web, e-mail, or telephone.

Universal access need not be provided in order to meet the audit checklist’s access requirements. A repository’s users (including the designated community or communities) may be a small or limited set of people, and confidentiality requirements or producer agreements may mean that different members may be entitled to access only highly restricted subsets of the repository’s holdings. It is vital that the repository is capable of demonstrating that these restrictions are applied properly.

One dimension of trust is the trust that information producers have in the repository. Where producers place requirements on the repository to permit only specific forms of access or use to specific, identified communities, they must have confidence that the repository will implement these restrictions in a suitably secure manner.

Not all repositories will have restrictions on access. Some repositories may require anyone, including even the producers, to get a court order for access to some information. This would be appropriate for highly confidential information preserved for future access, perhaps many years hence. Some repositories might not even communicate to the public the extent, content, or nature of some or all of their holdings.

All these approaches are acceptable provided the repository makes its policies clear and can demonstrate its adherence.

Repository policies should document the various aspects of access to and delivery of the preserved information. There is an additional expectation that the policies, or at least the consequences of them, should be communicated to the designated community. Among other things, the users should know what they can ask for, when, how, and whether a charge will be levied. The repository must make clear what users can and cannot do, what access is possible, and the mechanisms a repository provides to meet their reasonable needs. Typical questions that may be addressed include: Can users search a catalog via the Web? Can they visit the repository to speak to someone to help them find information?

Can they download copies instantly or must they be ordered for delivery by mail? Can they request subsets of AIPs, or multiple AIPs in a single request?

Can they choose different file formats for delivery? What types of searches can they perform?

Repository policies should clearly define access and delivery mechanisms available to its designated communities. There are no objectively compulsory request types that must be supported by every repository; instead, individual repositories must state the specific types of request that they can handle: online, batch, onsite, incidental, programmed or repeated—either by request or automatically, based on characteristics of the material. Similarly, a repository need not support any particular kind of delivery mechanism, but it must describe and communicate the types of delivery it can provide. Among other things, repositories should determine whether types of delivery are defined and announced (digital files, sent, for example, by e-mail attachment, Web, or FTP, or sent by mail on disk, tape, or in print) and whether there are limits on the types or the size of the result sets.

Where there are charges associated with using the digital objects within the repository, these should be clearly defined with respect to the repository’s designated communities within repository olicies. Not all repositories will charge; some will only charge for certain services; some may have annual subscription fees with unlimited usage and others may charge per item or even per search. In some repositories, charges will be calculated automatically by an online ordering system whereas in others the charge for delivering an item may not be known until the item is produced. The latter approach may be appropriate where substantial manual work is required to produce a DIP and the work is charged by the hour, for instance. Any and all of these policies are acceptable provided the charging mechanism and the services it applies to are made known to users. The repository should also be able to demonstrate that the charging mechanisms are applied consistently.

While some repositories will deal with a single or homogeneous user community, others will be required to work with multiple or disparate communities. Where appropriate, alternative policies should be conceived to meet the challenges posed by different communities as well as for different collection types.

-- DavidGiaretta - 20 Apr 2009

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