[Esip-documentation] More reasons not to change attribute names

Fri Sep 26 13:47:08 EDT 2014

ACDD 1.0 is a great standard that has been available for a long time 
with no changes. (Thank you Ethan!)
In that time, a lot of groups committed to ACDD 1.0 and its attribute 
names.
If the proposed 1.3 changes are made, they will *punish* all the groups 
that decided to use ACDD 1.0.  The more the group committed to ACDD 1.0, 
the more they will be *punished* by these changes. Is that any way to 
treat your supporters?

I know for me, the passage of these changes will mean I will *never* 
trust ACDD to be a stable standard. In the future, I will use it as 
little as possible and make as little commitment to it as possible. And 
when I give talks about standards I will stop using ACDD as an example 
of a good standard to follow.

* Just as ACDD 1.0 adopted many CF terms, other standards have adopted 
ACDD 1.0 terms, e.g., the new IOOS glider file format standard
https://github.com/ioos/ioosngdac/wiki/NetCDF-File-Format-Description
These files will be archived at NODC. Is ACDD 1.3 saying there is no 
clean migration path from ACDD 1.0 to 1.3, so if the glider group wants 
to move to 1.3, either the collection will be inconsistent or they will 
have to rewrite the 1.0 files?  For any 1.0 files that get into the 
archive, that isn't going to happen.

* There is software which adopted and committed to ACDD 1.0 attribute 
names.  For ERDDAP, I wanted to insist upon good metadata and have all 
the datasets have a consistent set of core metadata. I adopted ACDD 
1.0.  (Isn't that what ACDD is promoting?) So ERDDAP requires 
"institution" and strongly recommends most of the other ACDD 1.0 
attributes which 1.3 is deprecating.  Now there are 50+ ERDDAP 
installations (and 50+ ERDDAP administrators) with 10000+ datasets all 
following the ACDD 1.0 standard.  And you want to break that just 
because you like the new names better?

* The NOAA UAF project has been working to create a consistent way to 
discover and access all of NOAA's gridded data (that's the goal, they're 
making good progress). The project is a collection of THREDDS catalogs. 
So the group has been promoting ACDD 1.0 metadata so that ncISO in 
THREDDS can generate the ISO 19115 metadata.  So ACDD 1.0 attributes 
were added to 1000's of datasets, so they could get the green light from 
the rubric that measured metadata quality. To move forward to ACDD 1.3, 
you're telling all of those data providers they need to make 12+ changes 
to each of their datasets (which are often collections of files).

Don't punish these groups that have been ACDD's biggest supporters.

---
Standards are like the foundation of a building. You can make changes 
that add to or otherwise improve them.  But you can't just knock the old 
one down and build a new one shifted east by 12 inches.

---
The attribute names in a standard should be like the API of a software 
library. It is fine to add new functions to the API, because that 
doesn't break existing software that uses the API. It is fine to change 
the description of existing functions or change how the function gets 
the job done, again, because that doesn't break existing software. But 
you can't (shouldn't) change the name of the function or remove it, 
because that does break existing software that relies on the API.

---
If you feel the ACDD 1.0 attribute names don't clearly define the 
attributes, then
*improve the definitions**, but **don't**change attribute names.*

There is no way that the benefit of changing "creator_name" to 
"creator", "project" to "project_institution", "institution" to 
"creator_institution", etc. are worth the pain caused by the change.  So
* Leave creator_name alone.
* Define "project" to be the creator's project.
* Define "institution" to be the creator's institution.
* Add "project_info"  (not creator_project_info)
* Add "publisher_info"
* Add "publisher_institution"
* Do similar things for all those date created/modified/issued attributes.
* Don't get rid of contributor_name and contributor_role (separate is good).
* Etc. Etc. Etc.

Improve the definitions, but don't change attribute names. Add new 
attributes as needed.

-- 
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/20140926/fbe4b89c/attachment.html>