[Esip-documentation] ACDD: creator, project, institution

[John Graybeal via Esip-documentation]

The short technical answer is: Because (a) not everyone used these terms the same way you did, and (b) there was a need to distinguish the uses unambiguously, both for human users and for interoperability with other standards like ISO.

I know it feels to you like redefining these terms is the obvious answer, but existing practices varied, so there was no one right definition. You liked your original definition of what those terms meant; other people liked their definition. So we thought the new terms had satisfied most; maybe the email list and adjudication meeting will (continue to) provide further insight on that score. Everyone who has an opinion on this topic may want to sit in next Thursday at the adjudication meeting, and help it decide how to proceed with these changes.

Speaking of definitions, I prefer to say that breaking a standard happens when the meaning of an existing version (e.g., 1.1 being the latest version, but 1.0 is also an existing version) is modified, and the version is not changed. In this case we are clearly moving to a new version, which no one is obligated to use (and you certainly don't have to rewrite existing files).  It's my experience from working with many standards that changing or deprecating names is common, when it is necessary to address issues that the original names created, and it usually is not considered breaking a standard. 

That said, obviously we want to make this transition as seamless as possible, with ERDDAP on board with the latest ACDD once all is settled. So it looks like there is still work to do.

John


On Sep 25, 2014, at 16:03, Bob Simons - NOAA Federal <bob.simons at noaa.gov> wrote:

> I'm sure I'm coming late to this discussion:
> 
> Why does ACDD 1.3 have creator, not creator_name, like 1.0?
> Why does ACDD 1.3 have creator_project, not project, like 1.0?
> Why does ACDD 1.3 have creator_institution, not institution (which is in CF!), like 1.0?
> If you want to add creator_institution_info, why not just add institution_info?
> 
> It seems like these changes are just to change to names that the new ACDD group prefers, but at a HUGE cost.
> I have 1000's of datasets that have creator_name, project, and institution attributes.
> I have written software, ERDDAP, that strongly recommends creator_name and requires institution.
> I have told numerous people and groups to follow the ACDD standard. 
> Now you are breaking your own standard.
> The new ACDD group seems to think there are no consequences to changing attribute names and that it can be done just to suit the group's fancy.  
> It doesn't matter if you or I think the new names are better. That is not the issue.  If you are unhappy with the old system, change the definitions to clarify the attribute's usage, don't change the attribute names. Changes that break the old standard are wrong, wrong, wrong. 
> And no, saying that all attributes are optional doesn't make it okay to change the attribute's names. If ACDD says that the data creator's name is in an attribute called creator_name, then that is where it should be (last year, this year, next year, and in 50 years).
> 
> ---
> Standards should be backwards compatible.  
> Standards should be as stable as possible. 
> ACDD should be cleaning up the definitions of existing attributes and sparingly adding new attributes that provide a place for new pieces of information, NOT changing existing attribute names.
> 
> 
> -- 
> 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/74ca08f8/attachment.html>