[Esip-documentation] New ACDD home page
Nan Galbraith
ngalbraith at whoi.edu
Fri Jun 14 10:45:37 EDT 2013
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
> <http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_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
> <http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_%28ACDD%29_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 <mailto: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 <mailto: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 <mailto: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 list
> Esip-documentation at lists.esipfed.org
> http://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 *
*******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20130614/16be0105/attachment-0001.html>
More information about the Esip-documentation
mailing list