Thibodeau, Kenneth, et al. "Preservation as a Service for Trust (PaaST): Functional and Data Requirements for Digital Preservation – version 1.0 (InterPARES Trust, May 2017).
Existing Citations
access data (p. 37): When Access results in a change of state, data describing the results should be stored in appropriate categories. Access that involves only output of information or production of Instantiations for external clients would not change the state of any PreservationTarget. Details of what was output as a result of Access actions should be captured as AccessData. (†2487)
access service (p. 49): The Access Service manages access by all Actors to information resources and Capabilities. Thus, in the Access Service, "access" refers not just to the ability to search for and receive access to PreservationTargets and related information, but more broadly to access to participation in PreservationActions and other actions in the Preservation Environment. (†2488)
access service (p. 49): The Access Service includes three sequential sets of functions and the management of PreservationManagementData about Access. The first set of functions covers receiving requests for access to information, PreservationAction Capabilities, Information Management Capabilities or Preservation Management Capabilities. The second set determines if the requested Access is authorized and feasible. Authorization includes both conditions on access imposed on particular information resources and access rights and restrictions of individual Actors. The third comprises responding to requests.
(†2489)
actor (p. 12): Following the description of Actor in UML Use Cases, an Actor is a role played by an entity that
interacts with a Preservation Environment using any capabilities defined in the PaaST requirements.
An Actor will often be a person but could be an external system. A person acting in one or more of
the capacities defined in [PaaST], may perform actions that would qualify them as Actors, but many actions entailed by these capabilities are external to the Preservation Environment. Such
actions include defining, implementing, managing, overseeing and evaluating preservation, rather
than carrying it out. In contrast, Actor is a class in the PaaST data model and is specifically
referenced in the requirements. (†2438)
actor (p. 12): There are four predefined ways an Actor may participate in activities that implement PaaST
requirements.
· Performer: an entity actively involved in executing one or more preservation capabilities,
· Authorizer: an entity whose approval is needed for an action to be executed in specified
circumstances.
· Problem Resolver: an entity responsible for resolving a problem that occurs in preservation
activities, and
· Approver: an entity who determines if the outcome of an action, including resolution of any
problems, is acceptable.
¶ Other roles might be defined to satisfy particular circumstances, in accordance with the
AttributableClass concept described in section above. (†2440)
archival permanent feature (p. 60): The class, ArchivalPermanentFeature, is a specialization of PermanentFeature. (†2490)
area of activity (p. 60): Multiple provenance could be preserved by identifying a Document as a Record of different RecordsCreators, possibly in different AreaOfActivity, and different RecordAggregates. (†2492)
area of activity (p. 63): AreaOfActivity identifies the activity in which a RecordsCreator used a Record. It is the second essential element of provenance. (†2493)
assessment (p. 46): Preservation Management Capabilities enable assessment of whether PreservationActions have been carried out properly, whether the objects used in digital preservation are what they should be and, crucially, whether
PreservationTargets have been preserved successfully. (†2494)
assessment status (p. 27): The impacts of a PreservationChange would be determined by Preservation Assessment and, therefore, recorded in AssessmentStatus. (†2495)
association class (p. 15): An association class is a model element that has characteristics of both an association and a class. It simultaneously associates two other classes and has attributes and possibly behaviors that are characteristics of the association. Each instance of an association class links one instance of one of the associated classes to one instance of the other associated class.
(†2496)
benchmark value (p. 26): The benchmarkValue becomes the standard for judging the preservation of the PermanentFeature in all subsequent assessments and verifications. (†2497)
binary encoding (p. 15): An Instantiation is related to only one BinaryEncoding, a logical consequence of the fact that a BinaryEncoding corresponds to only one IntellectualEntity. The BinaryEncoding represents the entity; the Instantiation expresses it. But a BinaryEncoding may have more than one Instantiation because the BinaryEncoding may be used to generate successive Instantiations over time. Moreover, an IntellectualEntity may have different Instantiations.
(†2453)
binary encoding (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2463)
capability (p. 40): Most PaaST requirements are formulated with the phrase, “The service shall provide the capability to ….” The intent is to ensure that the requirements provide a sufficient and trustworthy basis for digital preservation while allowing a Preservation Director to decide which specific requirements are needed in given situation.
(†2498)
class (p. 2): [PaaST] adopts UML [Unified Modeling Language] definitions of 'class' and related terms. UML defines a class as "a set of objects that share the same specifications of features, constraints, and semantics." An object is an instance of a class. The features, constraints and semantics of an object are specified in the description of its class.
(†2424)
class (p. 50): A class is any group of objects that have at least one Feature in common. (†2512)
cloud (p. 1): Just as the Cloud is not a specific technology, or even a family or configuration of technology, the primary challenges it poses for digital preservation are not technological. Rather, the challenges stem from the loss of control over, and even knowledge of, what hardware and software are used and how they are used. Insufficient knowledge and control create a basic issue of trust: how can we trust preservation in the Cloud without adequate knowledge or control over how it is accomplished?
(†2419)
component description (p. 15): A DigitalComponent is associated with a specific BinaryEncoding by means of a ComponentDescription. A ComponentDescription describes a DigitalComponent that is necessary to instantiate the IntellectualEntity represented by a BinaryEncoding. . . . A ComponentDescription relates one BinaryEncoding to one DigitalComponent. Furthermore, the attributes of a ComponentDescription indicate how the DigitalComponent is used to instantiate the IntellectualEntity.
(†2502)
component description (p. 27): A BinaryEncoding contains a ComponentDescription for each DigitalComponent needed to instantiate the PreservationTarget it represents. (†2503)
controlling object (p. 63): ArchivalPermanentFeatures must be defined for every PreservedRecord and PreservedRecordAggregate in order to achieve archival preservation. The minimal ArchivalPermanentFeatures for every PreservedRecord are the identities of the RecordCreator and the RecordAggregate. Implementing additional ArchivalPermanentFeatures enhances the quality of archival preservation. The following ArchivalPermanentFeatures are derived from the results of earlier InterPARES projects about data that support the authenticity of Records: ArchivalPermanentFeatures that support the identification of a Record sufficiently to distinguish it from all other Records are:
· names of the persons concurring in its creation,
· date(s) and time(s) of issuing, creation and transmission,
· the matter or action in which it participated,
· the expression of its archival bond,
· documentary form,
· BinaryEncoding,
· the indication of any attachment(s),
· digital signature, and
· name of the person responsible for the business matter.
ArchivalPermanentFeatures that support the integrity of a PreservedRecord are:
· name(s) of handling persons over time,
· name of person responsible for keeping the record,
· indication of annotations,
· indication of technical changes,
· indication of presence or removal of digital signature, and
· dates/times of records management transactions.
(†2491)
digital component (p. 14): A DigitalComponent is a digital object that is used in one or more BinaryEncodings to instantiate the IntellectualEntity the encoding represents. A DigitalComponent may be a file in a storage system or a bit stream that is part of a package that contains many other bit streams, or it might be a digital object that is embedded in a larger digital object. What differentiates one DigitalComponent from another is not where it is located or how it is stored, but how it is used to instantiate an IntellectualEntity.
(†2450)
digital component (p. 14): DigitalComponent differs from all other PaaST classes in that instances of the other classes consist
only of data about the things they describe. In contrast, DigitalComponents are the primary persistent
means of maintaining IntellectualEntities over time and instantiating them when needed. A
DigitalComponent should be maintained without change for as long as it is needed to instantiate any
IntellectualEntity. (†2451)
digital component (p. 14): A DigitalComponent is a digital object that is used in one or more BinaryEncodings to instantiate the IntellectualEntity the encoding represents. A DigitalComponent may be a file in a storage system or a bit stream that is part of a package that contains many other bit streams, or it might be a digital object that is embedded in a larger digital object. What differentiates one DigitalComponent from another is not where it is located or how it is stored, but how it is used to instantiate an IntellectualEntity.
¶ DigitalComponent differs from all other PaaST classes in that instances of the other classes consist only of data about the things they describe. In contrast, DigitalComponents are the primary persistent means of maintaining IntellectualEntities over time and instantiating them when needed. A DigitalComponent should be maintained without change for as long as it is needed to instantiate any IntellectualEntity. (†2507)
document (p. 60): A single Document, or copies of the same Document, can be different Records in different contexts. (†2578)
document (p. 60): A single Document, or copies of the same Document, can be different Records in different contexts. (†2579)
feature (p. 26): If an IntellectualEntity is not a PreservationTarget, then its Features might be subject to change and, therefore, would not be deemed permanent. (†2508)
heuristic information (p. 13): An IntellectualEntity has two subclasses, PreservationTarget and HeuristicInformation. A PreservationTarget is something that is preserved. HeuristicInformation is human readable information that is important in helping people to understand and interpret correctly the information conveyed by a PreservationTarget. These two subclasses are not mutually exclusive. An information object could be both a PreservationTarget and HeuristicInformation. The distinction depends essentially not on what the object is, but on the context in which it is managed, processed or used.
(†2445)
heuristic information (p. 30): As the OAIS standard recognizes, preservation of a PreservationTarget often requires additional information, for example information about the structure and semantics of the PreservationTarget, that helps people to understand it. In PaaST, such information is classified as 26 HeuristicInformation. HeuristicInformation is information that helps people to discover, understand, evaluate or use one or more Preservation Targets. Thus, HeuristicInformation is distinguished from other IntellectualEntities not by its content or form, but by its relationship to PreservationTargets.
(†2509)
human readable intellectual entity (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2459)
human readable intellectual entity (p. 18): A HumanReadableIntellectualEntity has a RuntimeVersion, but requires a Manifestation to be accessible to humans.
(†2510)
human readable intellectual entity (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2511)
information management (p. 50): Information Management Capabilities support creating and managing PreservationManagementInformation about objects, actions, and Actors. These Capabilities include organizing, managing and reporting information and data. Information Management Capabilities support organizing information into classes and sets.
(†2513)
initial source (p. 11): Initial Source has possession of and/or control over Preservation Targets before they are sent to a Preservation Environment; has authority to decide or agree to what is to be preserved and the terms under which they will be preserved. [Note:] An Initial Source may be only indirectly involved in activities that address PaaST requirements. An Initial Source may establish an agreement with a Preservation Director for preservation of its records or other information objects it has. The Preservation Director may independently contract with one or more Preservation Service Providers to fulfill some or all of the requirements for preservation. (†2426)
initial source (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
¶·Submitters and Access Clients have secondary roles in that their rights and responsibilities could be specified in Preservation Agreements or contracts without their involvement. (†2431)
initial source (p. 11): Initial Source has possession of and/or control over Preservation Targets before they are sent to a Preservation Environment; has authority to decide or agree to what is to be preserved and the terms under which they will be preserved. [Note:] An Initial Source may be only indirectly involved in activities that address PaaST requirements. An Initial Source may establish an agreement with a Preservation Director for preservation of its records or other information objects it has. The Preservation Director may independently contract with one or more Preservation Service Providers to fulfill some or all of the requirements for preservation.
(†2514)
inspection (p. 52): Inspection capabilities enable examination of objects in the Preservation Environment. Inspection targets PreservationManagementInformation, DigitalComponents and Realizations. Inspection of PreservationManagementInformation encompasses examining not only the data it contains, but also their associations and associated objects. . . .
¶ Inspection may be accomplished using software tools, where appropriate, or by observation by a human Actor. The results are captured as PreservationManagementData and may be published in a PreservationActionReport. The Inspection requirements provide for correlating data from multiple assessments of the same scope. This could be desirable in a variety of cases. (†2515)
intellectual entity (p. 14): An IntellectualEntity has two subclasses, PreservationTarget and HeuristicInformation. A PreservationTarget is something that is preserved. HeuristicInformation is human readable information that is important in helping people to understand and interpret correctly the information conveyed by a PreservationTarget. These two subclasses are not mutually exclusive. An information object could be both a PreservationTarget and HeuristicInformation. The distinction depends essentially not on what the object is, but on the context in which it is managed, processed or used.
(†2443)
intellectual entity (p. 14): Within a Preservation Environment, an IntellectualEntity is a description of an information object. For
PreservationTargets, an IntellectualEntity also specifies what must remain unchanged. (†2446)
intellectual entity (p. 15): An Instantiation is related to only one BinaryEncoding, a logical consequence of the fact that a BinaryEncoding corresponds to only one IntellectualEntity. The BinaryEncoding represents the entity; the Instantiation expresses it. But a BinaryEncoding may have more than one Instantiation because the BinaryEncoding may be used to generate successive Instantiations over time. Moreover, an IntellectualEntity may have different Instantiations.
(†2454)
intellectual entity (p. 14): Within a Preservation Environment, an IntellectualEntity is a description of an information object. For PreservationTargets, an IntellectualEntity also specifies what must remain unchanged.
(†2520)
item (p. 20): An Item may contain other Items and a Collection may contain other Collections. . . . However, there is an asymmetric relationship in that Items may be contained in a Collection, but an Item cannot contain a Collection. The multiplicities of this aggregation relationship are that, by definition, a Collection contains several Items, but an Item might not be a member of any Collection, but it could belong to one or more Collections.
(†2521)
local preservation environment (p. 1): A Preservation Environment is the highest level set of Preservation Targets that are preserved under the same Preservation Rules, together with the technological infrastructures and tools used in their preservation. The Preservation Environment may include separate, different and independently managed hardware and software used by different Preservation Service Providers. The capabilities offered by a single provider are called the Local Preservation Environment.
(†2423)
machine readable intellectual entity (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2461)
machine readable intellectual entity (p. 17): A MachineReadableIntellectualEntity is used by a program, application, or system in a RuntimeVersion. (†2524)
managed record (p. 63): Put simply, a ManagedRecord is a subtype of Record that has been subjected to a records management regime. Through a RecordCategory, records management assigns a ManagedRecord to a RecordAggregate, an association that must be preserved with the Record.
(†2525)
management set (p. 37): The PaaST requirements enable the definition and implementation of ManagementSets, sets of objects based on management objectives. A ManagementSet is not necessarily a PreservationCollection. Rather it is a means of grouping objects for purposes such as mass execution of an action on all members of the set or application of a PreservationRule to all members. The members of a ManagementSet do not have to be instances of the same class or hierarchy of classes. ManagementSets that should be useful in most Preservation Environments include SubmissionSets, PreservationActionSets and PreservationNetworks. Optionally, a Preservation Director or Preservation Service Provider could create other ManagementSets to achieve particular management purposes.
(†2526)
management set (p. 51): A ManagementSet is a group of objects that is established to facilitate accomplishing a specific preservation management objective. The PaaST data model defines three specializations of ManagementSet: SubmissionSet, PreservationActionSet, and PreservationNetwork. A SubmissionSet is a set of objects that are transferred to a Preservation Environment together. A PreservationActionSet is a set of objects that are subject to PreservationActions. A PreservationNetwork is a set of objects that is focused on a specific PreservationTarget and that are either closely related to it or contribute to understanding or using it.
(†2527)
manifestation (p. 14): A Manifestation is the output of an IntellectualEntity in a form accessible to humans; for example, on a display device, audio speaker, or in hard copy. (†2449)
manifestation (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2460)
notice of intent to submit (p. 47): A NoticeOfIntentToSubmit enables the Preservation Service Provider to create a data model of the Submission, as described under capturing information about a Submission, prior to receipt. This model comprises critical benchmarks for determining if a received Submission is what it should be. The NoticeOfIntentToSubmit is optional and in some cases it may not even be possible.
(†2528)
permanent feature (p. 2): A PermanentFeature is an attribute or a behavior of an object that must remain unaltered for preservation to be deemed successful. (†2420)
permanent feature (p. 2): A PermanentFeature is an attribute or a behavior of an object that must remain unaltered for preservation to be deemed successful. (†2531)
permanent feature (p. 26): When a PermanentFeature exists, its value must remain unchanged. Most often the value of a PermanentFeature will be specific to an instance of a PreservationItem; however, in some cases, the value may be determined for all members of a class.
(†2532)
preservation (Abstract): The requirements reflect the finding of the first InterPARES collaboration that in the digital realm, if you wish to preserve something meant to be understood by humans, you cannot preserve the information object in the form intended for human consumption, you can only preserve the ability to reproduce it. Similarly, if you wish to preserve something that is intended to be run on a computer, you can only preserve the ability to reload it in a computer processing unit.
(†2418)
preservation action (p. 15): A PreservationAction is an action that implements one or more PaaST Requirements and either directly impacts or involves the preservation of one or more PreservationTargets. (†2455)
preservation action (p. 16): A PreservationAction impacts or involves at least one PreservationTarget. An impact is a change of state of a PreservationTarget or one or more of its parts. Actions that produce state changes include initiation, alteration, and deletion. Initiation is either creation, such as when a data file is created by migration from an earlier format, or introduction, which happens when an existing object is submitted to a Preservation Environment. A PreservationAction involves a PreservationTarget as input. (†2533)
preservation action (p. 17): A PreservationAction generates at least one piece of PreservationManagementInformation that documents that the action was taken and describes the result. In addition, if any problem occurs in carrying out a PreservationAction, data about the problem and what is done to address it should be captured. If a PreservationAction results in a new or altered PreservationTarget, data describing the result would also be produced.
(†2534)
preservation action data (p. 34): PreservationActionData is data describing a PreservationAction, the Parties and PreservationTargets involved and the results or outcomes of the action, including any problems encountered and their resolution. PreservationActionData should be created every time a PreservationAction is executed, regardless of whether it completes successfully.
(†2535)
preservation action data (p. 36): The subcategories of PreservationActionData are SubmissionProcessingData, PreservationStorageData, PreservationChangeData, PreservationAssessmentData, VerificationData and AccessData. There is also a subclass, ProblemHistoryData, that identifies any problems encountered in Preservation Action and the responses to problems.
(†2536)
preservation action set (p. 38): A PreservationActionSet is a set of PreservationTargets established to facilitate executing a PreservationAction, or Actions collectively on all members of the set. The criteria used to define PreservationActionSet depend on the particular management objective to be served. A PreservationActionSet may be defined solely on the basis of one or more common Features of PreservationTargets, without specifying the Preservation Action.
(†2537)
preservation agreement (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
(†2432)
preservation agreement (p. 34): A document representing an agreement between an Initial Source and a Preservation Director to preserve certain Preservation Targets, often specifying terms and conditions applicable to their preservation. (†2539)
Preservation as a Service for Trust (PaaST) (p. 2): The PaaST requirements constitute a supplement to the Open Archival Information System (OAIS) Reference Model. OAIS is a conceptual framework for digital preservation that describes, in a technologically neutral manner, the activities and the information that are necessary for preservation. Effectively, it has defined the universe of discourse for digital preservation in a variety of contexts around the world. As a reference model, OAIS neither specifies a design or an implementation nor prescribes or even recommends any specific technology for preservation. The standard recognizes that implementations might organize functionality differently. PaaST requirements supplement OAIS in that they are intended to be directly implementable in software. Nonetheless, like OAIS, PaaST does not specify what technology should be used. Rather, it defines what the technology must be able to do.
(†2421)
preservation assessment (p. 52): A Preservation Assessment involves one or more Preservation Actions that assesses the actual status of one or more instances of PreservationManagementInformation, DigitalComponent, Realization, or compares related PreservationManagementData, or compares PreservationManagementData with the DigitalComponent, Realization they describe. Preservation Assessment is carried out by means of Inspection of Preservation Objects and/or Evaluation of PreservationManagementData.
(†2538)
preservation change (p. 48): A Preservation Change may be necessitated by the obsolescence of one or more DigitalComponents in a BinaryEncoding. Preservation Change might also be effected in accordance with a policy that requires standardizing formats for certain classes of objects. A Preservation Change process might also be executed to respond to a request by an external Access Client for a copy of a DigitalComponent in a special format; however, this process might be limited to delivering the requested copy without creating a new Binary Encoding that is maintained in the Preservation Environment. A Preservation Change may involve modifying or replacing any or all DigitalComponents in a BinaryEncoding, including ContentObjects, SoftwareObjects, and InstantiationObjects.
(†2540)
preservation change service (p. 49): The Preservation Change Service includes Capabilities for both creating new BinaryEncodings and for capturing PreservationManagementData about them. These data are essential for PreservationManagement. (†2541)
preservation collection (p. 29): One PermanentFeature that is common to all PreservationCollections is the criterion or set of criteria that determine membership in the aggregate. That Feature can be used to determine both whether a PreservationCollection is complete and whether it includes IntellectualEntities that do not belong. A PreservationCollection could have other Permanent Features. If the Producer of a PreservationCollection imposed any order on the members, that would be a PermanentFeature of the aggregate.
(†2542)
preservation commitment (p. 46): The process of preservation starts with a decision to preserve one or more IntellectualEntities, which
are thus qualified as PreservationTargets. This decision is called a Preservation Commitment. A Preservation Commitment is an agreement, obligation or intention to preserve one or more PreservationTargets. There are three basic types of Preservation Commitment: Preservation Agreement . . . , Preservation Obligation . . . , Preservation Intention . . . . (†2543)
preservation director (p. 11): Preservation Director directs the preservation of digital materials. . . . A Preservation Director decides which PaaST requirements are implemented in any Preservation Environment. This flexibility enables different approaches to fulfilling requirements, for example by performing some PreservationActions in-house while contracting with one or more Preservation Service Providers for other capabilities. (†2428)
preservation director (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
¶·Submitters and Access Clients have secondary roles in that their rights and responsibilities could be specified in Preservation Agreements or contracts without their involvement. (†2433)
preservation director (p. 2): PaaST assumes that the needs, interests, and capabilities of the Designated Community are addressed in plans, policies and procedures of the Preservation Director and that, to the extent these need to be addressed in preservation, they are expressed and implemented as PreservationRules that derive from stipulations in Preservation Services Contracts.
(†2546)
preservation director (p. 3): The Preservation Director has the option of deciding which requirements are implemented in any Preservation Environment. (†2547)
preservation environment (p. 1): Rather than speak of a preservation system, PaaST uses the concept of a Preservation Environment. A Preservation Environment is the highest level set of Preservation Targets that are preserved under the same Preservation Rules, together with the technological infrastructures and tools used in their preservation. The Preservation Environment may include separate, different and independently managed hardware and software used by different Preservation Service Providers. The capabilities offered by a single provider are called the Local Preservation Environment.
(†2422)
preservation environment (p. 17): Any Preservation Environment will have many Preservation Rules and different Preservation Environments may have different rules. (†2548)
preservation environment (p. 2): A Preservation Environment is the highest level set of Preservation Targets that are preserved under the same Preservation Rules, together with the technological infrastructures and tools used in their preservation.
(†2561)
preservation intention (p. 46): Preservation Intention: a Preservation Commitment unilaterally articulated by an Initial Source to preserve one or more PreservationTargets. A Preservation Intention may or may not identify the Preservation Director responsible for deciding how preservation is carried out or the Preservation Service Provider responsible for carrying out preservation.
(†2549)
preservation management data (p. 17): PreservationManagementDocument and PreservationManagementData are differentiated according
to their users, humans and computers, not their contents. The two specializations will extensively
have the same content. (†2550)
preservation management data (p. 30): HeuristicInformation may exist in free standing documents or it may be stored as PreservationManagementData extracted from documents or generated from PreservationActions. Such structured data, in turn, may be output in reports from PreservationManagementData.
(†2551)
preservation management data (p. 34): PreservationManagementData is an abstract class with four specializations:
PreservationActionData,
PreservationTargetData,
PreservationRule,
[and] Actor (†2552)
preservation management data (p. 53): Comparing PreservationManagementData to DigitalComponents and Realizations tests whether the data accurately and adequately describes a DigitalComponent or one of its Realizations. (†2559)
preservation management document (p. 17): PreservationManagementDocument and PreservationManagementData are differentiated according to their users, humans and computers, not their contents. The two specializations will extensively have the same content.
(†2553)
preservation management document (p. 34): An abstract class, PreservationManagementDocument has several defined specializations that should be common in Preservation Environments: [Preservation Agreement, Preservation Service Contract, NoticeOfIntentToSubmit, SubmissionDocument, PreservationActionReport, ProblemReport, ProblemResolutionReport, and PreservationAssessmentReport.]
(†2554)
preservation management document (p. 51): A PreservationManagementDocument is a human readable object whose contents are about preservation or relevant to preservation management. PreservationManagementDocument Capabilities include management of each of the specializations of PreservationManagementDocument that are defined in the PaaST data model. In addition, PreservationManagementDocument Capabilities enable Actors to define other specializations of PreservationManagementDocument, enabling additional customization in different situations. These requirements also address generating, sending and receiving PreservationManagementDocument, and extracting PreservationManagementData from PreservationManagementDocuments.
(†2555)
preservation management information (p. 15): PreservationManagementInformation describes both PreservationTargets and PreservationActions. (†2456)
preservation management information (p. 17): PreservationManagementInformation comprises information needed for adequate appropriate, consistent, and verifiable preservation. It describes PreservationTargets, PreservationActions or both. Some PreservationManagementInformation is used in PreservationActions and, over time, more and more PreservationManagementInformation is generated in PreservationActions. PreservationManagementInformation may also describe Parties.
(†2556)
preservation management information (p. 33): PreservationManagementInformation is an abstract class which has two specializations: PreservationManagementDocument and PreservationManagementData. (†2557)
preservation network (p. 39): Any PreservationTarget has at least one BinaryEncoding and at least two DigitalComponents needed to instantiate it. There may be many more, including additional Binary Encodings and Data Objects, and possibly several HeuristicInformation objects that clarify it. Every DigitalComponent has an associated ComponentDescription. Over time, there will be a growing quantity of PreservationManagementInformation about all of these objects. All of these objects are significant, and many are necessary, for successful preservation of the PreservationTarget. The set of all such objects constitute a PreservationNetwork with the PreservationTarget as its focus. [Note:] The concept of ‘PreservationNetwork’ expands on the OAIS concept of ‘Representation Network,’ but a Representation Network is, by definition, more limited: “The set of Representation Information that fully describes the meaning of a DigitalComponent.” OAIS p. 1-15.
(†2558)
preservation problem (p. 53): Comparing PreservationManagementData to DigitalComponents and Realizations tests whether the data accurately and adequately describes a DigitalComponent or one of its Realizations. Comparison may show either consistency or some discrepancy. A discrepancy is a situation where data values that should be identical are not; or data values that should be consistent are not; or data do not correspond to the things they describe. Any data discrepancy is flagged as a preservation problem.
(†2560)
preservation rule (p. 17): PreservationRules support both consistency and optimal automation in implementing the capabilities articulated in PaaST requirements. A PreservationRule can trigger the execution of a PreservationAction. Such a rule should identify the circumstances when the capability is necessary or advantageous and prescribe what should be done when those circumstances occur.
(†2562)
preservation rule (p. 41): Figure 12, PreservationRule, shows the structure of a PreservationRule. A PreservationRule may prescribe a single action or a sequence of actions. The action or actions prescribed by a PreservationRule must correspond to a capability articulated in one or more PaaST requirements. A PreservationRule may contain zero or more other rules. (†2564)
preservation rule (p. 41): Generically, a PreservationRule is a statement in one of two formulations: · If specified circumstances occur, then the situation predicated in the applicable PreservationCondition should be true. · If specified circumstances occur, then perform the PreservationAction prescribed by the rule and produce the result specified in the applicable PreservationCondition.
¶ In the first formulation, a PreservationRule could be called a state rule because the applicable PreservationCondition should specify the values that attribute(s) of an object should have; that is, each PreservationCondition describes the state of an object. In the second formulation, a PreservationRule could be called an action rule because the applicable PreservationCondition describes the result(s) of a PreservationAction; however, the PreservationConditions applicable to an action rule should also include PreservationState because, by definition, a PreservationAction involves at least one PreservationTargets. (†2563)
preservation service (p. 12): A Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
(†2565)
preservation service contract (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
(†2434)
preservation service contract (p. 40): Thus, an important part of any Preservation Service Contract is to specify which requirements must be satisfied; moreover, the contrast should also specify where and when particular requirements should be applied. These contract specifications should then be translated into executable Preservation Rules.
(†2566)
preservation service provider (p. 11): Preservation Service Provider has and provides technological capabilities (infrastructures,
applications and tools) that satisfy PaaST requirements. (†2429)
preservation service provider (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
¶·Submitters and Access Clients have secondary roles in that their rights and responsibilities could be specified in Preservation Agreements or contracts without their involvement. (†2435)
preservation service provider (p. 11): Preservation Service Provider has and provides technological capabilities (infrastructures, applications and tools) that satisfy PaaST requirements. (†2567)
preservation service provider (p. 12): A Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
(†2568)
preservation target (p. 14): An IntellectualEntity has two subclasses, PreservationTarget and HeuristicInformation. A PreservationTarget is something that is preserved. HeuristicInformation is human readable information that is important in helping people to understand and interpret correctly the information conveyed by a PreservationTarget. These two subclasses are not mutually exclusive. An information object could be both a PreservationTarget and HeuristicInformation. The distinction depends essentially not on what the object is, but on the context in which it is managed, processed or used.
(†2444)
preservation target (p. 14): Ideally, a PreservationTarget should not change; however, the uncertainty of the evolution of information technology means that there is no guarantee that future Instantiations will preserve all properties without change.
(†2570)
preservation target (p. 25): Like all IntellectualEntities, a PreservationTarget exists in its proper form only temporarily as instantiated in a RuntimeVersion or Manifestation. For a PreservationTarget, then, remaining in a definitive state translates into every Instantiation being identical in all essential respects. The essential properties are articulated as PermanentFeatures of the PreservationTarget.
(†2571)
preservation target data (p. 34): PreservationTargetData comprise data that describe a PreservationTarget or any of its specializations or parts or their subclasses. (†2572)
preservation target data (p. 36): PreservationTargetData has two immediate specializations, TargetDescription and TargetState. (†2573)
preserved record (p. 60): A Record is a type of Item and a RecordAggregate is a type of Collection. Similarly, a PreservedRecord is a type of PreservationItem and a PreservedRecordAggregate is a type of PreservationCollection. As specializations of PreservationTarget, both PreservedRecord and PreservedRecordAggregate have PermanentFeatures. They all have the universal PermanentFeature of integrity.
(†2574)
preserved record (p. 60): A PreservedRecord is a type of PreservationItem and a PreservedRecordAggregate is a type of PreservationCollection. As specializations of PreservationTarget, both PreservedRecord and PreservedRecordAggregate have PermanentFeatures. They all have the universal PermanentFeature of integrity. A PreservedRecord may have PermanentFeatures that derive from the type of document that it is, as well as ArchivalPermanentFeatures that relate specifically to its status as a Record.
(†2575)
preserved record (p. 63): The minimal ArchivalPermanentFeatures for every PreservedRecord are the identities of the RecordCreator and the RecordAggregate. Implementing additional ArchivalPermanentFeatures enhances the quality of archival preservation.
(†2576)
problem handling (p. 37): The data describing the handling of any problems that occur in PreservationAction should be stored as PreservationActionData, but the impact of ProblemHandling on any object should be stored in the categories that would be used if no problem occurred. (†2580)
problem history data (p. 36): There is also a subclass, ProblemHistoryData, that identifies any problems encountered in Preservation Action and the responses to problems. ProblemHistoryData is included because the record of any of the other subclasses would be incomplete if details about problems and problem handling were not included.
(†2582)
producer (p. 11): A person or entity that created or otherwise produced one or more PreservationTargets.
The Producer’s role as Producer ends once the PreservationTarget has been produced. The
Producer may not even make the decision that an IntellectualEntity should be a PreservationTarget.
That decision is made by the Intitial Source. The person or organization who was the Producer,
nevertheless, could act in one or more other capacities. (†2425)
record (p. 60): Moreover, because the context determines the meaning of a Record, a Record can only belong to one RecordAggregate.
(†2577)
record aggregate (p. 60): Because a Record is, by definition, a document in a specific context of use, a Record must belong to a RecordAggregate. Moreover, because the context determines the meaning of a Record, a Record can only belong to one RecordAggregate.
(†2586)
record aggregate (p. 60): An archival fonds is the highest level RecordAggregate and is defined as “The entire body of records of an organization, family, or individual that have been created and accumulated as the result of an organic process reflecting the functions of the creator.” [SAA Glossary 2005] (†2587)
record category (p. 63): Through a RecordCategory, records management assigns a ManagedRecord to a RecordAggregate, an association that must be preserved with the Record. RecordCategory can be attributed with the specific classifications used in a particular recordkeeping system.
(†2588)
rule domain (p. 42): RuleDomain has three types of parts: Actor, PreservationAction and PreservationTarget, all associated by aggregation. There is not necessarily any Actor actively involved in the execution of a PreservationRule, but there may be more than one. Accordingly, a RuleDomain contains zero or more instances of Actor.
(†2589)
runtime version (p. 14): A RuntimeVersion is a digital object that has been loaded into a computer’s central processing unit. (†2448)
runtime version (p. 21): It might seem that HumanReadableIntellectualEntity is equivalent to Manifestation and MachineReadableIntellectualEntity equivalent to RuntimeVersion. However, the two pairs are correlated, but not equivalent. A MachineReadableIntellectualEntity has only a RuntimeVersion, while a HumanReadableIntellectualEntity has both a RuntimeVersion and a Manifestation. Neither form of Instantiation is persistent. Both Machine- and HumanReadableIntellectualEntities are expressed in Binary Encodings.
(†2462)
runtime version (p. 14): An Instantiation materializes, creates a concrete instance of, an IntellectualEntity in a form suitable either for processing by a computer or consumption by a human. These two alternatives are called RuntimeVersion and Manifestation, respectively. A RuntimeVersion is a digital object that has been loaded into a computer’s central processing unit.
(†2590)
submitter (p. 11): Submitter sends Submissions and related information to a Preservation Environment. (†2427)
submitter (p. 12): A Submitter’s participation in preservation activities is limited to actions related to the transfer of PreservationTargets to a Preservation Environment. (†2439)
submitter (p. 11): In a scenario where preservation is accomplished in the Cloud, one or more Initial Sources reach Preservation Agreements with a Preservation Director who accepts responsibility for preservation of digital information assets. The Preservation Director then enters into a Preservation Service Contract with a Preservation Service Provider who provides the technological resources necessary for preservation and carries out preservation activities as directed by the Preservation Director and, presumably as specified in the Preservation Service Contract. However, an Initial Source could retain authority over the materials it wants preserved and thus also act as Preservation Director. Also, a Preservation Director could provide some preservation services in house and only contract with a Preservation Service Provider for a limited set of preservation activities. Alternatively, the Preservation Director might rely on Preservation Service Providers for all preservation services, but rely on one provider for basic ongoing services, such as processing of Submissions and storage of Preservation Targets, while awarding other contracts for specialized services, such as format conversion.
¶·Submitters and Access Clients have secondary roles in that their rights and responsibilities could be specified in Preservation Agreements or contracts without their involvement. For example, when the Initial Source is a government agency, its Preservation Service Agreement with the government archives might provide for several operating units to transmit Submissions of specified series of records for preservation. Each of these units would be a Submitter. Similarly, the Preservation Director’s contract with a Preservation Service Provider might designate classes of Access Clients who may request and receive copies of Preservation Targets, and it may limit their rights by defining access restrictions for privacy, proprietary or other reasons. (†2436)
success criterion (p. 45): A SuccessCriterion, then, must have one or more ProblemHandlingInstructions. A ProblemHandlingInstruction is a business rule that specifies what is to be done when a problem is identified in executing a PreservationRule. A ProblemHandlingInstruction is a special type of PreservationRule, one that is invoked when another PreservationRule fails to execute successfully.
(†2581)
target description (p. 36): PreservationTargetData has two immediate specializations, TargetDescription and TargetState. TargetDescription encompasses data about PreservationTargets, their specialization and parts that should be invariant. There must be a TargetDescription for every instance of any of these objects.
(†2592)
target state (p. 36): An instance of TargetState should be created whenever there is a change of state of a PreservationTarget, BinaryEncoding, DigitalComponent or Instantiation or when existing state data is verified in a PreservationAssessment. State changes include creation, deletion and modification of the value of one or more Features of an object. TargetState, thus, captures the impact of a PreservationAction on any PreservationTarget. TargetState subclasses include:
· SubmissionStatus about the authorization, Submitter, transmission, contents or conditions of a Submission;
· StorageStatus describing the storage of DigitalComponent;
· Assessment Status, describing the results of Preservation Assessment,
· VerificationStatus, describing the results of Verification, and
· PreservationDescription, a generic category for other data that describe the preservation of a PreservationTarget. (†2593)
verification (p. 16): A special type of involvement is Verification; that is PreservationActions that determine whether a PreservationTarget has been preserved successfully. Verification is essential in digital preservation because unintended and inappropriate changes can happen in storage, transmittal and in other PreservationActions that impact PreservationTargets. (†2457)
