This is a multi-part message in MIME format.
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
Mark et al.-
We at NCDC are working on a similar issue. Specifically, we're looking
at how best to store satellite data by writing a new convention that
extends CF for some satellite specific issues. The metadata
content/attributes is an excellent example of what needs to decided.
IMO, I recommend a naming convention similar to that used by Unidata for
http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html
be used. Unidata made an attempt to show how the metadata can be mapped
to other standards at:
http://www.unidata.ucar.edu/software/netcdf-java/formats/ncACDD-metadataMappings.html
In short, what could be done is
a) Data producers provide data in netCDF files following some convention
(CF, ...)
b) Producers provide metadata following a "generic" Metadata Convention
(e.g., specified using global attribute "Metadata_Conventions") .
c) Metadata harvesters can then build algorithms to search for and map
the generic metadata to their preferred convention (e.g., FGDC)
Perhaps a standard metadata naming convention could be developed
(similar to the standard_names in CF) which is a "lowest common
denominator" of the existing conventions? Of course the downside to this
is that it produces another metadata convention...
Or perhaps each standard (FGDC, ISO19115, ...) could have its own list
of netCDF attributes.
Also, NCML could also be used to provide mapping and attribute renaming
from one convention to another.
Additionally, with respect FGDC information, it would good to provide
only dynamic metadata in the netCDF file and provide static metadata
through a link/URL.
These aren't answers, just more ideas.
-Ken
p.s. As a post-script/appendix, I am attaching a portion of our strawman
(which is still being developed mind you ;-) CF-Satellite convention [an
extension of the CF convention to archive satellite data]
>
>
> Appendix A. Attributes
>
> The CF convention specifies a small number of attribute names (at
> least compared to metadata conventions like FGDC, etc.). For CF-SAT,
> we categorize metadata as 'use' or 'discovery' metadata. 'Use'
> metadata are those which need to be applied to the data to make use of
> the variables (this describes the bulk of the CF attributes). On the
> other hand, 'discovery' attributes are those which summarize or
> provide more detail of the data. In netCDF data, discovery attributes
> tend to be global attributes.
>
> There is, of course, overlap between use and discovery metadata,
> however, it provides a conceptual means for identifying the purpose of
> the attributes: attributes are either used to help the data be used or
> understood.
>
> Furthermore, conventions such as FGDC require metadata that is both
> dynamic and static. For instance, in satellite data, orbital
> parameters change periodically so they are dynamic. However, the
> launch of the satellite is constant and not changing, thus it is
> static. It is proposed that some static metadata not be recorded in
> the CFSAT convention (i.e., in the netCDF file), rather data users can
> be pointed to a static URL using a global attribute from which the
> remaining static metadata can be determined.
>
> It is convenient that the efforts of dataset conventions (like CF)
> have primarily been concerned with Use metadata while other
> conventions (e.g., FGDC) provide requirements on discovery metadata.
> The two are largely orthogonal in that using the complete CF
> attributes and a metadata convention like FGDC will provide little
> conflict.
>
Mark Ohrenschall said the following on 7/9/2007 5:09 PM:
> 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
> ===============================================================================
>
>
>
--
Ken Knapp
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave
Asheville, NC 28801
828-271-4339 (voice) 828-271-4328 (fax)
