1. Presentation at VOPlaneto 2009 Under the SC-B of COSPAR
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
International Planetary Data Alliance (IPDA) – An update M. T. Capria INAF - IASF December 15, 2009
Presentation at VOPlaneto 2009
International Activities
for the enhancement of the research and exploration activities
in the worldwide planetary community, since 2006.
Under the SC-B of COSPAR

2. I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
Objectives of the IPDA
Give scientific communities world-wide access to data
archives
Reduce cost of archiving and distributing science data
Ensure reusability of science data across time
Ensure reusability of science data across
agency/mission/instrument boundaries
Make it simpler to coordinate archiving processes
and plans across international missions and archives
Improve and increase services offered
In the 37th COSPAR meeting in 2008, the IPDA received the support resolution from the Science Commission B. 2

3. I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
IPDA Portal, developed using an open source portal called Plone, provides news, standards, project information and other content for IPDA members and stakeholders

4. I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
International Planetary Data Alliance : Who? Steering Committee Members :
Chair Yasumasa Kasaba (Tohoku Univ., Japan)
Deputy Chair Dan Crichton (NASA/JPL, PDS)
Former Chair ( ) Joe Zender (ESA: PSA)
Former Chair ( ) Maria Teresa Capria (IASF/INAF, Italy)
NASA-PDS Reta Beebe (NMSU)
ESA-PSA Dave Heather, Jorge Vago
Canada (CSA) Mickael Germain
France (CNES) Richard Moreno, Thierry Levoir, Alain Sarkissian (IPSL)
Germany (DLR) Karin Eichentopf, Thomas Roatsch
India (ISRO) Gopala Krishna, R. Srinivasan
Italy (ASI) Maria Teresa Capria, Paolo Giommi
Japan (JAXA) Iku Shinohara, Yukio Yamamoto
UK Mark Leese (Open Univ.), Peter Allan (RAL)
with the participations from China and Russia.

5. The 4th Steering Committee Meeting July 2009 at ASI, Rome
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
The 4th Steering Committee Meeting July 2009 at ASI, Rome
S. Joy
(UCLA, PDS)
Missing
P. Osuna
(ESA/PSA)
N. Hirata (U. Aizu, Japan)
D. Heather (ESA/PSA)
Y. Yamamoto (JAXA, Japan)
T. Stein
(Washington U., PDS)
Y. Kasaba (Tohoku U., Japan)
P. Allan
(BNSC, UK)
R. Beebe (NMSU, NASA/PDS)
J. Salgado (ESA/PSA)
T. Roatsch
(DLR, Germany)
I. Shinohara
(JAXA, Japan)
S. Hughes
(NASA/PDS)
B.G. Krishna (ISRO, India)
D. Crichton (NASA/PDS)
A. Sarkissian
(IPSL, France)
M.T. Capria (INAF, Italy)

6. IPDA Architecture Development
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
IPDA Architecture Development
In 2008, IPDA developed a system architecture model for the IPDA derived from the IPDA requirements
IPDA as a system is a heterogeneous, distributed, service-oriented system with distributed data and services at IPDA member sites

7. IPDA Process Architecture
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
IPDA Process Architecture
Archive Planning
Common approaches for working with data providers, particularly on an international basis
NOTE: A 2009 project is to begin to identify this process leveraging the PDS Archive Process Guide (APG)
Standards management
Management of the top-level standards for the planetary science community including both data and technical standards to support interoperability
Preservation
Approaches for long term management of the data
Peer review of data
Common peer review processes, particularly for joint, international missions

8. What was achieved? – Projects in 2008-09
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
What was achieved? – Projects in
<International Standards> (Project Leader)
IPDA Architecture and Standards Definition D. Crichton (NASA/JPL)
Definition of a high level system architecture, to identify the critical elements that need to be defined within the IPDA.
IPDA Information Model and Data Dictionary S. Hughes (NASA/PDS)
Selective adoption of the NASA PDS data standards.
Further progress should be linked to the development of NASA/PDS next generation standards, called PDS4.
Inter-operable Implementations J. Salgado (PSA), N. Chanover (PDS)
The PDAP specification: updated to Ver. 0.4
Implementation of PDAP to Venus Express (ESA/PSA and NASA/PDS)
Hayabusa (JAXA: small body), Selene (JAXA: moon)
PDAP assessment Y. Yamamoto (JAXA)
Review of PDAP Ver.0.3, which is & will be reflected in future updates.
Establishment of ‘Assessment How-To’

