ISO Archiving Standards - Sixth International Workshop - Minutes

Subject: Minutes of CCSDS Panel 2 Plenary Workshop (Archiving Portion)
Meeting Date: 5 May - 15 May 1998 12 May-15 May 1998 (Archiving)
Place: Houston, USA
Present:
BNSC	David Giaretta Simon Marshall	DG SM
CNES	Patrick Mazal Claude Huc Denis Minguillon	PM CH DM
ESA	Nestor Peccia Gian Maria Pinna	NP GMP
NASA	Don Sawyer John Garrett Terry Longstreth Mike Martin Lou Reich Robert Stephens Alan Wood	DS JGG TL MM LR RS AW
NARA	Bruce Ambacher	BA
NASDA	Yoshio Inoue	YI
CAST	Xu XuDong Katy Zhang	XX KR

Table of Contents

• Welcome and Introductions
• Logistics and Agenda Review
• Archive Management Report
• Date and Location of Next Panel 2 meeting
• Review of OAIS White Book version 3.0
• High Level Issues
• Role of Recommended practice text
• Function allocation in functional view
• Others?
• Section by Section Issues
• Edit Log
• Individual comments/papers
• WP700 Status Report
• Archiving Progress Report
• Change in OAIS Functional Model - email from D Sawyer
• List of Registered Documents
• Action Item List

Archiving

Welcome and Introductions

Attendees were welcomed. Participants introduced themselves.

Logistics and Agenda Review

The draft agenda was presented and accepted.

Archive Management Report

See Appendix G1

Date and Location of Next Panel 2 meeting

Date: 25th-30th October (management mtg on 25th evening)

Location:Majority prefers Toulouse, France but NP wants meeting at ESOC, Darmstadt, Germany.

[Editor's Note: Archiving portion will likely be 2 or 3 days during the week. Location is currently set for Toulouse, France.]

Review of OAIS White Book version 3.0

High Level Issues

Role of Recommended practice text

This is in response to comments from D Giaretta. DG made it clear that he was not advocating removal of the additional text - merely to make it clear what the DEFINITIONS and what the specifications were - and make the additional text clearly separate. DS noted that ISO preferred material as Standards - otherwise it might be sensible to place some of this material to a "Green Book". However LR pointed out that publishing Annex A as a separate document would shorten the document considerably.

7.4.1.2 Function allocation in functional view

See mail from DS dated 7 April 1998 (Appendix G.2) on the reason for changing the Functional Model - combining Access with Dissemination.

1) should we merge the functions of Access and Dissemination?

DG found the argument about needing a "single point of contact" a spurious point - we are talking about functions NOT implementation. However the argument about not being able to cleanly separate the functions and interactions WAS persuasive.

It was AGREED that we should combine the functions.

2) Name of combined function:

LR found the name "Access and Dissemination" clumsy.

After considerable discussion the name "ACCESS" was agreed as the name of the merged functions.

However it was recognised that there may be some initial confusion from reviewers. However it was felt that ACCESS was sufficiently generic that it would cover both data and metadata access (i.e. Dissemination as well as Search). This issue MAY be reopened at a later stage. (Suggest putting "XXACCESS" throughout RM to facilitate later changes of name.)

7.4.1.3 Others?

None

7.4.2 Section by Section Issues

Note that the document will go through a professional Technical Editor before publishing.

7.4.2.1 Edit Log

General:

• The style of type at the first introduction of terms must be clarified - this may be covered by CCSDS or ISO style guides. We will BOLD the first instance and describe the style in section 1.

Section 1.1

• Change wording to: Long Term is long enough to be concerned with the impacts of changing technologies, including support for new media and data formats, and with a changing user community requirements.

• Change bullet to: provides a framework including terminology and concepts for describing and comparing architectures and operations of existing and future archives
• Add to last para note on notion that we are defining "maximal archive" but "minimal responsibilities" Also point out that we are including examples and best practice.

Section 1.2

• Add specific mention about applicability to "active archives"
• perhaps different name e.g. "embedded archive" or "close-coupled archive"
• JGG suggests adding statement of Conformance Section as would be required by a standard. AGREED.

Section 1.4:

• JGG: State that Panel 2 is author of document
• Change second sentence to say that the standards may be developed by any organisation but should be coordinated with CCSDS Panel 2.
• Separate accreditation from archival practises
• DG: Add possible standard concerned with monitoring changing user community requirements. NOT AGREED

Section 1.6 to addressed later

Section 1.7 - note references are Informative not Normative

Section 2

Para 4 second sentence - change "preservation function" to "preservation and access function".

Remove last paragraph ("At the same time ...")

Section 2.1

• AGREED: put bulleted definitions of "producers", "consumers" and "management"
• Add definition of "Designated Community" since this is an important concept (in section 2 or 2.1)

Section 2.2

Section 2.2.1

Section 2.2.2

• CH: concern about "Packaging Information" definition - is the physical media part of packaging information? Is Packaging Information a relevant concept?
• AGREED: first sentence of first para after bullets - remove the phrase "into an entity". Change "relates" to "relates and identifies".
• Add "to the Designated Community" to sentence "...Representation information needed to make the Digital Object understandable".
• Change "understandable" to "interpretable" in change above
• Make definition of Descriptive Information (DI) more obvious
• e.g. make Descriptive Information boldi
• Alter definition of "Fixity Information":
• Change FIXITY mini-definition to reflect 4.2.1.2.2 e.g. "unintentional" to "undocumented"

Section 2.2.3

• Reformat SIP, DIP AIP descriptions, consider moving some details to later sections.

Section 2.3

• GMP: Is Packaging Information always present? DS: Packaging Information is effectively being used in 2 ways - (1) in Submission IP and (2) Any IP. This must be clarified - see section 2.3.2.
• Need to make style more consistent and clarify which parts are definitions and which are examples etc" throughout this section

Section 2.3.1

• Clarify definition of Management
• Last bullet should be marked as Advice

Section 2.3.2

• GMP: make it clear that there is a many to one as well as a one to many mapping for SIPs to AIPs, optionally introduce concept of granularity. AGREED.

Section 2.3.3

• Make it clear that payment may not be required.
• Definition of Subscription Order should be changed to clarify that this covers a single session as well as multiple sessions and possibly change the name.

Section 2.3.4

• Move the material here elsewhere to describe applicability of OAIS to other data processing contexts.

Section 3

Section 3.2

• Copyright section will be shortened and clarified
• Obtaining Adequate Representation Information: Separate the example text. Delete text in paragraph following "Conceptually, this chaining ...". Also in second para remove bold
• Agreements with external organization: Delete from "This begins ..." to the end of the paragraph.
• Add point that if an agreement has been made then it should be monitored.
• Delete second para

Section 3.3

• Move definition of Designated Community to start of section

Section 3.4

• Trim down last paragraph to only address the software aspect.

Section 3.5

• Delete everything after first sentence in first para.
• Clarify that second para is an EXAMPLE
• Address issues about monitoring Designated Communities here

Section 3.6

• first sentence: change "consumers" to "designated community"
• 3rd sentence: rewrite - it is confused
• Delete first sentence of second para

Section 4

Remove AIC and AIU from this chapter

Make Figures consistent throughout - label lines etc

Note that we add labels above and below lines (strictly OMT has labels only above lines)

Note Object Identifier for AIP do NOT change over time, however AIC's may be added to over time.

Section 4.1

• Change label Data Management to ACCESS to "Result Set" instead of DI
• After some discussion from LR about the length of time it would take to produce diagrams for each of the boxes in the Functional Model and the lack of advisability of doing so, NP produced drafts of the figures. See NP example figures below: - NASA to attempt to use these diagrams or something similar.

• Make numbering on arrows in Data Flow diagrams consistent with the text

• Delete FRA97 action: Number all bullet points for easier reference throughout the subsections

• Remove "*" at beginning of each of functions listed. Do NOT put numbers
• Remove "negotiate submission" from INGEST - leave this function to Administration

Section 4.1.1

Section 4.1.2 (Ingest)

• Remove function "Schedule Submission Delivery"
• Add "Quality Assurance Monitoring of SIP" function
• Add "other information sources" to Generate Descriptive Information
• Coordinate Updates:
• change "storage location of the AIP" to "storage identification of the AIP"
• Generate Archival Information Package: last sentence change "may issue request reports" to "may issue report requests"

Section 4.1.3 (Archival Storage)

• Receive Data: penultimate sentence change "Transfer Receiving function" to "this function"
• Disaster Recovery: reword to make it clear that removable media is NOT required. Also make it clear we are talking about DIGITAL archives here.
• FRA97 actions

• Address concept of levels of maximum bit-error rates tolerate (restart 30/1/97) - CONTINUE
• Error checking - add example of Error Correction e.g. Reed -Solomon done in addition to any error correction intrinsic to the storage hardware.

