# 7 WP700 - Archiving

## 7.1 Welcome and Introductions

## 

  --------------- ----- ---------------------------------------- ---- -------- -----
  **P/9810/03**   100   DG to request MC to approve publication  DG   981104   
                        of OAIS RM as RB by email ballot at end                
                        of year                                                

  --------------- ----- ---------------------------------------- ---- -------- -----

LR has Technical Edited version of doc. No major changes.

NP: how long will the RB review period be? ISO review may be
pre-determined as 6 months. We may not have the RIDS in time for the
next panel meeting. Perhaps we could move the date of the next w/s.

\*\*\*\*\*\*\* email DT and RS to check review period for ISO
\*\*\*\*\*\*\*\*\*\*\*\*\*

**//DONE Actual review is 5 months; see e-mail response from Bob
Stephens**

## 7.2 Logistics and Agenda Review

## 7.3 Archive Management Report

See Appendix G1

## 7.4 Review of OAIS WB version 4.0

### 7.4.1 Review of Actions not yet completed

Inputs:

-   Review of status of comments from DADS w/s.

-   Comments from NP, DG, SM, MM, Betty Brinker, AW, plus doc by Jacque
    Killawee\'s on the concept of \"records\".

Discussion of Jacque Killawee\'s paper:

-   JW is a student of Charles Dollar. The latter has several concerns.
    In particular he has a problem with terminology such as \"INGEST\"
    for which he suggested an alternative \"ACQUISITION\"

-   The classical \"archivist\" (not librarian) deals with \"records\" -
    connected with a legal transaction. His paper examines this concept
    in terms of scientific data.

-   NP: to include the term \"record\" in the RM would lead to confusion
    with database terminology

-   LR suggested that the most that would be done would be to include
    something about \"record\" in the Glossary plus maybe a short
    paragraph explaining that different communities may have different
    terminologies e.g. \"record\" **//DONE - Couple of sentences added
    to Glossary introduction.**

-   It was **[AGREED]{.underline}** that we should keep the term
    \"INGEST\" - it is not used in the archivist community (hence will
    not cause confusion) but IS meaningful for scientific users.

```{=html}
<!-- -->
```
-   DADS remaining comments -- paper N6:

-   D1.3: Add para about definition of "record" vs. Archivist classical
    definition **[AGREED]{.underline}** // **DONE - in section 1.7,
    along with a paragraph on terminology mapping across disciplines.**

    **\*\*\*NOTE: Following DADs comments have not been checked against
    the document. Some updates will still be needed and will be provided
    prior to the workshop at Newport Beach \*\*\***

-   D2.1: use of jargon -- await other comments from ISO review

-   D2.2: pre-ingest activities: this lies in the realm of good practice
    and should not be addressed in the RM -- except as para in section 2
    or 3.1 **[AGREED]{.underline}**

-   D2.3: not accepted

-   D2.4: not accepted

-   D2.5: obligation to inform users and producers of standards and doc
    requ etc **[AGREED]{.underline}**

-   D2.6: Done -- there are Unique Identifiers now included in the Model

-   D3.1: Add "digitised image" in an "e.g. list"
    **[AGREED]{.underline}**

-   D3.2: Put "ingest methodology" in some future standards document
    **[AGREED]{.underline}**

-   D3.3: Error control through the archive: look at possibility of a
    paragraph in the Administration function **[AGREED]{.underline}**

-   D3.4: List should be covered by the expansion of "Common Services"
    function **[AGREED]{.underline}**

-   D3.5: done

-   D3.6: check implications of migration on finding aids
    **[AGREED]{.underline}**

-   D3.7: rejected

-   D4.1: evolution of model is outside the RM itself

-   D4.2: inclusion of software in AIPs in addressed in Transformations

-   D4.4: boundaries of the model now addressed by the Conformance
    Statement

-   D4.5: metadata registry standards -- should be noted in the
    discussion of federated OAISs

-   D5.1: done

-   D5.2: review of "reference formats" should be covered by new
    Monitoring activities

