Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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 ==============================================================================
netcdfgroup archives: