1

PDS 4 Data Design WG Face-to-Face Summary

PDS Management Council

March 25, 2010

Meeting Goals

• In-depth discussion of big-ticket items

• Consider Implementation Details

• Scheduling

Major Take-aways

In no particular order:

• The label model needs to be simpler.

• Nomenclature is tricky in subtle ways.

• Implementation must be tractable.

• The DDWG should be wary of making policy.

• We have a useful concept of an “archive package”.

The label model needs to be simpler.

• Some division is good.

• Too much division is confusing and/or tedious.

We need to design for the non-PDS employee who is preparing or using data, not just ourselves. We have adjusted the model accordingly.

Nomenclature is tricky in subtle ways.

• We will certainly make nomenclature rules for some values - like IDs, times, etc.

• We can make nomenclature rules for keyword and class names - how to use case and underscores, class words, etc.

• We must enforce any rules we make.

Any nomenclature rules we make must be sufficiently useful to justify the effort and annoyance involved in enforcing them.

Implementation must be tractable.

• We have strictly limited time and resources.

• Model implementation has to proceed in step with other development.

• Schedule coordination with the Systems group is essential, and the two groups are working closely to keep on track.

Most data preparers do not work for the PDS and will require a high degree of support initially.

The DDWG should be wary of making policy.

• Data-related policies are reflected in the model, in things like data level designations, mission and instrument description links, etc.

• The model can also help enforce policies by requiring, e.g., that certain things be non-null.

The DDWG should be particularly careful about placing anything in the model that could be interpreted as a policy that does not already exist. If we need a policy decision, we must ask for one.

We have a useful concept of an “archive package”.

• We started to discuss a general-purpose “package” for delivery, distribution, etc.

• This led to discussions about associations across the PDS holdings to, for example, documentation, calibration data, etc.

• This in turn led to brainstorming about indices – how they might be formulated and used for various purposes.

Follow-up discussions on packaging for the deep archive have led to the concept of a “primary collection” and an “archive collection” – the analog of the PDS3 DATA_SET in the product-centric PDS4 paradigm.

Scheduling

• The DDWG and System Design WG need to stay in step.

• The DDWG work is being carefully scoped and kept on track with the system development.

• We need to pay particular attention to decisions we make now which it would be difficult or expensive to change later.

• Complex issues needing to be discussed in depth and resolved on schedule cannot be postponed.

Next Face-to-Face

• Finalize dictionary format(s)

• Finalize data product label structure

• Finalize document product label structure

• Finalize technique(s) for cross-referencing products to other elements in the PDS holdings

• Road-test XML and XML Schema procedures for data preparation

• Define generalized transfer package

Tentatively scheduled for April 19-23

Backup

11