[Esip-documentation] ACDD convention

[John Graybeal]

Carlo,

Thanks for looking into ACDD!

As I recall, when we were discussing these categories, there were some individual who felt that making any of these attributes 'required' was either not consistent with it being a guideline, or not appropriate because we can't know for sure that every situation would mandate any given attribute. In either case, it's fair to say we did not build a recommendation that itself allows for declaring compliance or non-compliance; that requires additional declarations.

I think there is not a single mapping that applies to every case. Rather, you should take every attribute and determine whether it applies for your service (or the data set descriptions being checked by your service). The rubrik for performing this check could be:

- highly recommended: Is there any reason we should not require this attribute? If we don't require it, should it generate a warning, and what kind?
- recommended: Is it possible we should require this attribute? If not, what kind of message should it generate, if any?  (In some cases a severe warning may be appropriate for your use cases; most missing attributes could only call for a warning or even a simple notification, because their absence is not necessarily a problem at all.)
- suggested:  If this attribute is not present, do we consider it an issue worth noting? If so, is it a warning or just a notation?

Reasons you might not want to require or warn on an attribute include: the providers may not have been told it was required or important; the attribute may be irrelevant for some collections; the attribute may be impossible to obtain; or the attribute isn't a big deal for your context (community, data types, etc.).

On the other hand, if for your data sets the attributes seem critically valuable—and for data sets archived for considerable re-use, societal benefit, and long periods of time, I think a large number of them are pretty important—you could declare many more of them required, or "required if meaningful". As long as the providers know in advance, I think that would not be misusing the guidance—if we included an attribute, we thought it had value.

John


> On May 12, 2021, at 7:03 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
> 

----------------------
John Graybeal
Administrator—ESIP Community Ontology Repository
jbgraybeal at sonic.net