ACDD 1.3 Revisions/Adjudication - Mtg #3 10/14

contributor_role

(1) contributor_role: (row 38, column G of Version Changes): proposed consent item, updating text. -- Status: Accepted

Added the text "Multiple roles should be presented in the same order and number as the names in contributor_names." This was to address the issue raised: "Need guidance on how to format the role values so they are associated with the corresponding name values, such as use same index in each attribute array. _Philip jones"

JG - is this change controversial? Any objections? -- No comments.

program

(2) program (row 29, columns G/I of Version Changes): Newly proposed attribute and defintion(s) -- Status: Accepted as reworded

original proposal:
 "The overarching program(s) of which the dataset is a part."
proposed replacement:
 "A program consists of a set (or portfolio) of related and possibly interdependent projects that meet an overarching objective. Examples: GHRSST, NOAA CDR, NASA EOS, JPSS, GOES-R."

JG - new definition. Who wants to talk about this?
HB - this was proposed by PJ - let’s wait until he attends the mtg.
JG - Phil proposed new definition. Correct?
PJ - column I added more definition to clarify difference from project.
JG - combine the two definitions, first sentence and examples.
BS - can we clarify the difference b/t programs and projects more here?
AM - would lump them together
PJ - usual definition is that a program oversees multiple projects. The dataset may be more closely aligned with a project.
HB - can we have examples for project as well?
PJ - PATMOS-X
JG - let’s combine program definitions and add a couple more project examples. Any objections?
PJ - can we work on these examples before Thurs?
JG - would like to have everything stable before Thurs, say by end of Wednesday or ideally end of today. Any objections to what we have so far, subject to additional examples? (silence)

(3) Geospatial Bounds attributes

3A) geospatial_bounds (row 38, column G of Version Changes): Newly proposed definition -- -- Status: Referred to subcommittee for final agreement.

JG - Aleksandar, can you describe your proposal?
AJ - the prevailing opinion of this group, the essential question is related to the ordering: lat lon or lon lat. Maybe geospatial_bounds is too technically heavy. Thought the consensus that lon always comes first and don’t assign any CRS. this is an approximate bounding area. Thinks Bob should talk about his pov. we should add a new attribute to describe CRS.
BS - my overall view is: proposing what Aleksandar described. Another approach is that WKT is specified by OGC therefore we should follow the OGC specification which says that there should always be a CRS described within the WKT format and the order of items should follow the CRS. We could back off this and just stick to OGCs specification. I can write up the alternative text
AJ - I think Bob should write up the alt text and then we look at it again.
BS - can we table this until next teleconference and talk about it in emails before then?
JG - what we have by default is not inconsistent. is OGC the only place where WKT is defined?
BS - Yes, OGC owns the WKT specification.
AM - CRS must be defined “within” WKT?
BS - No. We provide a new, separate attribute(s) for CRS.
JG - would like to have text in place before next telecon (this Thursday). Bob, please work on the new text as soon as you can, let's see if we can get an agreement on this.

3B) geospatial_vertical_units (row 45, column G of Version Changes): Proposed for consent (complex definition) -- Status: Accepted.

3C) geospatial_vertical_positive (row 45, column G of Version Changes): Proposed for consent (minor addition) -- Status: Accepted

JG - 3C clarifying sentence.

3D) geospatial_*_units (rows 47 & 49, column G of Version Changes): Proposed for consent (minor change) -- Status: Accepted

JG - 3D minor change to remove ‘geospatial bounds’ from definiton.

Any concerns/objections? None.

(4) Datestamp and Timestamp attributes

We will work with the Datestamps spreadsheet in discussing this item. We will follow this sequence:
(a) Determine if we can agree on any improvements to date_created, date_modified, and date_issued definitions.
(b) Determine if we can agree on any additional attributes.
(c) Determine if we can agree on any other changes, e.g., to the Attribute Content Guidance.
For 4c, we will use the text in the 1.3 document for the discussion.

JG - our primary option on the table: 3 definitions that Bob wrote, possibly with additional attributes thereafter.

Nan’s email response:

“I don't think I can make the meeting, but I need to urge you to remove the word 'original' from Bob S's proposed definition of 'date_created'.
This would be a SUBSTANTIAL change from the original definition, and makes my existing metadata wrong; furthermore this definition makes the term useless for many observational data sets. The date on which a real time data set was 'originally created' is not something anyone keeps track of for real time data.
Original: The date on which the data was created.
IMHO, this is fine, because it leaves the term 'created' open to the data-writer's own common sense.
I also like the idea of adding date_metadata_modified, which, for in situ data, completes the timeline information any user really needs.
If the other proposed terms in the time category are approved, I hope they'll be 'suggested', not 'recommended', because I think a perfectly well-documented NetCDF file can be written without any of them.”

(4)date_created, date_modified, date_issued definitions -- Status: Definitions accepted with minor modification

BS - ok with removing “originally” from definition.
JG - any discussion? (silence) any objection? (silence)

(4)date_metadata_modified addition -- Status: Addition accepted

BS - NOTE: new attribute date_metadata_modified should also be included
JG - any discussion? (silence) any objection (silence)

clarification of data and metadata meanings -- Status: Accepted plan to add clarifying section

JG - only concern is that people get confused about the diff b/t data and metadata. Would be helpful if we added specifically that data=values. metadata = attributes.
PJ - this is consistent with netCDF.
JG - any objections with adding this clarification?
AM - add Def to the overview?
JG - yea. will add a section before ‘maintenance metadata’.
PJ - are you proposing changing the name of the attribute?
JG - No. not going to change the name.

PJ - are we still adding date_product_modified and date_values_modified?
JG - No, these are not being added. Neither are any of the items in the sections below.

(5) Any remaining topics or concerns

(5a)uuid, platform & instrument items -- Status: uuid not included; platform* and instrument* attributes included, with some modifications

JG - should we discuss the deferred elements?
PJ - ok not including
AJ - would need to differentiate b/t uuid and fileID.
JG - nobody is asking to add
AJ - we should add platform, instrument, sensor to encourage consistency
JG - ‘suggested’ is the right category for these.
AM - remove platform *_vocabulary?
BS - we should keep.
PJ - are we keeping sensor? Or just using instrument?
JG - why would we remove sensor?
AJ - I’d keep sensor as a component of an instrument. Instrument is better and more generic that could also identify a sensor.
JG - leave out sensor attribute seems to be the consensus.
AM - add sensor to instrument definition.
JG - adding the sensor to the definition, like so.
PJ - should we change ‘this file’?
JG - changed definition to the usual data set or product.
JG - Any objections to these new changes? No objection.

BS - can we add “the name of the….” to the beginning of the defs?
JG - John will look to standardize the beginnings where possible.
BS - OK, not critical.

(5b) cdm_data_type question

PJ - added comment to cdm_data_type - list of values seem inconsistent.
JG - Can you propose a solution?
BS - its a mess, but don’t see a good solution
JG - there is time to discuss this at the cluster this thurs, if you can identify a proposal

(5c) review the overview text content on the wiki

AM - formatted text examples?
JG - don’t rely on line wrapping to preserve separation. producing an example could be too string a hint, it really isn't required/expected that people format text, and there are so many options...
BS - why is section about white space needed exactly?
JG - because of tendency of ncML to munge line wrapping with its own formatting
JG - will fix grammatics in sentence.
JG - any objections? (Silence)

Wrapup

JG: Well, if there are no more concerns, we have had a lot of progress and results. Thanks to everyone for all the attention and hard work.