[Esip-documentation] ACDD convention (2 things)

[Nan Galbraith]

Hi all -

I also agree, although I don't recall why we didn't set a minimum
standard for compliance.

On another detail about ACDD, the OceanSITES NetCDF spec follows
ACDD, and lists ACDD in our 'Conventions' attribute (along with CF and
OceanSITES). We're currently trying to translate our metadata into a
standard created by the OceanOPS group for GOOS (Global Ocean Observing
System), and I ran into a detail that really boggles my mind.

The recommended ACDD attribute 'id' - presumably the 5th most important of
our attributes, based on its location in the table, is defined as 'An 
identifier for
the data set...'  Why we didn't name it 'data_set_id' is beyond me. It's 
already
been misread as a platform ID by the GOOS translators, and I had to 
refer back to
our format spec, which quotes ACDD, to understand why that wasn't working
as they'd expected it to.

If this convention is ever updated, just in case I'm not involved, I hereby
recommend that this term be changed to something more meaningful; we
can't expect people outside the ESIP community to look up the definitions of
our terms, so they should be explicit.

Cheers - Nan


On 5/12/21 11:24 AM, John Graybeal via Esip-documentation wrote:
> And I fully agree with this perspective also, thanks Bob! (And hi!)
>
> john
>
>> On May 12, 2021, at 8:20 AM, Bob Simons - NOAA Federal via 
>> Esip-documentation <esip-documentation at lists.esipfed.org 
>> <mailto:esip-documentation at lists.esipfed.org>> wrote:
>>
>> My personal answer to your questions is:
>>
>> I think you may have a misunderstanding of the ACDD attributes with 
>> regard to compliance. ACDD (like CF) defines a set of attributes. 
>> Yes, they are categorized as "highly recommended", "recommended" or 
>> "suggested", but note that none are "required". So one might say 
>> that, technically, a dataset with none of the ACDD attributes is 
>> compliant with ACDD. But it's better to say that a file or dataset is 
>> compliant if it uses the ACDD attributes (hopefully all of the 
>> "highly recommended"  and "recommended" and many of the others) in a 
>> way that is consistent with the attribute definitions. It is not an 
>> error or a sign of non-compliance if a dataset doesn't have one or 
>> more of the ACDD attributes. Note that some of the attributes simply 
>> are not relevant to some files, so those attributes simply shouldn't 
>> be used for that file. In that case, their absence is not an error. 
>> Also, ACDD (like CF) allows the file to have other attributes, 
>> perhaps from other conventions, so the presence of non-ACDD 
>> attributes is not an error or sign of non-compliance..
>>
>> Regarding "the convention does not specify whether data is compliant 
>> with ACDD,"
>> Basically correct. And there is no official ESIP ACDD compliance 
>> checker which looks at a file or dataset's metadata to determine its 
>> compliance. However, other groups have made compliance checkers 
>> (i.e., software): search the web for these. I think NOAA's IOOS has a 
>> compliance checker which includes ACDD. NOAA's NCEI's checker may 
>> also include ACDD checking. Note that compliance checkers mostly just 
>> say "better" for files that have more of the ACDD attributes 
>> (especially the "highly recommended" ones), and "worse" for files 
>> that have fewer ACDD attributes, which is what the checker's authors 
>> are seeking, but not strictly what the ACDD convention says. And note 
>> that compliance checkers currently aren't actually smart enough to 
>> evaluate if an attribute value is in compliance with the attribute's 
>> specification or to evaluate the quality of the metadata (e.g., does 
>> the "title" do a good job of describing the dataset or is it a 
>> cryptic code that only the creator understands?). In that sense, it 
>> will take AI to make a checker that tests true compliance. I think 
>> the only true non-compliance that one of the current checkers might 
>> catch is if an ACDD attribute is misspelled or has the wrong data 
>> type (e.g., text when a number is expected).
>>
>> I hope that helps.
>>
>> Best wishes.
>>
>>
>
> ----------------------
> John Graybeal
> Administrator—ESIP Community Ontology Repository
> jbgraybeal at sonic.net <mailto:jbgraybeal at sonic.net>
>
>
>
>
> _______________________________________________
> Esip-documentation mailing list
> To start a new topic: Esip-documentation at lists.esipfed.org
> To unsubscribe and manage prefs: https://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://lists.esipfed.org/pipermail/esip-documentation/attachments/20210527/12e988e7/attachment.htm>