October 2014 Documentation Telecom

ACDD 1.3 – John Graybeal

·         Bob finding issues during final read – therefore no final vote today (Bob sent his issues to the list in the am)

o   Also have outstanding geospatial bounds issue, and possible cdm_data_type issue

Overview of changes

·         1) intro texts

o   Refine and enhance explanation

o   Add guidance section – iso 8601 – date/time, comma list, text formats

o   Added definitions, data, metadata

o   Added version and status text (help people know they have the correct page/convention)

·         2) attributes themselves

o   https://docs.google.com/spreadsheets/d/19fl5AgGkckG03yTchUjYUp4YnR09Fn1Nqps2KHenkC4/edit#gid=0

o   Added description is most significant change – 10-15 new, some modified…(mostly before last meeting)

o   Last month – added platform, instrument, references

o   Able to make ‘creator’ an entity other than a person - name, group, or position (by adding creator_type attribute)

o   Project was more clearly defined

o   Program added, it is a set of related or independent projects

o   Geospatial – lots of new text – definitions improved to enhance what they mean

§  The big open issue here is geospatial_bounds, still being discussed in detail

·         Includes proposal for 2 associated coordinate reference systems attributes – vertical and horizontal

o   Date/time – defined specific meanings for date_created, date_modified, and date_issued – matches many people’s understanding of what this always meant

o   Date/time—added date_metadata_modified to complement first three

o   (Anna) – We did not change existing attributes but updated definitions when possible – or added new attributes if needed, but did not change name of existing

Other concerns we need to discuss?

·         Ed – what about data provider processing info to describe a version, did you consider this?
John—no, it was discussed some in email but not considered explicitly in the adjudication meetings. So we should do so in this meeting.

o   Anna – processing_level of inputs – Version # to reflect algorithm

o   Added version_provider… but need to think about definition… “by data provider”

o   Proposed text is provided in the Datestamps page

§  https://docs.google.com/spreadsheets/d/19fl5AgGkckG03yTchUjYUp4YnR09Fn1Nqps2KHenkC4/edit?pli=1#gid=1933494942

§  copy of text for version or processing_version

·         Indicates the version number assigned to the dataset by the data producer. For example, refers to a unique data processing algorithm or methodology

·         There can be versions of multiple things including the product, system or software, file revisions, etc. 
A similar attribute from the GHRSST Data Specification is strictly for the product is named "product_version".
GHRSST definition:
"The product version of this data file, which may be different than the file version used in the file naming convention (Section 7)."

o   Multiple version # (from different sources) problem – need naming authority? What about using existing naming_authority attribute?

o   Is the version only for use to define processing changes? Or can it be used to indicate other changes in the data set, like running the same process on a new set of inputs?

§  Perhaps the processing changes can be expressed as an example?

§  And this would mean the name is just version, not processing_version

o   If this expresses processing level or input sources, how are the history and source attributes affected? Is there duplication there?

o   Suggest the more detailed purpose and definition be worked out offline, brought forward after this . (General agreement.)

Bob’s Issues

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

o   Yes, already changed in draft specification

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

o   Yes more general wording is more appropriate. John will change.

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

o   No – addressed @ end of document – not updating because it is not normative (and hard)

·         Suggestion:
In Overview, could you change "and use data efficiently" to "and use data correctly and efficiently"?

o   Yes. John will change if no objections received.

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

o   Yes. John will change if no objections received.

·         Suggestion:
For id, shouldn't "The id should not include blanks." be" The id should not include any whitespace characters."

o   Yes. John will change if no objections received.

o   ‘non-printing characters’ considered as an alternative, but not adopted on account of obviousness.

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

o   Linked to data list on web – there are multiple data type list

o   Is there a list that is static and will not break current/existing users

o   http://www.unidata.ucar.edu/staff/edavis/CDM/ScientificDatatypes.html

§  Anna – list hosted at unidata

§  Can we get someone to maintain this list into the future, to future-proof our intent? —Can ask John Caron about this.

o   Seems to be general consensus that updating this to the current reality is a good thing, and dropping the NODC guidance reference is also a good thing.

o   (John apologizes for previous denseness on this topic, having introduced some of these confusions in the long ago.)

Geospatial Bounds attributes (geospatial_bounds and *_crs)

·         Geospatial bounds (see email subject: proposed new wording for geospatial bounds attributes – updated)

o   There is a long email chain – latest Oct 16 by John

o   Aleksander presented the motivation for/history of the discussion.

o   Suggest meeting in a smaller group to sort out this definitions – then bring back to the larger group.

No objection to bringing back any agreement to the email list, and to then having that result (after opportunity for list review) presented as part of the final package.

In Conclusion/Wrap-up

·         Have completed  the pending work for this call– a few minor changes to text to be made, and we  will have a document proposed for adoption; only 2 attributes left to sort out

o   (Editor’s note: There are actually 3: geospatial_bounds and related; cdm_data_type; and version plus any related)

·         Want to wrap up discussion and have a final proposed document 2 weeks before Nov 20th meeting (by Nov 6), which is 3 weeks from now. So let’s get on those topics.

·         Contact Alek or John if you want to be part of the geospatial definition discussion