9. What will be achieved? – Projects in 2009 -10
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
What will be achieved? – Projects in
<International Standards>
IPDA Assessment of PDS4 Data Standards - International Assess and recommendation for new ‘PDS4’ definitions
S. Hughes (NASA/PDS)
IPDA Archive Guide - Documentation for archive preparation for PIs and Archivers.
M. T. Capria (INAF)
D. Heather (ESA/PSA)
IPDA Standards Identification - Development of the IPDA standards
E. Rye (NASA/PDS)
G. Krishna (ISRO)
Ancillary Data Standards - Implementation of Ancillary Data into the IPDA scheme
Chuck Acton (NASA/JPL)
IPDA Registries Definition - Develop IPDA registry architecture and plan
D. Crichton (NASA/PDS)

10. What will be achieved? – Projects in 2009 -10
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
What will be achieved? – Projects in
<Interoperability: Definitions>
PDAP Specification - Develop and update the PDAP specification
J. Salgado (ESA/PSA)
Y. Yamamoto (JAXA)
<Interoperability: Applications>
Interoperability Assessment - Assess the approach for accessing the Venus Express data R. Beebe (NMSU)
D. Heather (ESA/PSA)
PDAP Geographic Information System (GIS) extension - Extend PDAP to support GIS-oriented mapping data
N. Hirata (U. Aizu)
T. Hare (USGS)
We encourage members of the science community to contact leaders !
All of the leaders welcome contributions from worldwide scientists
and engineers who have interests for these activities.

11. our open international activities
I N T E R N A T I O N A L P L A N E T A R Y D A T A A L L I A N C E ( I P D A)
Next Step
Next Steering Committee Meeting: July 2010
One week before the 38th COSPAR (Bremen, Germany)
The 38th COSPAR at Bremen: July 18-25, 2010
The open session Planetary Space Sciences and Data Management (B09)
Report the IPDA activities to Science Commission B on Space studies of the earth-moon system, Planets, and Small Bodies of the Solar System
Let’s join & support
our open international activities
for a future scientific infrastructure !

12. The PDS4 Data Standards Task
9/1/2019
The PDS formed a working group to review the results of the IPDA Common Data Modeling task, IPDA Project #1.
Identified core elements.
Identified over 60 problems, issues and anomalies associated with the standards.
The PDS decided to develop the PDS4 data standards based on the core elements and to address the problems found. . 12 12

13. PDS4 Key Goals Enable a stable and usable long-term archive.
Enable more efficient archive preparation for data providers.
Enable services for the data consumer to find the specific data they need and provide the formats they require.
A few fundamental data structures that do not change over time. Think about how many Vax structured record formatted data products there are in the archive? How many data provideers now use VAX?

14. is defined in a formal language is independent of implementation
PDS4 Design Principles
The data model:
is defined in a formal language
is independent of implementation
defines a few fundamental data structures that do not evolve over time
is extensible enabling it to handle more complex data formats
The archive data formats shall be designed independent of data provider and data consumer formats.
The data architecture shall include a standard data dictionary model.
Produces a formal model that is that is concise and logical.
MDA
--- Logically Consistent - logic reasoner can be applied to identify inconsistencies and implied relationships. E.g. model a new class with fields and the reasoner would suggest the class was a table.
-Needed in a MDA architecture.
-Allows consistency checks
-Allows reasoning about the model
-A simple foundation that allows logical extensions and combinations is very powerful.
-We can control how complex we want it to become.

15. DDWG Deliverables PDS4 Information Model
9/1/2019
PDS4 Information Model
The Information Model defines PDS object classes. This includes data structures, formats, and products as well as data sets, documents, missions.
PDS4 Data Dictionary Model
The Data Dictionary Model provides the schema for the PDS data dictionary. The data dictionary documents the data elements used in the PDS4 Information Model.
PDS Standards Reference V4.0
The PDS Standards Reference V4.0 will be written in the format and tone of a standards reference document.
Grammar Options
The Grammar is used to capture PDS archive metadata for product labels. 15 15

16. PDS4 Data Design Accomplishments - General
9/1/2019
PDS4 Data Design Accomplishments - General
Project and Project Members Defined
Principles and Drivers updated
General Data Model (Draft)
Product Data Model (Draft)
Data Dictionary Model (Draft)
Grammar Options
PDS Standards Reference (Outline)
Data Dictionary Model (Final)
Grammar Decision
PDS Standards Reference (Draft)
PDS and community wide review
General Data Model (Final)
Product Data Model (Final)
PDS Standards Reference (Final)
Done
Substantial
Progress
Next 3 Months
Due 9/31/10
We have touched about everything.
-Much work at the fundamental structure layer.
-Substantial work at the data object and product level including software and document
-Incursions into the general data model. Mission
Next three months will focus on grammar, DD model, and standards ref
Software development can start once we have the grammar, data dictionary, draft models
Using MDA. 16 16

