[Esip-documentation] ACDD convention

[Bob Simons - NOAA Federal]

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.







On Wed, May 12, 2021 at 7:09 AM Carlo Lacagnina via Esip-documentation <
esip-documentation at lists.esipfed.org> wrote:

> Dear ESIP Documentation Cluster mailing list,
>
>
> I work in a service contract supporting the European Union Copernicus
> Climate Change Service (C3S). In this service, we are starting to check
> the ACDD convention 1.3. However, we have some questions about it, could
> you help me?
>
> In particular, it seems that the convention does not specify whether
> data is compliant with ACDD, but rather whether the metadata attributes
> are following "highly recommended", "recommended" or "suggested"
> specifications. Is the interpretation correct? In that case, does it
> make sense to map these 3 levels into "not compliant: error",
> "compliant: severe warning", "compliant: warning or ok" ?
>
> I understand that the answer might depend on the application, the aim
> for us is to identify which file is compliant with the ACDD convention.
> Would the mapping above make sense or would you suggest a different
> mapping? Thank you very much for your help.
>
>
> Kind regards,
>
> Carlo
>
>
> --
> Carlo Lacagnina
> Earth Sciences Department
> Barcelona Supercomputing Center (BSC)
> c/ Jordi Girona, 29
> 08034 Barcelona (Spain)
> Tel:+34 934134073
> http://www.bsc.es
>
>
> http://bsc.es/disclaimer
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.esipfed.org/pipermail/esip-documentation/attachments/20210512/ff2903d7/attachment.htm>