• Manage Storage Hierarchy : remove usage statistics
• Add examples of levels of service

Section 4.1.4 (Data Management)

Section 4.1.5 (Administration)

• Add "Verify Submission consistency with Submission Agreement"
• The function "Activate Request" will be moved to Administration.

• The Manage System Configuration function will be split in 2 functions:
• Management System Configuration. Add monitor designated community as an activity.
• Archival Information Update (name to be confirmed), covering AIPs/DIs/DIPs/SIPs updates. It has to be analysed if this function could be moved to other entity of Fig. 4.1.
• The function Schedule Submission Delivery in Ingest will be moved from Ingest to Administration and will be covered by the function Negotiate Submission Agreement.
• The activity for accounting and billing of the function Co-ordinate Request will be moved from Access to Administration
• The function Activate Request will be moved from Data Management to Administration
• Audit AIPs should be renamed and make clear that it is an audit of the Submission agreement and not instances.
• Add security aspects in Develop Standard and Policies

• Add "Environmental Issues" concepts

Section 4.1.6 Access and Dissemination

• The function Co-ordinate Request will be renamed as Co-ordinate Access Activities
• The activity for accounting and billing of the function Co-ordinate Request will be moved from Access to Administration
• Deliver DIPs: clarify that billing information has to be sent to Administration

Section 4.2

• Correct section numbering

Section 4.2.1

Section 4.2.1.1

• In fig 4-5 change "Bit Sequence" to "Bit"

Section 4.2.1.3.2

• Follow Frascati actions
• Put in statement that this is a dangerous practice even though it is common
• Replace ASISO in fig 4-8

Section 4.2.1.2 (wrong)

Section 4.2.1.2.1 (wrong)

• Delete last sentence of second para ("As an aside ...")
• Clarify third bullet "Importing Rep Info" - change to "Reference Rep. Info" and include in Glossary.
• "Representation Net" - should be "Representation Network" for consistency throughout

Section 4.2.1.2.2

Change "security" to "integrity preserving" in definition of FIXITY.

• GMP: is Provenance Info really mandatory for AIP? YES
• Add sentence saying that the adequacy of the Provenance Info content is determined by the archive - could just say that originator is unknown.

Section 4.2.1.2.3 Packaging Info (wrong number)

• last para: make concept more general - not just as an example.
• Clarify the point that the physical media IS NOT part of the Packaging Information - remove third sentence of para 1
• CH: in complex HSM/robotic storage the files (bits) are moved around and may be packaged differently

Section 4.2.1.2.4 Descriptive Information

• third sentence - clarify that DI is specialisation of AIO.
• Add sentence saying it is derived from CI/PDI.

Section 4.2.2 Logical Model of Information...

• Move details from section 2 back to 4.2.2 e.g. for SIP
• May need new concept for the 2 types of Packaging Info.

Section 4.2.2.1

• Last sentence: change to "There are several types of Information Objects which are used ..."
• Add paragraph explaining relationships and cardinality in OMT diagram

• Define "Package Descriptor" before use

Section 4.2.2.3 AIP

• Clarify relationship between Package Descriptor, Descriptive Info and Associated Information and make definitions of each clear
• GMP: is Provenance Info really mandatory for AIP? YES
• Add sentence saying that the adequacy of the Provenance Info content is determined by the archive - could just say that originator is unknown.

Section 4.2.3.1 Specialisation of AIP ...

Section 4.2.3.1.2 Unit Descriptor

• Add diagram after 4-18 showing Access Aids illustrating text
• second paragraph "technology advances increases" to "technology advances increase" and generally revise

Section 4.2.3.1.4 Collection Descriptors

• Define "Theme Collection" clearly, also:
• Possibly change name e.g. "Virtual", "Projection", "View", "Temporary", "Named Report", "Non-Archived Collection"
• Possibly show 2 sub-classes of Collections explicitly
• Further expand material after Fig 4-20

Section 4.2.3 Data Management Data

• Expand this section

Section 4.3 High Level Data Flows and Transformations

• Change title and first para to reflect the fact that this is an Operational Flow not a Data Flow
• Delete last para "it is important to note..." and remove reference to IP in second para.
• Complete FRA97 actions

Section 4.3.1 Data Trans in Producer..

Section 4.3.2 Data Trans. in Ingest

• second para - replace AIC with AIU or AIP where appropriate
• first para, last sentence change "must be added after ingest" to "must be added during the ingest process"
• first sentence last para change "information Content in the Producer" to "Content Information in the SIPs"

