[Esip-documentation] ACDD meeting #3 results, topics for tomorrow

Wed Nov 12 10:48:35 EST 2014

Hi Nan,

I prefer the former, as it is more inline with the use of the term publisher in the data citation/DOI context.  It isn’t perfect, but “assembling” doesn’t seem to be quite the right sort of revision.  A “publisher” of a journal article or a book, for example, does not need to be able to answer questions (at least not all of them) about the contents of that article or book.. that is up to the author.  The publisher maintains persistent access, an authoritative copy, some metadata, and an identifier...

-Ken

On Nov 12, 2014, at 10:34 AM, Nan Galbraith via Esip-documentation <esip-documentation at lists.esipfed.org> wrote:

> Hi all - 
> 
> I would like to change the definition:
> 
> publisher_name: The name of the person (or other entity specified by the 
> publisher_type attribute) responsible for publishing the data file or product 
> to users, with its current metadata and format.
> 
> to something like:
> 
> publisher_name: The name of the person (or other entity specified by the 
> publisher_type attribute) responsible for assembling and providing the data 
> and metadata in the file or product, in its current form.
> 
> Any thoughts on this?  If one person is running a thredds server, should they
> be the publisher of all the data on it? Can they answer any questions about the
> contents of the files?
> 
> Thanks - Nan
> 
> 
> On 11/2/14 3:02 PM, Nan Galbraith via Esip-documentation wrote:
>> I have a use case for changing the definition of publisher*.  I'm in the 
>> process of delivering data to an archive, and the person collecting all the 
>> data asked to be identified as the publisher, which didn't seem useful to 
>> me; a quick check of the current definition showed that we're back to a 
>> non-definitions (self-reference) for this term: 
>> 
>> 'The name of the person (or... ) responsible for publishing the data file or 
>> product to users, with its current metadata and format.' 
>> 
>> I think this should be the person who assembled the data and takes responsibility 
>> for the current metadata and format. Unfortunately, all the discussions on 
>> the talk page seem to have been wiped out - I can't believe we haven't gone 
>> over this more than once. 
>> 
>> I differ from Bob on how we should handle the DSG cdm_data_types. Since 
>> these terms are NOT part of ACDD, but part of CF, it seems to me that it's more 
>> appropriate to defer to the CF documentation.  How we do that doesn't matter 
>> to me, but I don't think a list of the currently-defined terms is a good idea. 
>> 
>> Other than that, I like all the points Bob raised in his email. 
>> 
>> Cheers - 
>> Nan 
>> 
>> 
>> On 10/16/14 1:47 PM, Bob Simons - NOAA Federal via Esip-documentation wrote: 
>>> Well. Time is up.  I only had time to do a partial read of the currently proposed ACDD 1.3.2 at 
>>> http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-3 
>>> I hope we delay voting to ratify ACDD 1.3 so that we can make small changes/improvements/fixes. 
>>> 
>>> Here are some questions, comments and corrections: 
>>> 
>>> 
>>> Correction: 
>>> In Alignment with NetCDF and CF Conventions, please remove 
>>> "with the exception of 'institution'; we specify 'creator_institution' and 'publisher_institution', to provide more provenance information" 
>>> 
>>> Correction: 
>>> In Maintenance of Metadata, shouldn't "characterize their containing (parent) granules."  be something like 
>>> "characterize the data to which they are attached."?  "granules" is too limiting. 
>>> 
>>> Suggestion: 
>>> For cdm_data_type, it is unfortunate that previous versions of ACDD included a link to a specific list. 
>>> Surely the intention is to evolve as Unidata/THREDDS/the common data model evolves, even if that particular list doesn't evolve. 
>>> Can we please remove that link and add the values from the CF DSG chapter that aren't in the current list here: timeSeries, timeSeriesProfile, trajectoryProfile? 
>>> And please remove the NODC guidance link. That is NODC guidance about the DSG variants that NODC prefers and is not strictly relevant to a list of cdm data types. 
>>> 
>>> Question: 
>>> In Attribute Crosswalks, has the data in the Mappings page been updated to include attributes that have recently been added or modified? I don't think so. 
>>> 
>>> Suggestion: 
>>> In Overview, could you change "and use data efficiently" to "and use data correctly and efficiently"? 
>>> 
>>> Suggestion: 
>>> In Definitions: Data and Metadata, could you change 
>>> "specifically to the values within the file, and the attributes of the file, respectively." 
>>> to 
>>> "specifically to the data values associated with the data variables, and the global and variable attributes in the file,         respectively." 
>>> or something like that? 
>>> 
>>> Suggestion: 
>>> For id, shouldn't "The id should not include blanks." be 
>>> "The id should not include any whitespace characters." 
>>> 
> 
> 
> -- 
> *******************************************************
> * Nan Galbraith        Information Systems Specialist *
> * Upper Ocean Processes Group            Mail Stop 29 *
> * Woods Hole Oceanographic Institution                *
> * Woods Hole, MA 02543                 (508) 289-2444 *
> *******************************************************
> 
> 
> _______________________________________________
> Esip-documentation mailing list
> Esip-documentation at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-documentation

[NOTE: The opinions expressed in this email are those of the author alone and do not necessarily reflect official NOAA, Department of Commerce, or US government policy.]

Kenneth S. Casey, Ph.D.
Technical Director
NOAA National Oceanographic Data Center
1315 East-West Highway
Silver Spring MD 20910
301-713-4849
http://www.nodc.noaa.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141112/3c6d59bc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook.png
Type: image/png
Size: 533 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141112/3c6d59bc/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RSS.png
Type: image/png
Size: 1654 bytes
Desc: not available
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141112/3c6d59bc/attachment-0003.png>