[Esip-documentation] ACDD comments

Thu Sep 18 13:59:31 EDT 2014

As the person most involved in several of these, I guess I will respond as best I can. 

On Sep 18, 2014, at 09:26, Bob Simons - NOAA Federal <bob.simons at noaa.gov> wrote:

> I have given up trying to keep up with all of the debate regarding ACDD in the ESIP documentation cluster and trying to figure out the new system for proposing changes. But I see several big problems in the currently proposed ACDD 2.0. Can you please deal with these comments before ratification of 2.0? Thank you.
> 
> * All of the date format references just say "Use ISO 8601 date format" and point to http://en.wikipedia.org/wiki/ISO_8601,
> but the original ISO 8601 actually presents a large range of possible formats, including these date formats: YYYY-MM-DD, YYYYMMDD, YYYY-WWW,  YYYY-WWW-D, YYYYWWWD, YYYY-DDD, YYYYDDD, and even variants with YY instead of YYYY.  I think it is better to specify just the most common format: "ISO 8601:2004 'extended' format date time in the form YYYY-MM-DDThh:mm:ss<zone> (although ss, mm, and hh can be omitted, and <zone> can be Z, ±hh:mm, ±hh, or omitted for dates without times)".

On many standards this questions has been argued, my impression is that smaller activities choose the narrower approach you recommend. Larger activities choose the broader, on the principal that libraries are now widely available that address all the formats, and there are functional advantages to supporting them on some projects. I strongly prefer supporting all formats. We could check ISO compatibility, which I think would be a good test.

> * The summary is now recommended to include the geospatial coverage of the data, and the temporal coverage of the data. But "Maintenance of Metadata" acknowledges the importance of software tool revising the metadata, notably the geospatiotemporal attributes when the dataset is modified. It is reasonable/possible for software tools to maintain e.g., geospatial_lon_min and max, but it is not reasonable to expect software tools to maintain the same values that occur within plaintext in the summary. Please remove the green sentence above.

This was extensively discussed on multiple threads, and Maintenance of Metadata was the result. The plurality seem to favor leaving the green in, and I don't know of anyone other than yourself still requesting it be removed.

> 
> * cdm_data_type should not be tied to 
> http://www.unidata.ucar.edu/software/thredds/current/tds/catalog/InvCatalogSpec.html#dataType
> which is out-of-date and obsolete .

Are you sure? I thought several on this list were still using it.

> * Personally, I would change all instances of "bounding box or cube" to "bounding box". A cube is just a much more restricted bounding box (with equal length edges). So it is redundant and confusing.

I support this change, and propose to make it if no one disagrees.

> * The current statement that geospatial_lon_max may be less than lon_min invites misuse. Please add an example, e.g., "For example, a dataset which contains data in the longitude range 160 to 180 and -180 to -160 would have geospatial_lon_min=160 and geospatial_lon_max=-160." (Or perhaps I have misunderstood the use of this.)

An example is an excellent idea, will do this as well if no objections.

> * For geospatial_bounds, WKT doesn't specify units. So it is unclear if the WKT values represent latitude and longitude, or x and y from some projection (which opens up a huge can of worms). Please either require the use of latitude and longitude (please) or make some provision for specifying units (good luck with that).

OK, I'm guessing we'll have to look into this. Thanks for pointing it out. WKT is not specified well in Z either, if I recall correctly.

> * long_name has been widely used to provide a longer, human readable, restatement of the variable's name (often with spaces, e.g., variable=par, long_name="Photosynthetically Active Radiation"). If I understand "the "long_name" attribute value will be used by THREDDS as the variable's name in the variable mapping." correctly, it means the correct name will be something like groupName1.subgroupName2.par. Is that correct? If so, then the please make a new attribute name (variable_mapping?) for this new usage.

Not sure I understand this.

> *** Deprecation is always a bad idea. It is far better to improve the definitions of existing attributes. CF understands this and has an excellent history of not deprecating terms. ACDD should follow CF's example.  Those of use who deal with the metadata for 1000's of datasets and for software really don't want changes that break the existing metadata in those dataset and in that software.

I think ACDD is an entirely different kind of standard than CF, in that attributes in ACDD are all recommended, whereas you can not use a CF name that is not in the vocabulary and still be compliant. So I don't think the analogy applies -- if someone still wants to use the old attributes, which people strongly felt had particular (conflicting) meanings, then they can still do so.

Just defining it better was not going to happen, for the reasons above.

> * Don't deprecate date_created. Just use the definition from date_product_available and remove date_product_available.
> * Don't deprecate date_issued. Just define it better.
> * Don't deprecate date_modified. Just use the definition from date_product_modified or date_values_modified and remove one of those newer terms.
> * How can you deprecate institution, which is in CF?! Just use the definition from creator_institution and remove creator_institution.

And people can still use it for whatever CF needs it to be. Creator_institution has a specific meaning which is not necessarily consistent with the one in CF (I need to double-check that claim.)
> 
> Thank you for considering these comments. I hope you will pursue these changes.

We will certainly discuss them today!

john

> 
> -- 
> Sincerely,
> Bob Simons 
> IT Specialist 
> Environmental Research Division 
> NOAA Southwest Fisheries Science Center 
> 1352 Lighthouse Ave 
> Pacific Grove, CA 93950-2079 
> Phone: (831)333-9878 (Changed 2014-08-20) 
> Fax: (831)648-8440 
> Email: bob.simons at noaa.gov 
> 
> The contents of this message are mine personally and 
> do not necessarily reflect any position of the 
> Government or the National Oceanic and Atmospheric 
> Administration. 
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20140918/52799748/attachment.html>