Section 4.3.3

• first para, last sentence change Ingest Storage to Archival Storage

Section 4.3.4

• Change "Customer" to "Consumer"
• Make consistent with move of function "Activate Request" to Administration
• Last para, penultimate sentence - change "may generate AIP" to "may generate DIP"
• Last para , last sentence add "and many DIPs from many AIPs"

Figure 4-16 - should have Package Descriptor to Collection Descriptor

Figure 4-19 - change Collection Descriptor to Archival Information Collection and

label should be "derived from" instead of "described by" on top and "described by" under line.

Between AIC and PI - add label "identifies" under line

Between CI and PDI - label as "further described by" above line. Remove label under line.

Figure 4-14 - add label "idenifies" under "delimited by" between AIP and PI

Figure 4-17 AIP should be AIU

Figure 4-18 move to head of section

Section 5 Data Migration Perspectives

• Change "transmutation" to "transformation" throughout

Section 5.1

• second bullet: change title to "Cost-effectiveness"
• third bullet change "consumer" to "designated community"

Section 5.2

• GMP proposes that sections 5.2 and 5.3 be removed from the document as they are not necessary. NP agrees.
• consider removing this section

Section 5.3

• 3rd para: use "bit sequences" instead of "byte sequences", also
• 4^th para: change "application-provided byte sequences" to "file contents" and delete rest of sentence.
• Expand concept of "Reversible transformation" and "Non-reversible transformation" and risk of loss of information - possibly a subtle, hard to detect loss
• Add Replication as category of preservation
• LR suggests following table plus supporting text to clarify section 5:

	Replication	Repack-aging	Transformation -reversible	Transformation - non-reversible
Media Decay	X
Obsolescence		X	X	X
New Technology		X	X	X
Consumer Services		X	X	X

Section 5.4

• DS to write his 4 options for "Content Info" bits in combinations with media

Section 5.4.1

Section 5.5

• Restructure this section

Section 5.6

• Attempt to move this material to section 2 or section 4.

Section 6

• Change title to "Archive Interoperability"
• Delete second bullet under Managers
• Last bullet under managers: change "the OAIS" to "several OAIS's"
• Clearly separate definitions from examples
• Archives can consolidate - this should be explored

Section 6.1

Section 6.1.1

Section 6.1.2

Section 6.1.3

• Refer to ISO Directory Services model
• Produce diagrams of each of the 3 types of Federated archives. Fig 6-3 only deals with type 2.
• Explain acronyms of archives,
• add non-space archives if possible
• get contribution to Annex A if possible

Section 6.1.4

• Add case of common INGEST in diagram 6-4
• Add last sentence "The CNES Long Term Storage Facility is an existing example of a storage function shared by several archives"
• Possibly move references to existing systems to Annex A and refer to the annex for specific examples

Section 6.2

Annex A

• Aim to make this a separate document
• Examples and template used may need to be revised

Individual comments/papers

P/9805/37	700	Change term DESCRIPTOR in OAIS document to avoid clash of meaning with DEDSL	LR	980901	Open

---

Document Schedule

New version by	980831
RIDS by	980928
New draft by	981018
P2 meeting	981026
Red Book	981104

---

CCSDS Panel 2 Report to TSG (Archiving Portion)

WP700 - Archiving

• Red Book, and simultaneous submission as ISO DIS - slipped by 6 months to November 1998
• Several workshops organised around OAIS and follow-on standards

TSG-97-13:

• All Panel and sub-panel chairmen to produce Roadmaps for Panel and sub-panel activities. Will be reviewed under point 5 of the agenda.

Current Work Plan

• The Panel chairs are requested to update their plans of work introducing for the various work items - among others - the categories Research, Development and Deployment

Current Work Plan for Panel 2

Research	Development	Deployment
	WP700: Archives

Road Map to the Future

Item 9: Data Protection

• Archive work:
• Long-term preservation is one of the fundamental motivations for the Reference Model
• Legal issues - copyright
• Access control is part of Reference Model
• Physical protection
• Restricted access
• Authorised access
• Implies user authentication
• Encoding/Encrypting
• ADID gives format of data - not encoding/encrypting info - this is NOT considered part of the format. However individual ADID's can be registered for combinations of Encoding and Format e.g. Zipped FITS file
• Possible use of extensions
• "processing class" to detail encoding contents of data, plus
• "complex objects" to relate encoded info and encoding info
• NB some labels would be in the clear

---

Archiving Progress Report

