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

Wed Nov 12 14:18:17 EST 2014

Hi all -

Thanks, Ken, I admit that that makes sense, in many cases. My problems
with it are:

a)  the identity of the person who runs the archive or portal may not be
known when the file is written and

b)  the archivist/ TDS manager (etc) seems unlikely to be the one person
who the user needs to locate.  I'd like to provide a name that gets the 
user
back to where the data was written - isn't that fairly important?

To my mind, the rest of the contacts can be in the contributor list, and the
person who's serving the data should be identified on the server itself, but
the PI and 'data author' should be identified clearly, in the metadata.

 From an old esip-doc thread (04/2013):

> There are a few categories of terms that need better definitions, IMHO.
>
> 1. people:
> creator_name (recommended)
> publisher_name (suggested)
>
> In a 'normal' research/observing/modeling situation, who are these 
> people?
>
> I think there are 2 necessary points of contact, the person who 'owns'
> the research and gives you the go-ahead to use/publish the data, and
> the person who put the data into the file and/or on line. You don't really
> need to know how to contact the other contributors, even if they had 
> equally
> or more important roles.
>
> I believe that NODC recommends naming the principal investigator as 
> the 'creator' -
> although in some circumstances there is no single PI, so maybe we 
> should say this
> is the person who grants the use of the data.
>
> I'm using the publisher as the person who wrote the actual file that 
> contains
> the terms, and I'm listing co-PIs and data processors as contributors.
I didn't get any replies, back then, on this particular subject, it just led
to a discussion of code lists and the role of the acdd team.

Thanks - Nan

On 11/12/14 10:48 AM, Kenneth S. Casey - NOAA Federal wrote:
> 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 
> <mailto: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 *
*******************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-documentation/attachments/20141112/da4d10b1/attachment.html>