Current Applications of the OAIS Model

1. Current Applications of the OAIS Model David Giaretta

2. Outline • Conformance – what does it mean • Examples • NSSDC • CDPP • Lotar

3. Conformance – what does it mean? • Section 1.4: A conforming OAIS archive implementation shall: • Support the model of information described in section 2.2 • But OAIS RM does not define or require any particular method of implementation • Fulfill the responsibilities listed in section 3.1 • OAIS RM does not specify mechanisms • Roadmap identifies areas suitable for OAIS-related standards

4. OAIS Responsibilities • Negotiates and accepts Information Packages from information producers • Obtains sufficient control to ensure long-term preservation • Determines which communities (designated) need to be able to understand the preserved information • Ensures the information to be preserved is independently understandable to the Designated Communities • Follows documented policies and procedures which ensure the information is preserved against all reasonable contingencies • Makes the preserved information available to the Designated Communities in forms understandable to those communities

5. NSSDC - DIOnAS • Data migration project DIOnAS • Using OAIS concepts • Producing AIP’s • Transforming existing data to Canonical format from VMS operating system specific format • Maintaining metadata to specify VMS-specific features

6. AIP • Based on ISO 12175 (SFDU packaging) • ADID is an internationally object-type-unique identifier • Points to additional metadata • This metadata may initially be very simple BUT can be enhanced later

7. SFDU concept

8. NSSDC - IMAGE satellite data • NSSDC provided software to IMAGE project to convert their “Level-0.5” data products into AIPs • Original data is tar files containing “Universal Data Format (UDF) files. • Consumers will be provided with the UDF files plus software to read these • This may change as UDF falls out of use

9. IMAGE satellite data

10. OAIS Responsibilities • Negotiates and accepts Information Packages from information producers • Obtains sufficient control to ensure long-term preservation • Determines which communities (designated) need to be able to understand the preserved information • Ensures the information to be preserved is independently understandable to the Designated Communities • Follows documented policies and procedures which ensure the information is preserved against all reasonable contingencies • Makes the preserved information available to the Designated Communities in forms understandable to those communities

11. CDPP • CDPP created in 1998 • about 10 missions (WIND, ARCAD, …), 30 experiments, 100 data sets OAIS type • Information objects and type of objects • Domain dictionary (has already been run in on many missions) • Modeling of delivered data • Standards and tools (examples) • Data description in EAST is required from the producers • Tools are provided to create these

12. CDPP

13. Example of data delivery model PDI Source Context Reference Mission Experiments Mission, experiment descriptive files Data set (main, auxiliary data, images) Data Objects Data files EAST Structure sheet DIF Representation Information Catalogs Data Entity Dictionary DED File Descriptive docs CDPP data delivery

14. EAST • The EAST language was designed to meet three objectives in order to enable : • a complete description of any given data format, without any 'ephemeral' references to any short-life file management systems, • access to the values of the data by means of generic tools which do not require writing of even a single line of specific code for the data to be read, • formatting the data on their storage or exchange medium while guaranteeing a structure that matches their description. • The EAST language is an international standard (CCSDS and ISO). • Tools based on this standard have been developed. They can be used to help players throughout the "data life cycle".

15. EAST • CNES point of view : EAST success will be achieved by using free tools. The user by using the OASIS tool doesn ’t have to learn a new language. package logical_PRODUCT_X_SUN_FCSTC000 istype PRODUCT_X_NAME is (PRODUCT_X) ;for PRODUCT_X_NAME'size use 72 ;type AGENCY_ID is (CNES, NASA, USER_ESA, BNSC, CCSDS) ;for AGENCY_ID'size use 8 ;type NUMBER_TYPE is range 0 .. 9999 ;for NUMBER_TYPE'size use 32 ;type PRODUCT_ID_TYPE is record NAME : PRODUCT_X_NAME ; PRODUCER : AGENCY_ID ; NUMBER : NUMBER_TYPE ;end record ;for PRODUCT_ID_TYPE use record NAME at 0 * WORD_16_BITS range 0 .. 71 ; PRODUCER at 4 * WORD_16_BITS range 8 .. 15 ; NUMBER at 5 * WORD_16_BITS range 0 .. 31 ; end record ; for PRODUCT_ID_TYPE'size use 112 ; Some lines of EAST

