+-----------------------------------+----------------------------------+
| **Ref.:** P/0010                  | ![](media/image1.p               |
|                                   | ng){width="2.9145833333333333in" |
|                                   | height="1.4229166666666666in"}   |
+-----------------------------------+----------------------------------+
| **Minutes of CCSDS Panel 2        |                                  |
| Plenary Workshop**                |                                  |
|                                   |                                  |
| **30 Oct -- 6 Nov 2000,           |                                  |
| Oxford/RAL, UK**                  |                                  |
|                                   |                                  |
| **EXECUTIVE SUMMARY**             |                                  |
|                                   |                                  |
| Significant progress was made on  |                                  |
| the Open Archival Information     |                                  |
| Systems (OAIS) Reference Model.   |                                  |
| Although the meeting occurred     |                                  |
| before the ISO review had ended   |                                  |
| nevertheless a large number of    |                                  |
| CCSDS RIDS were addressed from a  |                                  |
| number of international           |                                  |
| organisations. The more important |                                  |
| of these led to the agreement     |                                  |
| that, for clarity, the            |                                  |
| "preservation" related activities |                                  |
| should be transferred to a new    |                                  |
| functional entity labelled        |                                  |
| "Preservation Planning" in the    |                                  |
| functional model. This change     |                                  |
| will require a short second ISO   |                                  |
| review and the projected FDIS     |                                  |
| date is now September 2001. The   |                                  |
| remaining RIDS will be resolved   |                                  |
| by email and telecon.             |                                  |
|                                   |                                  |
| The number of projects in many    |                                  |
| countries which are basing work   |                                  |
| on the OAIS Reference Model is a  |                                  |
| tribute to the way in which this  |                                  |
| standard has been developed.      |                                  |
|                                   |                                  |
| The standards which will follow   |                                  |
| on from the Reference Model are   |                                  |
| being planned and a number of     |                                  |
| working groups for Information   |                                  |
| Submission, Mission Archives,    |                                  |
| Certification and Software      |                                  |
| Preservation - are being set up.  |                                  |
| In the USA and now in France,     |                                  |
| there are national efforts        |                                  |
| bringing together industry,       |                                  |
| academia and government to work   |                                  |
| in this area.                     |                                  |
|                                   |                                  |
| The review periods of two of the  |                                  |
| Data Dictionary Specification     |                                  |
| Language (DEDSL) books, one for   |                                  |
| the Abstract Syntax and one for a |                                  |
| PVL Concrete Syntax, were also    |                                  |
| near completion. A large number   |                                  |
| of RIDS were resolved; any        |                                  |
| further RIDS received by the end  |                                  |
| of the review period will be      |                                  |
| resolved by telecon and email.    |                                  |
|                                   |                                  |
| In addition, a new DEDSL concrete |                                  |
| syntax using XML/DTD has been     |                                  |
| produced and is now ready to      |                                  |
| publish as a Red Book. A further  |                                  |
| DEDSL book using XML Schema is    |                                  |
| planned.                          |                                  |
|                                   |                                  |
| The use of XML is part of a       |                                  |
| initiative to recast the ideas of |                                  |
| the Panel in Internet friendly    |                                  |
| ways, including studies of an     |                                  |
| XML-based "Internet SFDU".        |                                  |
|                                   |                                  |
| It has long been recognised that  |                                  |
| the standards must be supported   |                                  |
| by software tools. CNES have      |                                  |
| published a suite of EAST tools   |                                  |
| on a WWW server, for use on a     |                                  |
| number of platforms. It is        |                                  |
| envisaged that this will          |                                  |
| significantly increase the usage  |                                  |
| of EAST technology. In addition a |                                  |
| number of JAVA tools are being    |                                  |
| developed, including an XML DEDSL |                                  |
| parser. Furthermore the new       |                                  |
| version of the ESA free Control   |                                  |
| Authority server is now           |                                  |
| available.                        |                                  |
+-----------------------------------+----------------------------------+

+-------+-----------------+-------+------+---------------+----------+
| **    |                 |       |      |               |          |
| Subje |                 |       |      |               |          |
| ct:** |                 |       |      |               |          |
| Mi    |                 |       |      |               |          |
| nutes |                 |       |      |               |          |
| of    |                 |       |      |               |          |
| CCSDS |                 |       |      |               |          |
| Panel |                 |       |      |               |          |
| 2     |                 |       |      |               |          |
| Pl    |                 |       |      |               |          |
| enary |                 |       |      |               |          |
| Wor   |                 |       |      |               |          |
| kshop |                 |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| **Me  |                 |       | **   |               |          |
| eting |                 |       | Plac |               |          |
| Da    |                 |       | e:** |               |          |
| te:** |                 |       | RAL  |               |          |
| 30    |                 |       | /Oxf |               |          |
| Oct   |                 |       | ord, |               |          |
| -- 6  |                 |       | UK   |               |          |
| Nov   |                 |       |      |               |          |
| 2000  |                 |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| **    |                 |       | **C  |               |          |
| Prese |                 |       | opie |               |          |
| nt:** |                 |       | s:** |               |          |
|       |                 |       | T    |               |          |
|       |                 |       | hose |               |          |
|       |                 |       | Pre  |               |          |
|       |                 |       | sent |               |          |
|       |                 |       | +    |               |          |
+-------+-----------------+-------+------+---------------+----------+
| BNSC  | David Giaretta  | DG    | BNSC | Peter Allan   | PA       |
|       |                 |       |      |               |          |
|       | Wyn Cudlip^1^   | WC    |      | R Holdaway    | RH       |
|       |                 |       |      |               |          |
|       |                 |       |      | Simon         | SM       |
|       |                 |       |      | Marshall      |          |
+-------+-----------------+-------+------+---------------+----------+
| CNES  | Patrick Mazal   | PM    |      | Corina        | CB       |
|       |                 |       |      | Boer^1^       |          |
|       | Claude Huc^2^   | CH    |      |               | DM       |
|       |                 |       |      | Denis         |          |
|       | Arnaud Lucas    | AL    |      | Minguillon    |          |
|       |                 |       |      |               |          |
|       | Daniele         | DB    |      |               |          |
|       | Boucon^2^       |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| ESA   | Nestor Peccia   | NP    | ESA  | Carlo Mazza   | CM       |
|       |                 |       |      |               |          |
|       | Gian Maria      | GMP   |      |               |          |
|       | Pinna           |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| NASA  | Don Sawyer      | DS    | NASA | Jim Grimes    | JG       |
|       |                 |       |      |               |          |
|       | John Garrett    | JGG   |      | David Townley | DT       |
|       |                 |       |      | Robert        |          |
|       | Lou Reich       | LR    |      | Stephens      | RS       |
|       |                 |       |      |               |          |
|       | Alan Wood^2^    | AW    |      | Terry         | TL       |
|       |                 |       |      | Longstreth    |          |
|       |                 |       |      |               | MM       |
|       |                 |       |      | Mike Martin   |          |
|       |                 |       |      |               | JR       |
|       |                 |       |      | John Rogers   |          |
|       |                 |       |      |               | PS       |
|       |                 |       |      | Peter Shames  |          |
+-------+-----------------+-------+------+---------------+----------+
| NARA  | Bruce           | BA    |      |               |          |
|       | Ambacher^2^     |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| NASDA | Yoshio Inoue    | YI    |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| N     | Titia Van Der   | TVDW  |      |               |          |
| edlib | Werf^2^         |       |      |               |          |
|       |                 | LS    |      |               |          |
|       | Lex Sijtsma^2^  |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
| JISC  | Neil Beagie^2^  | NB    |      |               |          |
+-------+-----------------+-------+------+---------------+----------+
|       |                 |       | CAST | Katy Zhang    | KZ       |
|       |                 |       |      |               |          |
|       |                 |       |      | Xu XuDong     | XX       |
+-------+-----------------+-------+------+---------------+----------+
|       |                 |       | INPE | Eduardo       | EB       |
|       |                 |       |      | Bergamini     |          |
+-------+-----------------+-------+------+---------------+----------+
| ^1^pr |                 |       |      |               |          |
| esent |                 |       |      |               |          |
| for   |                 |       |      |               |          |
| DEDSL |                 |       |      |               |          |
| d     |                 |       |      |               |          |
| iscus |                 |       |      |               |          |
| sions |                 |       |      |               |          |
|       |                 |       |      |               |          |
| ^2^pr |                 |       |      |               |          |
| esent |                 |       |      |               |          |
| for   |                 |       |      |               |          |
| OAIS  |                 |       |      |               |          |
| d     |                 |       |      |               |          |
| iscus |                 |       |      |               |          |
| sions |                 |       |      |               |          |
+-------+-----------------+-------+------+---------------+----------+