1998-05-13

The active work packages in Archiving are WP710, WP720, and WP730.

---

WP710 Archiving Reference Model

A. Progress

NASA held two US archiving workshops since the fifth ISO/CCSDS archiving session in Frascati. Results of this workshop and US workshops have been put on the WEB.

White Book version 3 of the reference model, which has incorporated a significant fraction of, but not all of, the Frascati agreed updates, was produced following the April US workshop. This version has been registered for the Houston workshop. Also available are the following papers:

• 7.5 Review of Reference Model White Book: gives the status of the Frascati requested updates.
• Key Archive Reference Model Issues: a note to P2 regarding the proposal to combine Access and Dissemination
• Cover note sent with White Book discussing the status of the document in terms of major issues, editorial issues, and known deficiencies
• Written comments from Nestor Peccia
• Written comments from David Giaretta
• Written comments from Gian Maria Pinna

B. Changes

No changes in direction are identified.

C. Problems

No unusual problems are noted.

D. Forecast

We should be able to resolve the major technical issues at this workshop. We will need to do significant editing to reflect these issues, and to provide missing content in the Annexes. It would be very helpful to have a solid international review of version 3.1 which should be available in July. This should enable a version 3.2 for review at the October workshop, which should be proposed to the MC as a Red Book following this workshop. It should also be circulated as a draft international standard at that time.

E. Milestone Table

WP#	Description	Projected Completion Date	Status	Completion Date
710.2	Draft Archiving Reference Model	96.09.01	Closed	96.10.28
710.3	Draft ISO Committeee Reference Model	97.05.31	Closed	97.05.31
710.4	Draft ISO Standard Reference Model	98.05.31	Open

---

WP720 Archiving Submission Standards

A. Progress

It was decided to defer active work pending the results from the Digital Archive Directions workshop and the European Earth Observing Systems workshop.

B. Changes

None to date.

C. Problems

None to date

D. Forecast

Sufficient priority and resources have not yet been identified.

E. Milestone Table

WP#	Description	Projected Completion Date	Status	Completion Date

---

WP730 Archival Recommended Practices

A. Progress

It was decided to defer active work pending the results from the Digital Archive Directions workshop and the European Earth Observing Systems workshop.

B. Changes

None to date.

C. Problems

None to date

D. Forecast

Sufficient priority and resources have not yet been identified.

E. Milestone Table

WP#	Description	Projected Completion Date	Status	Completion Date

---

Change in OAIS Functional Model - email from D Sawyer

Date: Tue, 07 Apr 1998 08:04:40 -0500

From: Donald Sawyer <donald.sawyer@gsfc.nasa.gov>

Reply-To: donald.sawyer@gsfc.nasa.gov

Organization: code 633

To: ccsdsp2@xfiles.gsfc.nasa.gov

Subject: Key Archive Reference Model Issues

X-MIME-Autoconverted: from quoted-printable to 8bit by nameserv.rl.ac.uk id OAA31041

Dear P2 members,

I¹d like to get an early response from you on a proposed change to the archive Reference Model functional diagram and related text. You will recall that there were a number of issues having to do with the roles of Access, Dissemination, and Data Management, including the right names. We have been discussing these issues extensively in our last 2 US workshops, as well as in two US telecons we held just prior to the US workshop last week.

A couple of perspectives have emerged,as follows:

