One of the things I've noted over the last several years is that there
are several conventions in the atmospheric sciences and oceanography,
but there's little convention or standardization.
I support the concept that we need to promote a semantic mapping among
the various conventions to facilitate crosswalks. I fear, however, that
we've not reached a point that we've got enough cooperation to make
real headway, however.
I'd prefer seeing agreement to cooperate on a semantic process than for
yet another group to decide to revamp the naming conventions without
broad consensus. Steve, I think I am restating what you expressed.
gerry
Steve Hankin wrote:
Hi Mark,
I've taken the liberty of re-posting your message to the CF email list.
The underlying question to the CF group: if a particular community
wants to add additional attributes to their files are there best
practices guidelines to minimize the chances of a name space clash? As
far as I know the answer is "no". But it might be reasonable to devise
such guidelines. What follows is an initial "thinking out loud" on the
subject.
Should CF consider an explicit escape mechanism in the style of ?
:nonCFAttributeList = "foobar1, foobar2, foobar3";
Of course, this does nothing to reduce the chances of a namespace
collision.
A poor-man's namespace can be created with a prefix. So one might imagine
:nonCFattributePrefix = "ngdc_";
and then use ngdc_foobar1, ngdc_foobar2, ... for your attribute names.
You've also posed a question of equivalences -- essentially wanting two
different names for the same attribute in order to satisfy two different
communities. This question feels like it needs to be fleshed out
further. Yes, you have a standard name for a particular concept in some
other standard. But what do you gain by retaining that same name
explicitly in the CF files? Isn't the missing piece the mapping that
shows the equivalence between the name in CF and the name in the other
standard? Your application could read this mapping from an XML file.
NcML is also a vehicle that can be used to allow different applications
to see difference "faces" of a CF file -- essentially renaming the
attributes on the fly. Until we have CFlib, however, (confirm: will
CFlib handle NcML?) the NcML approach is limited to Java code or netCDF
data accessed via OPeNDAP.
- Steve
===============================
-------- Original Message --------
Subject: Are There Best Practices for Developing New NetCDF Conventions?
Date: Mon, 09 Jul 2007 15:09:30 -0600
From: Mark Ohrenschall <Mark.A.Ohrenschall@xxxxxxxx>
Reply-To: Mark Ohrenschall <Mark.A.Ohrenschall@xxxxxxxx>
To: netcdfgroup@xxxxxxxxxxxxxxxx
Hi folks,
We are developing CF compliant netCDF files with additional (or
"optional") metadata in the netCDF header from our own sources, e.g., a
subset of the FGDC metadata content standard, our Rich Inventory
database, etc... Our sources are potentially new, additional netCDF
conventions, and so our essential question is if there is a best
practices guide for netCDF convention developers, especially so that
various conventions do not clash or conflict with each other.
For example, if we are free to name our new, homemade netCDF attributes
however we like, could those attribute names conflict with existing or
future netCDF conventions? Is there any mechanism for indicating which
convention(s) a netCDF attribute complies with? Is there a namespace
mechanism so that if two conventions use the same name for an attribute,
that attribute can be disambiguated?
We're also wondering what to do for those attributes which serve both
the CF convention and our own FGDC (or others) convention. For the sake
of netCDF software that is looking for CF attributes we'd have to name
such a common attribute using its CF name, but what if we also wanted to
ensure that that common attribute remained associated with its FGDC
siblings? (E.g., suppose we wanted to extract all FGDC attributes from
the netCDF header?) Do we then need to define that attribute twice, once
with its CF name and once with its FGDC name?
So we are wondering what the netCDF conventions community thinks about
these considerations, and any advice or experience they may offer us on
how to add our own attributes to a netCDF file in a coherent way that is
harmonious with other, existing conventions.
Thank you -- Mark
==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin@xxxxxxxx
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
"The only thing necessary for the triumph of evil is for good men
to do nothing." -- Edmund Burke
--
Gerry Creager -- gerry.creager@xxxxxxxx
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX 979.862.3983
MAIL: AATLT, 3139 TAMU
Physical: 1700 Research Parkway, Suite 160,
College Station, TX 77843-3139
==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
