PDS Atmospheres Node
Plans for PDS4 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
PDS4 Roll-outStatus
Management Council Meeting, UCLA 28-29 November 2012
1
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
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
2
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])
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
3
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).
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
4
First Mission Node Will Support With PDS4
8/28/12
PDS4 Roll-outStatus
5
First Mission Node Will Support With PDS4
8/28/12
PDS4 Roll-outStatus
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 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
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
7
Data Migration Plans
8/28/12
PDS4 Roll-outStatus
8
User tool needs for PDS4 roll-out
PDS-wide, and
Node-specific
User Tools
8/28/12
PDS4 Roll-outStatus
9
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)
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
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
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
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 PDS4 as a
novice because of the Bundle-CollectionProduct structure and the XML usage.
• Website design should, in part, drive some of
the organization  the goal is end-user easeof-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.
Management Council Meeting, UCLA 28-29 November 2012
8/28/12
PDS4 Roll-outStatus
12