PDS Atmospheres Node Plans for PDS4 User Roll-out

8/28/12 PDS4 Roll-outStatus 1

Reta Beebe Lyle Huber Lynn NeakraseJim Murphy Nancy Chanover

Joni Johnson Irma TrejoShannon Rees Dylan White Ernesto Gonzalez

Management Council Meeting, UCLA 28-29 November 2012

8/28/12 PDS4 Roll-outStatus 2

Management Council Meeting, UCLA 28-29 November 2012

Topics

Testing to date with the PDS4 data standard

First mission the node will support with PDS4

Data migration plans

User tool developments plans for PDS4 roll-out

Lessons learned

8/28/12 PDS4 Roll-outStatus 3

Management Council Meeting, UCLA 28-29 November 2012

Testing to Date with the PDS4 data standard

Migration testing has been done with several mission datasetsMars Phoenix (5 Bundles) PDS3 – Detached Labels (ASCII Tables) MET package LIDAR Atmospheric Science Experiment (ASE) Atmospheric Opacity (AO) Telltale Anemometer (TT)

Accelerometer Data – PDS3 Attached Labels PDS4 Detached Mars Reconnaissance Orbiter Accelerometer (1 Bundle) Mars Odyssey Accelerometer (1 Bundle) Mars Global Surveyor Accelerometer (1 Bundle)

Prototype products for Galileo UVS/EUV Binary tables

Prototype products for Maui Observations of Jupiter and Saturn (FITS) 

Prototyping preparation for upcoming missions LADEE Instrument Label templates (UVS, NMS) MAVEN Instrument Label templates (NGIMS, IUVS [FITS])  

8/28/12 PDS4 Roll-outStatus 4

Management Council Meeting, UCLA 28-29 November 2012

Testing ProcessWith PDS4 data standard

  

1.Migration is being done with a modular approach to allow efficient construction of labels from PDS3 information.

2.Each dataset presents unique issues but the core Python code for migration is the same in each case.

3.Data product label migration is automated with this code (i.e., translating PDS3PDS4 labels).

4.Documents are unpredictable and represent considerable effort in migration and usually require by-hand construction of the PDS4 label.

5.Ingestion of new data products from LADEE and MAVEN hopes to use the core migration code for populating their PDS4 labels (i.e., values gleaned from incoming data will be used to populate a label template much like taking it from a PDS3 label).

8/28/12 PDS4 Roll-outStatus 5

First Mission Node Will Support With PDS4

8/28/12 PDS4 Roll-outStatus 6

First Mission Node Will Support With PDS4

8/28/12 PDS4 Roll-outStatus 7

Management Council Meeting, UCLA 28-29 November 2012

Data Migration Plans

 

MAVEN will act as a driver of our plan MAVEN is an atmospheric loss mission, there are no other Lunar atmospheric missions. The Mars atmospheric community will use PDS4 to access this data. For convenience all Mars data should be available in the same format.

Thus, our plan is:1. Migrate Mars data first Prepare access pages for conversion to PDS4 Migrate the ATMOS Mars archive2. Assuming we migrate Juno data on arrival at the PDS, other Jupiter data should be in a compatible format.3. Migration of Cassini and other data should follow. 

In Addition:We are designing help pages that also can be defined as products in PDS4

8/28/12 PDS4 Roll-outStatus 8

Data Migration Plans

8/28/12 PDS4 Roll-outStatus 9

User tool needs for PDS4 roll-out

PDS-wide, and Node-specific

User Tools

8/28/12 PDS4 Roll-outStatus 10

Management Council Meeting, UCLA 28-29 November 2012

Reliance on EN Node

• Current suite of tools (through Sean Hardman) - PDS-Wide Search- PDS4 Label to Text (Download and Install)- PDS4 Label to PDS3 Label (May not be different

from Text)- PDS3 Label to PDS4 Label (Download and Install)- Data Format Translations (In development as

needed)

• Current versions of these tools are usable now, but may not be the final interfaces

• Interfacing between our local registry and the global registry will still require EN support regarding search routines

• Data format translations are low priority at this time for ATM data migration efforts (Most likely to be handled in-house as needed; e.g., Binary Table to Character Table translation for end users)

8/28/12 PDS4 Roll-outStatus 11

Management Council Meeting, UCLA 28-29 November 2012

Lessons Learned

• Use simple products to start with to exercise in house automation of the data labeling adding complexity with each iteration/new migration.

• Related products should be given priority in the migration queue.

For ATM:Mars products first (to dovetail with

MAVEN)Jupiter products next (driven by JUNO)

•Migration WILL NOT be a one-time event, but a continuum of reiteration and refinement.

Every migration (each migrated dataset) will allow refinement of the process and provide new insight on best practices.

Some early focus must be on automating parts of the process to be independent of the version of the schemas.

Discussion of lessons learned across the DNs will help each node refine this process 

Migration Strategies

8/28/12 PDS4 Roll-outStatus 12

Management Council Meeting, UCLA 28-29 November 2012

Lessons Learned

 

• The data have to be organized slightly differently from past iterations.

• Bundle structures must be clearly visible and spelled out for the user.

• Need to treat every user for PDS4 as a novice because of the Bundle-Collection-Product structure and the XML usage.

• Website design should, in part, drive some of the organization the goal is end-user ease-of-use.

• The One-Stop-Shop/User Guide approach seems to be a good starting point for the ATMOS node for linking all related data and documentation.

• Having multiple reviewers with constructive input has helped in refining our focus in what is important from the end-user/scientist perspective.

  

Organization.