1. At the last international workshop, we were asked to remove the line (communication) between Access and Dissemination, with the assumption that these functions communicated through Data Management (and possibly Administration). There was the view that a Consumer help desk was in Administration, that Access was the interface for access to Data Management data, and that the Consumer received DIPs from Dissemination. We supported this view in Frascati and have been attempting to use it in addressing a more complete view of how requests, including Œstanding orders¹ are handled. This approach ends up providing the Consumer with 3 primary interfaces with the archive, which also means that there is no way to talk about a single Œpoint of contact¹ for handling the typical range of Consumer requests and responses. We have found this quite unsatisfactory.
2. We need to recognize that requests, in general, need to be recorded and then partitioned and given to the appropriate functions to work on. Some parts will need data from Data Management, some will need data from Archival Storage, and some will need data from both to be completed. The partitioned requests may be accomplished in real time, or they may take an extensive period to complete, regardless of whether the data comes from Data Management or Archival Storage. As such, the status of each part of a request will need to be updated, independently, in Data Management as appropriate. There may be partial disseminations of information during this process. Eventually, the request will be completed and marked as such. This suggests the clear need for some type of Œrequest coordination¹ function. This function is typical in the archives we are familiar with.
3. We have been attempting to partition the functionality among Access, Dissemination, and Data Management. We have come to the conclusion that there are too many optional ways to do this, and picking one results in the flavor of an implementation, not a refernece model. Therefore we believe that Access should be the primary Consumer interface for requests, including walk-ins off the street as well as on-line searching and ordering. This allows it to be the focus for a Œrequest coordination¹ function, with the ability to give the Consumer order status as needed. When we have done this, coupled with the views above on how requests get handled in general, we are left with Dissemination in an odd position. It can continue to do its function, but we would need some similar type of function to work on the Data Management based requests when they can¹t simply be satisfied by an automated response supported by Data Management data. We certainly don¹t want to add more boxes, so we have come to the unanimous conclusion (Don, Lou, John, Bob, Paul, Mike, and Bruce) that we should merge the Dissemination function and the Access function into one box called ³Access and Dissemination². This allows us to do all the request handling and subsequet data processing, if needed, in one functional area without trying to split out the processing AIPs and Data Management data in a way that highlights messages flowing between them. This does not mean we loose the DIP processing, however.

We do not make this proposal lightly as we are reluctant to make this level of change at this stage of the development. Nevertheless, it has provided us with a way forward that we are now comfortable with and that we find better handles the issues of request handling, processing on both the Data Management data and the Archival Storage data, and the dissemination of DIPs, Result Sets, and Reports to the Consumer. The basic sub-functions in Access and Dissemination are retained, and a ŒRequest Coordination¹ subfunction is added.

Since we have been unable to make progress on the Access/Dissemination/Data Management issues before we came to this conclusion, we are now proceeding with text and figures along these lines. We would like to get a consensus that this will be acceptable for review in the version we will have available on April 15, and we would like your initial reactions to this Access/Dissemination approach.

Ciao,

Don

---

List of Registered Documents

Document Number:	HOU/98/P2/N9
Title	Reference Model for an Open Archival Information System
Author	Lou Reich and Don Sawyer, editors
Agency	NASA
Abstract	Version 3 for review in Houston
URL	ftp://stpdf1.bnsc.rl.ac.uk/users/mirrors/ccsds/books/archive/refmodel
Location	books/archive/refmodel/refmwb3.m60, refmwb3.pdf, refCwb3.m60

---

Action Item List

		ACTIONS CLOSED
AI #	WP #	Description	Act'	Date	Status	Comments
P/9705/33	700	Brief the Agency CEOS-ATT or Sub-Group on Data counterparts about OAIS activities	All	980210	Closed
P/9710/45	700	Panel to raise the importance of OAIS and suggest that they identify appropriate projects/individuals from other agencies to participate in OAIS discussions	ALL	980430	Closed
T/9804/01	700	Comments on Ref Model White Book3	All	980428	Closed
T/9804/01	700	Comments on Space Ops 98 Arch. Ref. Model Paper	All	980428	Closed
		ACTIONS OPEN FROM PREVIOUS MEETINGS
AI #	WP #	Description	Act'	Date	Status	Comments
P/9611/32	700	Produce a concept paper that assist the panel in agreeing on several archive standard	DG	981031	Open
P/9710/40	700	Send updated versions of OAIS RM to OGIS contacts	DS	981130	Open
P/9710/41	700	Add diagrams to OAIS RM showing functions in section 4 - as per NP comments	LR	980831	Open
		ACTIONS OPENED AT THIS PLENARY MEETING
AI #	WP #	Description	Act'	Date	Status	Comments
P/9805/35	700	Produce Conformance Section	JGG	980901	Open
P/9805/36	700	Produce next level data flow diagrams	NP	980512	Closed
P/9805/37	700	Change term DESCRIPTOR in OAIS document to avoid clash of meaning with DEDSL	LR	980901	Open

---

Wider Views

Overview of the Sixth International Workshop
Overview of International Effort


---

URL: http://ssdoo.gsfc.nasa.gov/nost/isoas/int06/minutes.html

A service of NOST at NSSDC. Access statistics for this web are available. Comments and suggestion are always welcome.

Editor: David Giaretta
Curator: John Garrett (garrett@ncf.gsfc.nasa.gov) +1.301.441.4169
Responsible Official: Code 633.2 / Don Sawyer (Donald.Sawyer@gsfc.nasa.gov) +1.301.286.2748
Last Revised: 15 May 1998, David Giaretta (13 July 1998, John Garrett)