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

8/28/12PDS4 Roll-outStatus 2 Management Council Meeting, UCLA 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/12PDS4 Roll-outStatus 3 Management Council Meeting, UCLA November 2012 Testing to Date with the PDS4 data standard Migration testing has been done with several mission datasets Mars 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/12PDS4 Roll-outStatus 4 Management Council Meeting, UCLA November 2012 Testing Process With 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 PDS3  PDS4 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/12PDS4 Roll-outStatus 5 First Mission Node Will Support With PDS4

8/28/12PDS4 Roll-outStatus 6 First Mission Node Will Support With PDS4

8/28/12PDS4 Roll-outStatus 7 Management Council Meeting, UCLA 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 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 PDS4

8/28/12PDS4 Roll-outStatus 8 Data Migration Plans

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

8/28/12PDS4 Roll-outStatus 10 Management Council Meeting, UCLA 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/12PDS4 Roll-outStatus 11 Management Council Meeting, UCLA 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/12PDS4 Roll-outStatus 12 Management Council Meeting, UCLA 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.