[Esip-documentation] ACDD questions

Sat Apr 27 07:54:26 EDT 2013

Ted - thanks for reminding me of this page.  It is full of good info.

All  - I should mention that in NODC's approach to the CF/ACDD-compliant netCDF templates, we were addressing a related but perhaps fundamentally different problem.  We were explicitly (and are explicitly) not trying to solve the problems/weaknesses/imprecisions/etc in the existing standards.  We are focused, in the NODC netCDF template work, solely in tying to help people use the existing standards.  Despite the problems, the standards are already incredibly useful for a variety of purposes so we will keep trying to get more people on board with them.

In discussions like this flurry of recent emails, however, we are happy to help try to solve the problems too :-)  I think my point is that in any references to the NODC templates we should keep in mind what I said above and that they are just our best attempt at translating the complicated language of the documentation and making sense of the existing standards for our community of ocean data producers. 

Ken

On Apr 22, 2013, at 5:17 PM, Ted Habermann <thabermann at hdfgroup.org> wrote:

> Nan et al.,
> 
> Most of these concerns are discussed at http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata along with more general solutions. IMHO, we should go after real cures rather than patching a few symptoms...
> 
> Ted
> 
> 
> On Apr 22, 2013, at 3:37 PM, Nan Galbraith <ngalbraith at whoi.edu> wrote:
> 
>> On 4/19/13 8:15 PM, John Graybeal wrote:
>>> As I had a fair number of comments on the last set of definitions, I volunteer to produce a first revision (for discussion of course!) of any term definitions you want me to.
>> That's great. It might be a good idea to cross check against the definitions 
>> that NODC has added -  as part of their NetCDF template project they wrote
>> some better descriptions. They're at nodc.noaa.gov/data/formats/netcdf/ 
>> 
>> There are a few categories of terms that need better definitions, IMHO. 
>> 
>> 1. people: 
>> creator_name (recommended)
>> publisher_name (suggested)
>> 
>> In a 'normal' research/observing/modeling situation, who are these people?  
>> 
>> I think there are 2 necessary points of contact, the person who 'owns'
>> the research and gives you the go-ahead to use/publish the data, and 
>> the person who put the data into the file and/or on line. You don't really
>> need to know how to contact the other contributors, even if they had equally 
>> or more important roles.
>> 
>> I believe that NODC recommends naming the principal investigator as the 'creator' - 
>> although in some circumstances there is no single PI, so maybe we should say this
>> is the person who grants the use of the data.
>> 
>> I'm using the publisher as the person who wrote the actual file that contains
>> the terms, and I'm listing co-PIs and data processors as contributors.
>> 
>> 2. file times:
>> date_created (recommended)
>> date_modified (suggested)
>> date_issued (suggested)
>> 
>> These could well have different meanings for model data; for my in situ data, I 
>> have 2 (or, for real time data, possibly 3) useful file times; the time the last edit
>> or processing occurred, which is the version information and could be useful if
>> the underlying data has been changed,  and the time the file was written, which 
>> could provide information about translation errors being corrected. (We don't update 
>> files, we overwrite them; some people might need to describe the  time the
>> original file was written and time of last update?) For real time data it could also be
>> interesting to know the last time new data arrived, which could be asynchronous.
>> 
>> NODC doesn't seem to use date_issued, but they have defs for created and modified.
>> 
>> date_created:  "The date or date and time when the file was created.
>> ... This time stamp will never change, even when modifying the file." 
>> 
>> date_modified: This time stamp will change any time information is changed in
>> this file. 
>> 
>> 3.  Keywords - since iso uses keyword type codes instead of cramming all the 
>> possible keywords (theme, place, etc) into one structure, I don't see why we don't 
>> do something similar. We could use our pseudo-groups syntax; keywords_theme, 
>> keywords_dataCenter ...etc.
>> 
>> 4. coordinate 'resolution' terms - the word resolution is a poor choice, and if
>> it's going to be kept, it needs to be defined as meaning 'spacing' or 'shape' and 
>> not an indication of the precision of the coordinate. For measurements that are
>> irregularly spaced along a mooring line, it's fairly useless - unless we come up
>> with a vocabulary describing this and other possible values. 
>> 
>> For my data, the term might be more useful with the other definition; our depths 
>> are approximate 'target depths', and, while we may know the lat/long of an anchor 
>> and of a buoy (the latter being a time series, the former being a single point)  we 
>> don't actually know the lat/long of any given instrument on a mooring line. The
>> watch circle of the buoy is really the 'resolution' we need to supply here.
>> 
>> 
>> Thanks - Nan
>> 
>> 
>> 
>> On 4/19/13 8:15 PM, John Graybeal wrote:
>>> On Apr 19, 2013, at 13:33, Derrick Snowden - NOAA Federal <derrick.snowden at noaa.gov> wrote:
>>> 
>>>> I also think we need another page that serves as the versioned list of attributes (if it's not on the list, it's not part of the convention) and that each attribute contain a well written clear definition.  I think the definitions we have now need to be improved. 
>>> 
>>> As I had a fair number of comments on the last set of definitions, I volunteer to produce a first revision (for discussion of course!) of any term definitions you want me to.
>>> 
>>> +1 on multiple keyword vocabularies. The nice thing about being able to use a recognizably unique code (e.g., a URI) is that the provider can choose what level to provide the keywords, and for what topics, and with what vocabularies. I think this will result in more, and more accurate, keywords than if we constrain it.
>>> 
>>> John
>>> 
>>> 
>> 
>> -- 
>> *******************************************************
>> * Nan Galbraith        Information Systems Specialist *
>> * Upper Ocean Processes Group            Mail Stop 29 *
>> * Woods Hole Oceanographic Institution                *
>> * Woods Hole, MA 02543                 (508) 289-2444 *
>> *******************************************************
>> 
>> 
>> _______________________________________________
>> Esip-documentation mailing list
>> Esip-documentation at lists.esipfed.org
>> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation
> 
> ==== Ted Habermann ===========================
>    Director of Earth Science, The HDF Group
>    New phone#: (217) 531-4202
>    New email: thabermann at hdfgroup.org
> ==== thabermann at hdfgroup.org ==================
> 
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20130427/3cc105d0/attachment.html>