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

[Nan Galbraith via Esip-documentation]

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/6a7c5bf8/attachment.html>