16. Snapshot d ’écran OASIS

17. Data Entity Dictionary Specification Language • Design Goals of DEDSL • Able to carry the definitions of data elements for various purposes • Establish a discipline/domain dictionary independent of any particular data product usage • Establish a product level dictionary that can be specialized from a domain level dictionary or created independently • Support registration of dictionaries as whole entities • Provides standard attributes for use in the description of scientific data products • Attribute set easily extendable by any Data Entity Dictionary creator • Support both human understanding and automated validation and processing • Harmonized with ISO 11179-3 data element efforts

18. DEDSL Concepts • One Abstract syntax with multiple concrete syntaxes defined for different languages and environments • The Abstract Syntax does not specify the schema or physical design of a Data Entity Dictionary implementation • The concrete syntax uses the constructs of the underlying language to implement the abstract model • Entities are described by the values of a set of standard Attribute values which may be extended by specifying user defined attributes • Attributes are defined by a set of Descriptor values • A Data Entity Dictionary consists of: • 1 set of Dictionary Entity attribute definition • 0 or more User-defined attribute definitions • 1 or more Data Entity Definitions • A Data Entity Dictionary may be transferred using any agreed DEDSL concrete syntax specification.

19. Dictionary Attributes Provide information that applies to the entire Data Entity Dictionary: • IDENTIFYING • *Dictionary_name • RELATIONAL • External_dictionary_reference • DEFINITIONAL • Dictionary_definition • REPRESENTATIONAL • *Text_field_character_set • Case_sensitivity default=not_case_sensitive • *Language • ADMINISTRATIVE • *DEDSL_version • Dictionary_version • Dictionary_identifier *= mandatory

20. Input Output of OASIS Syntaxic Description Data Description EAST OASIS INTERPRETER :Library for readingand validating data DATA GENERATOR :Library for writing data (generation of data for simulation) SemanticDescription DATA DEDPVL DED2XML HTML pages are inserted into MS WORD documents XML translator HTML DEDXML DEDDTD XSL Processor Users documentation

21. Main CDPP difficulties • Non-availability of the Producer, or inadequate available resources • Diversity of experiments and data produced • Late intervention of the Archive in the data production process • Absence of standard archiving structuring format (in Plasma Physics) • No imposed schedule

22. OAIS Responsibilities • Negotiates and accepts Information Packages from information producers • Obtains sufficient control to ensure long-term preservation • Determines which communities (designated) need to be able to understand the preserved information • Ensures the information to be preserved is independently understandable to the Designated Communities • Follows documented policies and procedures which ensure the information is preserved against all reasonable contingencies • Makes the preserved information available to the Designated Communities in forms understandable to those communities

23. LOTAR • Long Term Archiving and Retrieval and Product Data within the Aerospace Industry • AIRBUS • MTU • EADS • Fairchild Dornier • PROSTEP AG • ProSTEP iViP Association

24. Requirements • Very large number of 3-D CAD models • Various formats – software dependent • “quasi-safe for about 10 years” • Not safe enough for Legal and product liability • Legal: • Ability to verify the conformity of a part with its documentation • System has to enable the user to assure the provisions of a law regarding data security and protection of data privacy over the life cycle of the archives • Possibility to audit the process of archiving and retrieval • Security • Ensure the information is understandable by the Designated Community without the assistance of the information producers • … • …

25. Approach • Use vendor neutral ISO 10303 (STEP) • Use OAIS RM • Document examines all the functional entities in great detail • Recognises that Designated Community may be broadened

26. OAIS Responsibilities • Negotiates and accepts Information Packages from information producers • Obtains sufficient control to ensure long-term preservation • Determines which communities (designated) need to be able to understand the preserved information • Ensures the information to be preserved is independently understandable to the Designated Communities • Follows documented policies and procedures which ensure the information is preserved against all reasonable contingencies • Makes the preserved information available to the Designated Communities in forms understandable to those communities