[Fwd: Are There Best Practices for Developing New NetCDF Conventions?]

[Gerry Creager]

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 at noaa.gov>
> Reply-To: 	Mark Ohrenschall <Mark.A.Ohrenschall at noaa.gov>
> To: 	netcdfgroup at unidata.ucar.edu
> 
> 
> 
> 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 at noaa.gov
> 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 at tamu.edu
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
==============================================================================