1 Management Group Meeting (30 Oct 2000)
[4](#management-group-meeting-30-oct-2000)

1.1 Agenda Review [4](#agenda-review)

1.2 Action Item Status (Management Items)
[4](#action-item-status-management-items)

1.3 Reports from Agencies [4](#reports-from-agencies)

1.4 Panel Directions [7](#panel-directions)

1.5 Schedule for the next meeting [8](#schedule-for-the-next-meeting)

2 WP200 -- Requirements [9](#wp200-requirements)

3 WP300 - Data Administration [9](#wp300---data-administration)

3.1 Action Item Status (Data Administration Items)
[9](#action-item-status-data-administration-items)

3.2 Control Authority Procedures Update
[9](#control-authority-procedures-update)

4 WP400 -- Structures [10](#wp400-structures)

4.1 Action Item review [10](#action-item-review)

4.2 Future Plans -- Internet SFDU [10](#future-plans-internet-sfdu)

4.2.1 Requirements: [10](#requirements)

4.2.2 Example -- from VIL99 [11](#example-from-vil99)

4.3 Report on CEOS (WC) [12](#report-on-ceos-wc)

4.3.1 Interaction with Panel 2 [12](#interaction-with-panel-2)

5 WP500 -- Languages [13](#wp500-languages)

5.1 XML Concrete Syntax [13](#xml-concrete-syntax)

5.2 DEDSL Abstract Syntax RIDS Review
[15](#dedsl-abstract-syntax-rids-review)

5.2.1 CNES RIDS on DEDSL Abstract syntax
[15](#cnes-rids-on-dedsl-abstract-syntax)

5.2.2 CNES RIDS on DEDSL PVL syntax [17](#cnes-rids-on-dedsl-pvl-syntax)

5.3 PVL Green Book [19](#pvl-green-book)

5.4 EPD use of PVL [19](#epd-use-of-pvl)

5.5 Work Plan: [22](#work-plan)

5.6 DEDSL Green Book [22](#dedsl-green-book)

5.7 PVL Blue Book revision [22](#pvl-blue-book-revision)

6 WP600 - Software Implementation [23](#wp600---software-implementation)

6.1 AMS Demo Report [23](#ams-demo-report)

6.2 CEOS Report [23](#ceos-report)

6.3 EAST Activities [23](#east-activities)

6.4 NSSDC Migration and Ingest [24](#nssdc-migration-and-ingest)

6.5 SML [25](#sml)

7 WP700 -- Archiving [27](#wp700-archiving)

7.1 Work package report [27](#work-package-report)

7.2 Project/Agency Reports [27](#projectagency-reports)

7.2.1 France/CNES Claude Huc [27](#francecnes-claude-huc)

7.2.2 US/NASA Don Sawyer/Lou Reich [27](#usnasa-don-sawyerlou-reich)

7.2.3 NEDLIB Titia Van der Werf/Lex Sijtsma
[28](#nedlib-titia-van-der-werflex-sijtsma)

7.2.4 Other Reports [31](#other-reports)

7.2.4.1 UK: JISC Workbook (NB) [31](#uk-jisc-workbook-nb)

7.2.4.2 ESA report [32](#esa-report)

7.3 RID Review Overview [34](#rid-review-overview)

7.4 RID Review [35](#rid-review)

7.4.1 GENERAL COMMENTS FROM ICSTI [36](#general-comments-from-icsti)

7.4.2 EDITORIAL COMMENTS FROM ICSTI [38](#editorial-comments-from-icsti)

7.4.3 SECTION 1 [39](#section-1)

7.4.4 SECTION 2 [47](#section-2)

7.4.5 SECTION 3 [50](#section-3)

7.4.6 SECTION 4.1 [52](#section-4.1)

7.4.7 SECTION 4.2 [59](#section-4.2)

7.4.8 SECTION 5 [67](#section-5)

7.4.9 SECTION 6 [69](#section-6)

7.5 OAIS RM Workplan [70](#oais-rm-workplan)

7.6 Nedlib Presentation [70](#nedlib-presentation)

7.7 Ingest Process (DB/CNES) [71](#ingest-process-dbcnes)

7.8 Work Plan [74](#work-plan-1)

7.8.1 ARCHIVING SUBMISSION STANDARDS WP
[74](#archiving-submission-standards-wp)

7.8.2 ARCHIVE RECOMMENDED PRACTISES [75](#archive-recommended-practises)

7.9 Access/Display Preservation and Software Preservation
[75](#accessdisplay-preservation-and-software-preservation)

7.10 Mission Archives [75](#mission-archives)

7.11 Archive Certification/Checklist/Best Practice/Guidelines
[75](#archive-certificationchecklistbest-practiceguidelines)

Appendix A: WP100 Status Report [76](#appendix-a-wp100-status-report)

Appendix B: WP200 Status Report [78](#appendix-b-wp200-status-report)

Appendix C: WP300 Status Report [78](#appendix-c-wp300-status-report)

Appendix D: WP400 Status Report [78](#appendix-d-wp400-status-report)

Appendix E: WP500 Status Report [81](#appendix-e-wp500-status-report)

Appendix F: WP600 Status Report [83](#appendix-f-wp600-status-report)

Appendix G: WP700 Status Report [83](#appendix-g-wp700-status-report)

Appendix H: List of Registered Documents
[84](#appendix-h-list-of-registered-documents)

Appendix I: Open Action Item List
[88](#appendix-i-open-action-item-list)

# Management Group Meeting (30 Oct 2000)

## Agenda Review

See Appendix A for final agenda.

## Action Item Status (Management Items) 

See revised Action List in Appendix I.

9911/01: 8601 -- LR to distribute latest version: 5 digit dates but
nothing much on negative dates. 2000

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/01**   100   Distribute latest draft 8601    LR          20001115   

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

0005/04: Navigation book is being revised.

MC report:

OMG will be working closely with P3.

There are possible areas of common interest of OMG with P2. At the
moment there is no active OMG group in this area. However there is the
possibility that some vendor group will want to start work in this area.
A concern would be that this would have to work closely with P2 and not
work independently.

LR mentions a "Space Day" in Orlando in December -- but news of this has
not been distributed widely. DG will raise this with MC.

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/02**   100   Ask about "Space Day" at TSG    DG LR       20001128   
                        and MC                                                 

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

## Reports from Agencies

**BNSC**:

Budget about same as previous years

a)  GRID proposals

    a.  CCSDS P2 work could play a significant role in GRID work because
        the latter encourages multi-disciplinary work with complex data
        formats

    b.  E-science: includes some work on incorporating Data Dictionaries
        (based on DEDSL-XML)

        i.  Also may be interest in using EAST tools

DS notes that NASA GRID money is being used at AMES to support work by
Regan Moore on Preservation in collaboration with NARA. They are using
the OAIS Reference Model and making presentations about this to NASA
people. They are also working with the EO-DIS site in Maryland.

GMP: ESA work on GRID may use EAST tools. He is defining archive
requirements, and is basing this on AMS (see presentation later)

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/03**   100   Find out about GRID work at     DS          20001115   
                        AMES and EO-GRID work                                  

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

b)  JAVA work

    a.  DEDSL-PVL parser and DEDSL-XML -- NO COMPLETED APPLICATION since
        the last meeting. However it is hoped that these will be
        progressed in GRID work.

c)  Related meetings:

    a.  SpaceOps presentation prepared -- given by NP

    b.  IAF meeting attended

        **CNES**

        Budget is about level with last year and includes maintenance of
        EAST tools.

Free software server has been opened at CNES. It has EAST tools as well
as many other tools.
[http://logiciels.cnes.fr](http://logiciels.cnes.fr/) They can be
downloaded. There is also an information server related to EAST which
will be opened soon.

EAST is being adopted by an increasing number of projects into their
operational software.

Additional tools have been developed around EAST -- data checker and
EAST-shell (command interpreter for EAST).

DEDSL books have been sent and XML version has been distributed.

CH has made OAIS presentations to various groups in France. A working
group has been defined within ARISTOTE
([http://www.aristote.asso.fr](http://www.aristote.asso.fr/) ) --
interested in archive digital information, including libraries and Dept
of Justice.

CNES has started a French translation of the latest PVL BB.

**ESA**

AMS work -- see presentation. Final acceptance test soon. Includes PVL
and EAST.

Kick-Off in Jan 2001 for GSTP making use of Advanced archiving
technologies study - should use OAIS reference model.

No funding for CA developments, however most of JGG comments have been
implemented. There is a maintenance contract in place. If extra features
are identified these can be added to the maintenance schedule for
inclusion in due course.

Funding is being sought for a new study for distributing data via the
WWW using XML packaging as per W3C task group description. If approved
this work would start early next year.

Other projects are using http-XML products.

At the workshop yesterday in ESTEC questions were raised about what
comes after the OAIS reference Model. Ingestion seems to be a hot topic.

In ESA all science planetary data will be controlled by a dept which is
in close contact with JPL. They are using VOLDESC, PVL, DEDSL -- but
from 15 years ago.

ESOC is developing a generic data distribution system, as well as a
generic data cataloguing system with browsable keywords, under ROSETTA
-- note this does NOT include EO data. There will be problems trying to
get agreement between disciplines.

ESA is moving to SMALL missions for EO, rather than big ones:
Cornerstones, Flexi-missions (\$250M) e.g. Mars Express, SMART-missions
(\$50M) for technology investigations. Earth Explorer missions -- core
missions (\$250M), Earth Core opportunity missions in which ESA builds
the spacecraft and industry etc builds instrument. The funding for the
Ground segments will be limited. Some data rates will be very low (e.g.
4Kbits/sec).

**NASA**

John Kelley is taking over from David Townley.

Budget is about level, split between NSSDC and SOMO funding.

GSFC-Standards Coordination Group looks across all standards activities
at GSFC, including Data Standards. This should coordinate all GSFC
standards activity, including OMG related work. This has still to make
its mark. WWW page will be implemented.

Formats Evolution Process Committee leading involvement continues. This
is trying to increase interoperability in various formats in science,
particularly Space Science.

Two papers:

1)  Time series object paper -- paper N8.

2)  "Levels" paper -- draft presented at previous meeting. (N10?)

    Both are available from fepc site
    [Http://ssdoo.gsfc.nasa.gov/nost/fep](http://ssdoo.gsfc.nasa.gov/nost/fep)

B Brinker is installing EAST s/w and plans to do some demos. OASIS is
working. A presentation will be made at a Formats conference at GSFC
(this week or next).

OAIS:

Two US archive workshops have been held. Draft responses to RIDS have
been generated. Various presentations have been made, including "Federal
Depository Library Conference" (concerned with depositing Federal docs
to certain section of libraries)

LR presented OAIS to CODATA in Italy (during the floods).

**Report on CODATA meeting**

CODATA and ICSTI (parts of ICSU) will be doing a major joint project on
Digital Archives. Ad-hoc special interest meeting on Archives held.
Brian McMahon -- Chief Research Officer for Crystallography pubs (based
in UK) was very supportive of using OAIS RM as a basis for their work --
it will save them a great deal of effort. Leader of the project is the
head of the Southern Africa Archive.

Crystallography WWW site shows a lot of work analogous to P2 work e.g.
SFDU, PVL, DED. (see <http://www.ch.iucr.org/iucr-top/welcome.html> )

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/04**   100   Contact Brian McMahon           DG          20001128   

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

IGARS meeting -- presentation given by Larry Fishtowler (CSC)

Presentation made to Agricultural Library preservation group by DS. Don
Waters and Daniel Greenstein were present.

Several other groups are starting work with the OAIS RM as a
pre-requisite.

A forthcoming RFP of Digital Library (EO and other) will require use of
OAIS RM as an ***architecture***.

AIA (aeronautical manufacturers) have a requirement to store designs
over the long term. They are looking at the OAIS RM.

OAIS work has been nominated for CSC Technical excellence award.

The Space Physics Archive Search Engine (SPASE) project has been
proposed as a collaboration between NASA, CNES and RAL. It has been
suggested that the CIP be examined. It is now further suggested that the
OGC work be investigated because that is taking the CIP further,
removing discipline dependence, with both a stateful and stateless
approach, and including CORBA, XML, WWW etc.

**NASDA**

##  {#section .unnumbered}

## Panel Directions

It was proposed that future work on the Panel should be based on
long-term preservation/archiving, OAIS issues, to help to focus and
justify the work, and provide a unifying framework.

This will require a re-write of the Management Plan.

It will still mean working on DEDSL, EAST etc. It would still mean that
specific requests from the other Panels would be addressed. Technologies
would be developed as required, for example where holes in existing
capabilities are discovered, rather than as "research" activities.

This could also allow us to collaborate better with other bodies --
doing other parts of the overall work planned out by the Panel.

Concern was expressed about narrowing the Panel's remit too much. Also
people may not understand the need for archives.

EAST is used both for Interchange as well as Preservation in CNES.

**Summary**:

1)  Functional focus for the panel itself would be useful -- to use as a
    way of judging where we should be putting our effort. We should NOT
    change our Charter/Mission Statement.

It was agreed that this required considerable further thinking. It will
be re-addressed at the next meeting.

## Schedule for the next meeting

Spring 2001 meeting will be held at AMES in May 2001.

Fall 2001 meeting location is TBD.

# WP200 -- Requirements

At this meeting these cycle of discussions the details were distributed
through the rest of the Work Packages in order to understand some of the
implications of related developments in other parts of the Global
Information Infrastructure.

# WP300 - Data Administration

## Action Item Status (Data Administration Items) 

See action list

Report on EPA: (Metadata Registries)

Work is behind schedule. Web sites are being updated instead.

This will be continue to be monitored.

Also may be awaiting stable 11179-3.

## Control Authority Procedures Update

See doc <http://www.ssd.rl.ac.uk/ccsdsp2/oxf00/CAPUpdates.doc>

The analysis showed that changes were NOT urgently required and could
wait for the next review of CAP and CADS.

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/05**   300   Check reaffirmation of CADS            DG   20001128   

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

# WP400 -- Structures

## Action Item review

See revised table of actions

## Future Plans -- Internet SFDU

-   Need list of requirements (**[not]{.underline}** exhaustive list,
    BUT addressing some actual problems/concerns). Start with current
    SFDU capabilities. Add additional capabilities.

    -   Also list of useful technologies

+--------+---+-------------------------------+-----+---+--------+----+
| *      | 5 | Provide Technical part of SOW |     | N | 20     |    |
| *P/001 | 0 | for data distribution system  |     | P | 001231 |    |
| 0/06** | 0 | (if approved project)         |     |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+
| *      | 5 | Use Case and Requirements     |     | N | 20     |    |
| *P/001 | 0 | plus tools and technologies   |     | P | 010331 |    |
| 0/07** | 0 | for what he has to distribute |     |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+
| *      | 5 | Requirements for Internet     |     | D | 20     | Cl |
| *P/001 | 0 | SFDU                          |     | S | 001131 | os |
| 0/08** | 0 |                               |     |   |        | ed |
|        |   |                               |     | A |        |    |
|        |   |                               |     | L |        |    |
|        |   |                               |     | L |        |    |
+--------+---+-------------------------------+-----+---+--------+----+
| *      | 5 | Comment on requirements for   |     | A | 20     |    |
| *P/001 | 0 | Internet SFDU (section 4.2.1  |     | L | 001215 |    |
| 0/09** | 0 | in minutes of OXF00)          |     | L |        |    |
+--------+---+-------------------------------+-----+---+--------+----+

Identify "gaps" -- BINARY data (referenced or included), encoding,
compression

Aim produce something useful to Space Agencies, MAY be useful elsewhere

Aim at specific milestone date and reduce requirements to fit that
timescale.

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/10**   500   Produce prototype Internet SFDU        DG   20010201   
                        implementation and tool                                

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

### Requirements:

Draft Requirements for SFDU Packaging using XML Approach

DMS 2000-11-06

1\. Major current SFDU capabilities

1.1 Delimit both character and binary data objects in a single file,
each with their own collection of associated \'label information\'.

1.1.1 Allow some of the data objects to be separate files on the same
medium (i.e., spans files)

1.1.1.1 Support this on directory structured media

1.1.1.2 Support this on sequential, tape like, media

1.1.1.2.1 Where a file name is available

1.1.1.2.2 Where a file name is not available.

1.2 Label each data object with the following:

1.2.1 Version of the label

1.2.2 Identification of a description of the data object (ADID, from
CCSDS or Control Authorities)

1.2.3 Identification of the class of the data objects, where some of the
classes are identified as C, K, I, D, E, F, Z, R (may have a different
implementation in xml), and they identify leaf objects or containers

2\. Address the following needed capabilities

1.  A mechanism to contain relationship information and identify the
    data objects involved (largely clarifying those relationships which
    were implicitly defined in the SFDU blue book).

    1.  One of these relationships sets is a \'table of contents\' of
        the package, which requires the ability to point to individual
        objects at various levels of nesting within containers.

    2.  Another of these relationships is the ability to specify the
        meanings associated among data objects within the same
        container, and between/among those outside and inside of a
        container.

2.  Allow data objects anywhere on the internet to be logically included
    in the packaging e.g. using URL/URI and various X... techniques
    (Xpath, Xlink etc).

3.  A mechanism to identify that, in addition to the description of the
    data object, there are a number of uniquely identified decodings
    which should be applied in a particular sequence to reverse the
    encodings which have been applied. Example, that a data object has
    been encoded and then compressed, or that a set of objects has been
    tarred and then compressed.

    1.  Allow encodings to be combined without having to register each
        combination. This will allow encodings to be readily changed
        during processing of the package, without having to re-do
        registrations of descriptions.

    2.  Provide a mechanism to hold a description of the encodings

4.  The package should be easily usable within applications -- i.e. at
    least one well defined API/Interface should be defined.

    1.  Software Class ("P" class) -- including a Scripting Language
        (e.g. JPython)

```{=html}
<!-- -->
```
2.  Proposed for the further future

    1.  *Ability to begin to process a single XML file object BEFORE it
        is all received.*

### Example -- from VIL99

DG showed the example XML-SFDU first shown at VIL99

This used ADID's as JAVA class names which could be used to process the
"data"

Note that BINARY data and multiple steps such as compression & encoding
could be accomplished using multi-level blocks each with ADID.

Binary data could be included as say MIME encoded text.

-   Tapes must be supported.

-   Need to support relative and absolute URL/URI.

-   Need namespace definition.

Also need to look at mapping to current SFDU to show suggested usage --
i.e. SFDU on tape OK but when transferring over internet then transform
to Internet-SFDU. Long-term storage advice TBD.

File size limits may also be important, at least in the short term (
while 32 bit addressing is still around). It was noted that several
projects limit file sizes to around 2GB.

DS notes that David Holdsworth has adopted ASN.1 and does not want to
use XML; DH focuses on linking the data to multiple software packages
associated with access and display of the data.

DG notes that the "standard interfaces" would seem to bring in the
"Time-series" object work that GSFC has been working on.

## Report on CEOS (WC)

CEOS Test Environment -- included agencies PLUS end-users e.g.
University groups. Bring together all tools that are available and to
create an Information System specific to each project e.g. GOFC project.
WGISS working with GOFC over the next 5 years to set up such an
information system. Funding is from individual contributing agencies,
plus the GOFC project, in a loosely coordinated way.

Common requirement -- to know of the existence of data and be able to
access it. Therefore the first phase will probably be a "heavy-duty"
(i.e. scientifically useful) data browse facility, possibly with
sub-setting. The Test Facility will address the problems raised by this
e.g. differing data formats. Note that CIP could be used to do the
queries. OGC will also contribute e.g. visualization services.

The GOFC data is collected and held by the various agencies, and will be
made available through the GOFC portal. This portal will filter queries
etc to limit response to data of relevance to GOFC-type work.

GOFC requirements are being generated by the GOFC science team, but will
not be exhaustive. A full project schedule will be more difficult to
produce however there are milestones for demonstrations and incremental
developments in capabilities.

IGOS-P -- another organization of end-users -- will also be setting up a
Test Environment. Also Disaster Management Test Environment.

The toolkits produced by each Test Environment will be used by
subsequent systems.

The Test Environments may be transformed into fully funded services
after the 5 year development phase.

### Interaction with Panel 2

Things such as DEDSL-XML should be very useful to these Test
Environments.

# WP500 -- Languages

## XML Concrete Syntax

-   Section 1

    -   Take out reference to SFDU/LVO in Glossary.

    -   Make definitions consistent with DEDSL-PVL doc.

    -   XML & DTD -- add to Acronyms with correct definitions
        (exten**[sible]{.underline}** Markup language)

    -   Update References and correct numbers in text. Remove
        unnecessary references

    -   Add XML references

-   Section 2:

    -   Add text "XML is designed to...." -- as done in DEDSL-PVL book
        (check if any RIDS change this wrt conformance which does not
        include the material in this section)

    -   Table 1 -- add NOTES which are referenced. The "DEDSL Type"
        column of table 2-1 from DEDSL-PVL should be the same as the
        "DEDSL Type" column here. Show the DTD constructs used "\*" and
        "+".

    -   2.2.2 -- use DICTIONARY_IDENTIFICATION (rather than
        DICTIONARY_DESCRIPTION) to be consistent with DEDSL-PVL.

    -   Add note about use of CDATA -- to allow users to put in special
        characters in tags.

    -   \*\*\* Check the implications of the NMTOKEN restriction in
        Identifier \*\*\* - review the PVL and XML character
        restrictions.

-   Section 3:

    -   Add introductory material -- see DEDSL-PVL book

    -   Remove "+" from DICTIONARY_LANGUAGE in DTD since DEDSL allows
        only 1 primary language now.

    -   Add note that TEXT_FIELD_CHARACTER_SET does not show up as TAG
        explicitly and refer to section 3.4

    -   CASE_SENSITIVITY -- it is mandatory but we wanted this to be
        allowed to be defaulted if omitted. Check usage of defaulted
        element where it does not appear (cf EMPTY ELEMENT TAG).

        -   OR

        -   Delete (DICTIONARY\_)CASE_SENSITITY and instead make it an
            attribute of DICTIONARY_DESCRIPTION and put in default
            properly and show minimum appearance.
            \*\*\***[AGREED]{.underline}**

    -   3.3 -- add rule that this is mandatory if an external dictionary
        is referenced

    -   3.6: quotes around "fr" rather than "\>\>"

    -   3.9 -- DEDSL_VERSION -- make consistent with DEDSL-PVL -- should
        be full CCSDS document number

    -   3.10: needs more explanation on usage

        -   need section for Data_Entity_User_Defined_Attributes at end
            of section 5 also

        -   add sentence that we need definition of this attribute

        -   Put User Defined Attribute in the Example.

-   Section 4:

    -   4.4: ATTRIBUTE_MAXIMUM_OCCURRENCE - how is 'n' treated --
        unclear what the comment is

    -   4.9: ATTRIBUTE_ENUMERATION_VALUES should be changed to
        ATTRIBUTE_ENUMERATION_VALUE since each occurrence has one value.

    -   4.0 table -- add note about the decision not to have a Tag
        called ATTRIBUTE_VALUE_TYPE -- instead have tags for each data
        type such as ATTRIBUTE_INTEGER_TYPE etc.

    -   Change MAX_SIZE to ATTRIBUTE_MAXIMUM_SIZE in
        ATTRIBUTE_IDENTIFIER_TYPE and ATTRIBUTE_TEXT_TYPE

-   Section 5:

    -   In table of categories add new Category called EXTENSION for
        user defined attributes.

    -   Change KEYWORDS to KEYWORD since each occurrence has one value

    -   COMPOSITE_TYPE could inherit component from MODEL and hence need
        not have anything explicit

        -   Delete COMPONENT attribute and COMPOSITE TYPE should be
            added to Representational section. The element
            COMPOSITE_TYPE contains zero or more COMPONENT elements
            which have optional attributes of MIN and MAX (check -- may
            it should be MAXIMUM_OCCURRENCE)

    -   5.4.4.2 -- RELATION_WITH should be RELATION

    -   Change REAL_REFERENCE to REAL_CONSTANT_VALUE etc

    -   5.6.1: ENUMERATION_VALUE should have #REQUIRED rather than
        #IMPLIED

    -   5.4.4: see "XXX" -- change "FROM_DICTIONARY" to
        "EXTERNAL_DICTIONARY"

-   Section 6:

    -   State that the DTD is the ruling specification for the syntax.
        The Abstract DEDSL book provides the semantics

    -   \*\*\* Conformance -- should include section 2 (Check DEDSL-PVL
        also)

-   ANNEX A

    -   Change this to a proper Section so that it is part of the
        Standard.

    -   Put additional comments in the DTD -- especially additional
        constraints captured in various Notes

```{=html}
<!-- -->
```
-   Suggestion -- switch sections 4 and 5 to be consistent with
    DEDSL-PVL. **[AGREED]{.underline}**

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

Need Book by MC (28 Nov).

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/11**   500   New issue of DEDSL-XML book     AL          20001108   

  **P/0010/12**   500   Email comments on DEDSL-XML to  ALL         20001115   
                        AL                                                     

  **P/0010/13**   500   Telecon on DEDSL-XML            ALL         20001116   

  **P/0010/14**   500   New issue of DEDSL-XML book     AL          20001122   

  **P/0010/15**   500   Email comments/approval         ALL         20001124   

  **P/0010/16**   500   Final version on DEDSL-XML      AL          20001127   
  --------------- ----- ------------------------------- ------ ---- ---------- -----

## DEDSL Abstract Syntax RIDS Review

CNES RIDS -- 3 reviewers including one who had seen previous version.

Comment: needed examples earlier and the ones that were there were too
simple or too abstract or incomplete.

It was noted that the reverse of these comments had been encountered
previously and the examples had then been moved to the Annex.

### CNES RIDS on DEDSL Abstract syntax

Review of the DEDSL Red Books (CCSDS 647.1-R-2 and CCSDS 647.2-R-1) at
CNES

Generally, the reviewers found the books clear and comprehensible. They
thought the reader should have access to concrete examples earlier
without having to wait for the annexes where they can be found. The
examples given in the body of the specification were sometimes too
simple and the reviewers would advise giving more references to the
annexes through the documents.

They often referred to the tables 3-1, 4-1 and 4-2 throughout the
reading, which appeared fundamental to them.

The following RIDs have been classified according to the proposed
classification (T for technical fact, R for recommended, E for
Editorial). There is no priority attached to the order of these RIDs.

**ABSTRACT SYNTAX :**

> *RID 1-T : section 3.8 (ATTRIBUTE_VALUE_TYPE) second paragraph of
> Descriptor Type*
>
> *State more explicitly that in the case of Entity_Type value, the
> attribute value is replaced by one of the other possible values
> between Enumerated and Identifier.*

Incorrect -- note that data_type of an entity cannot be Identifier. Add
note to Entity_Type to say that the Data_Type of an entity may be
Enumerated, Integer, Real, Text or Composite.

Change "can be" to "may be"

*RID 2-R : section 3.8 (Attribute_VALUE_TYPE) on the examples*

> *The examples 3-1 to 3-5 are too abstract on their own, there should
> be references to more concrete examples given under section 4.4.
> Furthermore, there should be a warning at the beginning of this
> section stating that forward references will necessarily be made in
> that section.*

It is recognised that the items labelled as "examples" are really
illustrations and were not meant to be full examples.

Replace "attribute" with "descriptor" in the examples since e.g. the
attribute_value_type is a Descriptor.

Add note that these constructs are used in Section 4.4 i.e. avoid full
forward reference but give people some reassurance that the constructs
are used further on.

> *RID 3-R : section 4.4.2.4 (Attribute UNITS)*
>
> *A standard indicator could be used to give the dictionary user an
> indication that all the units in this dictionary are pure SI ones
> without prefix representations.*

**[REJECTED]{.underline}**. It is possible to be a User defined
attribute for this.

> *RID 4-R : section 4.1.9 (relational attributes introduction)*
>
> *This section appeared as being not at the same level of abstraction
> as the previous ones. This section seems to be redundant with the
> following descriptions of each of the corresponding attributes.
> Moreover, section 4.6 gives much more information on the different
> relationships. Section 4.1.9 could be reduced to only a reference to
> the section 4.6 which is considered useful anyway, probably best kept
> where it is.*

**[AGREE]{.underline}** -- delete 4.1.9

> *RID 5-R : section 4.4.2.5 (Attribute specific_instance) under
> attribute_comment*
>
> *The example given is too specific of a particular use. It is
> confusing for the general purpose of this descriptor.*

Keep only the 1^st^ sentence of ATTRIBUTE_COMMENT. Also change
"...Entity_type DEGREE..." to "...DEGREE with the ENTITY_Type of REAL.."

*RID 6-R : section 4.4.3.2 (Attribute component) under
attribute_value_type*

> *The notation a..b is not previously defined in the recommendation as
> the other notations. On the other hand, it is used only in this
> section. Should we specify it earlier ?*

Suggestion: add definition of this notation to section 3.8. NOT AGREED

\*\*\*Proposal needed \*\*\*\*

*RID 7-R : section 4.4.3.4 (Attribute relation) under
Attribute_value_example*

> *The example given does not seem appropriate with respect to the names
> chosen as identifiers.*

\*\*\* CNES to propose a better example -- will be used in all 3 books.

*RID 8-R : section 4.6.2.2*

> *The sentence was not clear to the reviewers. We should expand more on
> the reasons and explain the use of « may » in the sentence.*

Remove the words "but the order...." to the end of the sentence to avoid
this confusion.

*RID 9-E : figure 2-4*

> *Replace in the figure « DED associated with product_X » with
> « Product_X DED » which is used in the rest of the section.*
>
> *Same for « DED associated with product_Y ».*

AGREE

*RID 10-E : from page 3-10*

> *From this page onwards a number of keywords do not follow the
> convention 2 given in section 1.5.4 about the keywords or major
> concepts (which should be bold).*

AGREE -- check

*RID 11-E : section 4.4.4.6 (attribute language) under
attribute_maximum_size*

> *The size should be List(40,3).*

AGREE

*RID 12-E : page A-7 and A-10*

> *Change the short definition for LONGITUDE which is not adequate.*

Delete the SHORT DEFINITION

*RID 13-E : page A-10*

> *Update the RELATION value for W_IMAGE_SIZE : ...spacecraft W2 image
> ...*

AGREE

*RID 14-E : page B-3*

> *The attributes case_sensitivity and language which appear at the
> bottom of the page have already been listed before. The last ones
> should be suppressed.*

AGREED

*RID 15-E : whole document*

> *Insert a white space before and after every colon character (:)*

REJECTED

### CNES RIDS on DEDSL PVL syntax

**PVL SYNTAX :**

*RID 1-R : section 4.1.2 example 4-1*

> *The example is too simple. It should include several groups.*

AGREE -- can add definitions for YEAR, MONTH and DAY to completeness.

*RID 2-R : section 4.2 table 4-1*

> *A number of attributes are missing, specially the ones which cannot
> be declared outside of a block.*
>
> *It is the case for TEXT_SIZE_MIN, OCCURRENCE_MIN and OCCURRENCE_MAX.*

This is true -- add sentence explaining that there are additional
attributes defined for use within the blocks, and associated rules.

*RID 3-R : section 4.5.10.3*

> *ENUMERATION_VALUE gives the value of an enumerated item, while
> ENUMERATION_VALUES in the abstract syntax gives the list of the values
> for the different enumerated items. This should be stated somewhere
> possibly in a Tutorial.*

Add sentence in section2 to explain that several attributes in the
Abstract spec giving lists and named as the plural are represented in
the PVL syntax as separate entries each of one in named as singular.

> *RID 4-R : section 5.8 (Attribute_value_type)*
>
> *PVL_sequence and PVL_set are introduced for the first time here. They
> could be defined in the glossary with a reference to the PVL
> specification.*

PROPOSAL: Change PVL_set to PVL Set and PVL_sequence to PVL Sequence to
be consistent with section 2.1. Could ALSO put definitions in the
Glossary.

CNES to clarify the RID.

*RID 5-R : Annex B*

> *Recall at the beginning of this annex that all the following examples
> are the ones used in the Abstract Syntax Book.*

AGREED -- also consider doing the same in the XML book.

*RID 6-E : page 1-1*

> *Last line. Correct « ...formats ;the exchange.. » by inserting a
> white space after the « ; »*

AGREED

> *RID 7-E : section 4.4.5 (specific_instance)*
>
> *Correct boiling point of H2O.*

AGREED

*RID 8-E : section 7 in the list of Data Entity attribute names*

> *CONSTANT_VALUE is misplaced.*

AGREED

> *RID 9-E : Annex A2 :*
>
> *A blank line has to be suppressed.*

AGREED

*RID 10-E : whole document*

> *ENUMERATION_CODING and ENUMERATION_CONVENTION are used for the same
> concept.*

AGREED

*RID 11-E : Annexes A2 and A3*

> *In the enumeration groups, shift the group values to the right for
> more clarity.*

AGREED

*RID 12-E : Annex B1*

> *The order of the attributes in the DICTIONARY_ENTITY_DEFINITION group
> should be the same as in the corresponding example of the abstract
> syntax book.*

AGREED

*RID 13-E : pages B-5 and B-8*

> *The value given to SHORT_DEFINITION for LONGITUDE should be modified
> as already notified for the abstract syntax book.*

AGREED

> *RID 14-E : page B-8 under W_IMAGE_SIZE, DATA_2 and DATA_2_PIXEL
> entity definitions*
>
> *W should be W2 (5 times).*
>
> *DATA_W should be DATA_2. W should be W2 (2 times).*

AGREED

*RID 15-E : page B-9*

> *Correct DATA_1_PIXEL to DATA_2_PIXEL.*

AGREED

*RID 16-E : pages B-5, B-6 and B-9*

> *KEYWORDS should be KEYWORD.*

AGREED

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/17**   500   Request MC to hold email ballot DG          20001128   
                        for DEDSL to be published as BB                        

  **P/0010/18**   500   Send out proposals for RID      PM          20010115   
                        resolution                                             

  **P/0010/19**   500   Telecon to resolve DEDSL RIDS   ALL         20010123   

  **P/0010/20**   500   New version of DEDSL Abstract   PM          20010210   
                        and DEDSL-PVL                                          

  **P/0010/21**   500   Review final draft DEDSL        ALL         20010315   
                        Abstract and DEDSL-PVL                                 

  **P/0010/22**   500   Request email ballot for DEDSL  DG          20010322   
                        Abstract and DEDSL-PVL                                 
  --------------- ----- ------------------------------- ------ ---- ---------- -----

## PVL Green Book

See document XXXX

PVL Blue Book has been changed. The new issue of the PVL Green Book
reflects these changes, for example extended character set. Some
additional examples have been given.

GMP: Add reference to DEDSL -- although at the current time the DEDSL is
a Red Book so add reference to RB and as normal say that latest version,
RB or BB, should be used. **[AGREED]{.underline}**

## EPD use of PVL

GMP example of EPD demo file:

BEGIN_GROUP = EPD_DESCRIPTION;

EPD_NAME = \"LANDSAT_TM_RETRIEVAL\";

OBJECTIVES = \"Extraction of all the blocks from a directory data
product corresponding to an extraction criterion (number of seconds for
example). The image and descriptor files are in the same product
directory. We extract all records which verified date=PARAM1 from
\*.IMA\";

END_GROUP = EPD_DESCRIPTION;

BEGIN_GROUP = CRITERIA_DESCRIPTION;

PARAM1 = \"TIME1\";

PARAM2 = \"TIME2\";

END_GROUP = CRITERIA_DESCRIPTION;

BEGIN_GROUP = KEYS_DEFINITION;

RULENAME = \"DEMO_TM\";

FILENAME = \"Product_path\";

END_GROUP = KEYS_DEFINITION;

BEGIN_GROUP = VARIABLES_EXTRACTION;

FILENAME = \"Product_path/HEADER.DAT\";

APD_FILENAME = \"\$SVA_APD_FILE_SPACE/user_header.eas\";

BEGIN_GROUP = PARAMETER_EXTRACTION_DEFINITION;

PARAMETER_NAME = \"SWATH_SIZE\";

PARAMETER_PATH = \"POINTERS_TO_TAPE_DATA.SWATH_SIZE\";

PARAMETER_TYPE = \"INTEGER\";

END_GROUP = PARAMETER_EXTRACTION_DEFINITION;

BEGIN_GROUP = PARAMETER_EXTRACTION_DEFINITION;

PARAMETER_NAME = \"SWATH_PER_BLOCK\";

PARAMETER_PATH = \"POINTERS_TO_TAPE_DATA.SWATH_PER_BLOCK\";

PARAMETER_TYPE = \"INTEGER\";

END_GROUP = PARAMETER_EXTRACTION_DEFINITION;

END_GROUP = VARIABLES_EXTRACTION;

BEGIN_GROUP = VARIABLES_EXTRACTION;

FILENAME = \"Product_path/BAD.DAT\";

APD_FILENAME = \"\$SVA_APD_FILE_SPACE/block_adr_descriptor.eas\";

BEGIN_GROUP = PARAMETER_CONDITIONAL_EXTRACTION_DEFINITION;

PARAMETER_NAME = \"BLOCK_NUMBER_BEGIN\";

PARAMETER_PATH = \"VIDEO_START_ADDR\";

PARAMETER_TYPE = \"INTEGER\";

CONDITION = \"(SATELLITE_TIME \< PARAM1)\";

CONDITION_PARAMETER_TYPE = \"TIME_IN_MILLISECOND\";

END_GROUP = PARAMETER_CONDITIONAL_EXTRACTION_DEFINITION;

BEGIN_GROUP = PARAMETER_CONDITIONAL_EXTRACTION_DEFINITION;

PARAMETER_NAME = \"BLOCK_NUMBER_END\";

PARAMETER_PATH = \"VIDEO_START_ADDR\";

PARAMETER_TYPE = \"INTEGER\";

CONDITION = \"(SATELLITE_TIME == PARAM2)\";

CONDITION_PARAMETER_TYPE = \"TIME_IN_MILLISECOND\";

END_GROUP = PARAMETER_CONDITIONAL_EXTRACTION_DEFINITION;

END_GROUP = VARIABLES_EXTRACTION;

BEGIN_GROUP = VARIABLES_COMPUTATION;

PARAMETER_NAME = \"BLOCK_LENGTH\";

PARAMETER_VALUE = \"(SWATH_PER_BLOCK \* SWATH_SIZE)\";

PARAMETER_TYPE = \"INTEGER\";

END_GROUP = VARIABLES_COMPUTATION;

BEGIN_GROUP = VARIABLES_COMPUTATION;

PARAMETER_NAME = \"START_BYTE\";

PARAMETER_VALUE =\"(BLOCK_NUMBER_BEGIN \* BLOCK_LENGTH)\";

PARAMETER_TYPE = \"LONG\";

END_GROUP = VARIABLES_COMPUTATION;

BEGIN_GROUP = VARIABLES_COMPUTATION;

PARAMETER_NAME = \"NB_BLOCKS\";

PARAMETER_VALUE =\"(BLOCK_NUMBER_END - BLOCK_NUMBER_BEGIN)\";

PARAMETER_TYPE = \"INTEGER\";

END_GROUP = VARIABLES_COMPUTATION;

BEGIN_GROUP = VARIABLES_COMPUTATION;

PARAMETER_NAME = \"SIZE_BLOCKS\";

PARAMETER_VALUE =\"(NB_BLOCKS \* BLOCK_LENGTH)\";

PARAMETER_TYPE = \"INTEGER\";

END_GROUP = VARIABLES_COMPUTATION;

BEGIN_GROUP = VARIABLES_COMPUTATION;

PARAMETER_NAME = \"STOP_BYTE\";

PARAMETER_VALUE =\"(START_BYTE + SIZE_BLOCKS)\";

PARAMETER_TYPE = \"LONG\";

END_GROUP = VARIABLES_COMPUTATION;

BEGIN_GROUP = RECORDS_EXTRACTION;

COMMENTS= \"This statements group allows to extract records from a set
of blocks located in a file. These blocks are repetition of records. All
blocks will be analyse on a record by record basis.\";

FILENAME = \"Product_path/IMAGE.DAT\";

START_ADDRESS = \"START_BYTE\";

STOP_ADDRESS = \"STOP_BYTE\";

APD_FILENAME = \"\$SVA_APD_FILE_SPACE/sensor_TM_data.eas\";

BLOCK_DUMPING = \"FALSE\";

LENGTH = \"BLOCK_LENGTH\";

CONDITION = \"(LANDSAT_TM_MAJOR_FRAME.SATELLITE_AUXILIARY_DATA.DATE \>
PARAM1) AND (LANDSAT_TM_MAJOR_FRAME.SATELLITE_AUXILIARY_DATA.DATE \<
PARAM2)\";

CONDITION_PARAMETER_TYPE = \"TIME_LANDSAT\";

OUTPUT_FILE = \"\[7\]\_\[8\]\_EXTRACT.DAT\";

END_GROUP = RECORDS_EXTRACTION;

The PVL parser that the EPD contractor has supplied is fairly basic. An
"external" function allows one to spawn extra processes to perform
additional calculations. The EAST interpreter is used to extract values
from the data file. EAST could not be used by itself since it can handle
only a single file at a time, whereas multiple files have to be accessed
at one time here. (see VIL99 presentation XXXX)

List of the possible identified keywords:

BEGIN_GROUP, END_GROUP, VARIABLES_EXTRACTION, COMMENTS,
INPUT_FILE_NUMBER, EPD_DESCRIPTION, EPD_NAME, OBJECTIVES,
INPUT_PARAMETERS_DESCRIPTION, PARAMETERS_FILE_PATH,
INPUT_FILES_WITH_EAST_DESCRIPTION, INPUT_FILES_WITHOUT_EAST_DESCRIPTION,
OUTPUT_FILES, INPUT_PARAMETERS, PARAMETER_EXTRACTION_DEFINITION,
PARAMETER_NAME, PARAMETER_PATH, PARAMETER_TYPE,
PARAMETER_CONDITIONAL_EXTRACTION_DEFINITION, CONDITION,
VARIABLE_COMPUTATION, INTEGER, REAL, PARAMETER_VALUE, RESULT_LOCATION,
TEMPORARY_MEMORY_AREA, STOP_ADDRESS, START_ADDRESS, MEMORY,
BLOCK_LOCATION, CONDITION_PARAMETER_TYPE, OUTPUT_FILE_NUMBER,
FIELD_NAME, RECORDS_EXTRACTION.

List of identified operators:

"==", "=" , ";", "\<", "\>", "\<=", "\>=" , "+", "-", "\*", "/", "(",
")", "."

## Work Plan:

## DEDSL Green Book

  --------------- ----- ------------------------------- ------ ---- ---------- -----------
  **P/0010/23**   500   Produce DEDSL Green Book        PM AL       20010401   To be
                                                                               confirmed

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

## PVL Blue Book revision

# WP600 - Software Implementation

## AMS Demo Report 

Software, apart from the JAVA client, has been received but not fully
tested.

The demo involves subsetting a 6Gb file. EAST and PVL are used.

An optimising step allowing one to avoid reading all the blocks of the
data -- and instead use an index into the start times of each block.
However there are constant improvements in the EAST interpreter and also
in the hardware.

The approach used gives a great deal of flexibility and a good
performance.

There was discussion about the advantages of specific scientific formats
such as HDF. HDF can make easy use of fancy indices and other
optimisations. Using the EAST interpreter would be slower but the
bottleneck may in fact be in getting data from the tapes. Publishing new
data formats simply requires providing the EAST description and the
appropriate PVL file.

The format can be a multi-file format i.e. various parts of the format
are held in separate files. EAST can describe only one file at a time so
the PVL has declarations of each file plus the EAST name of the element
needed.

The system is still under development.

## CEOS Report

## EAST Activities

Presentation:

**Free Software Server**

-   General free software

-   OASIS & EAST Tools Available to download

-   URL : http://logiciels.cnes.fr

DEMO

**EAST Webserver**

-   EAST/OASIS general description

-   Links to the CNES Free Software Server for downloading

-   On-line documentation

-   FAQ

-   EAST/OASIS users ' forum

-   URL : Available soon ...

DEMO

**EAST Tools**

-   Performances improvement - v2.7

    -   new API functions

        -   sequence recording for Interpreter

        -   sequence recording for Generator in v2.8

    -   code improvement

-   Generator new feature

    -   Automatic generation of the constant fields

-   OASIS new features

    -   Automatic generation of the Ada declaration part

    -   NT version ... soon !!!

        **NEW EAST TOOLS**

-   DATA \_CHECKER

    -   Data error checking tool

    -   Test if data are compliant with the EAST description (type,
        range, structure)

    -   For Solaris, NT, Linux ...

    -   Available with v2.8 distribution

-   the EAST SHELL

    -   Command interpreter

    -   Direct call of the EAST API functions

    -   Easy to use, no programmation

    -   For Solaris, NT, Linux ...

    -   Available with v2.8 distribution

        **EAST ACTIVITIES**

-   EAST WORKSHOP

    -   30 th November

-   EAST use in projects

    -   HELIOS mission center will use East technologies

    -   SSALTO delivers East based software to the JPL

    -   GERALD generic EAST description from SPOT 1 to 5

    -   CDPP : DEDSL-HTML version of the products available on-line

-   EAST Tools now available for :

    -   Solaris, HP-UX, NT(\*), Linux, OpenVMS, OSF/1\
        (\*) : server version not available (full Ada only)

        **DED2XML - VIEW**

```{=html}
<!-- -->
```
-   New tool bound with ded2xml for the presentation of XML-DEDSL files

-   Creation of a specific view of the dictionary

-   Implemented by a new xml tree where each node is meaningful for the
    final user

-   The documentation is then produced by processing the view tree

The CNES free software server is available.

[http://logiciels.cnes.fr](http://logiciels.cnes.fr/)

OASIS on limited platforms

EAST tools: available on many platforms -- no problems with different
versions of UNIX.

[http://east.cnes.fr](http://east.cnes.fr/)

Comments about the Web pages are welcome, including suggestions for
additional information needed.

There is a discussion forum in the French version and one will be added
in the English version of the WWW pages soon.

The EAST tools have been improved. In particular there are several
performance enhancements e.g. using sequence recording for the
interpreter to allow reuse of the parsing -- use depends upon the
structure of the data i.e. no discriminant data. A sequence recording
feature will be available for the Generator in v2.8.

OASIS also has new features: there is automatic generation of the Ada
declaration part, so it can be used directly in an Ada programme using
the EAST API. It is planned also to generate C header files -- perhaps
next year. The NT version of OASIS will be available at the end of
November. This will greatly increase the client base i.e. lots of people
have NT on their desktop.

New EAST tools for data verification and also EAST shell which allows
direct calls to the EAST API functions. This also runs on NT.

EAST has also been used in a delivery to JPL, although the EAST is
hidden from the user. OpenVMS is the operating system.

There will be an EAST workshop on Nov 30^th^ -- in French.

A new tool, DED2XML, produces a DEDSL-XML file from the EAST-DED.

## NSSDC Migration and Ingest

NSSDC is migrating data from VMS to UNIX, as described at the last
meeting.

The work has now started.

Data is also coming in from IMAGE. That project is producing SFDU's with
attribute objects and sending these to NSSDC. These AIP's all have
unique logical Archival ID, which is stored in the archive database. The
first 4 characters are unique to the project c.f. ADID, plus 10 digits.
The Attribute Object uses PVL.

Data descriptions are incomplete. There are other problems e.g. the
IMAGE files are TAR files which each contain other files.

## SML

<http://www.interfacecontrol.com/sml/>

<http://www.oasis-open.org/cover/spacecraftML.html>

DS presentation: XXXXX

Initial Response

-   Basic approach of XML based message moving among processing systems

    -   Believe it has merit for moving data from ground stations
        through processing and eventually to final archives

-   Detailed approach to inheritance, etc.

    -   Needs review by all of P2

    -   What about xml schema?:

    -   What about xml DEDSL?

    -   What about xml SFDU packaging?

-   Standardization effort?

    -   Needs P3 as well as P2

    -   CCSDS would need to make changes in SML

Issues:

-   What is the intent about completing short-term and long-term
    archival levels of SML? Is it appropriate that CCSDS P2 pick up
    these issues?

    -   Higher level data products are very different and are therefore
        increasingly difficult to standardise under SML

-   **How is binary data treated?**

-   How is merging streams to produce new products handled?

-   What is the role of XML in the end-to-end CCSDS view?

    -   View SML document as a Concept Paper (more aimed at P3 at the
        moment -- other layers are pretty well undefined).

    -   Needs to be evaluated by the TSG for end-to-end view.

        **[CCSDS would need to make changes in SML]{.underline}**

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/24**   700   Advise MC/TSG that SML needs to DG          20001128   
                        be reviewed by all Panels                              
                        because it addresses end-to-end                        
                        issues. CSOC connection also                           
                        relevant.                                              

  **P/0010/25**   700   Propose TSG workshop including  DG          20001128   
                        SML and CSOC attendance "XML in                        
                        Space" with response from each                         
                        Panel on XML plans                                     
  --------------- ----- ------------------------------- ------ ---- ---------- -----

# WP700 -- Archiving

## Work package report

See Appendix F

## Project/Agency Reports

### France/CNES Claude Huc

See presentation

<http://www.ssd.rl.ac.uk/ccsdsp2/Oxf00/cnes_activites_oais_oct_2000-gb.ppt>

and report

[http://www.ssd.rl.ac.uk/ccsdsp2/Oxf00/Report%20on%20the%20OAIS%20meetings%20held%20in%20France.doc](http://www.ssd.rl.ac.uk/ccsdsp2/Oxf00/Report on the OAIS meetings held in France.doc)

### US/NASA Don Sawyer/Lou Reich

DMS:

2 workshops in the USA

17^th^ Workshop: RIDS were addressed. Preservation Function was a key
issue.

18^th^ Workshop: positions were generated for most of the RIDS received.
A revised section 4.1 was sent out

In addition the CENDI meeting was attended. The OAIS RM was presented by
DMS. They are considering whether they will take the RM and extend it
for their specific needs.

Nat Agricultural Library is also considering the OAIS RM.

LR gave presentation to CODATA (Committee on Data for Science and
Technology) -- see later in minutes. Also an associate gave a
presentation at IGARS.

Federal Deposit Library Conference -- presentation. Mostly librarians.

LR:

CODATA is about to start an archiving project. This was to be based on a
paper by NRC, with large literature survey. However they will now be
looking at OAIS RM.

We are receiving much more frequently queries on the RM. It is clear
that is a very high interesting area.

AW: Life Sciences Archive

Continued and increasing level of interest. Proprietary formats are a
concern. Preparations are in hand for International Space Station -- it
is hoped that the OAIS-RM will be used as a basis.

BA: NARA

2 significant events:

-   The 2000 census has been completed -- Congress has ordered that 750
    million scanned images must be preserved (to capture notes to
    grandchildren)(250M to 500M may be blank). The proposal is to store
    these as film, planning to rescan these later, using OAIS as a basis
    -- saving significant amounts of money.

-   A great deal of R&D effort is being obtained from San Diego Super
    computer center with ARPA -- looking at long-term preservation of
    information. Connection to GRID effort in US.

-   Prototype in 2005, production system 18 months later.

-   Requirement 2 million files a year.

### NEDLIB Titia Van der Werf/Lex Sijtsma

General

Adoption of OAIS

Scoping

Integration

Extending OAIS with preservation

Liaison with Jeff Rottenberg

Work with BnF on metadata for preservation

-   First Problem was the terminology.

```{=html}
<!-- -->
```
-   Publishers increasingly producing digital publications, rather than
    for example scanning in paper documents.

-   It was decided that NEDLIB would be for data that was originally
    digital.

    -   Paper documents are retrievable through the catalogue system

        -   Scanning paper documents are regarded in the same way as an
            electronic publication, but preservation is less of an issue
            because of availability of paper original.

-   The original system design (1998) had Capture, Storage and Access

-   The OAIS-RM was then adopted. Functions then were INGEST, Data
    management, Storage, Access and Admin.

-   OAIS was found to be very broad. For example Finding Aids were a
    familiar type of tool. They had searchable catalogues, registration
    of users.

-   It was therefore decided to scope the NEDLIB design on Storage, with
    parts of the other functional areas.

-   The distributed deposit archives use the same cataloguing formats
    (based on MARC) -- but search protocols are different and hence
    there are interoperability problems, hence they are looking at
    Z39.50.

    -   Publishers use a variety of formats. Recent study shows that the
        majority are proprietary formats. However there is an increasing
        amount of PDF and WWW/HTML.

-   The new Deposit System for Electronic Publications (DSEP) needs to
    be integrated into the existing infrastructure.

    -   New interfacing modules:

        -   Capture and Delivery (to Ingest)

        -   Packaging and Delivery (to Access)

    -   These allow the DSEP to be as generic as possible (and future
        proof). The national variations e.g. legal restrictions,
        publishers and publisher formats, are captured in the interface
        modules.

        -   Capture and Delivery produces a standard SIP

        -   Packaging and Delivery accepts the DIP from Access and
            tailors the output to users' local requirements.

-   NEDLIB found insufficient hooks in the OAIS-RM for preservation. As
    an *aide-memoire* an additional Preservation functional box was
    added, even though initially it was not clear what it would contain.

    -   Literature search showed a number of approaches

    -   Agreement on the Preservation Requirements was not reached.

        -   Pragmatic approach was adopted -- allowing various
            implementations

        -   It was recognized that User demands would change and become
            more demanding

    -   Jeff Rothenberg approach (Sci Am 1995, also video "Into the
        Future") using EMULATION was examined in detail. (See report
        <http://www.kb.nl/coop/nedlib/results/emulationpreservationreport.pdf>
        )

        -   A Testbed was set up: Publication runs on software which
            runs on some h/w configuration. The h/w will change in the
            future. Therefore an emulation of the hardware will be
            necessary, specified using some Emulator Specification
            Language plus an Interpreter.

            -   Some reference platform is chosen for, say, the next 5
                years (e.g. PC).

            -   The Emulator runs on a Virtual Machine (EVM), which
                itself has a cycle of Emulation Spec, Interpreter etc in
                a recursive loop -- which terminates on whatever happens
                to be the Reference Platform.

        -   Rothenberg has integrated this view into the OAIS. The
            rendering software is preserved in AIP's, as well as the
            emulation software.

            -   NP notes that ESA/ESOC are adopting emulation for
                spacecraft support -- it is difficult to find
                experienced emulation s/w engineers.

            -   DS notes that David Holdsworth is also looking at this
                type of approach.

        -   The emulation testbed does not have funding after this year.
            However further work is in fact needed to continue this into
            the future.

            -   DG suggests using a commercially supported Virtual
                machine system such as JAVA. Implementing the emulation
                in JAVA would then be future-proof as long as JAVA is
                available. Also the JAVA VM is well defined.

        -   BA asks to what extent the archives can dictate the format
            that they will receive the data in. The answer was that you
            cannot dictate e-publishing formats but that you can agree
            on standard packaging formats for submitting e-publications
            plus accompanying metadata/software.

-   The NEDLIB view about metadata is that they already do a great deal
    of cataloging. There is therefore some resistance to adding yet more
    metadata fields. In addition much of the metadata already captured
    is only human readable.

    -   The minimum sensible metadata should be collected. Things like
        PDI -- context and provenance -- should be kept to a minimum and
        fits best in the cataloguing system.

    -   Technical metadata should be encoded in such a way that the
        archival system can act upon it (metadata-driven system)

    -   See Biblioteque National de France (BNF) report on metadata on
        NEDLIB WWW-site.

> Layered model based on OAIS annex (items that they proposed to record
> are in ***bold***)

  ----------------------------------- -----------------------------------
  ***APPLICATION***                   

  ***Object Format***                 Subroutine lib

  Primary data Types                  ***Interpreter/compiler***

  Filesystem                          ***Operating system***

  Physical storage                    ***Hardware Device***
  ----------------------------------- -----------------------------------

-   NEDLIB funding finishes in December. TvdW is keen to continue the
    work on an international basis.

    -   15 Dec workshop

        LS: Report on Project

Collect published and digitized material. They have a system to hold
journals from 2 main publishers; this was built as a pilot system and
lacks several facilities e.g. backup. This has caused some problems.

The increase of electronic documents meant that they needed a larger
system. The OAIS model assisted in defining the requirements for the
system which was used in an RFI.

Commercial companies offered solutions apart from Emulation. Based on
the responses of the RFI an RFP was created. The OAIS-model was used to
structure the functional requirement. Per main functional entity a
number of questions were devised that should be answered by the
companies in the tender. In total more than 500 questions were created.

The document is available at <http://www.kb.nl/dea>

IBM was selected. One of the work items was a study on Preservation.
Note that Refesh and Replication were regarded as something different --
part of Archival Storage.

IBM has developed a model of Emulation (Lorie). This involves a
Universal Virtual Computer (UVC) which requires special applications to
access the data. These special applications are expressed in the
instruction set of the UVC.

JAVA was noted as one way of implementing this. One problem with this
approach would be the need for an application to read .g. MS Word
documents because of proprietary formating.

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/26**   700   Send copy of IBM emulation      TVDW        20010131   
                        report to DMS                                          

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

The study is aimed at Content preservation. The budget for the whole
project is about EURO 4M over 2 years, including hardware and software.
There will be a separate contract for technical maintenance by IBM.

BA: what percentage of total collection is accessed in a year? - for
NARA this is 4%

A number of different types of archiving: Dutch Deposit of Electronic
Publications

-   digitization

-   publishers documents -- with various access restrictions

-   Web national archive -- but difficult to harvest since much is
    produced dynamically from databases.

    There is also Identification, Authentication and Authorization layer
    e.g. for

```{=html}
<!-- -->
```
-   Handling payments

-   Enforcing and checking accounts

Other National libraries:

-   British Library ( also placed a contract with IBM -- also based on
    OAIS

-   German library is a partner in NEDLIB.

-   Nat Lib Australia

-   Nat Lib Canada

NARA is asking for \$130M to \$160M -- may NOT include hardware -- the
storage may be contracted out (Virtual Storage).

### Other Reports

#### UK: JISC Workbook (NB)

A pre-publication draft of the Preservation Management of Digital
Materials workbook has been published as a PDF on the JISC WWW site
(http://www.jisc.ac.uk/dner/preservation/workbook/ ). The workbook draws
on a wide-range of experience in projects across the UK and
internationally and will be published by the British Library in the
summer 2001. Comments on the draft are welcome and the deadline for
comments is 8th December.

The Joint Information Systems Committee funds several preservation
projects in the UK. NB's role is to develop synergies between these
projects and external partners.The JISC is working with partners in the
UK to establish a Digital Preservation Coalition. It is hoped to build
on the Workbook by integrating it with other publications and training
workshops.

Other useful sources of information: a synthesis of 7 JISC/NPO research
studies into digital preservation is available in Feeney, M (ed) (1999).
Digital Culture: maximising the nation's investment. London: National
Preservation Office. Free copies can be obtained from: Julia Foster of
the National Preservation Office at the British Library Freepost
LON8974, London WC1B 3BR, telephone +44 (0)171 412 7612 or email
julia.foster@mail.bl.uk. The document can also be downloaded as a pdf
file from
http://www.ukoln.ac.uk/services/elib/papers/other/jisc-npo-dig/intro.html

All seven research studies are available online
(http://www.ukoln.ac.uk/services/elib/papers/supporting/#blric ). The
studies are also published in hard copy by LITC. Each study is priced
£20.00 plus postage and packaging and sales are handled by TBC
Distribution email: tomlinsons@easynet.co.uk

Public consultation ends 8^th^ December.

#### ESA report 

**NOTES :** Round Table on Future Space Environment Data Systems

ESTEC, 30.10.2000

-   **SAAPS -- Spacecraft Anomaly Analysis and Prediction System**

    **P. Wintoft, IRFL - Swedish Institute of Space Physics**

> ESA contract (2 years: April 1999 -- April 2001) -- Development of AI
> methods for prediction

The system consists of:

1.  DB (self developed OO DB)

2.  S/W has 2 modules: Analysis and Prediction (neural network based)

> Data is represented in its own format, but it is exportable to ASCII.

-   **SEDAT -- Space Environment Data System**

    **RAL -- Rutherford Appleton Laboratory**

> No presentation given by M. Hapgood (from RAL) who could not
> participate.
>
> TRP ESA contract (24 months, 250 keuro).
>
> Web based tools, near native data format, IDL based.
>
> It operates on multiple data sets, interfaced via STPDF.

-   **DMAS -- Maintaining the SREM DB with the Data Management and
    Analysis System**

    **P. Buehler, PSI - Paul Scherrer Institut, Switzerland**

SREM -- Standard Radiation Environment Monitor.

The system evaluates Radiation Environment data. STRV satellite and MIR
data have been evaluated. SREM will be on board STRV-1c (DERA
satellite).

**The DMAS system functions are:**

1.  Data reduction

2.  Data storage

3.  Data display

4.  Data dissemination

5.  Data analysis.

> It is written in PV-Wave. The data format is CDF (IACG compliant)

-   **OAIS -- Open Archival Information System**

    **N. Peccia, CCSDS P2**

```{=html}
<!-- -->
```
-   **CDPP -- Centre de Donees de la Physique des Plasmas**

    **C. Harvey, CESR - Centre d'Etude Spatiale des Rayonnements**

> It is a centre to preserve and make available data related to the
> physics of space plasmas.

CDPP

1.  collects and prepares the data and other information for insertion
    into the archive.

2.  Develops new end-users services (new search tools, transformation of
    data prior to delivery, interoperability)

-   **SIPAD -- Systeme d'Information de Preservation et d'acces aux
    Donnes**

    **M. Nonon-Latapie, CNES**

    Software suite that makes CDPP work. It contains multi-mission long
    term data

Data archived is:

1.  Space plasma data

2.  Auxiliary data (orbit, attitude, etc.)

3.  Metadata (docs., browse, event catalogues)

SIPAD uses a commercial DB system (Metaphase from SDCR) allowing object
modelisation and management upon a relational DB (ORACLE).

SIPAD is compliant with OAIS Reference Model. Data preservation is done
via STAF (CNES facility).

> Data sets are supplied (compulsory) with:

1.  EAST description

2.  CCSDS data and time format

3.  Data set descriptor (DIF)

4.  Definition of a dictionary (DEDSL)

5.  Info delivered in PVL

-   **SPASE -- Space Physics Archive Search Engine**

    **M. Gangloff, CESR -- Centre d'Etude Spatiale des Rayonnements**

> SPASE is a meta search engine. It searches several archives
> (multi-mission) with a common query.
>
> The query is transformed in a query server into an URL query to the
> archives, which respond with an XML file.
>
> Software Tools :

1.  http server: Tomcat from Apache / Jakarta

2.  Java 2

3.  XML to Html: Apache XALAN XSLT processor

-   **Implementation of satellite DBs in SPENVIS**

D. Heynderickc ,BIRA / IASB - Belgisch Instituut voor Ruimte-Aeronomie

SPENVIS -- SPace ENVironment Information System is a WWW tool written in
IDL. It displays satellite and image data. Every morning downloads GOES
data and converts it to CDF and writes the HTML pages (data mining and
retrieval)

> It is used for ISTP projects.

-   **Solar DBs**

    **Isabelle Scholl, University Paris CNRS**

> SOHO Solar archive consists of 4 sites (RAL, GFSC, Turin University
> and MEDOC-Multi Experiment Data and Operations Centre-). The goal was
> to design the system with an unique catalogue and archive interface.
>
> Http server is java based and connects via TCP/IP to the DB server
> (relational).
>
> MEDOC is a multi mission catalogue (SOHO, TRACE, THEMIS). The Archive
> design is based on the OAIS model.
>
> The solarWeb project provides a single centralised tool for browsing
> simultaneously several catalogues. It is still under development.

-   Archive Plans for ESA's Planetary Missions

J. Zender, ESA / ESTEC / SO

> All ESA/SSD PDS (Planetary Data Systems -- Giotto, Huygens, SMART-1,
> MARS Express., Rosetta) archives are based in Panel 2 tools developed
> by JPL during late 80's (Data Dictionary, PVL, parsers, VOLDESC).

ESA is trying to develop a generic archive system at VILSPA.

Defined Data Item Type (500). For each of these define a limited set of
searchable keywords -- to limit the size of the catalogue.

Generalised design of the catalogue and well defined API AMS transaction
(fetch, update, delete etc) is used.

Browser uses generic functionality.

Generic system for file transfers, specifying recipient for specific
DIT.

A portable archive is being developed -- based on SUN hardware.

## RID Review Overview 

US workshop addressed the RIDS received, including some which had been
addresses at the CCSDS meeting. For the latter in some cases different
resolutions were proposed. \*\*\*\*\*\*\*\*\*\*\*\*

The issue that was raised about the lack of PRESERVATION was initially
regarded with incredulity. However it was then recognized that this was
indeed an area that could be improved.

LR distributed a revised version of document N3. It is available as
xxxxxx. This is presented as a proposal to address the changes required
in order to put in a "Preservation" functional entity.

A Functional Entity called "Preservation Planning" - this was done in
part to avoid having another entity which connects to all other
entities. It communicates with Administration to implement its plans.

In addition it was recognized that there was an Inventory function
required. A number of functions were transferred from Administration to
Preservation Planning. Note that "Interact with Management" has been
deleted since it seems superfluous. A number of other activities such as
Monitor Technology, develop strategies etc were implicit in other parts
of the document but were NOT in the functional model in the published
Red Book.

The inclusion of a new functional entity does make the Administration
detailed diagram more complex.

In Preservation Planning a function called "Monitor Archive Status" had
been added to the diagram but this function was found in another entity.
Therefore the figure will be modified to delete this box.

Round table:

**DG**: likes the addition

**GMP**: has grown to like it but concerned about impact on overall
schedule

**NP**: need super-Nestorgram to show up any inconsistency (MM has
funding for this)

**AW**: as GMP

**BA**: likes it -- maybe move even more from Administration into
Preservation Planning. 20% of archive budget could be spent on
preservation -- many apparently day-to-day activities re in fact
focussed on Preservation

**TvdW**: happy with addition. It will help to sell this to her
community. Some concern about the tendency for migration to be
implementation oriented rather than generic (DMS: this will be addressed
tomorrow)

**LS**: agreed with BA

**CH**: likes the addition -- makes this activity clearer

**YI**: OK

**PM**: as CH

**JGG**: likes it but not sure about the boundaries -- should be either
strictly planning or else more implementation.

LR/DMS noted that the boundaries of PP had been drawn in such a way as
to minimise changes to the model and avoid making PP as ubiquitous as
Administration and Common Services.

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/27**   700   Try to document the archive as  LR          20010131   
                        a producer in migration and                            
                        upgrade functions.                                     

  **P/0010/28**   700   Send current (or updated if     DS          20001131   
                        available) template to TvdW                            

  **P/0010/29**   700   Produce scenario from a         TvdW        20010115   
                        National Deposit Library        LS                     
                        perspective                                            
  --------------- ----- ------------------------------- ------ ---- ---------- -----

BA requests that people look at other sections and other chapters to
ensure that the new functions are properly integrated in the book.

## RID Review

**OXF/00/P2/N3**

**OAIS Critiques/RIDS**

**25 October 2000**

This document contains all the OAIS relevant critiques and RIDS received
as follows:

NARA RIDs

CNES RIDs

CEDARS Review

NEDLIB Review

Nat. Lib. Australia Review

ICSTI Review

GSFC RIDs

It does not include any material from official ISO channels.

To facilitate review, the comments have been sorted either by OAIS
document section number and paragraph, or by topic. However the ICSTI
comments arrived late and so their \'General Comments\' and \'Editorial
Comments\' have been inserted at the beginning of the list without
specific reference to what parts of the document they may affect.

Some of the critiques/RIDs had received initial P2 dispositions, but are
included here for completeness and because the US group has now taken a
position. The US perspectives were generated at the US/ISO Archiving
workshops held 19-20 July, and September 14-15, 2000. If there is no
additional annotation from a US workshop, the US group was in agreement
with the previous disposition.

In some cases the editor of this document (DMS) has added a subsequent
note as more information has become available (such as DMS meeting with
David Holdsworth on September 18th). Two NASA/GSFC RIDs were received as
this list was being finalized and they have been inserted in appropriate
sections.

All critiques/RIDs have been numbered, starting with R-1 (for RAL -1) up
to R-85, but with 2 others needing to be added, so the total is now 87
RIDs.

==============

### GENERAL COMMENTS FROM ICSTI

**R-1: ICSTI REVIEW**

One of the major issues raised by the review of the OAIS is the
different definitions of what constitutes an "archive". For example,
most learned societies, because of their commitments and charters to
preserve the research (both data and publications) of their communities,
consider their entire publications process to be "archiving". While the
comments below, particularly under functions and compliance, will show
that there is not much difference between the Reference Model's
applicability to "archiving" in this sense versus the narrower
preservation sense, this is still an area of confusion. It would be
helpful to have the full publications process addressed in the context
discussion or the scope refined to indicate specifically that the Model
is not intended to encompass the whole process, and therefore, not
"archiving" in the broader sense.

US Response: OAIS is not \'publications in the broader sense\'; we
attempt to use \'archiving\' in the traditional sense, versus extremes
of usage such as \'putting the data on a medium\', or \'the full
publications process\'. Basically reject, with explanation.

**[AGREE with response]{.underline}**

================

**R-2: ICSTI REVIEW**

One reviewer thought that use of such a Model would make him less likely
to create material to deposit in an archive and more expensive to be an
archive.

US Response: Yes, real preservation costs money and this is a prime
point we are attempting to emphasize.

**[AGREE with response]{.underline}**

=============

**R-3: ICSTI REVIEW**

One reviewer was concerned that this might not adequately address
records management and suggested that the CCSDS make sure that it has
been reviewed by groups such as records managers, government and
institutional archivists.

US Response: Presented to SAA and to ARMA, and comments have been
provided by NARA. Presented to DOD records manager (5015.2 STD is their
basic document).

**[AGREE with response]{.underline}**

==============

**R-4: ICSTI REVIEW**

Some of the examples used throughout the draft should be less
data-centric -- for example while a checksum is mentioned as a means of
ensuring integrity after migration, it was noted by one of the
publishers who maintains an archive that a checksum does not necessarily
work well on full text.

US Response: Specific examples would be needed. The checksum does work
on full text. These are only examples.

**[AGREE with response]{.underline}**

=====================

**R-5: ICSTI REVIEW**

Most of the examples relate to CD-ROMs, when Web-based information
presents other archiving problems.

US Response: We don\'t try to cover all possible cases in the examples.
We don\'t give solutions for specific media types or environments. We
would recommend applying the same approaches to the WEB. What other
problems are being referred to here?

**[AGREE with response]{.underline}**

=======================

**R-6: ICSTI REVIEW**

**In the Annex of scenarios, it would definitely be good to have a wider
spectrum of applications, perhaps one from the national library and
another from a learned-society scientific publisher.**

**US Response: We would welcome a scenario from such groups as long as
they**

**follow the template, which we can provide on request.**

**[NEDLIB example expected \*\*\* see action XXX]{.underline}**

====================================

### EDITORIAL COMMENTS FROM ICSTI

R-7: ICSTI Review

**The definitions should appear in alphabetical order.**

[AGREED]{.underline}

**================================**

**R-8: ICSTI Review**

**Under Fixity\--CRC is not in the list of acronyms.**

[AGREED]{.underline}

**================================**

**R-9: ICSTI Review**

**Reference Information might include SICI or DOI to use a
library/publisher example.**

[AGREED \*\*\* Review by TvdW \*\*\*ACTION XXX]{.underline}

**================================**

**R-10: ICSTI Review**

**It would have been much easier to read if the major acronyms (AIC, AIP
AIU, etc.) had been spelled out throughout the text.**

[REJECT: a style decision was made not to have 2 letter acronyms. The
first time 3 letter acronyms are used they are given in
full]{.underline}

**=================================**

**R-11: ICSTI Review**

**Section 4.1.1 ("Detailed Description of Functional Entities" begins
with a discussion of the IEE POSIX OSE Reference Model that does not
appear to have any real relevance to the rest of the document. The
section goes on to describe in detail the internal functions of an OAIS
system. Although this section does provide some useful guidance to the
system builder/designer, it seems that it belongs more in the annex than
imbedded in the middle of what is a generally theoretical/conceptual
discussion.**

[REJECT: this is an important section. The POSIX OS model discussion is
just an acknowledgement of the source]{.underline}

**================================**

**R-12: ICSTI Review**

**One reviewer thought that some important terms in section 6 are
missing from the glossary (e.g., federated archives, co-operating
archives).**

[ACCEPT: will add these 2 to the GLOSSARY -- any other suggestions for
entries are welcome]{.underline}

**=================================**

**R-13: ICSTI Review**

**There is inconsistency in the way the definitions are structured. Most
terms are nouns, but the definitions begin with a variety of articles or
no article at all.**

**[ACCEPT: will make these more consistent]{.underline}**

=========================================================================

### SECTION 1

R-14: AGENCY RID NUMBER NARA

Discussion of additional comments in the meeting:

Section 1.1 Last sentence Current versions reads as an apology i.e.

\"Finally it attempts to define a maximalS.., but it defines a
minimalS\"

Suggest swapping the phrases to:

\"It defines a minimal set of responsibilities for an archive to be
called

an OAIS , and it also defines a maximal archive to provide a broad set
of

useful terms and concepts\"

AGREED

**[ACCEPT]{.underline}**

=============================

R-14.5: AGENCY RID NUMBER NARA

Section 1.3 1st sentence Read literally we are led to understand

that organisations are exploding!

Suggest changing \"an explosion of organization\" to \"an explosion in
the

number of organization\"

AGREED

**[ACCEPT]{.underline}**

===========================

R-15: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER : 5

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 1-4

PARAGRAPH NUMBER : 3

RID SHORT TITLE : how to read this document

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

DESCRIPTION OF REQUESTED CHANGE :Use From : \"\...\' To \"\...\" format)

The advice about the subsections 1.1, 1.2 and 1.4 are no more useful at

this place in the document.

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_X\_\_\_\_ Editorial :

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION :

Style issue: we\'ll go with the ccsds style consensus, whatever that
turns

out to be.

**[REJECT: we will follow the style guide and CCSDS editor's
advice.]{.underline}**

========================================

R-16: National Library of Australia

Section 1.6.1 acknowledges this and provides a useful guide

to readers. However, there are some important concepts that are only

develped fully well into the model. For this reason, we would recommend
a

last check to align the definitions in Section 1.7.2 carefully with the
full

model, particularly where there are multiple concepts with similar
sounding

definitions. Examples where clarification would help are:

\* Both Content Information and Information Object are defined as a Data

Object together with its Representation Information. It would make the

model clearer if Information Object was defined as a super-class of

Content Information in this section as it is in Figure 4-13.

US: Propose replacing second sentence in definition of Content
Information with the sentence: \"It is an Information Object\".

**[ACCEPT]{.underline}**

\* Similarly, it needs to be clarified in Section 1.7.2 that Archival

Information Package, Submission Information Package and Dissemination

Information Package are all types of Information Package and that

Archival Information Unit and Archival Information Collection are

specialisations of Archival Information Package.

US: Propose revision of AIP to: \"An Information Package which is
preserved within an OAIS.\" Also, revised definition of DIP for
parallelism with SIP.

\*\*\* Think more about these definitions \*\*\*

Accept in principal for 2 examples, but need the complete problem list.

**[ACCEPT]{.underline}**

======================================

R-17: AGENCY RID NUMBER NARA

2\) PAGE NUMBER: 1-7 PARAGRAPH NUMBER: 1.7.2

RID SHORT TITLE: Terminology

DESCRIPTION OF REQUESTED CHANGE: (Use From: \"\...\" To \". .\" format

Move the entire Terminology Section to the Annex and review all
definition

against existing Standards definitions

SUPPORTING ANALYSIS

The terminology section in the front of the document confuses the
reader,

since some of the definitions are not consistent with or what are used
in

the actual body of the document, Therefore, it is more appropriate to
have

this section as a reference. But the definitions should be consistent

throughout the document

\*\* dms- The location of the terminology section can not be changed as
it is

an ISO style. Any inconsistent use of terms needs correction \*\*

Many of the existing definitions are in conflict with current ISO

definitions, as well as other standards documents such as the Society of

American Archivists (SAA) Glossary. In addition, some of The definitions

are in conflict with definitions within the document. These have been

identified specifically in other comment sheets

\*\* dms- ISO definitions are not consistent across all ISO documents.
We

need specifics on which definitions are in conflict before any changes
can

be made.\*\*

DISPOSITION:

REJECT this but we will ask for specific examples and also review
Glossary

US: We\'ll ask for specific examples of conflicts apart from those given
later.

**[REJECT but will consider specific examples if
presented.]{.underline}**

===================================================

R-18: 1.7.2 Terminology

DAVID HOLDSWORTH

In using the model we constantly have the need for a precise term that

describes the original digital object (i.e. that part that together with
the

representation information forms the Content Information). PDO Primary

Digital Object or perhaps Preserved Digital Object. I prefer the first
one,

as we need to refer to it before it has got to the stage of being
preserved.

US: Accept in principle; Content Data Object, and see how it works in
the application. In section 4.2.1.4.1, first sentence becomes: \"The
Content Information is the primary information that the OAIS is tasked
to preserve.\"

Then the third sentence becomes: \"The Content Information, which is an
Information Object as shown in Figure 4-9, is the Content Data Object
together with its Representation Information\". Delete the last sentence
of the paragraph which is now redundant.

**[AGREE with proposal]{.underline}**

**[(some discussion -- NB and TvdW - about "original" CI and versions --
see RID79)]{.underline}**

==================================================

R-19: AGENCY RID NUMBER NARA

3\) PAGE NUMBER: 1-7 PARAGRAPH NUMBER: 1.7.2

RID SHORT TITLE: Terminology - Definition of Archive

DESCRIPTION OF REQUESTED CHANGE: (Use From: \...\" To \....\" format)

Change definition of Archive from \"An organization that intends to
preserve

information\...\" to \"An organization that intends to preserve archival

information packages\...\"

\*\* dms- The original sense is what we meant, while the proposed change
gets

into the \'how it is done\'. Recommend we reject this \*\*

Add definition for \"Archives\" - The DOCUMENTS created or received and

accumulated by a person or organization in the course of the conduct of

affairs, and preserved because of their continuing value. Historically,
the

term referred more narrowly to the NONCURRENT RECORDS of an organization
or

institution preserved because of their continuing value.

2\) The building or part of a building where archival materials are
located;

also referred to as an archival repository.

3\) The AGENCY or program responsible for selecting, acquiring,
preserving,

and making available archival materials; also referred to as an archival

agency, archival institution, or archival program.

\*\*dms- We define \'archive\' as an organization that intends to
preserve

information. We intend \'archives\' to be the plural form. We do not use
it

to refer to the documents being preserved nor to just the building in
which

they are housed. Therefore our usage, in singular form, is more in line

with definition 3 above. Do we need to define \'archives\' as the plural

form of \'archive\' to help avoid confusion with \'documents\'? \*\*

SUPPORTING ANALYSIS:

The change to archive adds clarification to the document. The new

definition of archives adds consistency with other archival Standard

definitions within the International Council on Archives (ICA) Glossary.

\*\* dms- We should check this glossary. Perhaps we need to note these
other

uses of the term \'archives\' and make clear this is not our intended
usage.\*\*

DISPOSITION:

REJECT - we use OAIS specifically to avoid the overloaded definition of

\"Archive(s)\". However we will add a \"(S)\" after Archive and
organisation in

the glossary definition of Archive to make ourselves clear.

TBD after review of the ISO definition identified.

US: Propose that we reject the rid and not add an \'s\'. However we
propose to include a \'thesaurus\' that shows that \'archives\', in
sense 3 above, is close to our use of \'archives\'. This could be a
subsection of 1.7.2.

**[REJECT but agree that editors should find acceptable way to indicate
the possible common mappings: Records, Accession & Archives (plus others
if equired)]{.underline}**

================================================

R-20: AGENCY RID NUMBER NARA

4\) PAGE NUMBER: 1-8,4-25, PARAGRAPH NUMBER: 1.7.2, 4.2.1.4.2

RID SHORT TITLE: Terminology - Definition of Context Information

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

DESCRIPTION OF REQUESTED CHANGE: (Use From: \" \... To \".. \" format)

As part of the definition of \"Context Information\", delete the last 2

words, \"existing elsewhere\".

SUPPORTING ANALYSTS:

This change to the \"Context Information\" will add Clarify to the

definition. The words \"existing elsewhere\" confuse the reader and
create

the unanswered question of Where might these other objects exist?\" For
the

standard it is not important where they might exist.

\*\* dms- Seems acceptable. \*\*

DISPOSITION:

AGREED

**[AGREED]{.underline}**

====================================

R-21: AGENCY RID NUMBER NARA

5\) PAGE NUMBER 1-8 PARAGRAPH NUMBER: 1.7.2

RID SHORT TITLE: Terminology - Definition of Data

DESCRIPTlON OF REQUESTED CHANGE: (Use From: \"\...\~ To \~

Delete the current definition of data, and use the ISO definition.

SUPPORTING ANALYSIS:

This change will add consistency across standards.

\*\* dms- I requested identification of the ISO document, as our
original

definition was taken from an ISO document. I\'ve received a response
saying

it could be found in ANSI X3.172-1990, Dictionary for Information
Systems.

It cites ISO 2382, Vocabulary - Information Systems, as the source of
the

definition of data. We should check this definition to see if it is

acceptable. \*\*

DISPOSITION:

TBD after review of the ISO definition identified.

US: Agreed: An editor will look this up.

**[AGREE to check ISO document and then decide]{.underline}**

=================================================

R-22: AGENCY RID NUMBER NARA

6\) PAGE NUMBER: 1-10 PARAGRAPH NUMBER: 1.7.2

RID SHORT TITLE: Terminology - Definition of Format

DESCRIPTION OF REQUESTED CHANGE: (Use From: \~\...\" To -\...\" formal)

NATIONAL ARCH 1

Delete the definition of format.

Supporting ANALYSIS:

The concept of \"format\", by itself is not addressed in the body of the

document. e.g., there are \"file formats\" and \"data formats\" but not
format

alone. As a result, the term only adds confusion, particularly using
words

like \"sequential organization\" and \"components\" in the definition
which are

not further defined elsewhere.

\*\* dms- While format is sometimes used alone, it is then a short hand
for

\'data format\' or \'format of a piece of data\'. I have no problem with

deleting the definition of \'format\' because as a general concept it is
a

bit abstract. I think format is generally understood sufficiently to not

need a special definition \*\*

DISPOSITI0N:

AGREED

**[AGREED]{.underline}**

===========================

R-23: ICSTI REVIEW

One reviewer thought that the terms were confusing, because they stand
in the abstract. More real-world examples would help.

US Response: Would need identification of specific terms needing
examples.

**[REJECT]{.underline}**: but we will consider specific examples if
presented

=========================

R-23.5: ICSTI REVIEW

Some reviewers expressed concerned about the definitions of data and
information. This is probably a hold over from the data community
perspective. On the other hand, it could be that this type of problem
with the definition is particular to the information community
(libraries and publishers in particular). However, one reviewer noted
that while the distinction between data and information in the
introduction and the glossary is clear, it is not maintained throughout.
For example, the term Data Management Data, is defined in terms of Data,
but perhaps should be defined in terms of information and maybe the term
should be changed.

US Response: We should look at this.

**[ACCEPT -- editor will search for use of DATA and consider
changes]{.underline}**

===========================

R-24: ICSTI REVIEW

The concept of a "designated community" from a primary publisher's
environment caused some concern. However, the group thought that this
was just a matter of degree and suggested that "designated community"
would best be equated with the term "primary audience" for a journal.

US Response: We agree.

**[AGREE -- no change to text except possible addition to "thesaurus".
Could also be "target audience"]{.underline}**

===================

R-25: ICSTI REVIEW

From a publisher\'s point of view, the Content Information and the
Provenance Information appear to be very narrow. For them, content is
likely to be at the article level or report level and provenance would
include where the content was published (though the framers did include
\"who has had custody\" which could be the publisher).

**US Response: We would welcome additional examples.**

[This is a comment rather than a RID, but extra term may be added to
table 4-1. \*\*\*see TvdW action XXXX\*\*\*]{.underline}

**=====================**

R-26: ICSTI REVIEW

"Ownership" is used in the definition of an archive, and this may be
misinterpreted to have intellectual property implications; "stewardship"
might be a better term. Ownership of the object and ownership of
intellectual property need to be better distinguished.

US Response: We need to look at the distinction between ownership (ideal
case) and stewardship where there are copyright issues, to see if this
is clear.

REJECT: first para of 3.2.2 makes the distinction between ownership and
custodianship. (\*\*\*ACTION Check glossary for "ownership" -- may be
appropriate to change to custodian/owner)

==================

R-27: ICSTI REVIEW

One reviewer thought that "ingest" sounded too much like a computer
term. More importantly, it does not connect readily with the other terms
related to the function of submitting data\-- Data Submission Session,
Submission Agreement, and Submission Information Package.

US Response: Reject. This has been the topic of much review and the
consensus is to stay with \'ingest\'.

**[REJECT]{.underline}**

**========================**

R-28: ICSTI REVIEW

The term "Digital Migration" is defined as a "transfer of digital
information". It seems that to many people transfer means to move
without changing, but that applies only to one kind of transfer
identified in the document (refresh). Migration might better be defined
as a "transformation". As a special case of digital migration, refresh
operation would then involve a null (no change) transformation, but
other types would have varying degrees of change.

US Response: Reject: We feel that \'transfer\' doesn\'t necessarily
imply change, but does capture the important aspect of moving. Therefore
we feel the current terminology is appropriate.

**[REJECT]{.underline}**

**========================**

R-29: ICSTI REVIEW

The definition of an "Archival Information Unit" as atomic is confusing.
Perhaps some examples would help here.

US Response: Reject: AIU is not defined as \'atomic\'. This is only one
way to view it. We give the definition and we give an example, in the
glossary.

**[REJECT]{.underline}**

**=========================**

R-30: ICSTI REVIEW

One reviewer more involved in traditional archive functions, questions
the applicability of the word "Consumer", because it suggests cost
involved in using the archive.

US Response: Reject: Definition doesn\'t imply cost. To consume doesn\'t
mean you have had to buy what you are consuming.

**[REJECT]{.underline}**

**=========================**

R-31: ICSTI REVIEW

For one reviewer, there was confusion over the description of an
Archival Information Collection. Although some attention is paid to the
idea of organizing by "origin" more time is spent on thematic
collections. However, in traditional archiving the organizing principle
is origin or provenance with the thematic being handled by queries
against the archive. If the idea is that the AIC, one based on
provenance or one based on theme, is built from a query, it wasn't
completely clear. This same reviewer noted that the AIC scheme, if
applied according to provenance, is a very good one, since it allows for
description at the constituent unit level as well as at the collection
level. Preservation Description Information would then repeat across
units when provenance is the combining factor, making a collection-level
PDF much easier to put together, and more meaningful for users.

US Response: We think the reviewer figured it out very well!

**[Not a RID]{.underline}**

**==========================**

**R-32: ICSTI Review**

Another odd term was the "Ad Hoc Query" (as my guess is most queries to
an archive are not event-driven, i.e., cyclical, but are to find
specific information known or expected to be held in the archive). But
it could be mapped easily to something else.

US Response: It appears to have conveyed the intended meaning.

**[Not a RID]{.underline}**

**==========================**

R-33: ICSTI REVIEW

"Member Description" was unclear, as the definition is a \"member of a
collection.\"

US Response: This is not the definition. The key part is that it is an
associated description. As a note to editors, remove the plural from
\'associated descriptions\' in the glossary.

**[Agree with response]{.underline}**

**==========================**

R-34: ICSTI REVIEW

The term "Finding Aid" seems to be any search tool, even an online
public access catalog. This clashes with the archivist's use of the
term. Would it be better to call the concept "Searching Aid"?

US Response: Finding Aid is more general, which is intended, and is
found to be widely accepted in the archival community.

**[REJECT]{.underline}**

**==========================**

R-35: ICSTI REVIEW

The term "Designated Community" might be better as Consumer Community or
primary Consumer Community. The former connotes more deliberate
intention in reaching an audience than is common on Internet sites
today.

US Response: The reason for using \'designated\' is to make clear that
an active identification of the relevant Consumer Community is to be
made. However the glossary definition needs clarification because there
are too many \'sets\'. Perhaps :...\' who should be able to understand a
particular collection of information.\'

[Agree with response]{.underline}

**=============================**

R-36: ICSTI REVIEW

The term "Data Management" has a multi-part definition that one reviewer
could not understand. There are several ways to add parentheses, commas
and semi-colons, but not sure which one would be correct.

US Response: Accept: Propose wording is:

Data Management: The OAIS entity that contains the services and
functions for populating, maintaining, and querying a wide variety of
information. Some examples of this information are catalogs and
inventories on what may be retrieved from Archival Storage, processing
algorithms that may be run on retrieved data, Consumer access
statistics, Consumer billing, Event Based Orders, security controls,
OAIS schedules, policies, and procedures

**[Agree with response -- but change "querying" to
ACCESSING]{.underline}**

**===========================**

R-37: ICSTI REVIEW

One reviewer indicated a problem with treating producer and consumer as
roles, since it is then difficult to talk about sets or groups of these
roles. He suggested the following definitions: Consumer: An agent (a
person, organization, or program) with a persona that may interact with
OAIS search and access services. This persona (a set of motives and
responses) may actuate the agent temporarily or intermittently, but does
not define it: for example, a Consumer may also be an OAIS or a
Producer. A similar definition was suggested for Producer.

US Response: We don\'t feel that a significant problem has been
presented with the current use of \'roles\', and find the proposed
definitions to be more confusing .

**[REJECT]{.underline}**

### SECTION 2

R-38: REVEW ITEM DISPOSITION (RID )

AGENCY RID NUMBER NARA

SUBMITTING ORGANIZATlON (Agency, Center): NARA

REVIEWER\'S NAME: Mary Ann Hadyka

CODE

E-MAIL ADDRESS: MaryAnn.Hadyka@arch2.nara.go

TELEPHONE: (301) 713-7360 X222

DOCUMENT NUMBER: CCSDS 650.0-R-1 Red Book, issue

DOCUMENT NAME: OAIS Reference Model

DATE ISSUED: May 1999

1\) PAGE NUMBER:2-1 PARAGRAPH NUMBER: 2, 3, 4

RID SHORT TITLE: \"OAIS CONCEPTS

DESCRIPTION OF REQUESTED CHANGE: (Use From: \"\" To \" format

Paragraph 2, Sentence 2, change: \"Traditionally, an archive\" to \"

Traditional archives\"

\*\* dms- Seems acceptable \*\*

AGREED

**[AGREED]{.underline}**

Paragraph 3 -, Delete the sentence: \"Although some archives may be

temporary, some or all of their information my need to be preserved

indefinitely.\" Combine the next two sentences to read: \"Because much
of the

supporting information necessary to preserve this information is more

easily available or only available at the time when the original

information is produced, these organizations need to be active
participants

in the long-term preservation effort

\* dms- This change removes the use of the term \'temporary archive\'
from the

document. Seems acceptable dms - should be further reworded later \*\*
AGREED

**[AGREED]{.underline}**

Paragraph 4 -delete the last sentence which begins with: \"The designers
and

architects should document where compromises have been made. \...\"

\*\* dms- This change has the effect of not encouraging compromises, in

active archvies, of preservation for the sake of access,etc. \-- Seems

acceptable on this basis \*\*

REJECT BUT AGREE to change \"compromises\" to \"solutions\" and reword
the

sentence to keep spirit of the suggestion.

**[Agree with reponse]{.underline}**

SUPPORTING ANALYSIS

The use of archive, archives, and temporary archives is confusing. These

changes clarify the terms. Also designers and architects play no role in

the body of the reference model, so the sentence is irrelevant to the

document.

\*\* dms- Designers and architects are mentioned several places in the

document as primary beneficiaries of the reference model, so this
rationale

is not correct, but I find the changes acceptable \*\*

DISPOSITION

See above for individual points

=======================================

R-39: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER : 4

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 2-5

PARAGRAPH NUMBER : 5

RID SHORT TITLE : definition of \'Content Information\'

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

DESCRIPTION OF REQUESTED CHANGE :Use From : \"\...\' To \"\...\" format)

We suggest replacing \'The Content Information is that information which
is

the primary target of preservation\' (this sentence is valid only for
AIP,

certainly not for DIP) by \'The Content Information is the primary

information of interest\'.

Regarding to the \'information definition, section 2.2.1), it seems

interesting to add : \'The Content Information is an information object

which consists of SS

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_X\_\_\_\_ Editorial :

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION :

Agreed that there is an inconsistency. Need to work on a solution which

doesn\'t dilute the preservation notions being introduced at a high
level in

section 2, while removing the inconsistency.

We can clarify that the content information is an information object, as

introduced a bit earlier.

US: Propose to change the definition of Content Information in glossary
to be the \"that information which is the original target of
preservation by the OAIS\". We need to clarify that a DIP is derived
from an AIP, and that non-AIP information is carried by a \'result set\'
or \'report\'. With regard to the suggestion that the definition include
the fact that it is an information object, this is already addressed and
agreed by US.

**[Agree with response]{.underline}**

============================

R-40: ICSTI Review

In 2.3.3 the text of the Reference Model implies, without stating it
specifically, that the consumer has no further rights to data residing
within the archive once the order has been completed. Many scientific
consumers, however, have some expectation that, having taken a
subscription for one year to a journal that they have rights to the data
in the archive for that year of the subscription for all time. They seek
to treat the purchase of an electronic subscription as giving them an
"eternal" archive in the same way that the print edition does.

US Response: This is a policy issue that goes beyond the model.

**[REJECT: this is a policy/implementation issue for a specific
sector.]{.underline}**

=====================

R-41: ICSTI Review

The discussion of "Order Agreement" doesn't mention authentication and
payment

US Response: This is intended to be a high level summary, although it
does mention pricing. Authentication is mentioned under common services,
in section 4.1.1.1.

**[REJECT -- agree with response]{.underline}**

### SECTION 3

R-42: AGENCY RID NUMBER NARA

7\) PAGE NUMBER: 3 .2 PARAGRAPH NUMBER 3.2.2

RID SHORT TITLE: Paragraph titled\" Copyright implications\"

DESCRIPTION OF REQUESTED CHANGE: (Use From: -\...\~ To \"\...\" format)

Change title of paragraph \"Copyright implications\" (occurs in 2
places,

paragraph 2 and 3) to \"Copyright implications, intellectual property
and

other legal restrictions on use\". Add new first sentence to paragraph
3:

\"An archive will honor all applicable legal restrictions.\"

Supporting ANALYSIS:

Addressing only copyright is misleading. This section needs to be

broadened and should be more general in dealing with legal issues
related

to intellectual property and other legal restrictions, eg., National

security classifications and Privacy Act.

\*\* dms- I think this is an improvement and should be incorporated. See

following RID for rest of the recommended change \*\*

DISPOSITION

AGREED

**[AGREED]{.underline}**

============================================

R-43: AGENCY RID NUMBER NARA

8\) PAGE NUMBER PARAGRAPH NUMBER: 3.2.1, 3.2.2

RID SHORT TITLE:

DESCRIPTION OF REQUESTED CHANGE: (Use From: u t. To \"\... format)

Change all but the first sentence of the first paragraph of 3.2 2 from

\"When acting as a custodian, the OAIS may need to involve the actual
owner

(s)) in some migration and access decisions depending on the authority
it

has been granted to act independently. When it is the legal owner, it

already has the independence to do what is required to preserve the

information and make it available.\" to \"**When acquiring lega1
ownership from**

**the producer or any other entity, the OAIS should ensure that the
transfer**

**of ownership clearly specifies any limitations imposed by the former
owner**

**and that its subsequent actions to preserve the information and make
it**

**available conform with these limitations. When the OAIS accepts
information**

**solely as a custodian, the OAIS should establish an agreement with
the**

**owner which specifics what involvement the owner will have in
preservation,**

**management or release of the information. In most cases, it will be**

**preferable for the OAIS to negotiate an agreement which specifies
the**

**(prior) owners requirements and authorizes the OAIS to act in
accordance**

**with those requirements without active involvement of the (prior)
owner in**

**individual cases**

SUPPORTING ANALYSIS:

The current draft assumes that in situations where an OAIS owns the

information it preserves, it has unrestricted discretion over the
actions

it takes. In fact, in many cases where an OAIS acquires ownership from

another entity, the transfer is effected by a deed of gift or other
legal

instrument which includes limitations on the OAIS\'s discretion. The

recommended revision addresses this fact It also suggests that in either
a

custodial or owner role, it is advantageous for the OAIS to have any

limitations on its discretion expressed in categorical terms which
minimize

occasions when another owner or party is actively involved in specific

decisions.

\*\* dms- I think this improves the paragraph and recommend it be
accepted. \*\*

DISPOSITION:

AGREED

**[AGREED -- but change "limitations" to "conditions" -- other
clrifications needed. \*\* ACTION : NB to suggest revised wording
\*\*\*XXXX\*\*\*]{.underline}**

==============================

R-44: ICSTI Review

Most felt that the responsibilities were complete and they could be used
independent of the stakeholder group doing the archiving function. One
reviewer indicated that the responsibilities of a compliant OAIS are
very similar to that of a responsible learned-society publisher.

US Response: Good

**[Not a RID]{.underline}**

=========================

R-45: ICSTI Review

Security of the archive seems to be missing both specifically in the
responsibilities and in the amount of text devoted to Fixity
Information.

US Response: Again, this is addressed in security services under common
services, because this is ubiquitous.

**[REJECT]{.underline}**

=========================

R-46: ICSTI Review

There was significant discussion about the requirement to have the
information remain "understandable for the designated community" group;
several reviewers believe this is out of the scope of an archive and
access is all that can be required. "Ensure the information .... Is
independently understandable...", raises the question "independent of
what?"

US Response: An OAIS is a long term preservation function which expects
the information to be understandable without going back to the creator.
This is a traditional function of an archive. We will look at revising
the \'independently understandable\' phrase to clarify.

**[AGREE: resolve by using text from Glossary definition of "Long Term
Preservation" and move it to a separate Glossary item for "Independently
understandable information" (note UNDERSTANDABLE rather than
USEABLE).]{.underline}**

**============================**

**R-47: ICSTI Review**

There are some aspects that aren't clear upon closer reading. For
example "negotiate and accept appropriate information" implies that the
information is negotiated, when it is more likely the archiving
agreement that is negotiated. Perhaps "negotiate for".

US Response: Change to \'negotiate for\' in section 3.1 and 3.2.1.
Provide other cases which are unclear.

**[ACCEPT for this specific case -- other specific examples would be
considered.]{.underline}**

### SECTION 4.1

R-48: AGENCY RID NUMBER NARA

11\) PAGE NUMBER: 4\~2 PARAGRAPH NUMBER: 4.1

RID SHORT TITLE: Functional Model, Administration

DESCRIPTION OF REQUESTED CHANGE: (Use From: \"\...\~ To \'. \" format)

In the paragraph titled \"Administration\" add the following phrase to
end

of the first sentence: \"which could include the hardware, software and

telecommunications.\"

SUPPORTING ANALYSIS:

Within Section 4 of the reference model, there is no stated function for

the entity which is responsible for the actual operation of the system

infrastructure (operations and maintenance of the hardware, software and

telecommunications). This may be implicit\' in the Administrative
function,

however, the function as currently described focuses on oversight not

actual operations. The change as described above will make the function

explicit.

\*\* dms- I think the issue here is whether there is an entity that is

\'responsible for the actual operation of the system infrastructure\'.
Is

the operation and maintenance of the hardware and software for each

function handled by that functions, or is there a general support

sub-function for this? Administration has a \'Manage System
Configuration\',

but does not talk about actually operating any systems. Needs
discussion.

\*\*

DISPOSITION

REJECT, this section already states that \"This entity manages the
overall

operation of the archive system.\" We specifically did not wish to imply
any

hierarchy of management or implementation.

US: First sentence becomes: This entity provides the services and
function for the overall operation of the archive system. For
parallelism, change first sentence of Access to: \"This entity provides
the services and functions that support Consumers in determining the
\....\". This will better address the issue while improving consistency.

**[AGREE with US proposal]{.underline}**

========================================================

R-49: AGENCY RID NUMBER: Wed Oct 25 14:09:04 2000

SUBMITTING ORGANIZATION (Agency, Center): NASA, GSFC

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

NAME: Elisabeth Brinker

CODE: code 586

E-MAIL: elisabeth.brinker@nasa.gsfc.gov

PHONE:

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

DOCUMENT NUMBER: CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME: OAIS Reference Model

DATE ISSUED: May 1999

PAGE NUMBER: PARAGRAPH NUMBER:

RID SHORT TITLE: Promote functional entity Common Services to figure

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

DESCRIPTION OF REQUESTED CHANGE: (Use From: \'\...\' To \'\...\' format)

FROM:

Current Text:

\" In addition to the entities described above, there are various

Common Services assumed to be available. These services are

considered to constitute another functional entity in this model.

This entity is so pervasive that, for clarity, it is not shown

in figure 4-1.\"

TO:

Recommended Text

\"In addition to the entities described above, there is an

infrastructure of various Common Services. These services are

considered to constitute another functional entitiy in this model

supporting the portability and interoperability that are

characteristic of Open Systems. This entity is pervasive enough

that, for clarity, connections to other functions are not shown

in figure 4-1.\"

Corresponding recommendation for figure 4-1: OAIS Functional

Entities.

Place a small rounded rectangle in the bottom right corner of the

figure, as follows: (figure did not copy)

The rectangle could be made with dashed lines as shown, or with

lighter ink to indicate the intended transparency of the

function.

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

CATEGORY OF REQUESTED CHANGE: Recommended

Technical Fact \_\_\_\_ Recommended: \_\_\_\_\_\_\_ Editorial:
\_\_\_\_\_\_\_

NOTES:

TECHNICAL FACT: Major technical change of sufficient magnitude as

to render the Recommendation inaccurate and unacceptable if

not corrected. (Supporting analysis/rationale is essential.)

RECOMMENDED: Change of a nature that would, if incorporated,

produce a marked improvement in document quality and acceptance.

EDITORIAL: Typographical or other factual error needing

correction. (This type of change will be made without feedback

to submitter.)

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

SUPPORTING ANALYSIS:

The purpose of this recommendation is to give a more consistent

and cleaner view of the functional model. The function of Common

Services is to be transparent to the user community but not to

the administrators and operators, as these functions are expected

to provide the infrastructure that supports openness between

archives and consumers.

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

DISPOSITION:

**[REJECT]{.underline}**

===============================

R-50: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER NARA

9)PAGE NUMBER: 4-6, 4-7, 5-1 thru 5- 4 PARAGRAPH NUMBER: 4,1,1,3, 5.1,

5,1,3, 5.2

RID SHORT TITLE: Paragraph titled \"Migrate Media\"

DESCRIPTION OF REQUESTED CHANGE: (Use From: \"\...\" To h\...\'l format)

Change title of paragraph which begins with \"The Migrate Media
function\" to

\"The Migration function\" Change the \"Migrate Media\" block in figure
4-3 to

\"Migration\"

Make Section 5.1, 5.2 consistent with this title change.

SUPPORTING ANALYSIS:

This name change is more general and better encompasses the four
migration

types identified in Section 5.1.3. adding clarification to the document.

\*\* dms- The \' migrate media\' function is archival storage covers the

migration types of refreshment, replication, and repackaging, but NOT

transformation. Calling this function \'migration\' is too general,
while

\'migrate media\' is perhaps too narrow. Basically, what this function
does

is migration as long as there is no change in the content information

(i.e., there is no transformation). This is spelled out in the text of

this section. Better name for this set of functions? \*\*

DISPOSITION

REJECT change simply to \"Migrate\" as this is too broad a term. However
it

is recognized that \"Migrate Media\" could be misleading. Therefore
change

this to \"**Replace Media**\" reproduce

US: \*\*\* Need more analysis. Come back after doing more work on the
preservation issue.

**[AGREE: Rename as "REPLACE MEDIA" -- also remove REPACKAGE from this
function -- leave only REFRESH and REPLICATE]{.underline}**

====================================================

R-51: Page 4-4 4.1.1.2 Ingest

DAVID HOLDSWORTH

before Generate AIP - new section

(but it may already be covered by the data formatting and documentation

standards aka motherhood and apple pie)

Identify the underlying abstract form (UAF) of the data. The UAF is some

conceptual view of the components of the data, that is likely to stand
the

test of time. Likely UAFs are: file tree, file containing lines of text,
a

relational database.

Once this form has been identified, the data should be converted into a
byte

stream for long-tem preservation. The archive must maintain a list of
UAFs

and have the transformation capabilities for converting from UAF to byte

stream and for regeneration of the UAF from the byte-stream.

The purpose of the UAF concept is to facilitate the delivery of data
onto a

platform different from that upon which it originated. This is
particularly

valuable for access to really old data, for which the original platform
(say

a \*\'\" tape, or 12\" laser disk) is unlikely to be available.

US: \*\*\* Hold off on this until we address the preservation issues to
come up later.

Need more information.

**[REJECT: the suggested change is too implementation specific however
we agree with the spirit of the comment.]{.underline}**

============================================

R-52: ICSTI Review

Ingest should be more specifically defined with some guidelines given
for the format of the information that is most easily ingested and best
for archiving, such as ASCII or SGML. While details about format would
be out of the scope of a Reference Model, it may be worth mentioning
that there are some standards that appear to be preferable when dealing
with migration, depending on the type of data.

US Response: This is done within negotiating the submission agreement.

**REJECT**

==========================

R-53: ICSTI Review

Ingest deals with the technical submission of data or documents into the
OAIS data base. This leads one to believe that scientific refereeing is
covered in the administration part of the Model and not in the \'Receive
submission\' which gives the impression on a first reading of an
oversimplified submission procedure. The same applies to \'Quality
Assurance\' which covers only the quality control of the data transfer
and does not in any way concern any tests on the scientific integrity
and quality of the data. In fact, \'scientific integrity and quality of
data\' being specifically mentioned in the \'administration\' part of
the Model.

US Response: The implementation of an OAIS is not specified by the
grouping of functions within the model. The separation was intended to
highlight the day-to-day operations in Ingest, with less frequent
reviews and verification of content taking place in Administration. A
full reading of the model is required.

**[REJECT]{.underline}**

====================================

R-54: Page 4-6 4.1.1.3 Archival Storage

DAVID HOLDSWORTH

I think that this section may be overly prescriptive. The function of
the

archival storage is to receive the AIP and return it sometime later.
This

includes appropriate activities to deal with disasters. With present

technology we assume media migration, and back-ups for disaster
recovery,

but new ideas may change that.

The best way to view all the diagrams of 4.1.1 may be as a checklist of

capabilities, rather than a prescription for implementation. (This
opinion

may sit uneasily with my previous comment on 4.1.1.2!)

US: REJECT: These figures are meant to give the concept of the scope of
the functions, not an implementation. Look to see where this may be made
even clearer.

DMS: David is concerned that some of the detailed concepts implied by
the subfunction breakout might discredit the model in the future as
technology evolves. For example, perhaps archival storage should
emphasize that submission of AIP and get it back, and the rest is
implementation.

**[REJECT -- it is made clear in section 1 that this is NOT a design for
an implementation]{.underline}**

===========================

R-55: AGENCY RID NUMBER: Wed Oct 25 14:56:35 2000

SUBMITTING ORGANIZATION (Agency, Center): NASA, GSFC

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

NAME: Elisabeth Brinker

CODE: code 586

E-MAIL: elisabeth.brinker@nasa.gsfc.gov

PHONE:

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

DOCUMENT NUMBER: CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME: OAIS Reference Model

DATE ISSUED: May 1999

PAGE NUMBER: F-11 PARAGRAPH NUMBER: 5

RID SHORT TITLE: Enlarge responsibility of Customer Service function in
text

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

DESCRIPTION OF REQUESTED CHANGE: (Use From: \'\...\' To \'\...\' format)

FROM:

\"The Customer Service function will also create, maintain and

delete Consumer accounts and will bill and collect payment from

Consumers for the utilization of archive system resources.\"

TO:

\"The Customer Service function will create, maintain and delete

Consumer accounts and will bill and collect payment from

Consumers for the utilization of archive system resources. This

function will also be a collection point for Consumer feedback on

products of the Archive.\"

Update corresponding figure 4-5, Functions of Administration, to

reflect this recommendation. Add such words as \"feedback\",

\"confirmation\", \"delivery acknowledgement\", or \"delivery status\"

between consumer and Customer Service.

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

CATEGORY OF REQUESTED CHANGE: Recommended

Technical Fact \_\_\_\_ Recommended: \_\_\_\_\_\_\_ Editorial:
\_\_\_\_\_\_\_

NOTES:

TECHNICAL FACT: Major technical change of sufficient magnitude as

to render the Recommendation inaccurate and unacceptable if

not corrected. (Supporting analysis/rationale is essential.)

RECOMMENDED: Change of a nature that would, if incorporated,

produce a marked improvement in document quality and acceptance.

EDITORIAL: Typographical or other factual error needing

correction. (This type of change will be made without feedback

to submitter.)

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

SUPPORTING ANALYSIS:

The Archive is intended to serve Consumers, albeit in an open,

standardized fashion. Does it not seem reasonable to acknowledge

communications other than payments?

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

DISPOSITION:

**[AGREE in concept -- editor will propose rewording.]{.underline}**

===========================

R-56: NEDLIB Review

The OAIS Document provides some perspectives on the issues of
information preservation using digital migration across media and across
new formats or representations, but it is not clear which processes are
needed and which functionality is required. It discusses medium
migration (refreshing or copying a publication) as a preservation
procedure belonging to Archival Storage. As formats become obsolete and
the viewers needed to interpret and render these formats be come
obsolete as well, measures to preserve the content of a publication and
all related aspects such as look and feel, layout, structure and
functionality, need to be taken. To this end, several strategies may be
followed, such as migration and emulation. The OAIS model does not
discuss different preservation strategies and how they affect the model.
It implicitly accepts data migration, i.e. \"transformation\" of digital
content, as the preferred strategy. In all cases, transformation leads

to a \"new version\" of the original publication. However, even with
this strategy, it is not clear where transformation processes take place
in OAIS. It does not belong to Archival Storage and this is
understandable because Archival Storage does not have (and does not need
to have) any knowledge of the content of a publication. The
Administration entity has an \"Archival Information Update\" function
that provides a mechanism for updating the contents of an AIP stored in
Archival Storage, by accessing it as a DIP, updating its content and
resubmitting it as a SIP to Ingest. However the Reference Model does not
clarify if and in what way this function belongs to a preservation
process.

What NEDLIB found missing in the OAIS Model was a conceptual entity
symbolising the preservation processes required of an OAIS, whatever the
preservation strategies followed. Therefore NEDLIB has added in its DSEP
model a Preservation entity that manages the preservation processes
required of a DSEP. Although it is recognised that the preservation
function affects all DSEP processes, NEDLIB has added this separate
preservation entity to make this function more visible and more explicit
in the model. Much in the same way as metadata processing affects all
DSEP functions, still, OAIS has defined a separate Data-Management
entity to visualise the metadata processing function.

Both transformation and emulation approaches are worked out in some
detail in the DSEP model. The resulting output is either a new version
of a formerly deposited publication, in which case it is ingested anew
in the system, or it is a set of specifications for interpreting or
emulating the interpretation of the publication. In both cases, new
preservation metadata are generated and managed by the Data-Management
process.

US: See the proposed new function \"Preservation Planning\" for a
partial response.

**[AGREE: see proposed new Preservation Planning entity.]{.underline}**

==================================

R-57: National Library of Australia

Need for a Preservation function

Our main concern with the model in its current form is the need to

incorporate a Preservation function. The Nedlib Project also found the
need

to extend the model in this area in its Data/Functional Model for a DSEP

(DSEP), which otherwise follows the OAIS Reference Model. There are
other

functional areas essential to deposit libraries building selective
archives

of electronic publications - for example, Selection , Evaluation and

Collection of Content Information - that we accept as falling outside
the

scope of the model. However, we see the preservation function is a core

responsibility of an OAIS. Section 5 currently goes some way towards

addressing this isssue but it still implies that Preservation is not a
core

function of an OAIS or that it is somehow already addressed within the

model. The new Preservation function needs to be separate from Archival

Storage to support Digital Migrations that change the Content
Information

and therefore create a new Archival Information Package. Work in this
area

would assist in identifying more fully the information needed to support
the

Preservation function, either as Preservation Description Information or
as

Data Management Data (see below). Currently, the sections on Data
Management

Data are most developed in relation to information needed to support the

Access function.

US: See the proposed new function \"Preservation Planning\" for a
partial response.

**[AGREE: see proposed new Preservation Planning entity.]{.underline}**

=====================================

R-58: NEDLIB Review

Handling software

Our understanding is not yet well advanced in relation to software
required for accessing a particular Archival Information Package and how
this is handled in the model. The model makes it clear that
Representation Information cannot depend on referencing software, as
this would not completely specify the Representation Network needing to
be in place for on going access to a given Archival Information Package.
However, we also assume that, at a given time, an OAIS will use software
as part of the Access function to provide current access. We assume that
software is another type of Information Object, that it might be treated
as an Archival Information Package in its own right, and that it might
be part of a set of operations invoked during Access. We are not sure
where information about the software needing to be invoked in order to
support current access to a given Archival Information Package would be
managed.

US: TBD

**[AGREE: Editor will propose text to address this.
XXXXXX]{.underline}**

================================

R-59: CNES Summary points

\-- Preservation

Long-term preservation of information constitutes the leading essential
mission of an OAIS archiving system. This is translated in the Model by
a series of consequences and at multiple levels:

For example: have representation information without which our bits
cannot be interpreted.

For example: the \'archival storage\" function must preserve the bits.

However, there is no central monitoring and control function for this
aspect. Technological developments must be taken into account in order
to decide on the migrations to undertake. Who decides on the migrations?
This is not easy to find in the Model. The \'storage\" function
comprises a sub-function \'migrate media\', but this only covers part of
the necessary migrations. A function handling all hard and soft aspects
of preservation would clarify the situation. Its role would be to ensure
permanently that all conditions required to preserve data using the
available technologies are satisfied. This function could be either an
integral function of the Model or a sub-function, part of DLIB seem
justified.

\-- Emulation

With regard to the substance, we are in full agreement with the
reservations expressed by the Reference Model concerning the question of
emulation (paragraph 5.2).

However, we must be aware that today there are thousands of electronic
documents in CD-ROM form, including the executable software required for
access to the information in these publications. In particular, this
concerns major publications such as encyclopedias.

For these publications, the Reference Model cannot simply adopt the
standpoint that, in the absence of a source code and appropriate
documentation, it is not and will not be possible to preserve these
publications.

The emulation technique is still too young to be able to settle this
problem definitively. The Model may be able to handle this problem in a
separate chapter. While describing the limits and dangers of this
approach, the possibility of developing this part, taking into account
long or medium-term experience, will be kept open.

Refer to the report by Jeff Rothenberg on this subject

http://www.kb.nl/nedlib/results/emulationpreservationreport.pdf

US: See proposed new function \"Preservation Planning\" for a partial
response to these issues. Need a view/paper on how AIP emulation may be
used. Note the distinction between preservation of information and
preservation of access to information, as called out in section 5.2

**[Take last para of 5.2 (ACCESS SERVICE PRESERVATION) but remove
REQUIREment of having source code. Summarise the techniques in
Preservation Planning.]{.underline}**

### SECTION 4.2

R-60: Pg 4-16 4.2.1.1 Information Object

DAVID HOLDSWORTH

I propose that a third choice be added to the data object alongside the

sequence of bits, namely a sequence of bytes, treating a byte as an
atomic

object.

Although it is true that a digital object is a bit-stream at the lowest

level, in practice computation since the 1980s has been completely

byte-oriented. The hardware that we have for implementing the storage is

byte-oriented, and the underlying abstract forms for representation of
the

data are also byte-oriented.

I used to think that this was a small point, but I now realise that if
bits

are the atoms, the process of recovery involves unpacking the bytes into

bits and then packing them back again. In CEDARS we are using ASN.1\'s
Basic

Encoding Rules for packaging the AIP and could easily accommodate the

choice. I note that X.509 insists in describing signatures as
BIT_STREAMs

and this leads to some messy practices in the PKCS standards, where
there is

a recognition that the byte has become a \"natural unit\" of
computatioN.

REJECT: We fail to see the problem that bit-stream brings, since bytes
and now unicode (16 bits) are comprised of bits.

DMS: David points out that modern storage technology stores bytes not as
individual 8-bit objects

**[REJECT]{.underline}**

==============================

R-61: Page 4-17 4.2.1.3.1 Representation Networks

DAVID HOLDSWORTH

It is quite clear in CEDARS\'s intended end-user community that the
archive

should enable use of software that renders access to the intellectual

content of the preserved material. Without software in the
representation

network, the chances are that the information will never be looked at. I

appreciate that this may be more a library perspective than that of
space

data.

The challenge is to keep the rendering software working over time. We
take

that view that keeping an inventory of these Gödel Ends in the

representation network. is a vital part of the function of the

Administration, and would recommend that Figure 4-5 and §4.1.1.5 be
amended

to include this.

We now have successful emulation of a 1970s operating system, giving
access

to information previously lost, and the implementation is only
dependedent

on the ability to run a C program. I believe that concentration on
rendering

facilities that depend only on implementation of main-stream programming

languages offers the best promise of continued access - but it must go

hand-in-hand with monitoring the Gödel Ends. After all, one can still
run

FORTRAN77, but most of the binary programs that were written in
FORTRAN77 in

1977 will not not now run - only those from IBM 360s

US: \*\*\* Agree that an inventory of \'ends\' is important. It might be
in Admin or somewhere else - hold off until we discuss the
\'preservation function\' issue.

**[AGREE -- see proposed new PRESERVATION PLANNING entity]{.underline}**

=============================

R-62: Page 4-17 4.2.1.3.1 Representation Information Types

DAVID HOLDSWORTH

The Figure 4-10 should have the semantic information box on the left so
that

it relates more easily to Figure 4-11 - or it may be that I have failed
to

understand Figure 4-11, which I find to be both more detailed and less

informative than Figure 4-10.

US: Agreed

I believe that I would find figure Figure 4-11 more convincing if Figure

4-12 were to be replaced by a concrete example. The current example is
more

by way of ectoplasm.

US: Agreed

DMS: David suggests we might want to put this in an annex, and then
consider referring to a URL where the reader could navigate the example.

I used to think that Figure 4-10 appeard as a one-off in the Red Book,
but

it reappears as a part of Figure 4-19, to give it extra substance. The

representation nets used in CEDARS are more easily seen in terms of the
4-9

formalism.

Whatever else, I think that relationship between 4-9 and 4-10 should be
made

clearer.

US: Seems clear to us. Ask him to propose how to make it clearer.

DMS: David has interpreted 4-11, operations and relationships, as a
realization of the semantic information, while the other children
correspond to the structure information. Therefore, swapping the two on
figure 4-10 would make this parallelism clearer.

**[AGREE to swap order of lower boxes in Fig 4-10]{.underline}**

=====================================================

R-63: Page 4-22 4.2.1.4.1 Content Information

DAVID HOLDSWORTH

On the third line there is a reference to \"primary data object\",
neatly

supporting my first point.

US: Already addressed

6th para - starting \"This is not difficult to do \...\"

The vital part of an environment is the API (applications programming

interface). It is this that needs to be preserved (and we have practical

proof of doing this). I take issue with Rothenberg on such matters of

emulation, but have not had time to write a paper on the subject. I
believe

that identifying the appropriate abstraction for the software
environment is

the correct route, and is closely parallel to the ideas about underlying

abstract form.

US: Basically agree, but not sure what you would like to see
differently. See also Annex E on a model for software use in
representation information.

DMS: David says: The essence of the environment is the API which is
normally realized by some underlying hardware, etc.

7th para - starting \"In summary \...\"

I never found the Subsection 6.2 refered to in the last sentence.

US: AGREED: Should be 5.2

8th para - starting \"An important \...\" - parts b, c and d

This is transitive closure until we arrive at nodes that are meaningful
to

the designated community. It may help to spell this out

US: REJECT: These words are not really clear to most readers, including
ALL of the review committee.

We found it vital to introduce the CRID (Cedars Reference ID) in order
to

make absolutely clear the need for globally unique names for use as
poniters

in the construction of representation nets. I note that you too have the

ADID. Perhaps here is something else that needs another term in the

glossary.

US: Reject - too much implementation

**[AGREE in part -- we use Content Data Object; correct section number
to 5.2; REJECT the rest]{.underline}**

====================================================

R-64: AGENCY RID NUMBER NARA

10\) PAGE NUMBER:4-23 PARAGRAPH NUMBER: 4

RID SHORT TITLE: Paragraph beginning in summary

DESCRIPTION OF REQUESTED CHANGE: (Use From: \"\...- To \"\...\" formal)

Incorrect reference: Last sentence refers readers to Subsection 6.2,

reference is incorrect, and it is unclear what the reference should be.

SUPPORTING ANALYSIS:

This is a factual error needing correction.

\*\* dms- This should have been 5.2, Access Preservation. Accept change
\*\*

DISPOSITION

ACCEPT

**[AGREE]{.underline}**

========================================

R-65: Page 4-25 4.2.1.4.2 Preservation Description Information

DAVID HOLDSWORTH

The section on Fixity entangles the concepts of error handling, and

authenticity. I propose scrapping any mention of errors. The faithful

preservation of the byte-stream is the job of the archival storage.

Authenticity is a different matter, and perhaps invites the use of
digital

signatures. If this is to be meaningful, it may introduce a new form of

migration, becuase today\'s 1024-bit keys may be easily cracked in 2050,
so

that the authentication may need some refresh process (perhaps another

layer) to sign things afresh with new technology cryptography. (This
begins

to look like a can of worms

US: Propose to replace the corresponding text under FIXITY with:

Fixity Information includes special encoding and error detection schemes
that are specific to instances of Content Objects. Fixity Information
does not include the integrity preserving mechanisms provided by the
OAIS underlying services, error protection supplied by the media and
device drivers used by Archival Storage. The Fixity Information may
specify minimum quality of service requirements for these mechanisms.

DMS: In discussion with David, the point is made that the underlying
services need to be treated with some skepticism for error detection.
Perhaps authenticity is more a matter for an implementation of
provenance.

**[AGREE in part: "Authentication" should be replaced -- use Data
Integrity check or Validation/Verification(XXX \*\*\* ACTION on editor
to check \*\*\*). Accept proposed text for second sentence
onwards.]{.underline}**

=======================================

R-66: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER : 1

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 4-25

PARAGRAPH NUMBER : 1

RID SHORT TITLE : inconsistent references

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

DESCRIPTION OF REQUESTED CHANGE :Use From : \"\...\' To \"\...\" format)

We suggest replacing \'Srepeat Steps 2 through 4\' by \'repeat Steps a
to d\'

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_\_\_\_\_ Editorial : X

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION :Accepted as per May version.

US: Already in the official May version

**[DELETE this RID]{.underline}**

================================================================

R-67: Page 4-26 4.2.1.4.3 Packaging Information

DAVID HOLDSWORTH

The last paragraph is superfluous (or even wrong) if the concept of

underlying abstract form is taken on board enthuiastically.

US: Don\'t see the concern. Suggest replacing the following sentence:

Packaging Information is not guaranteed to be preserved by Migration

DMS: In discussion with David, it may be useful to have the UAF concept
in section 5, and then be referenced as it is now from this section.
Needs review to see if this works.

**[REJECT]{.underline}**

======================================

R-68: Page 4-28 4.2.2.1 Information Package

DAVID HOLDSWORTH

If we had been more definite about the need for a name-space, the first

paragraph could be much crisper

US: REJECT: Too much implementation

**[REJECT]{.underline}**

=======================================

R-69: Page 4-30 4.2.2.3 The Archival Information Package

DAVID HOLDSWORTH

Figure 4-19: swap sides of the two boxes in the embedded Figure 4-9

US: Agreed, and change arrow direction

**[AGREED]{.underline}**

======================================

R-70: AGENCY RID NUMBER : 2

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 4-31

PARAGRAPH NUMBER : 1

RID SHORT TITLE : inconsistent reference

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

DESCRIPTION OF REQUESTED CHANGE :Use From : \"\...\' To \"\...\" format)

We suggest replacing \'and this is discussed and modeled in section 4\'
by

\'and this is discussed and modeled hereafter in this section\'

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_\_\_\_\_ Editorial : X

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION :

Agreed, but as: \'modeled later in this section.\'

US: Agreed

**[AGREED]{.underline}**

===========================================

R-71: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER : 3

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 4-34

PARAGRAPH NUMBER : 5

RID SHORT TITLE : inconsistent reference

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

DESCRIPTION OF REQUESTED CHANGE :Use From : \"\...\' To \"\...\" format)

The reference to \'4.2.3.1\' (this sub-section doesn\'t exist) should be

replace by \'4.2.3\'

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_\_\_\_\_ Editorial : X

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION : Agreed, but already in May version.

**[DELETE this RID]{.underline}**

================================================================

R-72: ICSTI Review

One reviewer compared the Model to the ISO/OSI which formalizes
components that are reasonably well established in practice.

US Response: Yes

Others thought the Model was too detailed and would make a particular
implementation too expensive.

US Response: The model is intended to make the true costs more apparent.
See the following reviewer\'s bullet.

[NO A RID]{.underline}

============================

R-73: ICSTI Review

One reviewer thought that the Model provided a good framework for the
analysis of his company's archiving approaches against high level best
practices and that it pointed out some issues that they had not
previously addressed.

US Response: Great!

**NOT A RID**

==========================

R-74: ICSTI Review

There could be issues related to the granularity of the AIPs. The case
cited by a reviewer is that in which a dissertation is archived by a
national library or institutional archive, but the archive version for
the document when the dissertation is published as a journal article
would reside with the publisher. The two would have separate "owners"
from the copyright standpoint and separate archiving responsibility. On
the other hand it may not make sense to divide such "objects" into
different packages. Minimally, there should be some link between the
two.

US Response: This is a typical problem, and the AIPs, with AIC and AIU
seems to provide a useful framework for these issues. There can
certainly be links between the two in the Descriptors. Provenance can
also address such issues. These are implementation decisions.

**[AGREED -- no change required]{.underline}**

===========================

R-75: ICSTI Review

Fixity Information, which is used to insure integrity, and issues
related to security should be covered more thoroughly.

US Response: Security is a ubiquitous concern and security facilities
are stated to be present in underlying services (e.g., see 4.1.1.1).
Fixity is directed to specific AIPs, and includes such techniques as
checksums and various encoding approaches. We\'re not persuaded by the
comment to add more specifics.

REJECT: agree with US response

=========================

R-76: ICSTI Review

**In the discussion of Representation Networks, the document does a good
job of describing the need for a low level of Representation Information
(i.e., cycling down through various representation schemes all the way
down to a discussion of ASCII). One reviewer thought that it would be
useful to introduce the concept of a base OAIS representation. This
would be a representation object that would be common building blocks
(e.g., ASCII) underlying all other representation information objects.
Almost a more bottom up approach.**

**US Response: It is not clear that there is a base OAIS representation
that will survive for very long. The OAIS needs to track emerging
technology to keep up to date with what is still useful. It is beyond
the scope of the model.**

**[REJECT -- this is an implementation concern for a specific
archive]{.underline}**

========================

### SECTION 5

R-77: Page 5-1 5.1.1 Digital Migration Motivators

DAVID HOLDSWORTH

It is obsolecence of disk and tape drives that is the prime motivator.
It

deserves a mention.

US: Accept, by clarifying what is meant by hardware in the second
bullet, by inserting \" (e.g., disk/tape drives)

**[AGREED]{.underline}**

=================================

R-78: ICSTI Review

The discussion of "Digital migration motivators" seems to over emphasize
the physical decay of the data support medium at the expense of the
obsolescence of the logical context.

US Response: We can add a bit about other changes to the Designated
Community that affect their ability to understand the information.
However, we are not clear what you mean by logical context. Is it like
directory structures or file systems?

**[REJECT -- BUT to clarify the issue change the order of the points in
this section, putting "Improved Cost Effectiveness" first and "Media
Decay" last in case people regard this as a priority order. Note that
that paragraph also addresses technology obsolescence.]{.underline}**

==============================

R-79: Handling old versions

National Library of Australia

Sections 5.1 and 5.1.3.4 state that the outcome of Digital Migration in
an

OAIS is a full replacement for the Archival Information Package that is

undergoing transfer. We understand that by this is meant that the
transfer

process should result in minimum information loss, not that the Archival

Information Package undergoing transfer is necessarily discarded. In
cases

where a new Archival Information Package is created, our archival policy

requires the source AIP to be retained. We might transform an Archival

Information Package from one file type to another to enhance current
access

while retaining the source copy as an archival master. At a later stage,
the

replacement copy might be used as the source of another transformation;
or

we might return to the archival master for the new transformation. It
would

be useful if this requirement to retain source AIPs was clarified in
Section

5.1.3.4.

US: Propose the following changes for clarification:

1\. Section 5.1.3.4, 1^st^ para. Replace material with:

In all cases the intent is to provide maximum information preservation.
The resulting AIP is intended to be a replacement for the AIP that is
undergoing Transformation. The new AIP qualifies as a new **Version** of
the original AIP. The previous versions may be retained.

2\. Section 5.1.4, 2^nd^ para, add sentence: \" The previous versions
may be retained.\"

**[AGREE with proposed responses, but change "new version of the
original AIP" to "new version of the previous AIP. The first version of
the AIP is referred to as the original AIP and may be retained for
verification of information preservation."]{.underline}**

=================================

R-80: AGENCY RID NUMBER NARA

Section 5.1.3 2nd bullet, last sentence Change \"but Replication

can occur without all the constraints of Refreshment.\"

To

\"but may require changes to the Archival Storage mapping
infrastructure.\"

For clarity.

AGREED

Section 5.1.3.4 3rd scenario, penultimate sentence Change

\"This approach is an advantage\"

to

\"This approach would be advantageous..\"

AGREED

US: Agreed

**[AGREED]{.underline}**

=================================

R-81: National Library of Australia

Handling process history information

Section 5.1.4 states that, when an Archival Information Package
undergoes a

Digital Migration that involves Transformation, the process history is

recorded in the Preservation Description Information of the new Archival

Information Package. In contrast, when an Archival Information Package

undergoes a Digital Migration that does not involve Transformation, the

Preservation Description Information does not get updated, but OAIS
still

tracks such migration. Presumably, this information would be stored as
Data

Management Data. If so, this means that process history information is

managed separately depending on the process performed. We are not sure
if

this is an issue, but it is an area where we have found it difficult to
make

a clean mapping between our model for the PANDORA Archive and the OAIS

Reference Model.

US: \*\*\* agree in principle- this is current situation

National Library of Australia

It would assist if examples of this kind of Data Management Data were

included in Sections 1.7.2 and 4.2.3. (See NLA Comment under 5.1.4)

US: Agree in principle

**We agree but the name may be Preservation Process History and will be
added in Data Management.**

=================================================================

### SECTION 6

R-82: AGENCY RID NUMBER NARA

Section 6.1 Bullets

The use of the phrase \"A Local Community\...\" to begin the bullets

is confusing.

Suggest changing to:

\"- Independent - Archives motivated by local concerns, with no
management

or technical interaction among them

\- Cooperating - Archives with potential common producers, common
submission

standards, and common dissemination standards, but no common finding
aids.

\- Federated - Archives with both Local and Global Communities, and
having

both local and global finding aids. The Local Community usually has

priority over the Global Community. Global dissemination and Ingest are

optional features.

\- Shared resources - Archives that have entered into agreements with
other

archives to share resources, perhaps to reduce cost. This requires
various

standards internal to the archive (such as ingest-storage and

access-storage interface standards), but does not alter the community\'s

view of the archive.\"

AGREED

Add definitions of Local Community and Global Community to

Glossary

**AGREED**

==============================

R-83: CCSDS REVIEW ITEM DISPOSITION (RID) :

RID INITIATION FORM

AGENCY RID NUMBER : -6

SUBMITTING ORGANIZATION (Agency, Center) : CNES

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

REVIEWER\'S NAME : Claude HUC CODE :

E-MAIL ADDRESS : huc@cnes.fr

TELEPHONE :33 5 61 27 44 21

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

DOCUMENT NUMBER : CCSDS 650.0-R-1 Red Book, Issue 1

DOCUMENT NAME : Reference Model for an Open Archival Information System

DATE ISSUED : April 2000

PAGE NUMBER : 6-2

PARAGRAPH NUMBER : 2, 3, 4 and 5

RID SHORT TITLE : clarification about terms global and local

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

DESCRIPTION OF REQUESTED CHANGE :

The terms global or local community, global or local access, Global

producer need to be clarified. These termes have not been understood by
the

readers.

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

CATEGORY OF REQUESTED CHANGE :

Technical Fact \_\_\_\_ Recommended : \_\_\_X\_\_\_\_ Editorial :

NOTES :

TECHNICAL FACT : Major technical change of sufficient magnitude as to

render the Recommendation inaccurate and unacceptable if not corrected .

Supporting analysis/rationale is essential)

RECOMMENDED : Change of a nature that would, if incorporated produce a

marked improvement in document quality and acceptance.

EDITORIAL : Typographical or other factual error needing correction.
(this

type of change will be made without feedback to submitter).

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

SUPPORTING ANALYSIS :

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

DISPOSITION :

Define \'local\' and \'global\' early in chapter 6. Local and global
producer

needs review and revision. Alternatively use other terms to convey the

distinctions.

**[AGREED]{.underline}**

===================================

R-84: 6.1 Technical levels \...\...\...\...

DAVID HOLDSWORTH

under Federated, last sentence - too much optionality!

US:ACCEPT: Delete the first \'Optional\'

**[AGREED]{.underline}**

=================================================================

R-85: 6.1.3Federated Archives

DAVID HOLDSWORTH

The section on unique AIP names would benefit from the introduction of a

glossary-level term for such a name (e.g. CRID, ADID).

US: We feel that \'unique AIP name\' is adequate.

**[REJECT]{.underline}**

===================================================================

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/30**   700   Send feedback on RIDS to        DS          20010208   
                        reviewers                                              

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

## OAIS RM Workplan

-   ISO review ends 15^th^ Nov

-   Inputs expected from TvdW (8 Dec for table update) and NB

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/31**   700   New version of OAIS RM doc      DS LR       20010208   

  **P/0010/32**   700   Comments on new draft of OAIS   ALL         20010228   
                        RM                                                     

  **P/0010/33**   700   FINAL FINAL OAIS RM doc to be   DS LR       20010401   
                        submitted to ISO 2^nd^ review                          
  --------------- ----- ------------------------------- ------ ---- ---------- -----

-   US workshop 20-22 Feb 2001 (will generate NASA comments on new
    draft)

-   Projected ISO dates:

    -   Submit 20010401, circulated 20010501, 2 month ISO review, 1
        month consolidation, submitted for FDIS 20010801, published as
        FDIS 20010901 (Sept 2001)

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/34**   700   Inform MC of projected OAIS     DG          20001128   
                        dates                                                  

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

## Nedlib Presentation

Electronic animated presentation about DSEP to introduce the OAIS
concepts in general terms and the DSEP design in particular.

This will be available on the Nedlib Web-site.

## Ingest Process (DB/CNES)

See presentation:
<http://www.ssd.rl.ac.uk/ccsdsp2/oxf00/CCSDS021100-gb3.ppt>

-   AW: Guidelines for Ingest proposed to Shuttle -- they were very
    appreciative

-   BA: However for producers who have well defined processes already
    then they will resist any "standardised" format

-   CH: Dept of Justice -- will define standardised XML-DTD. This is
    invisible to the people who input information.

-   DS: Publishers procedures etc are evolving and, especially if tools
    are available, then they may be amenable to moving to a common
    architecture.

-   BA: NARA has an INGEST verification system -- 100% successful on
    structured data (even e-mail - To, From etc with blob of undefined
    length) -- based on ORACLE. This has been made available to other
    National archives. Beginning work on Proof of Concept for Delivery
    System.

-   LR: CNES presentation stated that they did not want implementation
    in UML. However UML can capture methods and MAY be useful in
    standards.

-   CH: standard objects being developed

    -   TvdW: Elsevier science -- Tulip project -- develop format for
        delivering science journals to libraries. This is a well thought
        out format and RLN are gradually trying to persuade other
        publishers to use this format.

    -   BA: would be useful to capture common elements of various sorts
        of document in various domains e.g. for deeds of gifts to
        various organisations. This would capture a large amount of SIP
        details.

-   NP: an important requirement is that SEARCH is supported and SIP
    must have appropriate information e.g. keywords

-   DG: points out that many of the concepts that are being discussed
    have strong implications for the developments of the Panel work in
    the future and we should remind ourselves from time to time of the
    links to the P2 work. For example keywords and dictionaries are
    related to DEDSL -- and in particular the Discipline Dictionary
    concept in DEDSL.

    -   LR:

    -   CH:

    -   DS: for example one might imagine that there would be work on
        standardised data objects.

-   NP: timetable:

    -   CH: detailed plans need to be made. Have done feasibility study
        so far but this has verified that the work would be possible.

Agency views:

-   CNES/CH lead:

    -   Define first set of general objects

        -   Classification -- mapping to OAIS types e.g. PDI etc

        -   way to manage relationships between objects e.g. rep info to
            data object

    -   Case study

        -   E.g. Mission archives

    -   Detailed specialisation of the objects

        -   New attributes

        -   Brought out by Use Cases

    -   More detailed definition of steps in Ingest process

        -   Precise definitions of model, contents of SIP

            -   Include dynamic aspects

            -   Relationship of the model of the information being
                delivered to the SIPs and delivery sessions

                -   Consistency checks with model

    -   Tools

        -   XML implementation

            -   For the Model and for each SIP

-   DS/NASA:

    -   NSSDC interested in collaborating with CDPP for INGEST
        standardisation

        -   Level of support TBD -- feasible in the 2 year timescale of
            CH

        -   Concerns with metadata linkages

        -   Further work needed

        -   Look at relationship of objects and PDI info

        -   Need to flesh out work plan, scope

    -   Mission Archives:

        -   They are not so concerned with preservation (although they
            **[should]{.underline}** be!!!)

        -   They may be more concerned with objects related to Finding
            Aids.

        -   Also may be interested in "hand-off" process to longer-term
            archives i.e. where they act as Producer, putting data into
            Longer Term archive

        -   Requirement for increasing automation may be a driver e.g
            use of automatic Ingest processing

-   YI/NASDA

-   TvdW:

    -   Case study of Deposit Library -- their own and possibly other
        national

    -   Work on XLM/DTD for more generic type of objects

    -   Attempt to get Publishers involved in this effort

        -   Mission archive bullet points may be useful in the
            discussions

    -   Attempt to generalise the lessons learned from bottom up
        approach

-   BA:

    -   Ingest documents -- would it be worth analysing these to extract
        common areas

    -   Look at MARC (MAchine Readable Catalogue) description language
        may have some useful lessons

    -   Details of Ingest tools will be useful to others

        -   Produces standardised output product which will facilitate
            long-term preservation

        -   Case studies

-   AW:

    -   Case study

        -   Great multiplicity of producers/ formats make
            standardization of Ingest standards difficult

            -   Within each discipline e.g. hematology, here are
                standard formats. The challenge is to have
                cross-disciplinary approach

        -   However there are efforts to do some standardization to
            reduce costs

            -   Could be Guidelines

            -   Data Format plans on Web site (STS107) is becoming focus
                of mission planning and related presentations.

                -   Formats are specific to this mission

-   NP:

    -   Mission Archives usually

    -   One mission's Final Archive is being designed (XMM):

        -   Wants to make it generic and portable

            -   Currently rejects submission if catalogue info is
                invalid or missing

            -   Could also reject data submitted for archiving unless it
                has PDI

                -   Specified as PVL with specified keywords

            -   Currently Oracle 7, Solaris 6

                -   Uses SQL API

                -   All written in C

                -   Not O-O

            -   Needs to be completed in 9 months

            -   Will take into account the OAIS related work as far as
                possible within the project time constraints

-   GMP:

    -   For ESA Earth Observation missions, ESRIN is both producer and
        archive and so they can control formats.

        -   Exchange of data between long-term archives is more
            difficult. CEOS is attempting to define an exchange format.
            (see XXXX).

    -   Willing to provide help producing Case Study

    -   OAIS comments

        -   does not have adequate penetration in Space community

        -   very valuable in giving common vocabulary

-   NB: (UK Higher Education research)

    -   Major electronic collections

        -   Identifying gaps and services

        -   Build on CEDARS

        -   Below level of Reference Model may need "Implementation
            Group"

            -   May be a number of these for different disciplines

            -   LR: could be analogies with Z39.50 Implementation Group
                -- different profiles for different disciplines (see
                XXX)

    -   Lot of effort into training and raising awareness

        -   Few case studies of Ingest at the moment so Case studies
            being planned here would be useful for this

        -   Interested in Nedlib presentation -- would like this to be
            customizable

        -   Need to sell it to producers

        -   Need to sell it to funding bodies

    -   Technical metadata

        -   Technical documentation of software -- a number of studies
            done -- tend to show lack of "preservation"

        -   Cross-domain and international collaboration would be useful

    -   2 Case Studies are available:

        -   Oxford Text Archive

        -   History Data Service

-   DG:

    -   GRIDS XXX

    -   RAL archives XXX

## Work Plan

Revise Management Plan (NP).

### ARCHIVING SUBMISSION STANDARDS WP

-   Define first set of general objects

    -   Classification -- mapping to OAIS types e.g. PDI etc

    -   way to manage relationships between objects e.g. rep info to
        data object

```{=html}
<!-- -->
```
-   Concept paper (710.5)

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/35**   700   Preliminary version of Archive  CH          20010201   
                        Objects CP                                             

  **P/0010/36**   700   Email discussion of Archive     ALL         20010301   
                        Object CP and telecon if                               
                        required                                               

  **P/0010/37**   700   Second version of Archive       CH          20010401   
                        Objects CP                                             
  --------------- ----- ------------------------------- ------ ---- ---------- -----

-   Case study

```{=html}
<!-- -->
```
-   Concept paper (710.6)

+--------+---+-------------------------------+-----+---+--------+----+
| *      | 7 | Preliminary version of Case   | T   |   | 20     |    |
| *P/001 | 0 | Studies CP                    | vdW |   | 010301 |    |
| 0/38** | 0 |                               | NP  |   |        |    |
|        |   |                               |     |   |        |    |
|        |   |                               | NB  |   |        |    |
|        |   |                               |     |   |        |    |
|        |   |                               | BA  |   |        |    |
|        |   |                               |     |   |        |    |
|        |   |                               | DS  |   |        |    |
|        |   |                               |     |   |        |    |
|        |   |                               | CH  |   |        |    |
|        |   |                               | (le |   |        |    |
|        |   |                               | ad) |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+
| *      | 7 | Compiled version of Case      | CH  |   | 20     |    |
| *P/001 | 0 | Studies CP                    |     |   | 010401 |    |
| 0/39** | 0 |                               |     |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+

-   Detailed specialisation of the objects

    -   New attributes

    -   Brought out by Use Cases

-   More detailed definition of steps in Ingest process

    -   Precise definitions of model, contents of SIP

        -   Include dynamic aspects

        -   Relationship of the model of the information being delivered
            to the SIPs and delivery sessions

            -   Consistency checks with model

-   Tools

    -   XML implementation

        -   For the Model and for each SIP

            **INPUTS**: OAIS

**OUTPUTS**:

### ARCHIVE RECOMMENDED PRACTISES

## Access/Display Preservation and Software Preservation

-   Discussion group/ resource page

    -   Collaboration about investigating this including

        -   Limitations of emulation

        -   Use of Virtual machines such as JAVA

    -   Members: TvdW, LS, NB, LR (JGG to help with WWW)

+--------+---+-------------------------------+-----+---+--------+----+
| *      | 7 | Preliminary Roadmap for       | LR  |   | 20     |    |
| *P/001 | 0 | Software Preservation         | Tvd |   | 010301 |    |
| 0/40** | 0 |                               | WLS |   |        |    |
|        |   |                               |     |   |        |    |
|        |   |                               | NB  |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+
| *      | 7 | Software Preservation Web     | LR  |   | 20     |    |
| *P/001 | 0 | site                          | JGG |   | 010401 |    |
| 0/41** | 0 |                               |     |   |        |    |
+--------+---+-------------------------------+-----+---+--------+----+

## Mission Archives

-   Use Case template has been distributed

    -   Intended to describe an existing system in a fairly complete way

> It was decided to put this subject as "pending", and it will be
> re-assessed at the next IWS (May -- AMES)

## Archive Certification/Checklist/Best Practice/Guidelines

-   Interest was expressed by DG - the checklists may be of use for
    Research Council data policy development -- driven by the GRID

-   NB note that OCLC and RLG may be interested

-   DS: material collected in AWIICS

  --------------- ----- ------------------------------- ------ ---- ---------- -----
  **P/0010/42**   700   Provide contact names for OCLC  NB          20001131   
                        and RLG                                                

  **P/0010/43**   700   First draft CP on               DG          20010401   
                        Certification/Guidelines/....                          
                        (WP 730)                                               
  --------------- ----- ------------------------------- ------ ---- ---------- -----

-   GMP: original ISO9000 is comparable with OAIS. New ISO9000 places
    additional continuous improvement requirement.

# Appendix A: WP100 Status Report {#appendix-a-wp100-status-report .unnumbered}

(see minutes)

+------------+-------------------------------+-------------------------+
| Agenda     |                               |                         |
+------------+-------------------------------+-------------------------+
| **30       |                               |                         |
| October    |                               |                         |
| 2000**     |                               |                         |
+------------+-------------------------------+-------------------------+
| 9:00 AM    | Introductions                 | David Giaretta          |
+------------+-------------------------------+-------------------------+
| 9:15 AM    | Welcome and Hosting Details   | David Giaretta          |
+------------+-------------------------------+-------------------------+
| 9:30 AM    | Review of Minutes from Last   | David Giaretta          |
|            | Meeting\                      |                         |
|            | Review of Action Items        |                         |
+------------+-------------------------------+-------------------------+
| 10:15 AM   | WP100: Management\            | David Giaretta\         |
|            | MC/TSG Reports\               | Agency Heads            |
|            | Agency Reports                |                         |
|            |                               |                         |
|            | CODATA meeting report (LR)    |                         |
|            |                               |                         |
|            | Panel Direction\              |                         |
|            | AOB                           |                         |
+------------+-------------------------------+-------------------------+
| 11:45 AM   | WP100: Action Items           | David Giaretta          |
+------------+-------------------------------+-------------------------+
| 1:00 PM    | WP600: Implementers Workshop  | Lou Reich (moderator)   |
+------------+-------------------------------+-------------------------+
| 1:15 PM    | WP600: Implementers Workshop\ | Gian Maria Pinna        |
|            | AMS Demo Report\              |                         |
|            | CEOS Report                   |                         |
+------------+-------------------------------+-------------------------+
| 2:00 PM    | WP600: Implementers Workshop\ | Arnaud Lucas            |
|            | CNES Free Software Server\    |                         |
|            | EAST Information Web Server\  |                         |
|            | EAST Activities               |                         |
+------------+-------------------------------+-------------------------+
| 3:45 PM    | WP600: Implementers Workshop  | Lou Reich               |
|            | -- AOB                        |                         |
|            |                               |                         |
|            | Migration & Ingest work at    |                         |
|            | NSSDC (DS)                    |                         |
+------------+-------------------------------+-------------------------+
| 4:00 PM    | WP600: Implementers           | Lou Reich               |
|            | Workshop - Action Items       |                         |
+------------+-------------------------------+-------------------------+
| 5:00 PM    | Adjourn                       |                         |
+------------+-------------------------------+-------------------------+

  ------------ -------------------------------- -------------------------
  **31 October                                  
  2000**                                        

  10:00 AM     WP500: Languages - DEDSL - XML   CNES
               Syntax                           

               WP500: Languages - DEDSL -       CNES
               Abstract Syntax RIDS             

               WP500: Languages - DEDSL - PVL   CNES
               Syntax RIDS                      

               WP500: Languages - DEDSL - XML   TBD
               Demonstrations                   

               WP500: Languages - DEDSL - Green CNES
               Book                             

               WP500: Action Items              Nestor Peccia
  ------------ -------------------------------- -------------------------

  ------------ --------------------------------- -------------------------
  **01                                           
  November                                       
  2000**                                         

  9:00 AM      WP700: Archiving - Welcome and    Don Sawyer
               Introductions                     

  9:15 AM      WP700: Archiving - Agency Reports Agency Heads

  10:15 AM     WP700: Archiving - CNES           Claude Huc
               Activities                        

  10:45 AM     WP700: Archiving - NEDLIB         Titia Van Der Werf
               experimentation using OAIS        

  11:30 AM     WP700: Archiving - OAIS RID       TBD
               Review                            

  1:00 PM      WP700: Archiving - OAIS RID       TBD
               Review                            

  3:15 PM      WP700: Archiving - OAIS RID       TBD
               Review                            

  4:45 PM      WP700: Action Items               Don Sawyer
  ------------ --------------------------------- -------------------------

  ---------------- ---------------------------- -------------------------
  **02 November                                 
  2000**                                        

  9:00 AM          WP700: Archiving - OAIS RID  TBD
                   Review                       

  10:15 AM         WP700: Archiving - OAIS RID  TBD
                   Review                       

  1:00 PM          WP700: Archiving - OAIS RID  TBD
                   Review                       

  3:15 PM          WP700: Archiving - OAIS RID  TBD
                   Review                       

  4:45 PM          WP700: Action Items          Don Sawyer
  ---------------- ---------------------------- -------------------------

  ----------------- ---------------------------- -------------------------
  **03 November                                  
  2000**                                         

  9:00 AM           WP700: Archiving - Standard  Daniele Boucon
                    Producer to Archive          
                    Interface                    

  10:00 AM          WP700: Archiving - Ingest    TBD

  1:00 PM           WP700: Archiving - Mission   TBD
                    Archives                     

  3:15 PM           WP700: Archiving - Mission   TBD
                    Archives                     

  4:15 PM           WP700: Archiving -- AOB      Don Sawyer (moderator)

  4:45 PM           WP700: Action Items          Don Sawyer
  ----------------- ---------------------------- -------------------------

+----------------+---------------------------+-------------------------+
| **06 November  |                           |                         |
| 2000**         |                           |                         |
+----------------+---------------------------+-------------------------+
| 10:00 AM       | WP400: Structures -       | Nestor Peccia           |
|                | Internet SFDU             |                         |
|                |                           |                         |
|                | XML Packaging             |                         |
+----------------+---------------------------+-------------------------+
| 10:45 AM       | WP400: Structures -       | Nestor Peccia           |
|                | Internet SFDU             |                         |
+----------------+---------------------------+-------------------------+
| 11:15 AM       | WP400: Structures -- AOB  | Nestor Peccia           |
+----------------+---------------------------+-------------------------+
| 11:45 AM       | WP400: Action Items       | Nestor Peccia           |
+----------------+---------------------------+-------------------------+
| 1:00 PM        | WP500: Languages -- PVL   | Don Sawyer (moderator)  |
|                | Tutorial                  |                         |
|                |                           |                         |
|                | XSIL, SML etc.            |                         |
|                |                           |                         |
|                | Report on CEOS activities |                         |
|                | (WC)                      |                         |
|                |                           |                         |
|                | WP500: Action Items       |                         |
|                |                           |                         |
|                | Preparation for TSG/MC    |                         |
+----------------+---------------------------+-------------------------+
| 3:15 PM        | WP300: Data               | Don Sawyer (moderator)  |
|                | Administration            |                         |
|                |                           |                         |
|                | ESA CA software -- new    |                         |
|                | version                   |                         |
+----------------+---------------------------+-------------------------+
| 4:45 PM        | WP300: Action Items       | Don Sawyer              |
+----------------+---------------------------+-------------------------+

#  {#section-4 .unnumbered}

# Appendix B: WP200 Status Report {#appendix-b-wp200-status-report .unnumbered}

+------+----------------+-------------+-------------+----------------+
| **   |                |             |             |                |
| PROG |                |             |             |                |
| RESS |                |             |             |                |
| RE   |                |             |             |                |
| PORT |                |             |             |                |
| ON   |                |             |             |                |
| WP2  |                |             |             |                |
| 00** |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| **   | **PROGRESS**   | **CHANGES** | *           | **FORECAST**   |
| WP** |                |             | *PROBLEMS** |                |
+------+----------------+-------------+-------------+----------------+
| WP2  | Yellow book    |             | N/A         | CLOSED         |
| 10.3 | published.     |             |             |                |
|      |                |             |             |                |
| C    |                |             |             |                |
| CSDS |                |             |             |                |
| P2   |                |             |             |                |
| Met  |                |             |             |                |
| hodo |                |             |             |                |
| logy |                |             |             |                |
| docu |                |             |             |                |
| ment |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| WP2  | Draft of       | Put on hold | None        | May not be     |
| 10.4 | document is    |             | identified  | worth pursuing |
|      | available,     |             |             | to published   |
| SADT | Comments       |             |             | book.          |
| docu | awaited        |             |             |                |
| ment |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| WP2  | More detailed  | Apply       |             | This work      |
| 20.4 | WP description | Object      |             | package will   |
|      | needed.        | Model as    |             | probably be    |
| High |                | the         |             | re-designed to |
| L    | NOTE: This     | organising  |             | fit in to the  |
| evel | work package   | principle   |             | broad plans of |
| Requ | is in practice | of Panel 2  |             | P2 (e.g.       |
| irem | currently      | work.       |             | Internet SFDU  |
| ents | being subsumed |             |             | etc), within   |
| and  | by the process |             |             | the overall    |
| Mo   | of mapping out |             |             | CCSDS          |
| dels | P2 work in the |             |             | Strategic and  |
| Doc. | light of       |             |             | Operating      |
|      | developments   |             |             | plans.         |
|      | in the Global  |             |             |                |
|      | Information    |             |             |                |
|      | I              |             |             |                |
|      | nfrastructure, |             |             |                |
|      | e.g. Internet  |             |             |                |
|      | SFDU etc.      |             |             |                |
+------+----------------+-------------+-------------+----------------+
| W    |                |             |             |                |
| P230 |                |             |             |                |
+------+----------------+-------------+-------------+----------------+

# Appendix C: WP300 Status Report {#appendix-c-wp300-status-report .unnumbered}

# Appendix D: WP400 Status Report {#appendix-d-wp400-status-report .unnumbered}

**WP400 Status Report**

+------+----------------+-------------+-------------+----------------+
| **   |                |             |             |                |
| PROG |                |             |             |                |
| RESS |                |             |             |                |
| RE   |                |             |             |                |
| PORT |                |             |             |                |
| ON   |                |             |             |                |
| WP4  |                |             |             |                |
| 00** |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| **   | **PROGRESS**   | **CHANGES** | *           | **FORECAST**   |
| WP** |                |             | *PROBLEMS** |                |
+------+----------------+-------------+-------------+----------------+
| W    | NASA will      | No          | None        | SFDU packaging |
| P430 | present some   | significant | identified. | using XML has  |
|      | papers on      | changes in  |             | to be          |
| Exte | Formats        | the         |             | discussed at   |
| nded | Evolution      | definition  |             | RAL.           |
| St   | Process :      | of the      |             |                |
| ruct |                | activity or |             |                |
| ures | i.e. Time      | work to be  |             |                |
|      | Series Object  | done have   |             |                |
| Con  |                | been        |             |                |
| cept | level of       | identified. |             |                |
|      | abstraction    |             |             |                |
|      |                | To be       |             |                |
|      | XDF            | discussed   |             |                |
|      |                | at RAL IWS  |             |                |
|      | Internet SFDU  |             |             |                |
|      | development    |             |             |                |
+------+----------------+-------------+-------------+----------------+
| W    | Referencing    | None        | None        | WP closed.     |
| P440 | Environment BB |             | identified  |                |
|      | submitted for  |             |             |                |
| File | official issue |             |             |                |
| Na   | to CCSDS       |             |             |                |
| ming | editor         |             |             |                |
| Con  |                |             |             |                |
| vent |                |             |             |                |
| ions |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| W    | Addendum to    | None        | None        | WP closed      |
| P450 | structures BB  |             | identified  |                |
|      | submitted for  |             |             |                |
| Adde | official issue |             |             |                |
| ndum | to CCSDS       |             |             |                |
| to   | editor . MC    |             |             |                |
| St   | approved its   |             |             |                |
| ruct | publicatio.    |             |             |                |
| ures |                |             |             |                |
| BB   |                |             |             |                |
+------+----------------+-------------+-------------+----------------+
| W    | BB was         | None        | SFDU        | To be          |
| P460 | reaffirmed     |             | packaging   | discussed at   |
|      |                |             | using XML   | RAL IWS        |
| St   |                |             | approach    |                |
| ruct |                |             |             |                |
| ures |                |             |             |                |
|      |                |             |             |                |
| BB   |                |             |             |                |
| re   |                |             |             |                |
| view |                |             |             |                |
+------+----------------+-------------+-------------+----------------+

  ------------- ----------------- -------------- -------------- -----------------
  **MILESTONE                                                   
  TABLE FOR                                                     
  WP400**                                                       

  **WP \#**     **DESCRIPTION**   **Management   **STATUS**     **PROJECTED
                                  Plan                          COMPLETION DATE**
                                  Completion                    
                                  Date**                        

  430.1         Extended          01.04.95       Closed         26.04.95
                Structures                                      
                Concept Paper                                   

  440.1         Referencing       30.04.95       Closed         31.03.95
                Environment - WB                                
                Issue 1                                         

  440.2         Referencing       31.08.95       Closed         31.08.95
                Environment - WB                                
                Issue 2                                         

  440.3         Referencing       21.10.95       Closed         21.10.95
                Environment - WB                                
                Issue 3                                         

  440.4         Referencing       03.11.95       Closed         31.05.96
                Environment - RB                                
                Issue 1                                         

  440.5         SFDU - Tutorial   Tbd            Open           Tbd
                WB Issue 1.1                                    

  440.6         SFDU Tutorial GB  Tbd            Open           Tbd
                Issue 2                                         

  450.1         Structure         31.12.95       Closed         31.12.95
                Corrigendum,                                    
                Draft Issue                                     

  450.2         Structure         30.03.96       Closed         30.03.96
                Corrigendum,                                    
                Issue 2.1 (blue)                                
                MC approved issue                               

  460.1         Report            New            Open           Tbd
                recommending                                    
                suggesting needed                               
                updates                                         

  460.2         Structures RB,    New            Open           Tbd
                Issue 2.2                                       

  460."         Structures BB,    New            Open           Tbd
                Issue 3                                         
  ------------- ----------------- -------------- -------------- -----------------

# Appendix E: WP500 Status Report {#appendix-e-wp500-status-report .unnumbered}

+------+-----------------------+-------+---------------------+---------+
| **   |                       |       |                     |         |
| PROG |                       |       |                     |         |
| RESS |                       |       |                     |         |
| RE   |                       |       |                     |         |
| PORT |                       |       |                     |         |
| ON   |                       |       |                     |         |
| WP5  |                       |       |                     |         |
| 00** |                       |       |                     |         |
+------+-----------------------+-------+---------------------+---------+
| **   | **PROGRESS**          | *     | **PROBLEMS**        | **FOR   |
| WP** |                       | *CHAN |                     | ECAST** |
|      |                       | GES** |                     |         |
+------+-----------------------+-------+---------------------+---------+
| W    | BB and GB under       | WP    | WP closed           | WP      |
| P530 | publication           | c     |                     | closed  |
|      |                       | losed |                     |         |
| Ada  |                       |       |                     |         |
| as a |                       |       |                     |         |
| DDL  |                       |       |                     |         |
+------+-----------------------+-------+---------------------+---------+
| W    | DEDSL (Abstract       | RIDs  | > None              | Issue   |
| P560 | Syntax, PVL Concrete  | To be |                     | DEDSL   |
|      | Syntax) are under RB  | disc  |                     | BB and  |
| Stan | review process. CNES  | ussed |                     | PVS     |
| dard | RIDs were received.   | at    |                     | Syntax  |
| DED  | DEDSL XML Concrete    | RAL   |                     | as BBs  |
| St   | Syntax draft was      |       |                     | by      |
| ruct | issued.               |       |                     | e-mail  |
| ures |                       |       |                     | ballot. |
+------+-----------------------+-------+---------------------+---------+
| W    | None since Toulouse   | None  | The WP tasks ( to   | We need |
| P571 | 95 Workshop           |       | derive the          | to      |
|      |                       |       | requirements for    | discuss |
| Data |                       |       | the DEDSL, and      | how to  |
| Des  |                       |       | distinguish between | go      |
| crip |                       |       | DDL and DEDSL       | ahead   |
| tion |                       |       | functionality ) are | in this |
| Req  |                       |       | already reflected   | WP      |
| uir. |                       |       | in the DEDSL        |         |
| &    |                       |       | document.           | Sug     |
| Log  |                       |       |                     | gestion |
| ical |                       |       |                     | to      |
| M    |                       |       |                     | delete  |
| odel |                       |       |                     | /       |
|      |                       |       |                     | cancel  |
|      |                       |       |                     | the WP  |
+------+-----------------------+-------+---------------------+---------+
| W    | -   BB was reissued   | Drfat | None                | PVL GB  |
| P511 |                       | to be |                     | to be   |
|      | -   PVL GB draft was  | disc  |                     | updated |
| PVL  |     issued            | ussed |                     |         |
| BB   |                       | at    |                     |         |
| Re   |                       | RAL   |                     |         |
| view |                       |       |                     |         |
+------+-----------------------+-------+---------------------+---------+
| W    | The CIP Specification | None  | Doc. Structure      | We have |
| P590 | Release B 2.4 has     |       | changes (to         | to      |
|      | been issued.          |       | differentiate       | discuss |
| Ev   |                       |       | discipline          | how to  |
| alua |                       |       | independent against | go      |
| tion |                       |       | EO) to be discussed | ahead   |
| of   |                       |       | at RAL IWS          | at RAL  |
| C    |                       |       |                     | IWS.    |
| IP-B |                       |       |                     |         |
| S    |                       |       |                     |         |
| peci |                       |       |                     |         |
| fica |                       |       |                     |         |
| tion |                       |       |                     |         |
+------+-----------------------+-------+---------------------+---------+

  ------------- --------------------------- -------------- ------------ -------------
  **MILESTONE                                                           
  TABLE FOR                                                             
  WP500**                                                               

  **WP \#**     **DESCRIPTION**             **Management   **STATUS**   **PROJECTED
                                            Plan                        COMPLETION
                                            Completion                  DATE**
                                            Date**                      

  560.3         DED Interchange Structure   30.04.95       Closed       02.10.95
                White Book                                              

  560.4         DED Interchange Structure   30.09.95       Superseded   N/A
                Tutorial                                                

  571.2         Report on applications of   Tbd            Open         tbd
                DDL to selected projects                                

  571.4         Data Description            Tbd            Open         tbd
                Requirements and Logical                                
                Model - Issue 2                                         

  511.1         Report on proposed updates  Tbd            Open         tbd
                to PVL BB                                               

  511.2         PVL BB Issue 1.1            Tbd            Open         tbd

  511.3         PVL GB Issue 2.0            Tbd            Open         tbd

  590.1         Analysis of domain          Tbd            Open         tbd
                independence of CIP-B                                   

  590.2         Cover letter for informal   Tbd            Open         tbd
                CIP- Review                                             

  590.3         Set of RIDs to CEOS/PTT     Tbd            Open         tbd
                summarising informal agency                             
                reviews                                                 

  590.4         Report to P2 on approach to Tbd            Open         tbd
                standardising CIP                                       
  ------------- --------------------------- -------------- ------------ -------------

# Appendix F: WP600 Status Report {#appendix-f-wp600-status-report .unnumbered}

(see minutes)

# Appendix G: WP700 Status Report {#appendix-g-wp700-status-report .unnumbered}

(see minutes)

#  {#section-7 .unnumbered}

#   {#section-8 .unnumbered}

# Appendix H: List of Registered Documents 

  -------------- -----------------------------------------------------------------------------------------------
  **Document     **OXF/00/P2/N1**
  Number:**      

  **Title**      Minutes of Annapolis May 2000

  **Author**     Panel 2

  **Agency**     Panel 2

  **Abstract**   Minutes of the last meeting

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2/ann00/min0005-d.doc>

  **Location**   

                 

  **Document     **OXF/00/P2/N2**
  Number:**      

  **Title**      DEDSL - XML/DTD Syntax

  **Author**     A. LUCAS

  **Agency**     CNES

  **Abstract**   Draft recommendation of the XML/DTD implementation of the DEDSL

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/books/lang/dedsl_xml/DEDSLXML_october2000.doc>

  **Location**   /books/lang/dedsl_xml/DEDSLXML_october2000.doc

                 

  **Document     **OXF/00/P2/N3**
  Number:**      

  **Title**      OAIS Critiques/RIDs

  **Author**     Donald Sawyer (editor)

  **Agency**     NASA

  **Abstract**   A complete list of known OAIS RIDs as of 25 October, 2000.

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/books/archive/refmodel/oaisrids/RAL-RIDS.doc>

  **Location**   books/archive/refmodel/oaisrids/RAL-RIDS.doc

                 

  **Document     **OXF/00/P2/N4**
  Number:**      

  **Title**      Excerpts from OAIS Reference Model on Preservation of Information and Access, and an Analysis
                 of How They Appear Functi

  **Author**     Donald Sawyer and US ISO team

  **Agency**     NASA

  **Abstract**   This was generated to aid an analysis of how preservation concepts are discussed in the OAIS
                 document. It makes interesting reading. It lead the US group to propose a presrvation planning
                 function. Note there are some included issues raised by DMS on d

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/books/archive/refmodel/oaisrids/pres-ext.doc>

  **Location**   books/archive/refmodel/oaisrids/pres-ext.doc

                 

  **Document     **OXF/00/P2/N5**
  Number:**      

  **Title**      Parameter Value Language - A Tutorial

  **Author**     John Garrett

  **Agency**     NASA

  **Abstract**   This is an update of the PVL Tutorial Green Book to accomodate the extended character set
                 version of PVL (CCSD0008).

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/books/lang/PVL/641x0w1x1.doc>

  **Location**   /books/lang/PVL/641x0w1x1.doc

                 

  **Document     **OXF/00/P2/N6**
  Number:**      

  **Title**      Comparison of ISO/IEC 11179-3 and CADS Registration Attributes

  **Author**     John Garrett

  **Agency**     NASA

  **Abstract**   This is basically a couple tables comparing the ISO/IEC 11179-3 and the CADS Registration
                 Attributes.

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/meetings/oxf_p0010/Compare11179CADS.doc>

  **Location**   meetings/oxf_p0010/Compare11179CADS.doc

                 

  **Document     **OXF/00/P2/N7**
  Number:**      

  **Title**      Proposed RED BOOK Update Section 4.1

  **Author**     Lou Reich and US ISO Team

  **Agency**     NASA

  **Abstract**   This is section 4.1 only, with updates reflecting a proposed new function called Preservation
                 Planning. More context is given in \'section 1\'.

  **URL**        <http://www.ssd.rl.ac.uk/ccsdsp2_mirror/mirror/books/archive/refmodel/650x4.1.doc>

  **Location**   books/archive/refmodel/650x4.1.doc

                 

  **Document     **OXF/00/P2/N8**
  Number:**      

  **Title**      A Possible Time-Series Object

  **Author**     Don Sawyer,Andrew Davis, John Garrett, Carrie Gonzales, David Han, Joe King, Mik

  **Agency**     NASA

  **Abstract**   A look at a possible time series object to see how various formats might support it, and to see
                 if the community is interested in standardizing such an object

  **URL**        <http://ssdoo.gsfc.nasa.gov/nost/fep/levels_layers16.doc>

  **Location**   

                 

  **Document     **OXF/00/P2/N**
  Number:**      

  **Title**      Use Case Templates

  **Author**     Lou Reich Provided

  **Agency**     NASA

  **Abstract**   A description and example of how to generate use cases, originally prepared for OGC catalog
                 work. Intended here as an approach to generating mission archive systems.

  **URL**        

  **Location**   meetings/oxf_p0010/UseCase.rtf

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

 

# Appendix I: Open Action Item List {#appendix-i-open-action-item-list .unnumbered}

**[Sorted by Work Package and Action ID]{.underline}**

  -------- -------------- --------------------------------------- ------------------ ------------- ------------
  **WP**   **ActionID**   **Description**                         **ActioneeList**   **DueDate**   **Status**

  100      P/0005/04      Follow up CFDP (GPC) , Navigation       DG DS NP           20001130      Open
                          (P1J-) and On-board data transfer to                                     
                          maintain ongoing discussions                                             

  100      P/0010/01      Distribute latest draft 8601            LR                 20001115      Open

  100      P/0010/02      Ask about \"Space Day\" at TSG and MC   DG LR              20001128      Open

  100      P/0010/03      Find out about GRID work at AMES and    DS                 20001115      Open
                          EO-GRID work                                                             

  100      P/0010/04      Contact Brian McMahon                   DG                 20001128      Open

  100      P/9705/01      Revise sections 3.2 and 3.3 of the P2   DS                 pending       pending
                          Overview document                                                        

  100      P/9705/02      Provide comments on the new P2 Overview ALL                pending       pending
                          document to NP                                                           

  100      P/9911/53      New work on OAIS Methodology for        DS(Lead) CH GMP    20010415      Open
                          submission                                                               

  100      P/9911/54      New work on ingest standards - i.e.     DS(Lead) NP GMP CH 20010415      Open
                          more detailed - mission archives        LR JGG                           

  100      P/9911/55      New work on Internet SFDUs, JAVA        DG(lead) LR DS JGG 20010415      Open
                          objects etc                                                              

  100      P/9911/56      New work on XML-DEDSL related           DM(lead) LR        20010415      Open
                          presentation tools                                                       

  100      P/9911/57      New work on CAA services                JGG(lead) DG       20010415      Open

  100      P/9911/58      New work on P2 Cookbook for Projects    DS(lead) NP PM     20010415      Open

  100      P/9911/59      New work on OAIS certification          BA DG              20010415      Open

  200      P/9611/06      Produce the initial draft of the        DG                 pending       pending
                          document that will lead to the WB                                        
                          specified on WP220                                                       

  200      P/9810/05      Distribute selected project produced    ALL                ongoing       ongoing
                          JAVA interfaces, e.g. for Dictionary                                     
                          access or AIP access, to Panel for                                       
                          comments                                                                 

  300      P/0005/05      Follow up EPA software development      DS JGG             ongoing       ongoing

  300      P/0010/05      Check reaffirmation of CADS             DG                 20001128      Open

  300      P/9705/11      Investigate MIME registration of SFDU   DS                 20010315      Open
                          and either write concept paper or                                        
                          actually register it                                                     

  300      P/9810/09      DS to pursue URN information            DS                 ongoing       ongoing

  300      P/9905/13      Review CADS BB for 5 year review cycle  ALL                pending       pending

  400      P/0005/08      Email suggested XML-SFDU structure      LR DG              20010415      Open

  400      P/0005/09      Investigate registration of namespace   LR                 20010415      Open

  400      P/0005/11      Monitor and circulate information about DS                 ongoing       ongoing
                          relevant OMG developments                                                

  500      P/0005/18      Consult OGC on how to work with W3C     LR                 20010530      Open

  500      P/0010/06      Provide Technical part of SOW for data  NP                 20001231      Open
                          distribution system (if approved                                         
                          project)                                                                 

  500      P/0010/07      Use Case and Requirements plus tools    NP                 20010331      Open
                          and technologies for what he has to                                      
                          distribute                                                               

  500      P/0010/09      Comment on requirements for Internet    ALL                20001215      Open
                          SFDU (section 4.2.1 in minutes of                                        
                          OXF00)                                                                   

  500      P/0010/10      Produce prototype Internet SFDU         DG                 20010201      Open
                          implementation and tool                                                  

  500      P/0010/11      New issue of DEDSL-XML book             AL                 20001108      Open

  500      P/0010/12      Email comments on DEDSL-XML to AL       ALL                20001115      Open

  500      P/0010/13      Telecon on DEDSL-XML                    ALL                20001116      Open

  500      P/0010/14      New issue of DEDSL-XML book             AL                 20001122      Open

  500      P/0010/15      Email comments/approval                 ALL                20001124      Open

  500      P/0010/16      Final version on DEDSL-XML              AL                 20001127      Open

  500      P/0010/17      Request MC to hold email ballot for     DG                 20001128      Open
                          DEDSL to be published as BB                                              

  500      P/0010/18      Send out proposals for RID resolution   PM                 20010115      Open

  500      P/0010/19      Telecon to resolve DEDSL RIDS           ALL                20010123      Open

  500      P/0010/20      New version of DEDSL Abstract and       PM                 20010210      Open
                          DEDSL-PVL                                                                

  500      P/0010/21      Review final draft of DEDSL Abstract    ALL                20010315      Open
                          and DEDSL PVL                                                            

  500      P/0010/22      Request email ballot for DEDSL Abstract DG                 20010322      Open
                          and DEDSL-PVL                                                            

  500      P/0010/23      Produce DEDSL Green Book                PM AL              20010401      Open

  500      P/9810/42      Get more detailed specifications of PDS DS                 20010201      Open
                          administrative keywords for the                                          
                          Tutorial                                                                 

  500      P/9810/43      Consider adding examples of             PM                 20010415      Open
                          registration methods to DEDSL Tutorial                                   

  600      P/9911/30      Provides updates for P2 software page   ALL                ongoing       ongoing
                          http://www.ccsds.org/p2/software.html                                    

  600      P/9911/34      Provide suggestions for CAA services to ALL                20010215      Open
                          JGG                                                                      

  600      P/9911/35      Report progress on CAA work             JGG                ongoing       ongoing

  700      P/0005/31      Provide ENVISAT and ERS ground segment  GMP                20000715      Open
                          description -- payload data -- also                                      
                          RAL-ATSR archive -- Use Cases                                            

  700      P/0005/32      Provide description of ESOC mission     NP                 20000715      Open
                          data -- Use Cases                                                        

  700      P/0005/33      JPL multi-mission archive description   DS PS              20000715      Open
                          -- Use Cases                                                             

  700      P/0005/34      JSOC description with Use Case template DG                 pending       pending

  700      P/0005/35      Use Cases for Life Sciences/ISS         AW                 20000715      Open

  700      P/0005/36      Use Cases for HESARC                    DS                 20000715      Open

  700      P/0005/37      Use Cases for ECS                       LR                 20000715      Open

  700      P/0005/38      Use Cases for CDPP                      CH                 20000715      Open

  700      P/0005/40      Experiment with the proposed principles CH                 ongoing       ongoing
                          in the presentation                                                      
                          cnes_oais_activities.ppt in several                                      
                          contexts and several types of archive                                    

  700      P/0005/42      Identify national chain of ISO9000      DG DS PM NP YI     pending       pending
                          certification and sectored schemes and                                   
                          contact appropriate sector scheme                                        
                          bodies                                                                   

  700      P/0005/43      Review relevance of ISO9004-2 on        DS                 pending       pending
                          Service organisation                                                     

  700      P/0005/44      Circulate CSOC interfaces for comment,  LM                 20010301      Open
                          in particular: Data & archives, LZP,                                     
                          On-board interfaces                                                      

  700      P/0005/45      Investigate CSOC interfaces             LR                 20010301      Open

  700      P/0010/24      Advise MC/TSG that SML needs to be      DG                 20001128      Open
                          reviewed by all Panels because it                                        
                          addresses end-to-end issues. CSOC                                        
                          connection also relevant.                                                

  700      P/0010/25      Propose TSG workshop including SML and  DG                 20001128      Open
                          CSOC attendance \"XML in Space\" with                                    
                          response from each Panel on XML plans                                    

  700      P/0010/26      Send copy of IBM emulation report to    TvdW               20010131      Open
                          DMS                                                                      

  700      P/0010/27      Try to document the archive as a        LR                 20010131      Open
                          producer in migration and upgrade                                        
                          functions.                                                               

  700      P/0010/28      Send current (or updated if available)  DS                 20001131      Open
                          template to TvdW                                                         

  700      P/0010/29      Produce scenario from a National        TvdW LS            20010115      Open
                          Deposit Library perspective                                              

  700      P/0010/30      Send feedback on RIDS to reviewers      DS                 20010208      Open

  700      P/0010/31      New version of OAIS RM doc              DS LR              20010208      Open

  700      P/0010/32      Comments on new draft of OAIS RM        ALL                20010228      Open

  700      P/0010/33      FINAL FINAL OAIS RM doc to be submitted DS LR              20010401      Open
                          to ISO 2nd review                                                        

  700      P/0010/34      Inform MC of projected OAIS dates       DG                 20001128      Open

  700      P/0010/35      Preliminary version of Archive Objects  CH                 20010201      Open
                          CP                                                                       

  700      P/0010/36      Email discussion of Archive Object CP   ALL                20010301      Open
                          and telecon if required                                                  

  700      P/0010/37      Second version of Archive Objects CP    CH                 20010401      Open

  700      P/0010/38      Preliminary version of Case Studies CP  CH(Lead) TvdW NP   20010301      Open
                                                                  NB BA DS                         

  700      P/0010/39      Compiled version of Case Studies CP     CH                 20010401      Open

  700      P/0010/40      Preliminary Roadmap for Software        LR TvdW LS NB      20010301      Open
                          Preservation                                                             

  700      P/0010/41      Software Preservation Web site          LR JGG             20010401      Open

  700      P/0010/42      Provide contact names for OCLC and RLG  NB                 20001131      Open

  700      P/0010/43      First draft CP on                       DG                 20010401      Open
                          Certification/Guidelines/.... (WP 730)                                   

  700      P/9911/45      Submit any presentational material, or  ALL                ongoing       ongoing
                          pointers to that material, to NASA for                                   
                          inclusion on ISO Archiving WWW page                                      

  700      P/9911/46      Update ISO Archiving WWW page to allow  JGG                ongoing       ongoing
                          insertion of testimonials, and insert                                    
                          existing testimonials (obtained from                                     
                          DS/LR)                                                                   

  700      P/9911/47      Review Certification concept and        DS DG AW NP        ongoing       ongoing
                          suggest refinements and options e.g.                                     
                          Ingest needs to be adequate to support                                   
                          Long-term preservation. What are the                                     
                          alternatives                                                             

  700      P/9911/49      Try to evaluate national interest in    ALL                ongoing       ongoing
                          Archive work inside and outside Space                                    
                          Agencies (as done by NASA)                                               
  -------- -------------- --------------------------------------- ------------------ ------------- ------------

**[Sorted by Due Date:]{.underline}**

  -------- -------------- --------------------------------------- ------------------ ------------- ------------
  **WP**   **ActionID**   **Description**                         **ActioneeList**   **DueDate**   **Status**

  700      P/0005/31      Provide ENVISAT and ERS ground segment  GMP                20000715      Open
                          description -- payload data -- also                                      
                          RAL-ATSR archive -- Use Cases                                            

  700      P/0005/32      Provide description of ESOC mission     NP                 20000715      Open
                          data -- Use Cases                                                        

  700      P/0005/33      JPL multi-mission archive description   DS PS              20000715      Open
                          -- Use Cases                                                             

  700      P/0005/35      Use Cases for Life Sciences/ISS         AW                 20000715      Open

  700      P/0005/36      Use Cases for HESARC                    DS                 20000715      Open

  700      P/0005/37      Use Cases for ECS                       LR                 20000715      Open

  700      P/0005/38      Use Cases for CDPP                      CH                 20000715      Open

  500      P/0010/11      New issue of DEDSL-XML book             AL                 20001108      Open

  500      P/0010/12      Email comments on DEDSL-XML to AL       ALL                20001115      Open

  100      P/0010/03      Find out about GRID work at AMES and    DS                 20001115      Open
                          EO-GRID work                                                             

  100      P/0010/01      Distribute latest draft 8601            LR                 20001115      Open

  500      P/0010/13      Telecon on DEDSL-XML                    ALL                20001116      Open

  500      P/0010/14      New issue of DEDSL-XML book             AL                 20001122      Open

  500      P/0010/15      Email comments/approval                 ALL                20001124      Open

  500      P/0010/16      Final version on DEDSL-XML              AL                 20001127      Open

  700      P/0010/25      Propose TSG workshop including SML and  DG                 20001128      Open
                          CSOC attendance \"XML in Space\" with                                    
                          response from each Panel on XML plans                                    

  700      P/0010/34      Inform MC of projected OAIS dates       DG                 20001128      Open

  700      P/0010/24      Advise MC/TSG that SML needs to be      DG                 20001128      Open
                          reviewed by all Panels because it                                        
                          addresses end-to-end issues. CSOC                                        
                          connection also relevant.                                                

  300      P/0010/05      Check reaffirmation of CADS             DG                 20001128      Open

  100      P/0010/04      Contact Brian McMahon                   DG                 20001128      Open

  100      P/0010/02      Ask about \"Space Day\" at TSG and MC   DG LR              20001128      Open

  500      P/0010/17      Request MC to hold email ballot for     DG                 20001128      Open
                          DEDSL to be published as BB                                              

  100      P/0005/04      Follow up CFDP (GPC) , Navigation       DG DS NP           20001130      Open
                          (P1J-) and On-board data transfer to                                     
                          maintain ongoing discussions                                             

  700      P/0010/28      Send current (or updated if available)  DS                 20001131      Open
                          template to TvdW                                                         

  700      P/0010/42      Provide contact names for OCLC and RLG  NB                 20001131      Open

  500      P/0010/09      Comment on requirements for Internet    ALL                20001215      Open
                          SFDU (section 4.2.1 in minutes of                                        
                          OXF00)                                                                   

  500      P/0010/06      Provide Technical part of SOW for data  NP                 20001231      Open
                          distribution system (if approved                                         
                          project)                                                                 

  500      P/0010/18      Send out proposals for RID resolution   PM                 20010115      Open

  700      P/0010/29      Produce scenario from a National        TvdW LS            20010115      Open
                          Deposit Library perspective                                              

  500      P/0010/19      Telecon to resolve DEDSL RIDS           ALL                20010123      Open

  700      P/0010/26      Send copy of IBM emulation report to    TvdW               20010131      Open
                          DMS                                                                      

  700      P/0010/27      Try to document the archive as a        LR                 20010131      Open
                          producer in migration and upgrade                                        
                          functions.                                                               

  500      P/0010/10      Produce prototype Internet SFDU         DG                 20010201      Open
                          implementation and tool                                                  

  700      P/0010/35      Preliminary version of Archive Objects  CH                 20010201      Open
                          CP                                                                       

  500      P/9810/42      Get more detailed specifications of PDS DS                 20010201      Open
                          administrative keywords for the                                          
                          Tutorial                                                                 

  700      P/0010/31      New version of OAIS RM doc              DS LR              20010208      Open

  700      P/0010/30      Send feedback on RIDS to reviewers      DS                 20010208      Open

  500      P/0010/20      New version of DEDSL Abstract and       PM                 20010210      Open
                          DEDSL-PVL                                                                

  600      P/9911/34      Provide suggestions for CAA services to ALL                20010215      Open
                          JGG                                                                      

  700      P/0010/32      Comments on new draft of OAIS RM        ALL                20010228      Open

  700      P/0010/38      Preliminary version of Case Studies CP  CH(Lead) TvdW NP   20010301      Open
                                                                  NB BA DS                         

  700      P/0010/40      Preliminary Roadmap for Software        LR TvdW LS NB      20010301      Open
                          Preservation                                                             

  700      P/0005/45      Investigate CSOC interfaces             LR                 20010301      Open

  700      P/0005/44      Circulate CSOC interfaces for comment,  LM                 20010301      Open
                          in particular: Data & archives, LZP,                                     
                          On-board interfaces                                                      

  700      P/0010/36      Email discussion of Archive Object CP   ALL                20010301      Open
                          and telecon if required                                                  

  300      P/9705/11      Investigate MIME registration of SFDU   DS                 20010315      Open
                          and either write concept paper or                                        
                          actually register it                                                     

  500      P/0010/21      Review final draft of DEDSL Abstract    ALL                20010315      Open
                          and DEDSL PVL                                                            

  500      P/0010/22      Request email ballot for DEDSL Abstract DG                 20010322      Open
                          and DEDSL-PVL                                                            

  500      P/0010/07      Use Case and Requirements plus tools    NP                 20010331      Open
                          and technologies for what he has to                                      
                          distribute                                                               

  700      P/0010/33      FINAL FINAL OAIS RM doc to be submitted DS LR              20010401      Open
                          to ISO 2nd review                                                        

  700      P/0010/37      Second version of Archive Objects CP    CH                 20010401      Open

  700      P/0010/39      Compiled version of Case Studies CP     CH                 20010401      Open

  700      P/0010/41      Software Preservation Web site          LR JGG             20010401      Open

  700      P/0010/43      First draft CP on                       DG                 20010401      Open
                          Certification/Guidelines/.... (WP 730)                                   

  500      P/0010/23      Produce DEDSL Green Book                PM AL              20010401      Open

  100      P/9911/56      New work on XML-DEDSL related           DM(lead) LR        20010415      Open
                          presentation tools                                                       

  500      P/9810/43      Consider adding examples of             PM                 20010415      Open
                          registration methods to DEDSL Tutorial                                   

  100      P/9911/53      New work on OAIS Methodology for        DS(Lead) CH GMP    20010415      Open
                          submission                                                               

  100      P/9911/55      New work on Internet SFDUs, JAVA        DG(lead) LR DS JGG 20010415      Open
                          objects etc                                                              

  100      P/9911/57      New work on CAA services                JGG(lead) DG       20010415      Open

  100      P/9911/58      New work on P2 Cookbook for Projects    DS(lead) NP PM     20010415      Open

  400      P/0005/08      Email suggested XML-SFDU structure      LR DG              20010415      Open

  400      P/0005/09      Investigate registration of namespace   LR                 20010415      Open

  100      P/9911/54      New work on ingest standards - i.e.     DS(Lead) NP GMP CH 20010415      Open
                          more detailed - mission archives        LR JGG                           

  100      P/9911/59      New work on OAIS certification          BA DG              20010415      Open

  500      P/0005/18      Consult OGC on how to work with W3C     LR                 20010530      Open

  700      P/9911/45      Submit any presentational material, or  ALL                ongoing       ongoing
                          pointers to that material, to NASA for                                   
                          inclusion on ISO Archiving WWW page                                      

  200      P/9810/05      Distribute selected project produced    ALL                ongoing       ongoing
                          JAVA interfaces, e.g. for Dictionary                                     
                          access or AIP access, to Panel for                                       
                          comments                                                                 

  300      P/9810/09      DS to pursue URN information            DS                 ongoing       ongoing

  600      P/9911/30      Provides updates for P2 software page   ALL                ongoing       ongoing
                          http://www.ccsds.org/p2/software.html                                    

  600      P/9911/35      Report progress on CAA work             JGG                ongoing       ongoing

  700      P/9911/46      Update ISO Archiving WWW page to allow  JGG                ongoing       ongoing
                          insertion of testimonials, and insert                                    
                          existing testimonials (obtained from                                     
                          DS/LR)                                                                   

  700      P/9911/47      Review Certification concept and        DS DG AW NP        ongoing       ongoing
                          suggest refinements and options e.g.                                     
                          Ingest needs to be adequate to support                                   
                          Long-term preservation. What are the                                     
                          alternatives                                                             

  700      P/9911/49      Try to evaluate national interest in    ALL                ongoing       ongoing
                          Archive work inside and outside Space                                    
                          Agencies (as done by NASA)                                               

  400      P/0005/11      Monitor and circulate information about DS                 ongoing       ongoing
                          relevant OMG developments                                                

  300      P/0005/05      Follow up EPA software development      DS JGG             ongoing       ongoing

  700      P/0005/40      Experiment with the proposed principles CH                 ongoing       ongoing
                          in the presentation                                                      
                          cnes_oais_activities.ppt in several                                      
                          contexts and several types of archive                                    

  300      P/9905/13      Review CADS BB for 5 year review cycle  ALL                pending       pending

  200      P/9611/06      Produce the initial draft of the        DG                 pending       pending
                          document that will lead to the WB                                        
                          specified on WP220                                                       

  700      P/0005/43      Review relevance of ISO9004-2 on        DS                 pending       pending
                          Service organisation                                                     

  700      P/0005/34      JSOC description with Use Case template DG                 pending       pending

  100      P/9705/02      Provide comments on the new P2 Overview ALL                pending       pending
                          document to NP                                                           

  100      P/9705/01      Revise sections 3.2 and 3.3 of the P2   DS                 pending       pending
                          Overview document                                                        

  700      P/0005/42      Identify national chain of ISO9000      DG DS PM NP YI     pending       pending
                          certification and sectored schemes and                                   
                          contact appropriate sector scheme                                        
                          bodies                                                                   
  -------- -------------- --------------------------------------- ------------------ ------------- ------------