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

Fri Sep 26 15:14:16 EDT 2014

On 2014-09-26 11:47 AM, Nan Galbraith wrote:
> 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.
What about those other standards (e.g., IOOS Gliders) that have adopted 
ACDD 1.0 attribute names but in the future would like to add some of the 
new ACDD 1.3 attribute names)?

>
> 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.
Only if someone really misread the 1.0 definitions.

1.0 says "data creator's name" not "data file creator's name". It is the 
person/group that created the data.
You're taking an odd reading of the definition or some groups misuse of 
the existing name and definition and saying that that justifies 
deprecating the attribute.

And the "institution" definition is grouped with creator, so it is 
clearly the data creator's institution.

And "project" is defined in ACDD 1.0 as "The scientific project that 
produced the data."   (Not, e.g., the group that published the data.) It 
is clearly not the publisher's project.

So there is no need to change the existing attribute names.

>
> 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,
Exactly.
> 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.
Fine. Then leave project and institution as is for the creator, but add 
publisher_project and publisher_institution.

>
> 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.
I understand. Leaving project and institution as is for the creator, and 
adding publisher_project and publisher_institution offers a viable solution.

>
> 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
>>
>
>

-- 
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/0d1ee3a6/attachment.html>