[Esip-documentation] New ACDD home page

Fri Jun 14 12:26:26 EDT 2013

I think I agree with Nan in principle but a recent discussion on the CF
list might point to a slightly different definition.  See
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056660.html

Also, in that email chain you can see that the originator referred to the
unidata ACDD page.  Has anyone asked Ethan to put a note at the top of his
page referring people to the new ESIP page?

-Derrick

On Fri, Jun 14, 2013 at 10:45 AM, Nan Galbraith <ngalbraith at whoi.edu> wrote:

>  Hi all -
>
> One comment on the standard_names_vocabulary attribute on the working page,
> which was changed from the NODC templates, which were based on the
> original
> documentation:
>
> 'Since these templates comply with CF conventions, this attribute should
> contain "CF-1.6". '
>
> to:
>
> ' The unique name or identifier of the controlled vocabulary from which
> variable standard
> names are taken. If more than one controlled vocabulary is used, each may
> be presented
> with a prefix (e.g., "CF:NetCDF COARDS Climate and Forecast Standard
> Names") and a
> following comma, so that standard names may optionally be prefixed with
> the controlled
> vocabulary key. '
>
> I really prefer the old version, for 2 reasons. I think the vocabulary
> version is quite important,
> at least for CF, and, possibly more importantly, at present there's no
> namespace mechanism
> in CF, so an attribute like
>
> TEMP:standard_name = "CF:sea_water_temperature" ;
>
> is not a legitimate CF declaration.
>
> Cheers - Nan
>
>
>
>
>
> On 5/20/13 9:54 PM, John Graybeal wrote:
>
> Hi everyone,
>
>  I talked with David N and Derrick S end of last week, and we agreed on
> some basic strategies, and today I finally updated all the definitions [1].
>
>  Please consider these new definitions -- and deletions [3], additions,
> and rearrangements into different categories -- food for discussion.  You
> might want to first decide whether to broadly accept the approach in each
> case, then nit-pick the definitions.
>
>  The approaches are documented in some detail in the discussion page of
> the Working document [2]. But extremely briefly:
> - Neither totally computable, nor totally incomputable (but just right
> :->); encouraged use of structured text in many fields
> - Somewhat flat, but somewhat structured: structured text in fields
> (optionally), but fewer fields with ancillary metadata
> - Support a range of keyword styles, but avoid recommending any in
> particular; support multiple keyword and standard_name vocabularies
> - Generally did not include guidance, as much for lack of time as
> anything. I think a third column with guidance/references would be most
> valuable.
> - Reflected recommendations like
> http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata in terms
> of the skeleton, but considered them more guidance than something we could
> require at this stage. (Small steps.)
>
>  Other changes broadly described:
> - Geospatiotemporal: Now much more explicit about the geospatiotemporal
> attributes
> - Lineage: Now much more explicit about possible forms for this
> information.
>
>  As someone who works a lot with rich structured metadata, I like the
> flexibility this new approach gives to do that. Conversely, I don't think
> it shuts down any of the less formal providers/documenters of metadata.
> I'll be curious to see your inputs.
>
>  John
>
>
>  [1]
> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_(ACDD)_Working
> [2]
> http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_(ACDD)_Working <http://wiki.esipfed.org/index.php/Talk:Attribute_Convention_for_Data_Discovery_%28ACDD%29_Working>
> [3] We might want to move deletions into a deprecated section, so that
> they are allowed for backwards compatibility.
>
>  ======================================  (Past email thread, for
> reference)
>
>  In any case I will be tossing some additional specific text for each
> term on the working page (
> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_(ACDD)_Working).
>  Please take that page into account as you go forward.
>
>  There is a conflict in short-term and longer-term strategies, which I'll
> summarize here.  One can either have a flat list of attributes, or a list
> that supports rich relationships (groupings and descriptions of them), or a
> hybrid that cobbles together a way to show rich relations in a flat list.
> This especially affects contacts and their roles.  I classify it as
> short-term vs long-term, because I'm sure someday we'll want to migrate to
> the richer relations approach (or at least a hybrid), but I understand that
> time may not be now.
>
>  The other connected issue that keeps popping up is use of controlled
> vocabularies, where you can either specify *one* vocabulary a priori for
> each field, or include a vocabulary field for every attribute that calls
> for CV terms, or allow the use of fully unique CV terms within any of these
> attributes. This is somewhat affected by whether your attribute list is
> flat or rich.
>
>  I will add my comments on these two topics to the discussion page, but
> they have a strong bearing on the best integration approach.
>
>  John
>
>
>
>   On May 9, 2013, at 09:07, David Neufeld - NOAA Affiliate <
> david.neufeld at noaa.gov> wrote:
>
>   John,
>
>  Thanks for getting this started, I've added some information on
> governance.
>
>  Seems like a next step would be for Rich, Aleksandar, Ted and I to review
> the working draft and document some of the tweaks that crept into ncISO
> over the past year outside of ACDD.  Then we can discuss whether some (or
> all?) of those changes could be incorporated into the standard.
>
>
> http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery
>
> Dave
>
>
>
> On Fri, Apr 26, 2013 at 3:20 PM, John Graybeal <
> graybeal at marinemetadata.org> wrote:
>
>> Thanks Derrick. I'll try to get to this sometime this weekend -- with the
>> login snafus (I think all better now) I got delayed.
>>
>>  I like the Category page strategy. I think you're creating a convention
>> or profile or specification; for it to be a standard I arbitrarily would
>> say it has to go through a standards body.
>>
>>  Re versions: First, since the wiki versions pages, what we _don't_ want
>> to do is create a page called 1_1, and then 1_2, and so on…  I think we
>> want two pages though:
>>   Attribute_Conventions_Dataset_Discovery_Final (or Current) -- this is
>> the most recent agreed version; the version number is visible internally
>>   ACDD_Working -- this is where we have the working version (keeping in
>> mind there is also a Discussion page)
>>
>>  If we're debating some points that can go on the discussion page, and
>> so we can keep the main ACDD_Working page relatively clean, just minor
>> suggestions or questions there.
>>
>>  How does that sound?
>>
>>  John
>>
>>
>>
>>   On Apr 26, 2013, at 11:31, Derrick Snowden - NOAA Federal <
>> derrick.snowden at noaa.gov> wrote:
>>
>>   All,
>>
>>  Just to get the ball rolling I created two new pages on the ESIP Wiki
>> to host the output of this group.  The first page is a category page.
>> http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery I'm suggesting this as the home page and the page to use to reference the
>> activities of the group, the approved standard (dare I call it a standard?
>> convention?)  and things we are working on.  The benefit of using a
>> category page as the home page is that any other wiki page you create will
>> be listed on the main page if the new page includes
>>
>>  [[Category: Attribute Conventions Dataset Discovery]]
>>
>>  somewhere in the text of the page.  It is a convenience feature that I
>> think will be useful.  I created the ACDD page as a subcategory of the
>> "Documentation Cluster" so our work will show up on that page as well.  If
>> you don't understand how MediaWiki handles categories now, I hope it'll
>> make sense after you click around for awhile and experiment.  The key is
>> including the category label somewhere in the text.
>>
>>  I created a second page (http://wiki.esipfed.org/index.php/ACDD) that I
>> think should hold the current version of what is essentially a controlled
>> vocabularies.  John Graybeal volunteered to take a first stab at migrating
>> the list from the current home on the NOAA EDM wiki <https://geo-ide.noaa.gov/wiki/index.php?title=NetCDF_Attribute_Convention_for_Dataset_Discovery> to
>> this new page.  In the process he was going to add some of his
>> interpretations of new definitions and possibly new terms.  I think this
>> new page will represent a new version of the convention.
>>
>>  You can see that I didn't really come up with a scheme for versioning
>> the pages.  If someone has some ideas I'd love to hear them because it's
>> something we should probably commit to sooner rather than later.
>>
>>  Have a good weekend.
>>
>>  Derrick
>>
>>         _______________________________________________
> Esip-documentation mailing listEsip-documentation at lists.esipfed.orghttp://www.lists.esipfed.org/mailman/listinfo/esip-documentation
>
>
>
> --
> *******************************************************
> * 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
>
>

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20130614/e5e66617/attachment-0001.html>