Click on the "RID SHORT TITLE" to view the entire RID. |
 |
|  | REVIEWER'S NAME | REVIEW COORDINATOR | REVIEWERS E-MAIL ADDRESS | PAGE NUMBER | PARAGRAPH NUMBER | DESCRIPTION OF REQUESTED CHANGE: (Use From: "..." To "..." format) | CATEGORY OF REQUESTED CHANGE | Created |
|---|
 REVIEW COORDINATOR : Crichton Daniel (7) | | Representation Network formalized by Submitter Information Model | Steve Hughes | Crichton Daniel | steve.hughes@jpl.nasa.gov | 4-23 | 2 complete - As the Knowlnformation Modeledge Base of the Designated Community | Recommendation:
1) Add <submitter information model> as a component of the OAIS RM.
Also consider 2) Formalize the <OAIS RM required elements> as an information model. (Note this probably exists. The suggestion is to make it more explicit.)
Also consider 3) Add a <submitter to OAIS mapping> that maps from the submitter information model to the OAIS required element information model.
Rationale:
1) The <OAIS RM represetation network> is a key component of the reference model. It is abstractly defined, which is appropriate. It seems to be an abstraction of an information model. However by providing a formal information model, a submitter formally defines the representation network for the submission. This would seem to be an important component of a SIP. Note that the request is to provide an information model. The RM should not necessarily detail out how this is done. Also note that certain submitters (e.g. PDS) will have very formal information models. These could/should be included in the SIP.
2) A mapping from the <submitter information model> to the <OAIS RM required elements> would help in validation.
Background:
1) The OAIS RM defines Preservation Description Information (PDI) as the information that is necessary for adequate preservation of the Content Information. However the PDI information, specifically Provenance, Reference, Fixity, Context and Access Rights Information are only informally defined. For example, Table 4-1, Examples of PDI, provides a only few possible attributes for each of these categories.
The OAIS RM points out that a SIP can be submitted to an OAIS and distributed from an OAIS but that it might not be compliant to the OAIS model.
2) The OAIS RM also defines a "representation network" as follows.
Representation Network: The set of Representation Information that fully describes the meaning of a Data Object. Representation Information in digital forms needs additional Representation Information so its digital forms can be understood over the Long Term.
Representation network is only informally defined.
Issues:
When a non-OAIS archive wishes to interface with a compliant OAIS archive the differences must be addressed, if an OAIS compliant archive is ultimately desired. If the necessary representation data exists in the non-OAIS archive, it must be mapped to the OAIS-RM. If it does not exist, it must be provided.
A case study is the Planetary Data System (PDS) where the NSSDC, an OAIS compliant archive is used as the deep archive for the PDS. The interface consists of packaging a PDS volume as a SIP and submitting it to the NSSDC. Even though not designed to be compliant to the OAIS-RM information model (not formally defined), the PDS volumes have been peer reviewed by PDS archive stakeholders to ensure that the representation information is sufficient to meet the archive requirements of the planetary science community. To achieve this interface, the necessary metadata is extracted from the PDS volume to create the SIP. Metadata required by the OAIS-RM that is missing must of course be provided by some means.
Issue 1) The assumption is that a PDS volume is not compliant with the OAIS RM. However, the required information is contained in the volume or is can be extracted from other sources within the PDS archive. There is also a wealth of contextual information to insure the long term usability of the data. In fact there is a formal model for the PDS representation data.
Suggestions
1) The OAIS RM should allow the inclusion of any formal model (Information Model) that describes the non-OAIS archive data. This should be describe in the OAIS RM as a model for representation data. It should be promoted.
2) A metamodel should exist that maps from the submitted formal model to required attributes of the OAIS RM.
3) The required attributes of a OAIS RM should be more formally defined. (Assume this is being done elsewhere.)
Benefit - The submited formal models provides the representation network. A subset of this network maps to the formal OAIS RM.
Steve Hughes
| Recommended | | | Data Integrity, tracking and logging | Emily Law | Crichton Daniel | Emily.S.Law@nasa.gov | 4-10 | 4.1.14 | Lack of data integrity, tracking and logging policy. The Receive Database Updates function provides regular reports to Administration summarizing the status of updates to the database. Don’t think that’s sufficient for traceability of data flow. | Recommended | | | Archival Info CM | Emily Law | Crichton Daniel | Emily.S.Law@nasa.gov | 4-2 & 4-12 | 4.1 & 4.1.1.5 | The Administration entity functions include CM of system hardware and software. Page 4-12. The Archival Information Update function provides a mechanism for updating the contents of the archive. But Archival information CM and versioning are not explicitly referenced. | Recommended | | | Usability in Preservation Planning | Dan Crichton | Crichton Daniel | dan.crichton@jpl.nasa.gov | | | Under 4.1.1.6, there are elements that discuss aspects of preservation planning. There is no discussion related to “usability” planning. In Figure 4-6, the workflow shows several of the elements of preservation planning, but verifying usability is not shown. Again, this is an issue if both software and data are preserved | Recommended | | | Data Integrity Concepts | Dan Crichton | Crichton Daniel | dan.crichton@jpl.nasa.gov | | | Data Integrity is an important part of an archive and data system, however there is little reference to “Data Integrity” explicitly. Error Checking provides the conventional concept of data integrity (e.g., ensuring bits are not corrupted in data transfer, etc). Also, on page 4-8, the description of Error Checking says that its purpose is to ensure no corruption during transfer, however, this should also include data at rest. There are problems with data on disk becoming corrupted. This is referred to later in the paragraph when it says that a storage facility should do random checks, but I would recommend this be explicit under the description of “error checking” that both data transfer and data storage should have a data integrity protection in place. | Recommended | | | Figures | Dan Crichton | Crichton Daniel | Dan.Crichton@jpl.nasa.gov | | | Figures 2-3 and 2-4 use an unconventional notation. In figure 2-3, there is supposed to be, as I understand it, the notion of encapsulation of content information and preservation descriptive information, however, the notation doesn’t make this clear and it seems to be a different notation than others used in the book. Figure 2-4 again uses a slightly different notation showing “objects” on interfaces. The concept is fine, but the notation is different from the rest of the book and seems unconventional. | Recommended | | | (no title) | Howard Weiss | Crichton Daniel | howard.weiss@cobham.com | | | While this document is applauded for including various discussions on security requirements and services, a distinct security section (as required by the CCSDS procedures manual) is missing and should be included. | Editorial | |
|
|
|
|