PDS Atmospheres Node Plans for PDS 4 User

PDS Atmospheres Node Plans for PDS 4 User Roll-out Reta Beebe Lyle Huber Lynn Neakrase Jim Murphy Nancy Chanover Joni Johnson Irma Trejo Shannon Rees Dylan White Ernesto Gonzalez 8/28/12 PDS 4 Roll-out. Status Management Council Meeting, UCLA 28 -29 November 2012 1

Topics Testing to date with the PDS 4 data standard First mission the node will support with PDS 4 Data migration plans User tool developments plans for PDS 4 roll-out Lessons learned 8/28/12 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 2

Testing to Date with the PDS 4 data standard Migration testing has been done with several mission datasets Mars Phoenix (5 Bundles) PDS 3 – Detached Labels (ASCII Tables) MET package LIDAR Atmospheric Science Experiment (ASE) Atmospheric Opacity (AO) Telltale Anemometer (TT) Accelerometer Data – PDS 3 Attached Labels PDS 4 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 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 3

Testing Process With PDS 4 data standard 1. Migration is being done with a modular approach to allow efficient construction of labels from PDS 3 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 PDS 3 PDS 4 labels). 4. Documents are unpredictable and represent considerable effort in migration and usually require by-hand construction of the PDS 4 label. 5. Ingestion of new data products from LADEE and MAVEN hopes to use the core migration code for populating their PDS 4 labels (i. e. , values gleaned from incoming data will be used to populate a label template much like taking it from a PDS 3 label). 8/28/12 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 4

First Mission Node Will Support With PDS 4 8/28/12 PDS 4 Roll-out. Status 5

First Mission Node Will Support With PDS 4 8/28/12 PDS 4 Roll-out. Status 6

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 PDS 4 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 PDS 4 Migrate the ATMOS Mars archive 2. 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 PDS 4 8/28/12 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 7

Data Migration Plans 8/28/12 PDS 4 Roll-out. Status 8

User tool needs for PDS 4 roll-out PDS-wide, and Node -specific User Tools 8/28/12 PDS 4 Roll-out. Status 9

Reliance on EN Node • Current suite of tools (through Sean Hardman) - PDS-Wide Search - PDS 4 Label to Text (Download and Install) - PDS 4 Label to PDS 3 Label (May not be different from Text) - PDS 3 Label to PDS 4 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 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 10

Lessons Learned Migration Strategies • 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 8/28/12 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 11

Lessons Learned Organization. • 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 PDS 4 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 enduser 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 enduser/scientist perspective. 8/28/12 Management Council Meeting, UCLA 28 -29 November 2012 PDS 4 Roll-out. Status 12