I'm glad this discussion is open again - it's an important area for
CF to be involved in.
The geo-ide wiki is a useful reference, but there's not a lot of
discussion there, and no clear opportunity to participate.
Some of the mapping seems a little loose (e.g. NACDD summary is
mapped to ISO abstract - are these really the same?). Also, the
'roles' that are hard-wired don't necessarily translate well for some
institutions; creator, publisher, and then contributor(s), who can be
'principal Investigator' or 'author.' Ideally, at least in my world, there
would be some top-level terms like principal investigator (data owner),
metadata author (who created the NetCDF attributes), data editor, etc.
Last, the 'file dates' - created, issued, and modified - could use better
definitions; is the creation date ever different from the date modified
in NetCDF? When is data 'issued' -or in ISO/CI terms, published? My
feeling is that these are not necessarily appropriate for all data sets.
We use a version date, and a history attribute (which, admittedly,
should be improved), and leave it at that.
The mapping is really helpful, and a good step forward, but it
does seem like some discussion would be helpful.
John G wrote:
> So I may be missing the mark, but I see Martin's request as being
> about encoding ISO-compatible data into NetCDF files, whereas at first
> glance the NOAA/Unidata work appears to be about transforming pure
> NetCDF data/metadata into ISO format.
>
> It seems to me a fundamental question is whether you want to encode a
> complete ISO file as a single text attribute, or ISO attributes as
> NetCDF attributes using a standard transformation. Either could be
> done systematically. ..
>
> John
Encoding an ISO record as a single attribute would mean an awful
lot of redundant metadata, and that would create too much of
an opportunity for conflicting information, IMHO.
Using appropriately named attributes and relying on simple software to
generate the ISO record seems much more straightforward. Whether that
software should traverse only the global attributes or actually look at the
data seems like a pressing question; e.g. providing coordinate extents as
attributes instead of using the actual coordinate data values seems like
a potential problem, especially when data is subsetted by a web service.
Cheers -
Nan
>
> On Feb 21, 2011, at 04:27, Rich Signell wrote:
>
>> Martin,
>>
>> Ted Habermann & Dave Neufeld at NOAA and Ethan Davis at Unidata have
>> been making great strides in this department. I'm sure they'll
>> chime in with more info, but to get going, check this out:
>>
>> https://geo-ide.noaa.gov/wiki/index.php?title=NcISO
>>
>> -Rich
>>
>> On Mon, Feb 21, 2011 at 5:52 AM, Schultz, Martin
>> <m.schultz at fz-juelich.de <mailto:m.schultz at fz-juelich.de>> wrote:
>>
>> Dear all,
>>
>> after searching the mailing list archive without success, I
>> would like to bring up the topic of the ISO19115 metadata
>> standard for geographical information and how to best map this
>> into CF. Obviously, the ISO standard builds on XML and its
>> hierarchical structures, while (global) attributes in netcdf
>> files are "flat". While "professional" applications can organize
>> databases and maintain proper links between metadata information
>> in XML files and data in netcdf files, the normal user risks
>> loosing a lot of metadata information if he relies solely on the
>> content of the file. All that CF1.5 lists for the "Description of
>> file contents" is:
>>
>> "
>> title: A succinct description of what is in the dataset.
>> institution: Specifies where the original data was produced.
>> source: The method of production of the original data. [...]
>> history: Provides an audit trail for modifications to the
>> original data. [...]
>> references: Published or web-based references that describe the
>> data or methods used to produce it.
>> comment: Miscellaneous information about the data or methods
>> used to produce it.
>> "
>>
>> As an example of the level of detail ISO19115 defines, here is an
>> excerpt from
>> http://eden.ign.fr/xsd/isotc211/isofull/20090316/gmd/citation.xsd/view:
>>
>> <xs:complexType name="CI_Citation_Type">
>> <xs:annotation>
>> <xs:documentation>Standardized resource reference</xs:documentation>
>> </xs:annotation>
>> <xs:complexContent>
>> <xs:extension base="gco:AbstractObject_Type">
>> <xs:sequence>
>> <xs:element name="title" type="gco:CharacterString_PropertyType"/>
>> <xs:element name="alternateTitle"
>> type="gco:CharacterString_PropertyType" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element name="date" type="gmd:CI_Date_PropertyType"
>> maxOccurs="unbounded"/>
>> <xs:element name="edition"
>> type="gco:CharacterString_PropertyType" minOccurs="0"/>
>> <xs:element name="editionDate" type="gco:Date_PropertyType"
>> minOccurs="0"/>
>> <xs:element name="identifier"
>> type="gmd:MD_Identifier_PropertyType" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element name="citedResponsibleParty"
>> type="gmd:CI_ResponsibleParty_PropertyType" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element name="presentationForm"
>> type="gmd:CI_PresentationFormCode_PropertyType" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element name="series" type="gmd:CI_Series_PropertyType"
>> minOccurs="0"/>
>> <xs:element name="otherCitationDetails"
>> type="gco:CharacterString_PropertyType" minOccurs="0"/>
>> <xs:element name="collectiveTitle"
>> type="gco:CharacterString_PropertyType" minOccurs="0"/>
>> <xs:element name="ISBN" type="gco:CharacterString_PropertyType"
>> minOccurs="0"/>
>> <xs:element name="ISSN" type="gco:CharacterString_PropertyType"
>> minOccurs="0"/>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>>
>> I believe it would be nice if these two worlds could be better
>> connected. Obviously, an easy way would be via URI (for example
>> in a global attribute called iso19115 which would point to a
>> location where the XML file can be obtained). However, this is
>> rather fragile and it would be nice to save the extended metadata
>> information in the file itself. One way could be an attribute
>> named xml (either global or variable attribute(s)" which would
>> contain XML text - this text could then identify itself as being
>> ISO19115 compliant, for example. A virtue of such a concept would
>> be that automated data servers could insert the "external"
>> metadata information in the file upon delivery. Since the present
>> attributes to describe the file content are optional anyway, CF
>> wouldn't need to be modified much, except for mentioning the xml
>> attribute and its purpose.
>>
>> If there are other ways to integrate ISO19115 and CF which have
>> proven efficient in practice, I'd be happy to learn about them.
>>
>> Best regards,
>>
>> Martin Schultz
>>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Wed Feb 23 2011 - 09:29:31 GMT
