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

Nan Galbraith via Esip-documentation esip-documentation at lists.esipfed.org
Fri Sep 26 14:47:02 EDT 2014


Hi all -

If you're using an ACDD version number in your metadata, these
updates shouldn't cause any problems for you. If you eventually
decide that there's some value in the revised spec, you can adopt
the changes, otherwise your data & code should be just fine.

IMHO, changing the definitions of the terms in a standard is far
worse than changing the terms themselves. Creator_name was
originally defined as "data creator's name" - really no definition
at all. If we change that to add any meaning (one who originally
collected the data, or who created the data file?) we could make
metadata in existing data sets incorrect.

Other than that, though, I see your point, and sympathize with
your reluctance to change these terms.  I also agree that we may have
changed some terms without strictly needing to, but in the case of
creator_project and creator_institution (vs project and institution) I
think that allows for documenting other projects and institutions -
e.g. the project/institution that processes, aggregates, and/or
distributes a dataset might want some visibility for their efforts. In
the original version, they got that only at the expense of the originator's
information.

I've seen the effect of this many times, where data collected by a PI in
my group appears on a portal with only the name and institution of
the last person to handle it. Or, when I send my data to OceanSITES for
distribution,  I'd like the OceanSITES project to be part of the metadata,
but not to remove the original information about the person and project
that collected and originally provided the data. Having creator_project
and _institution as named fields makes this information more likely to
be preserved as it should be.

Regards -
Nan


On 9/26/14 9:46 AM, Nancy Ritchey - NOAA Federal via Esip-documentation 
wrote:
> Bob,
> Well said!  I agree with your assessment.  We've spent many years 
> working with our providers to use these standards appropriately 
> allowing the use of common tools across multiple platforms and 
> communities.  Changing the standard as proposed will have many 
> unintentional consequences that may negate its future use.  A 
> thoughtful, practical solution is needed.
> Nancy Ritchey
>
> ---------- Forwarded message ----------
> From: *Bob Simons - NOAA Federal via 
> Esip-documentation*<esip-documentation at lists.esipfed.org 
> <mailto:esip-documentation at lists.esipfed.org>>
> Date: Thu, Sep 25, 2014 at 7:03 PM
> Subject: [Esip-documentation] ACDD: creator, project, institution
> To: John Graybeal <john.graybeal at marinexplore.com 
> <mailto:john.graybeal at marinexplore.com>>, ESIP Documentation 
> <esip-documentation at lists.esipfed.org 
> <mailto:esip-documentation at lists.esipfed.org>>
>
>
> 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
>


-- 
*******************************************************
* Nan Galbraith                        (508) 289-2444 *
* Upper Ocean Processes Group            Mail Stop 29 *
* Woods Hole Oceanographic Institution                *
* Woods Hole, MA 02543                                *
*******************************************************





More information about the Esip-documentation mailing list