[Esip-documentation] ACDD questions

Fri Apr 26 20:09:46 EDT 2013

I think we would be more of a "community" role providing guidelines for best practices. If we do the job well then it would evolve into a "standard developer."

Regarding CF, in some ways they already use "codelists", e.g., standard names, so it is not entirely new. Its just their standard names are very human readable at the same time.

These are all very interesting topics we can expand on for the ESIP Summer meeting next July !

On Apr 26, 2013, at 11:38 AM, Derrick Snowden - NOAA Federal wrote:

Ted

Which role do you see this new ACDD steering group filling?  That of "standard developer" or that of "community".  I see us closer to the second role where we are providing fairly specific guidance and not just a framework for extensions.

Codelists can be seen as antithetical to the CF goal of creating self describing files.  Can we figure out a way to encode ISO objects with the need for references to other objects while still staying true to our goal of remaining aligned with CF?  The last thing I'd want us to recommend is to open a door down a pathway back to Grib and BUFR.

Other thoughts?

Derrick

On Fri, Apr 26, 2013 at 2:30 PM, Ted Habermann <thabermann at hdfgroup.org<mailto:thabermann at hdfgroup.org>> wrote:
John et al.,

I agree completely that a shared vocabulary with definition is critical. The old ISO vocab is at https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries#CI_RoleCode. Many new roles were added in the most recent revision. There is also a brief discussion at http://wiki.esipfed.org/index.php/ISO_People (I will update that list to include revisions)...

What is really important is that the representation allow specification of the source of the code along with the code itself. This is possible in THREDDS, but not ACDD. The job of the standard is to say we use a codelist for this item and that codelist has a location. It is the communities job to say: this is the codelist that our community uses.

Ted

On Apr 26, 2013, at 1:02 PM, John Graybeal <graybeal at marinemetadata.org<mailto:graybeal at marinemetadata.org>> wrote:

Should be from a controlled vocabulary IMHO. BODC has (for SeaDataNet) an extension of ISO role terms, if I recall correctly. I think it isn't just for contributor roles, it's for all roles that this is needed—ISO wasn't very thorough in the first place, but there will always be new ways for people to be connected to a data set.

I don't think we have to be restrictive (in what roles are allowed) but I think we should try to be explicit (about what a role means).

John

On Apr 26, 2013, at 10:57, Nan Galbraith <ngalbraith at whoi.edu<mailto:ngalbraith at whoi.edu>> wrote:

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<mailto:ngalbraith at whoi.edu>> wrote:

On Apr 22, 2013, at 3:37 PM, Nan Galbraith <ngalbraith at whoi.edu<mailto: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/> <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<tel:%28508%29%20289-2444> *
*******************************************************

_______________________________________________
Esip-documentation mailing list
Esip-documentation at lists.esipfed.org<mailto:Esip-documentation at lists.esipfed.org>
http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

_______________________________________________
Esip-documentation mailing list
Esip-documentation at lists.esipfed.org<mailto: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<tel:%28217%29%20531-4202>
   New email: thabermann at hdfgroup.org<mailto:thabermann at hdfgroup.org>
==== thabermann at hdfgroup.org<mailto:thabermann at hdfgroup.org> ==================

_______________________________________________
Esip-documentation mailing list
Esip-documentation at lists.esipfed.org<mailto:Esip-documentation at lists.esipfed.org>
http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

--
Derrick Snowden
System Architect, US IOOS <http://www.ioos.noaa.gov/>
1100 Wayne Ave, Suite 1225
Silver Spring, MD 20912
+1 301 427 2464 (o), +1 301 427 2073 (f)

Find us on Facebook<http://www.facebook.com/usioosgov>
_______________________________________________
Esip-documentation mailing list
Esip-documentation at lists.esipfed.org<mailto:Esip-documentation at lists.esipfed.org>
http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

-ed

Ed Armstrong
JPL Physical Oceanography DAAC
818 519-7607

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