[Esip-documentation] ACDD questions

Nan Galbraith ngalbraith at whoi.edu
Fri Apr 26 13:57:43 EDT 2013


Hi John -

One other item that I think we might need to have - beyond better 
definitions
for some of the existing terms -  is a CV for contributor roles. I think 
one exists,
somewhere, but I'm not sure where. BODC, maybe? MMI? Or should this really
be free text?

Thanks -
Nan

On 4/26/13 12:51 PM, John Graybeal wrote:
> Sorry for the noise. I pasted the wrong URL, meant to paste
>     https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery
> as my target space for work. Let me know if that doesn't make sense.
>
> Thank you all for your advice about logging in on ESIP Fed.  I'm getting there…
>
> John
>
>   
> ...
>
> Hi all,
>
> I'm focused on this for the next few hours today. The resources and comments are very far advanced from last time I looked in depth, hopefully I can do something reasonable in that amount of time.
>
> For what it's worth, I think you're both right. So while I may produce some recommended wording updates for variables, I think a broader, more systematic alignment with the ISO capabilities is worth pushing for. More on that later.
>
> Here we go.
>
> John
>
> On Apr 23, 2013, at 08:10, Nan Galbraith <ngalbraith at whoi.edu> wrote:
>
>>> On Apr 22, 2013, at 3:37 PM, Nan Galbraith <ngalbraith at whoi.edu 
>>> <mailto: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/ <http://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


-- 
*******************************************************
* Nan Galbraith        Information Systems Specialist *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                 (508) 289-2444 *
*******************************************************




More information about the Esip-documentation mailing list