Mark,
> 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.
I don't know of any such guide. Last week, John Caron and I gave a
talk on "Writing NetCDF Files: Best Practices" which touched on
conventions, including looking at some existing conventions for
observational data and at some issues in developing CF conventions for
netCDF-4. If you're interested in the presentations, they're
available here:
http://www.unidata.ucar.edu/community/seminars/
> 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?
You're right, there is a potential for name clashes in trying to
comply with multiple conventions, and we have no agreed on mechanism
to avoid this yet. Benno Blumenthal (IRI, The Earth Institute at
Columbia University) has requested that we add namespaces to netCDF
attributes, but we haven't figured out a reasonable way to do that
yet.
There are potential problems with using the natural XML syntax, since
an attribute name like "foo:bar" in CDL could be interpreted either as
a variable attribute named "bar" for a variable named "foo" or a
global attribute named "bar" in the namespace referred to by "foo".
An alternative is using a different character than ":" for namespaces.
New conventions can avoid collisions with existing namespaces by
choosing a unique short prefix for all their attributes, but it's too
late to require this for existing conventions like CF.
> 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?
In netCDF-4, groups provide name scopes within a single dataset, so an
FGDC group could have a group-level attribute named "title" and a
DublinCore group could have a different group-level attribute named
"title". But that doesn't solve the problem for variable attributes
or for netCDF-3.
> 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.
For now I would recommend simple prefixes as part of the attribute
name in new conventions comprehensive enough that name clashes with
existing conventions are likely. We'll consider other suggestions,
but we have to be conservative with regard to compatibility with
existing conventions, software, and data archives.
--Russ
==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