17. PDS4 Data Design Accomplishments - Details
9/1/2019
Four basic data structures
Homogeneous N-dimensional array of scalars – Array_Base
Heterogeneous repeating record structure of scalars – Table_Base
Unencoded byte stream
Encoded byte stream
Array_Base
Array_2D
Image_Grayscale
Spectrum_2D
Array_3D
Image_3D
Movie
Table_Base
Table_Character
Table_Binary
Table_Binary_Grouped
Identifiable
Digital Product
Data Product
Product_Image_Grayscale
…Image_3D
…Movie
…Table_Character
…Table_Binary
…Table_Binary_Grouped
Document Set
Software_Set
Non-Digital Product
Mission
Instrument
Resource
Data Type
Binary Data Type
Decimal Integer …
Character Literals
Character Integer
Inventory of the classes that have been defined.
Draft PDS Data Dictionary Model 17
Grammar – ODL+, PVL, and XML Labels 17

18. The Model Design Process
9/1/2019
Master model constrains data design and defines validation.
Master model and data dictionary are tightly coupled.
Document writer translates modeling information into target languages based on grammar and munging rules.
Updates to master model are reflected
quickly in the documents.
MDA
--- Logically Consistent - logic reasoner can be applied to identify inconsistencies and implied relationships. E.g. model a new class with fields and the reasoner would suggest the class was a table.
-- Model drives the generation of all artifacts. Direct and indirect
--- Munging rules are used to create target language construct.
---- DDWG is looking forward to tech session feedback. Consensus changes will typically be easy to implement. (examples excepted). 18

19. Example Results . Image _Grayscale Concept Map UML Class Diagram
9/1/2019
Image _Grayscale
Concept Map
UML Class Diagram
XML Schema
PVL Label Template
Class Definition Table
<!-- PDS4 XML/Schema for Product_Image_Grayscale -->
<xs:complexType name="Image_Grayscale_Type">
<xs:sequence>
<xs:element name="axes_order" type="axes_order_Type"
/* ******* Label Template - Product_Image_Grayscale
Object = Product_Image_Grayscale;
Object = Image_Grayscale;
local_identifier = ${local_identifier}; . 19

20. PDS4 Data Product Model Components
9/1/2019
Registry Object &
Web Resource
Product
Description Combinations
Data Object Description
Structure
Data
Classification
Concept Map to illustrate model’s basic architecture
Data – SOBAWANIK
Structure description – abstract, few, simple
Data object description
DO combinations
Products – package of DO
Identifiable – registry objects, web resources
Grayscale ex, all extension are similar map and Classified
-Fundamental, Extension, Set (combines), Package
Data Set 20

21. PDS4 Data Product Concept Map
9/1/2019
PDS4 Data Product Concept Map
Web & Registry View
User/Designers View
Programmer View
Another concept map to illustrated other products
Classify by user views - Rough
Basic I/O – Get bits into memory – Only 4
Programmer – Display, process image
User view – Products – package of data objects.
Web resources and registry objects – identification, versioning, tracking, distribution, search
Basic I/O View 21 21

22. PDS4 Product Label Creation
9/1/2019
DDWG
Data Engineer
Modeling
Tool A
Modeling
Tool B
Load
Design
Generic Label Schema
Edit
Specific
Label Schema
Design
Generate
Extract
Populate
2nd Process.
Ingest
Label
Ingest
Validate
Label
Model
Data Dictionary
Product Labels
Ingest/
Update
Mission Specific
Current using editor
Current using Oxygen/Future Design Tool
Proposed 22 22

23. Issue - Ambiguity
9/1/2019
A PDS3 Image object only requires the number of lines and line samples in a simple image.
However the 2 dimensional structure becomes a 3 dimensional structure with the addition of the BANDS keyword.
A two dimensional structure is assumed by the omission of the BANDS keyword.
Image Description
Simple Image
OBJECT = IMAGE
LINES = 800
LINE_SAMPLES = 800
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
END_OBJECT = IMAGE
Example of ambiguity.
The data structure is not defined
the omission of a keyword BANDS implies the type of data structure.
Bands – number of bands, a science concept, not structural
Spectral Band - A spectrum consisting of groups or bands of closely spaced lines 23 23

24. Problem Data Structure is not Rigorously Defined
9/1/2019
Current Image Description
Where is the first logical pixel?
Are the pixels in row or column major order?
How many axes exist?
Simple Image
OBJECT = IMAGE
LINES = 800
LINE_SAMPLES = 800
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
END_OBJECT = IMAGE
The pds model does not define structure. It is implied from the description of the data object. 24

25. Solution Rigorously Define Data Structures
9/1/2019
Array_Base Structure
Where is the first logical pixel? TOPLEFT
Are the pixels in row or column major order? FAST2SLOW
How many axes exist? <#axes>
Ambiguity cleared up.
Abstract Data Object Description
Object = Array_Base
Data_Location = (filename, 255);
first_element = TOPLEFT
min_index = 0
number_of_axes = #axes
axes_order = FAST2SLOW
byte_order = MSBF
element_bytes = 1
element_type = DECIMAL_INTEGER
axis_length = (#first, #second, …)
axis_name = (first, second, …)
End_Object = Array_Base
Simple Image
Defines
Concept map – Green
-Fundamental data structure defined
-We can describe the structure of the data object.
Data Object 25

26. Extend a Data Structure
9/1/2019
Data Object Description
Object = Image_Grayscale;
Data_Location = (filename, 255);
first_element = TOPLEFT;
min_index = 0;
number_of_axes = 2;
axes_order = FAST2SLOW;
byte_order = MSBF;
element_bytes = 1;
element_type = DECIMAL_INTEGER;
axis_length = (800, 800);
axis_name = (ROW, COLUMN);
End_Object = Image_Grayscale;
interpreted_by
IS-A
Simple Image
described_by
Extend the structure to interpret the data structure in the science domain. - Blue
Three important pieces of semantic information.
- data object is a Sequence of bits – it is digital
- the sequence of bits are in an array structure with axes and made up of elements.
- the array structure can be interpreted as a grayscale image.
Data Object
IS-A 26

27. Combine Data Structures - Sets
9/1/2019
Data Object Descriptions
Object = Tagged_Image_Grayscale_Set;
Object = Image_Grayscale;
Data_Location = (filename, 255);
first_element = TOPLEFT;
min_index = 0;
number_of_axes = 2;
axes_order = FAST2SLOW;
byte_order = MSBF;
element_bytes = 1;
element_type = DECIMAL_INTEGER;
axis_length = (800, 800);
axis_name = (ROW, COLUMN);
End_Object = Image_Grayscale;
Object = Header;
Data_Location = (filename, 0);
comment = “This Header…”;
bytes = 255;
End_Object = Header;
End_Object = Tagged_Image_Grayscale_Set;
File
Data Object
Data objects can be combined.
- Set 27

28. Package a Product Sets are packaged into products.
9/1/2019
Product
Object = Product_Image_Grayscale
Object = Identification_Section;
Identifier = "PDS4_IMG_IMAGE_...
URN = "
Title = "MARS PATHFINDER LANDER ...
Version = "1.0";
Label_Revision_Note = " :1.0 – initial ...
DD_Version_Id = "DD_Version_Id";
PDS_Version_Id = "PDS4.0";
Product_Creation_Time = T00:36:08.000;
End_Object = Identification_Section;
Object = Circumstances_Of_Observation_Section;
Spacecraft_Clock_Start_Count = " ";
...
Object = Tagged_Image_Grayscale_Set;
Object = Image_Grayscale;
Data_Location = (filename, 255);
first_element = TOPLEFT;
Identification Metadata
File
Data Object
Descriptive Metadata
Sets are packaged into products.
Identification information
The data objects.
Structural Metadata 28

29. Query Model
9/1/2019
A formal model consisting of classes, attributes, and relations
that are appropriate for use as search constraints
Types of query models include
Data Set
Product
Data Product
Document Product
Software Product
Any PDS4 Identifiable
The query models are subsets of the archive model
Can be augmented with external metadata (e.g. LDD)
Example query constraints
general parameters - time, target, mission, instrument host, instrument
any metadata defined in the archive model
any association between two classes
e.g. documents associated with data sets
class type and hierarchy
geometry - (lat, lon), (az, el), (ra, dec), (x,y,z).
Example
- Using current model we could extract a query model that would allows us to find all 3-d array data for an icy giant planet. (neptune and uranus even though the product is not tagged with icy giant)
- Elizabeth has suggested a simple addition that would allow additional constraint, an 3-array with a single spectral plane. 29

30. Benefits of the PDS4 Data Model
The data model is managed in a data modeling tool.
The model is formally defined.
The model can be validated and tested.
Defines a few simple fundamental data structures.
Fundamental data structures may be extended and combined to form more complex data formats
The overall architecture is model driven.
Disentangles the model from its implementation.
Model can evolve over time as research domain changes.
Drives the generation of documentation, label schema, and other model dependent artifacts.
The data dictionary uses a standard data dictionary model.
Restatement