-   D5.3:

Review of document section by section

-   Use less "informal" style of English e.g. "our images" should be
    "the images" etc. Will probably be caught by Technical Editor
    **[AGREED]{.underline} //NOT DONE YET**

-   MM: General point about \"non digital data\" DS: if non-digital
    people accept this then digital archive people should be happy.

-   LR: \"Long-term\" - is used in 2 different ways (1) technology
    evolution (2) change in Designated Community\'s knowledge base.
    However these really have different time-frames. The latter is
    important even for short-term archives.

-   Section 2 3^rd^ para: definition of \"Long-term\" includes both
    usages, but we should try to be explicit in each case
    (\"\...knowledge base changes ..\" and \"..technological
    changes\...\") where possible. Also we should be consistent in out
    use of \"Longterm\" or \"Long-term\". **//DONE**

-   There MAY be some confusion in using ARCHIVE and OAIS through the
    document.

-   \"Designated Community\" - DG suggests a closer definition in terms
    of the Knowledge Base. LR pointed out that in contractual terms
    archives do indeed have a specified \"community\" and the archive
    has to then insert enough metadata to fit the Knowledge Base. Also
    User Community are potential users for whom the metadata is not
    necessarily tailored.

-   Add discussion of \"Designated Community\", \"User Community\" and
    \"Knowledge Base\" in section 2.2/2.2 **//DONE - in 2.2.1**

-   **Foreword**

-   JGG: change \"for use in developing a consensus\" since it actually
    records a consensus. LR, DS: this really is a Reference Model which
    is trying to get a wide consensus.

-   Ensure that it is stated that Annex A is NOT part of the
    Recommendation **//DONE**

-   **Section 1.1 para 2**

-   GMP: \"It extends indefinitely\" is odd. **[CHANGE]{.underline}** to
    \"Long-term may extend indefinitely\" **//DONE**

-   BB: 6^th^ bullet - what does \"elements\" mean?
    **[AGREE]{.underline}** to leave as is **//DONE**

-   **Section 1.2**

-   **[ADD]{.underline}** 3^rd^ bullet to list to cover changes in
    \"Designated Community\", even for short-term archives.
    **[Perhaps]{.underline}** merge 2^nd^ bullet with into sentence to
    the bullets. **//Addressed by incorporating \'Designated Community\'
    into first bullet**

-   **Section 1.4**

-   DG: Use of SHALL instead of WILL - **[AGREED //DONE]{.underline}**

-   DG: Renumber section 3 so 6 main bullets are section 3.1 then
    introduce section 3.2 as \"Detailed discussions\" and current 3.1
    becomes 3.2.1 etc. Change reference in 1.4 to point to section 3.1
    etc. **[AGREED //DONE]{.underline}**

-   Para 3:

-   change \"maintenance of PDI\...\" to \"development and maintenance
    of PDI\...\" **//DONE**

-   Problem with terms AIP etc so early on in the document.

-   Replace \"\... support the structure and \...(to penultimate para)\"
    by \"..shall support the model of information described in section
    2.2\", and keep last sentence. **[AGREED //DONE]{.underline}**

-   **Section 1.5**

-   Change bullets \"standards for the interfaces\...\" to
    \"interfacing\...\" etc to fit in with introductory words.

-   References to CCSDS Panel 2 should be changed. In particular
    \"coordinated with CCSDS P2\" should read \"co-ordinated\"

-   Bullet 4: delete last sentence of the bullet **[AGREED
    //DONE]{.underline}**

-   Bullet 9: change \"representations\" to \"formats\" **[AGREED
    //DONE]{.underline}**

-   **Section 1.6**

-   **[ADD]{.underline}** sub-section \"How to read this document\" in
    order to help people decide which sections they MUST read because
    readers have been missing out section 2 and jumping to section 4.
    **//DONE**

-   **[Section 2:]{.underline}**

-   **Section 2.1**

-   3^rd^ bullet, last sentence change \"must be able\" to \"should be
    able\" **//DONE**

-   **Section 2.2.1**

-   Para 4: make \"Representation Info\" bold italics **//DONE - in
    3^rd^ paragraph using bold only**

-   Para 5: GMP: suggests dropping \"\...and it runs counter \...(to end
    of sentence)\" because trends change and it may make the model
    appear dated. **[CHANGE]{.underline}** to \"\...and it runs counter
    to information hiding approaches.\" **//DONE**

-   **Section 2.2.2**

-   MM: \"Information Object\" - relationship to \"Information Package\"

-   LR: see last para of previous section - could make this first para
    of section 2.2.1 **[AGREED //DONE]{.underline}**

-   MM: \"Packaging Information\" and \"Information Package\"

-   Change \"Packaging Information\" to \"Bundling Information\"

-   Or

-   \"Information Package\" to \"Information Bundle\"

-   or

-   **leave as is [- favoured option //DONE]{.underline}**

-   **Section 2.2.2**

-   Para 5:

-   DG: definition of PDI - text implies it contains everything at the
    start

-   LR: wishes to imply that PDI is very hard to change

-   DS: suggest changing \"\...and is needed to make the CI
    understandable when \...these facts\" TO \"\...and is needed to
    preserve the CI and to understand the environment in which the CI
    was created\" **[AGREED //DONE - also added need for
    identification]{.underline}**

-   Section 2.2.3

-   Section 2.2.4

-   **Section 2.3**

-   Fig 2.5

-   DIP appears to be created outside the OAIS, also SIP -

-   Take the arrow heads off the line from OAIS to DIP and from Producer
    to SIP **[AGREED //DONE]{.underline}**

-   LR: proposal to remove \"queries\" and \"result sets\" - TBD

-   **Section 3**

-   Section 3.2

-   2^nd^ para - 3 bullets rather than 4 referred to **//Done**

-   Section 3.3

-   Para 2: Merge with following para 1^st^ sentence and delete
    following sentences. **//DONE**

-   Section 3.4

-   **[ADD]{.underline}** discussion of \"Knowledge Base\" **//DONE**

-   **Section 4**

-   Section 4.1

-   GMP: 2^nd^ sentence: text says \"info flows in both direction\",
    this is inconsistent with the diagram as it is. Change to say this
    only shows major information flows, leave figure alone.
    **[AGREED//DONE]{.underline}**

-   LR: fig. 4.1 external flows should match external flows in fig. 2.5
    **[AGREED//DONE]{.underline}**

-   DG: Administration should contain something about tracking and
    responding to changes to the Designated Community and/or Knowledge
    base **[AGREED//DONE]{.underline}**

-   **Section 4.1.1**

-   **Section 4.1.1.1 Common Services**

-   Expansion **[STILL]{.underline}** needed //**Done**

-   **Section 4.1.1.2 Ingest**

-   GMP: should arrow between Receive Submission and Quality Assurance
    be labelled?

-   LR: merge the 2 bubbles and hence eliminate the arrow and merge
    appropriate text to Receive Submission **[AGREED// Proposal is to
    NOT do this as the split out was requested at the Houston meeting.
    Flows have been labeled.]{.underline}**

-   NP & MM: the arrow between \"co-ordinate updates\" and \"data
    management\" should be reversed **[AGREED//DONE]{.underline}**

-   SM: comment on audit

-   Change \"Audit Submission Agreement\" to \"Audit Submission\" and
    add connection to INGEST (SIP from INGEST and \"Report\" back), also
    corresponding changes in Fig 4-5 and section 4.1.1.5 **[AGREED
    //done but update to figure 4-5 is still needed]{.underline}**

-   From HOU98 - add \"other info sources with OAIS\" to \"Generate
    Descriptive Info\" **[//DONE]{.underline}**

-   **Section 4.1.1.3 Archival Storage**

-   GMP: Fig 4-3, missing label between Media and \"Manage Storage
    Hierarchy\" - label as \"Commands\" **[AGREED //DONE]{.underline}**

-   CH: Migrate Media - be clear about relationship to Transformation
    **//DONE - added a forward reference to migration terms - needs
    review.**

-   Resolve remnant comment \"\[Clarify the last phrase \".. when
    deciding..\"\]\"

-   Delete **[AGREED //DONE]{.underline}**

-   GMP: suggests arrow from \"Migrate Media\" to \"Media\" should be
    labelled AIP. **//DONE**

-   LR: REMOVE labels from arrow to and from \"media\" and \"backup
    media\" since these are very low level **[AGREED //DONE only for
    Disaster Recovery function -- Proposal is to leave others as
    shown]{.underline}**

-   GMP/LR: replace term \"Media\" by \"AIP Repository\"
    **[NO]{.underline}**

-   LR: add return arrow from \"Receive Data\" to INGEST labelled
    location and acknowledgement **[AGREED //DONE but labeled 'Storage
    Confirmation']{.underline}**

-   DS: maybe we should not call out these functions if we cannot define
    what MUST happen inside

-   From HOU98: \"Disaster recovery \...\" make it clear that removeable
    media is not required and that we are talking about digital data:

-   Add word \"digital\" **[AGREED //DONE]{.underline}**

-   In **Manage Storage H** add comment about max error rate **[AGREED
    //DONE]{.underline}**

-   In **Error Checking**

-   add note about Reed Solomon **[AGREED //DONE]{.underline}**

-   as per FRA97 comment add note about higher level of service
    **[AGREED]{.underline}** **[//DONE]{.underline}**

-   Change Standard Logs to Standard Error Logs **[AGREED
    //DONE]{.underline}**

-   **Section 4.1.1.4 Data Management**

-   From FRA -- move subscription from Access to Data management

-   This is in Administration **[AGREED]{.underline}** **//DONE -- no
    action required**

-   Fig 4-4 line between **Admin** and **Generate Report** should be
    double arrow **[AGREED]{.underline}** **[//DONE]{.underline}**

-   **Generate Report** text -- expand to include statistical report on
    usage of the archive, and add examples such as usage report etc
    **[AGREED //DONE]{.underline}**

-   LR: add line from Admin Database to Administration labelled as
    Policies **[AGREED//DONE]{.underline}**

-   **Section 4.1.1.5 Administration**

-   GMP: Archival Information Update

-   Should there be a link to Data Management?

-   Change Arch Info Update function, sentence 2 should be "...updates
    to AIP stored in Archival Storage or Descriptive Info stored in Data
    Management..." **[AGREED //DONE]{.underline}**

-   GMP: SIP, AIP and DIP should NOT flow into Administration

-   LR: these indicate a "logical" flow NOT a physical flow

-   AW: physical security missing

-   DG: the function of updating Designated Community and the Metadata
    needed to match the assumed knowledge-base is HIGH LEVEL and should
    be pulled out as a separate box. At the moment it is hidden within
    "Manage System Config" and "Archival Info Update"

-   DS will draft a Monitor Designated Community with connection to
    Producer, Consumer etc **[AGREED]{.underline}** **[//DONE (by
    Mike) - only the link to Consumer is show explicitly although the
    text mentions interactions with Producer and Management. Personally,
    I don\'t think the additional diagram complexity needed to show
    these additional 2 links are worth it.(DMS)]{.underline}**

-   Comment on Environmental issues

-   Assumed to be superceded **[AGREED]{.underline} //Done**

-   **Section 4.1.1.6 Access**

-   SM: what is difference between results Set and DIP

-   LR: Result Set is answer to a query, DIP is result of transformation
    of AIP. In text of Receive Request this is specified

-   LR/JG: need concept of an ORDER REQUEST **[AGREED]{.underline}
    //DONE -- an ORDER can be placed as one type of request**

-   LR/DS: use generic term "Response" instead of "DIP" and!or "Result
    Set" **[AGREED //Not Done\_- Have Result Set/Report and DIP as 2
    forms of response to Consumer to match (disregarding \'report\')
    with Figures 4-1 and 2-5.]{.underline}**

-   LR: change Generate DIP to Generate Response **[AGREED // Not done
    after proposal to simplify Access and telecon
    agreement.]{.underline}**

-   Also line from Coordinate Access Activities to Deliver Response
    labelled as Result Set or Report etc (not DIP)
    **[AGREED]{.underline}** **[// Not done following Acces s revision.
    Now shows 2 lines - one for Result set/Report and one for
    DIP.]{.underline}**

-   Line from Deliver Result to Consumer should be labelled as "DIP,
    Result Set ..." **[AGREED]{.underline}**/**/ Function is called
    \"Deliver Response\" and lines are Result set/Report and DIP.**

-   LR: label as "Status" the line between Coordinate Access Activities
    from Data Management **[AGREED]{.underline}** **[//NOT DONE
    following simplified Access function because now Co-ordinate Access
    Activities get back the results from these queries to Data
    Management. It prepares, as needed, the responses to be handled by
    \'Deliver Response\']{.underline}**

-   DS/LR: Missing return "Aids" from Prepare Access Aids to
    Administration and label as Aids AND add label "Access Aids" on line
    from Data Admin to Generate Response AND corresponding line in Admin
    diagram Fig 4.5 **[AGREED]{.underline}** **[//NOT DONE -- there is
    no mention of \'aids\' in Administration. Role of \'Prepare Access
    Aids\' needs review and then figure updates, as
    needed.]{.underline}**

-   **Section 4.1.1 figure inconsistencies -- NP**

-   Fig 4.2 vs. 4.5

-   Shows "Data Formatting and doc stds" from Admin to Ingest

-   Fig 4.5 shows "Policies" and "SIP" from Admin to Ingest

-   Join "Develop Policies and Standards" (4.5) to "Generate Arch Inf
    Package"(4.2), labelled as "Policies and Standards"
    **[AGREED]{.underline}** **[//DONE -- but labeled 'Format and Doc.
    Stds."]{.underline}**

-   Join "Arch Inf Update" (4.5) to "Receive Submission"(4.2) labelled
    as SIP **[AGREED //DONE -- but labeled '\[updated\]
    SIP']{.underline}**

-   Fig 4.4 vs. 4.5

-   4.4 shows "Report" and "Updates" from Admin to Data Management

-   4.5 shows "Policies" and "Status" from Admin to Data Management

-   Fig 4.4 vs. 4.6

-   4.4 shows "Report", "Request", "Query Request" and "Result Set"
    between Access and Data Management

-   4.6 shows "Report", "Request", "Results", "Query Request", "Report
    Request", "Result Set", "Specialised Query" and "Descriptive Info"

-   Delete line from "Generate Response" (4.6) to Data Management

-   Fig 4.5 vs. 4.6

-   4.5 shows "Dissemination request" and "DIP" between Admin and Access

-   4.6 shows "Billing Info"

-   Join "Activate Request" (4.5) to "Receive Requests"(4.6) labelled
    "Dissemination Request"

-   Remove line from "Archival Inf Update"(4.5) to ACCESS

-   Fig 4.6 vs. 4.3

-   4.6 shows "AIP" "Data Request" and "Notice of Data Transfer" between
    Access and Archive Storage

-   4.3 shows "AIP" and "Data Request"

    **FORGET MOST OF THE ABOVE -- CHANGE THE DIAGRAMS SO THAT ALL THE
    ARCHIVE ACCESS PREPARATIONS GO TO "Coordinate Access Activities"
    WHICH THE PASSES EVERYTHING TO "Generate Response"** **when ready**;
    **this may simplify the diagrams // Done, but slightly differently
    in that Coordinate Access Activities uses the Generate DIP function,
    and it puts everything together for delivery to Generate Response,
    as agreed at telecon. However, Prepare Access Aids is still not
    fully integrated and consistent in figures and text.**

  --------------- ----- -------------------------------------------- -------- ----
  **P/9810/34**   700   DS to produce super Don-O-gram as a bigger   981115   
                        and better version of Nestor --O-gram                 

  --------------- ----- -------------------------------------------- -------- ----

**//DONE - a few inconsistencies remain**

-   **Section 4.1.2 Data Flow Diagrams**

-   Fig 4.8 should

-   **Section 4.2 Information Model**

-   Fig 4.14 change "Archival Info Object" to "Info Object" for clarity
    **[AGREED]{.underline}** //**DONE**

-   **Section 4.2.1.3**

-   Add discussion of closure of Representation Net with Knowledge Base
    (and software) also in section 2.1.1 **[AGREED]{.underline}** //DONE

-   Add paragraph or two on why it is not a recommended practice to rely
    on software to end Rep Nets. **[AGREED]{.underline}** //**DONE**

-   Also add similar discussion about PDI evolution in 2.2
    **[AGREED]{.underline}** // DONE - by the fact that both Content
    Information and PDI are Information Objects and thus have networks
    of Representation Information that are terminated in some way,- by
    Knowledge Base and/or software.

-   **Section 4.2.1.3.2**

-   Fig 4.11 box "Referenced Rep Info" should be "References to Rep
    Info" **[AGREED]{.underline}** \[16:14\] //**Not done due to changes
    in Figure 4-11**

-   LR: replace "Additional Rep Information" box by its components
    "Additional Semantics" ( maybe renamed to "Interaction/operations"
    or "relations"), and "mapping rules". **[AGREED]{.underline}**
    **DONE** \[16:36\]

-   **Section 4.2.1.3.3 A Model for Software Use in Rep Info**

-   Update "Structure Info" and "Semantic info" in the Glossary

-   BB: various comments -- need more specific suggestions

-   MM: general comment -- difficult to understand and Utopian

-   LR: this section lacks motivation -- may be solved if/when
    discussion of emulation is added -- as per DADS workshop

-   LR: If adequate connection using emulation discussion cannot be
    inserted then move to Annex or to Section 5 **[AGREED]{.underline}**
    //**DONE**

-   **Section 4.2.1.4**

-   **Section 4.2.1.4.1**

-   BB: reword para 3 for clarity **[AGREED]{.underline}** //**DONE**

-   Para 4 -- change "quite temporary" to "may be short-lived"
    **//DONE**

-   **Section 4.2.1.4.2**

-   JGG: Add note that the table is only illustrative
    **[AGREED]{.underline}** //**DONE**

-   LR: move comparison with "Preserving Digital Info" to Annex and just
    put reference here **[AGREED]{.underline}** //**DONE**

-   AW: Ref Info bullet -- how does user find this content info? Various
    alternative ways of putting this:

-   What Taxonomic system(s) can this CI be related to

-   What reference system(s) would be used

-   What registration system(s) would be used

-   JG: Any specific choice of these systems should point to unique item
    in archive

-   NB these are different from Finding Aids in general

-   DS: these should be used as examples in the explanation of Reference
    Info **[AGREED]{.underline}** //**DONE** \[17:11\]

-   AW: other comments on bullets all accepted as per hand written notes
    **[AGREED]{.underline}** //**NOTDONE due to lack of handwritten
    notes**

-   **Section 4.2.1.4.3**

-   

-   **Section 4.2.1.4.4**

-   **Section 4.2.2**

-   Fig 4.15 and 4.17: make diagrams consistent **[AGREED]{.underline}**
    //**DONE**

-   **Section 4.2.2.3**

-   Change "commercial file management system" to " file management
    system" **[AGREED]{.underline}** //**DONE**

-   Change AIU to AIP **[AGREED]{.underline}** //**DONE**

-   JG: Fig 4.20: since ALL the boxes have Representations, the
    Representation box in this figure should NOT have a loop around to
    itself. Also ALL the boxes are Information Objects but only the CI
    has the Information Object components shown.

-   LR: perhaps we should remove this figure

-   DS: maybe add Representation Info to all the boxes

-   **Section 4.2.3**

-   **Section 4.2.3.1**

-   GMP: First sentence -- remove "important" since these are the only
    ones identified so far **[AGREED]{.underline}** //**DONE**

-   **Section 4.2.3.1.1 AIU**

-   Use of digital image, digital film, digital movie in the examples
    shuld be made consistent as digital movie. Also change "digital
    movie image" to "digital movie encoding" **[AGREED]{.underline}**
    **//DONE**\[18:16\]

-   **Section 4.2.3.1.2 Unit Description**

-   

-   **Section 4.2.3.1.3 Archival Info Collection**

-   1^st^ para, last sentence -- replace "in the OAIS ...section" by
    "here" **[AGREED //DONE]{.underline}**

-   **Section 4.2.3.1.4 Collection Description**

-   LR: Access Collections -- clarify the example or ordering in advance

-   **Section 4.2.3 Data Management Data (note incorrect section
    number)**

-   Change title to "Data Management Information" **[AGREED]{.underline}
    //DONE**

-   Remove "general ledger data" from list of examples
    **[AGREED]{.underline} //DONE**

-   **Section 4.3 Info Package Transformations**

-   Fig 4.22 "Package Descriptor "- should be "Package Descriptions"
    **[AGREED]{.underline} //DONE**

-   **Section 4.3.1**

-   Clarify what "agreement" has in

-   **Section 4.3.2**

-   Should use AIU instead of AIP throughout this section
    **[AGREED]{.underline}** **//Reversed by mistake - needs revision**

-   Remove phrase about maturity of data mining in 4^th^ para, followed
    by "Researchers are likely to continue ..."

-   Delete last para **[AGREED]{.underline}** **//DONE**

-   **Section 4.3.3**

-   Title should be "... transformations in the ..."... instead of
    "transformation by the..."

-   **Section 4.3.4**

-   Change ACCESS/DISSEMINATION to ACCESS **[AGREED]{.underline}
    //DONE**

-   Try to make title consistent with the other titles in this section
    **[AGREED]{.underline}** **//DID BEST**

-   Change "In most cases" to something less informal **[AGREED //NOT
    DONE - missed]{.underline}**

-   Refer to AIP instead of AIU in para 2 **[AGREED]{.underline}**
    **//NOT DONE - missed**

-   **Section 5 (DMS NOTE 99/04/15: There are 3 open issues below)**

-   1^st^ sentence: use OAIS instead of archive /**/DONE - applied
    throughout section 5.**

-   change "to preserve its digital information.." to " to preserve
    information.." //**DONE**

-   change 3^rd^ bullet "an internal OAIS perspective" TO "the full
    control and responsibility over all aspects of the transfer"
    **//DONE**

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\--

LR suggests the following reorganisation of the chapter, to include
other techniques:

5.0 The Problem

Technology Evolution

Designated Community/Knowledge Base Evolution

1.  Alternative Solutions

    Migration

    Emulation/Wrapping (around older applications)

    New AIUs (versions and editions)

    1.  Migration

    2.  Emulation/Wrapping

        e.g. if no source available then need to emulate the environment

    3.  Versions and Editions

2.  Comparison of techniques and recommendations

\-\-\-\-\-\-\-\-\-\-\-\-- **to be discussed in telecons**

**// In our discussions at a US archive workshop, we came to the
conclusion that emulation did not appear to be a practical approach to
information preservation and we did not want to put it at the same level
of discussion as preservation of the Representation Information through
migration. After reading Jeff Rosenburg\'s latest paper on this subject,
I still feel that emulation is not a viable approach and certainly has
not been demonstrated to work in an archival setting. Since we are
concentrating on preservation of the bits and corresponding
Representation Information, it appears to make more sense to put
emulation into the framework of a possible approach to preserving access
services - not information preservation. This is also the framework for
discussing a \'wrapping\' approach. Therefore I\'ve generated the
revised section 5 outline to be:**

**5.0 Preservation Perspectives**

**5.1 Information Preservation**

**5.1.1 Digital Migration Motivators**

**5.1.2 Migration Context**

**5.1.3 Migration Types**

**5.1.4 Distinguishing AIP Versions, Editions, and Devied AIPs**

**5.2 Access Service Preservation**

**With section 5.1 now titled \'information preservation\', I believe it
now is appropriate for the discussion on AIP version, editions and
derived AIPs to remain where it was since this is more general than the
previous title of \'digital migration\'.**

-   **Section 5.1**

-   

-   **Section 5.2**

-   Fig 5.1 -- string the two sides together to show that one side to
    AIP id on the left leads into the Archival Storage mapping etc
    **[AGREED]{.underline}** // **DON**E

-   **Section 5.3**

-   GMP: definition of transformation -- add clarification that full
    information content is preserved **[AGREED]{.underline}** /**/DONE**

-   Add ref to fig 5.1 after "Archival Storage mapping infrastructure"
    **[AGREED]{.underline}** **//DONE**

-   Penultimate sentence in Replication bullet should refer to "..the
    same or new media type ..." **[AGREED]{.underline} //DONE**

-   **Section 5.3.1 Refreshment**

-   Move to be sub section under Replication since it is a special case
    of Replication where the media is the same. **//Could be done if
    \'agreed\'**. **Is there consensus that this would be clearer?
    (ISSUE )**

-   **Section 5.3.2 Replication**

-   Last sentence in last para should be "This type of replication
    affords ease of migration ....." **[AGREED]{.underline}** //**DONE,
    but with slightly revised wording**.

-   Need better definition of the "Packaging Information" and some
    examples the various ways of including or excluding pieces of
    information under this heading **[AGREED]{.underline}** // **Done -
    Example of Packaging Information and mapping infrastructure given in
    Section 5.1.2.**

-   **Section 5.3.3**

-   

-   **Section 5.3.4**

-   5^th^ para should state that scenario 5 is a variation of
    scenario 4. /**/DONE originally, but at last telecon it was asked to
    give more context for each scenario within the Transformation
    sub-section. This was done and each scenario is now \'stand alone\',
    so there is no need to reference one from another.**

-   **Section 5.4**

-   DADS comment to review DOD document and check consistency with this
    section //**Not Done Yet// (ISSUE)**

-   NP suggested expanding this section **//Not Done. If there are
    specifics to be addressed, this could be done. (ISSUE)**

-   

-   **Section 6**

-   **Section 6.1.1**

-   Change "participated in the requirements" not imply participation
    **[AGREED]{.underline}** **//DONE**

-   **Section 6.1.2**

-   Add less symmetrical case of co-operation showing one archive acts
    as consumer for another **[AGREED]{.underline}** **//DONE**

-   **Section 6.1.3 Federated Archives**

-   SM: is it practical to mark data as original or copy in Federated
    Archives

-   LR: will clarify the scope of the problem being addressed for copy
    and original i.e. only the case where copy is made between
    Federation members -- NOT sourced from same producer
    **[AGREED]{.underline} //DONE**

-   GMP: correct diagrams -- should show "Acc" NOT "Acc/Dis"

-   GMP: fig 6.3 should show Common Catalogue "ingesting" catalogues in
    some way

-   LR: change figure6.3 to indicate alternate methods of setting up the
    common cat in 6.3 **[AGREED]{.underline}** **//DONE**

-   AW: include mechanisms for handing on responsibility for
    preservation of information if an OAIS closes down
    **[AGREED]{.underline}** **//DONE**

-   Clarify acronyms such as ECS etc. and perhaps include non-space case
    **[AGREED]{.underline} //DONE**

-   Annex A

-   Ensure that it is stated that Annex A is NOT part of the
    Recommendation **[AGREED]{.underline}** **//DONE**

-   Annex C

-   Check diagram conventions (NB plan to move to UML)
    **[AGREED]{.underline}** **//DONE**

=====