Discussion on an HDF-GEO concept

At the past several HDF & HDF-EOS Workshops, there has been some informal discussion of building on the success of HDF-EOS to design a new profile, tentatively called HDF-GEO. This profile would incorporate lessons learned from Earth science, Earth applications, and Earth model data systems. It would encompass all types of data, data descriptions, and other metadata. It might support 1-, 2-, and 3-D spatial data as well as time series; and it would include raw, calibrated, and analysed data sets. It would supprt data exchange by building its needed complexity on top of minimal specialized features; and by providing clear mechanisms and requirements for all types of appropriate metadata.

The organizers propose to host a discussion among the workshop participants on the need, scope, and direction for HDF-GEO. Souorce material will be found at ......

---

Discussion points:

• 1. Motivation: In many instances, application-specific 'profiles' or 'conventions' or best practices have shown their utility for users. In particular, profiles have encouraged data exchange within communities of interest. HDF provides minimal guidance for applications. HDF-EOS was a mission-specific profile; resulted in successes and lessons learned. HDF5 for NPOESS ia another approach. Is it time for another attempt, benefitng from all the lessons, and targeted at a broader audience?

• 2. Questions for discussion by Earth science practitioners - Bottom-up analysis:
• 2.1 What are the successful features of existing community data formats and conventions (HDF5, HDF-EOS, netCDF, CDF, GRIB BUFR, COARDS, CF-1, NITF, FITS, FGDC RS extensions, ISO, ...)
• 2.2 Progress being made -- John Caron's Common Data Model
• 2.3 Specific needs for geo- and time-referenced data conventions
• 2.4 Specific needs to support observed (raw), calibrated, and ananlyzed data sets

• 3. Questions for discussion by Earth science practitioners - Top-down analysis:
• 3.1 What is a profile? -- Specifics of how a standard or group of standards are implemented for a related set of uses and applications.
• 3.2 How does a profile relate to a format or other elements of a standard?
• 3.3 Why is it useful?
  • -- Establishes specific meanings for complicated terms or relationships
  • -- Establishes common preferred terms for attributes which can be described multiple ways.
  • -- Establishes practices which are consistent with portability across operating systems, hardware, or archives
  • -- Establishes common expectations and obligations for data stewardship
  • -- Clarifies community (and sponsor) long-term expectations, beyond short-term necessity
  • -- other ...
• 3.4 What consititutes overkill? How much profile would be beneficial, and how much would be difficult to implement and of limited utility?

• 4. Discussion
• 4.1 Is there a finite, definable Earth science & applications community of interest which can define internal data requirements? How does it relate to GIS? How does it relate to remote seninsing/imaging? How does it relate to modelling & simulation?
• 4.2 Bring your examples of successes and failures
• 4.3 Bring your opinions or experiences with too much or too little specificity in a profile
• 4.4 Is it worth the effort to establish a profile?
• 4.5 Should the activity be pro-active or passive, i.e., done by a committee, or allowed to happen with encouragement?
• 4.6 Should the profile be implemented as a subset of HDF, or as a set of design practices?

Back to abstracts

Last modified: 06/02/2017