[Esip-documentation] ACDD questions

[Nan Galbraith]

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 <mailto: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 *
*******************************************************


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