Conventions

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: Conventions
• From: kegp@xxxxxxxxxxxxx (k.prada)
• Date: Thu, 22 Oct 1992 08:31:29 EDT

Greetings,

I have read with pleasure all the comments generated as a result of Tim
Holt's announcement about netCDF use and my subsequent reply a month
ago.  The discussions are productive and positive.  My interest is that
of a toolmaker rather than an active user.  From the perspective of
someone crafting generic (and specific) software tools:

It is clear that needs and applications are quite diverse.  They range
from the flat recorded data sets from shipboard (re: Holt) to complex
models (re: Signell).  Conventions should be implemented that aid some
or all in handling, processing and sharing data sets.  Conventions
should not impose needless hardship upon users or toolmakers. The
design should not impose restrictions in order to accomodate low
probability needs or events.

It should be possible to have several layers of conventions, such as:

    - A minimal set that applies to all oceanographic data sets.
    - instrument specific conventions (CTD, ADCP,.....).
    - platform specific conventions (ship, buoy, bottom lander, ROV,.....).
    - discipline specific conventions (PO, Acoustics, Geology,.....).
    - application specific conventions .
    - site specific conventions (WHOI, PMEL, USGS,.......).

Attributes that have no relevance can be ignored, while others may be
added to support individual preferences and needs. NetCDF is strong and
versatile enough to support most or all of these needs.  It and a set of
wisely crafted conventions can achieve most of our goals.

The goals of establishing conventions must emphasize:

    o Provide a framework within which access to all oceanographic
      data is optimized.
    o Improve the situation where oceanographic data and software are
      rarely re-used within disciplines, and almost never re-used 
      between disciplines.

An analogy to all this might be a local area network.  The physical
layer is probably a coax cable (storage media).  The signal layer might
be ethernet (netCDF). Several protocols might co-exist using that
signal method (our conventions).  

We should also seek involvement from the many potential users and
contributors that do not reside on this mailbox.

Variable Names vs Attributes:

The strong advantages of netCDF reside in the richness of variable and
global attributes.  It is difficult to apply broad variability and
diverse meaning through the use of variable names.  The use of an
attribute "long_name" with an additional (and optional) modifier or
amplifier attribute such as "type" can contain an immense amount of
variability while retaining some simplicity.

For example, a mooring site has a large suite of instruments above and
below the water.  Temperature is measured at many locations by a
variety  of instruments.  In all cases it is a measure of temperature. 
In some cases it is water temperature, in others air.  In each case the
"long_name" is temperature.  The "type" attribute can define air or
sea.  An attribute "source" or "instrument_type" can define what made
the measurement.  A dimension or additional attribute can define
instrument depth or height.  At some point in future processing, a
"type" or other attribute may contain 'with John Doe's Scale Factor'. 
None of this information can be embodied in a variable name.

If I wanted to visualize temperatures (in any comparative way) from 
one or more data sets, I would search for "long_name" temperature
in all the variable names.  This would be easier than needing to know
all the possible variable name variants.  
___________________________________________________________________________
            Ken Prada                 |
Applied Ocean Physics and Engineering |       (508) 457-2000 Ext 2711       
Woods Hole Oceanographic Institution  |          kegp@xxxxxxxxxxxxx
  Woods Hole, Massachusetts  02543    |