[Moims-dai] Action from MOIMS-DAI Webex 20180605

Tue Jun 12 03:35:52 UTC 2018

I was actually thinking of a much simpler kind of example – something like the below (written in hast - not worded correctly, but just illustrating the level of detail).

“There can be different parts of the AIP that are produced by different procedures and system, and thus by different ‘incarnations’ of the OAIS. For example, an outside Producer wishes to submit information to be preserved by the OAIS, but has no knowledge about how the SIPs are best preserved. Agreement has been reached on the procedures to be followed. Inside the OAIS, there are specialist in preservation that may produce additional preservation information in order to be able to make the preservation on long term. This information has to be part of the AIPs for the outside Producers SIPs. The OAIS functional entities have to be considered for this additional information, but where the preservation specialists have the role of (internal) Producers. Agreement has been reached on the internal procedures to be followed. Ingest - including quality assurance - will most likely be implemented differently to the Ingest of the outside Producers SIP etc. Therefore, the additional information must be considered as ingested to an (inner) OAIS, where all functional entities are considered for this information. It should be noted that the outer OAIS only is only a complete OAIS, if the inner OAIS is present.”

I considered not to say inner and outer yet, but it is actually the same thing, - the only difference is that the Inner OAIS in the distributed Archival Storage example may be another organisation in form of a partner or a service provider. Thinking about it, the ‘only’ challenge is to formulate that an inner OAIS is contributing to an outer OAIS and therefore may not fulfill all requirements for ‘full’ preservation system, but the Outer OAIS will not be complete without the Inner OAISs.

Regards, Eld

________________________________
Fra: MOIMS-DAI <moims-dai-bounces at mailman.ccsds.org> på vegne af david <david at giaretta.org>
Sendt: 11. juni 2018 11:26
Til: MOIMS-DAI List
Emne: [Moims-dai] Action from MOIMS-DAI Webex 20180605

Action from Webex 20180605

  1.  David to write an example of the application of OAIS preservation concepts to components of PDI including illustration of Ingest and recursion.

A Producer – in this case outside the OAIS – wishes to submit information to be preserved by the OAIS. Agreement has been reached on the procedures to be followed. The Producer prepares one or more SIPs which are transferred to the OAIS.

  *   A Receive Submission function receives the SIP, and acknowledges the receipt or requests a re-submission if there is an error, for example as reported by Quality Assurance.
  *   The SIP (or the collection of SIPs together) contains the Content Information (Data Object and Representation Information), plus PDI and may also provide Information Property Descriptions of Information Properties.
  *   The AIP is generated by a Generate AIP function from the SIP(s) with any additional Representation Information required. I think that logically we can say that it may also produce Fixity Information, as part of verifying the transfer or if some file format conversions have taken place. Additional Provenance should be created to record the fact that the information has been taken into the OAIS. Some additional Context may be created and Reference Information will also be created to allow the Content Information to be found. The Packaging Information will be determined by the structure of the AIP which the OAIS has decided to use. Note that an AIP is defined as a logical container.
  *   The associated Descriptive Information is created by Generate Descriptive Information.
  *   Coordinate Updates transfers the AIP to Archival Storage and the Descriptive Information to Data Management.

The OAIS will need to preserve the PDI. Let us see how the each of the components of PDI is preserved. Let us say that the Fixity is encoded as a hash code, or example the Data for which is a sequence of bits which encode ASCII characters.

The following runs through a likely process, mapping it to the Ingest Functional Entity.

A Producer – in this case inside the OAIS – wishes to submit information to be preserved by the OAIS. Agreement has been reached on the internal procedures to be followed. The Producer prepares one or more SIPs which are transferred to the OAIS - in this case this is an internal transfer.

  *   In this case the SIP would contain the hash code.

  *   The Representation Information will probably be the same for many examples of Fixity if the OAIS uses the same method for many pieces of data; for example the RepInfo could be (1) Structure: ASCII code to go from bits (2) Semantic: SHA256 was used to create the hash. Therefore there needs only to be a pointer to the RepInfo for the hash.
  *   The Provenance would be that this was created at a particular time. The hash would have been created either by the external Producer or the OAIS. In the latter case one would only need to point to a single statement that the OAIS created the hash.
  *   The Reference Information provides the location where the hash may be retrieved – unique for each hash – surely each hash will have such a reference otherwise how can it be retrieved?
  *   The Access Rights would again be the same for things that are being preserved – no-one is allowed to alter the hash.
  *   The Context would be that the hash is created as part of the OAIS preservation functionality.

All the things (RepInfo, Provenance creator, Access Rights, Context) which are the same for all, or lots of similar, things, could be contained in the documentation about the process.

  *   The Receive Submission (possibly different from the one used for SIPs from the external Producer) function receives the SIP, and acknowledges the receipt or requests a re-submission if there is an error, for example as reported by Quality Assurance. One might expect these may be taken care of by the normal computing infrastructure since it is an internal transfer.
  *   The SIP(s) contains the Content Information (Data Object and Representation Information), plus PDI and may also provide Information Property Descriptions of Information Properties.
  *   The AIP is generated by a Generate AIP function from the SIP(s) with any additional Representation Information required. Again the Generate AIP function may be different from the one used for information from n external Producer. It should also produce Fixity Information, as part of verifying the transfer or if some file format conversions have taken place. Additional Provenance should be created to record the fact that the information has been taken into the OAIS. Some additional Context may be created and Reference Information will also be created to allow the Content Information to be found. The Packaging Information will be determined by the structure of the AIP which the OAIS has decided to use. Note that an AIP is defined as a logical container.
     *   As noted above, many of the components of the AIP would be common to many things and could be covered by a procedures document. The Packaging Information could be contained in a procedures document which essentially just has to say where all the components of the AIP are to be found.
  *   The associated Descriptive Information is created by Generate Descriptive Information.
     *   This again could be covered by a procedures document.
  *   Coordinate Updates transfers the AIP to Archival Storage and the Descriptive Information to Data Management.

As the next level of iteration one can work through the RepInfo or PDI of the procedures documents mentioned above – for example a Word file, written in English, written by a member of the OAIS staff and finalised at a specified time.

I hope it can be understood that the view that I take, re-using OAIS Information concepts repeatedly, does not lead to a plethora of confusing AIPs but instead allows us to be logically coherent in our approach to preservation by simply mapping what I would imagine any good repository would normally be doing, or, alternatively, to check that a repository _is_ doing the right things. To confirm this all you have to do is to go through the above steps and ask yourself whether any steps (or some equivalent steps since we are implementation agnostic) can be missed out.
Regards
David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20180612/45477a0d/attachment.html>