ACDD 1.3 Revisions/Adjudication - Mtg #2 10/9

Plan

We'll go through the consensus issues as "Any objections to these changes?" - no issues raised, it is approved.

Review by Attribute Name

Row 10: naming_authority - Summary: Approved

row 11: cdm_datatype:  Summary: Approved

row 13: source -  Summary: Approved (with possibility of suggestions later...)

PJ has question on source: is it appropriate to list as source the titles of the source data sets. Phil JG: Seems to be; but history seems more like the place for that?

PJ: history is modifications, can we use source to identifiy the inputs used in history: JG - not wrong; TH - source is more like instrument or platform than input data to produce something like a model. History is a set of changes to things; PJ - CF definition is different than ISO source; TH - lineage discription is beyond the scope of the discovery.

JG - Can we leave this issue to later, and you can make a specific request for a change at the end if you think it's important? PJ- Last note -- GRIB definition lists all source data to a GRIB data set reference.

It is accepted (at least for now).

Row 16: standard_name_vocabulary: Summary: Approved once slightly modified

Any issues? Suggestion to include date with identifier string.  BS - should have a consistent way to identify the CF Standard Name Table; JG - is the example OK? ; TH - should have date in ISO 8601 format; JG - date for this vocabulary has not always been stable within a version, so don't put the date in use the version number instead. PJ - what about Bob's example; JG copied new text into definition. "Example: 'CF Standard Name Table v27'"

Now there are no issues.

Row 19: metadata_link - Summary: Approved as modified

JG: ok with definition?; BS- URI only an identifier? ; TH - can you give an example of a URI?; JG - Aside from DOI (not enough?), there are handle based systems that may all be URLs, but sometimes not.; TH - with Bob on using URL so a tool can get more complete metadata. How would a doi be represented? JG - changed it back to just URL - removed URI language.; AJ - should this be location, or 'resource'? but also ok as is. ; JB - whole point of a doi is that code does not become invalidated if you rearrange your website. The point is to not have dead links. so this is valuable.; TH - number of orgs using persistent HTTP URIs, good point, but should still use links.; JB - ? ; TH - change to metadata_identifier; ? - add an attribute 'metadata_identifier'? ; TH - can't add a semantic attributes that are dependant on other attributes (?). TH - we added this attribute because we wanted to provide links to more complete metadata. ; AM - all dois can be represented with URLs. ; JG - does there remain an issue with using URL? ; PJ - can we add the characteristic of a "persistent URL"? ; JB - likes the ideas of encouraging persistent URL. ; JG - even though persistent the URL behind still needs maintenance.; JB; strongly disagree. much easier to change the URL behind a DOI than to create persistent URLs at NCDC; PJ - also difficult to update all instances of the URLs. ; TH - the idea that a link which is persistent is a good idea. probably does not need to go into this definition. Let's move on! ; JG - let's vote. current definition vs more changes.; EA - likes the addition of peristent URL, Preference was for persistence; final wording carefully avoided defining that term, accepted by all. "A URL that gives the location of more complete metadata. A persistent URL is recommended for this attribute."

Row 20-uuid - Summary: Deferred, may be considered later.

PJ - new attribute; JG - ; EA - uuid was put into GHRSST, because computer generated way to id something; TH - can you clarify "original", will the uuid change when the history changes?; AJ - always thought that it was digital fingerprint of a file, don't carry over the uuid to a new file. it's confusing; TH - original implies that uuid will never change.; JB - is it even meaningful? how do you identify where? ; EA - uuid would live in db in principle; TH - does this thing ever change?; EA - get's generated once per granule and does not change.; TH - does not change if something gets modified in the file; TH - definition could be uuid for THIS file. ; JG - let's move forward. Any objections? TBD - a related question - doesn't stop projects from including uuid, if it is not in the convention. ; JG - supports interest in using something common.; TBD - is it too generic?; AJ - add that 'changing the file or metadata in the file does not change the uuid'; JG - differs. if anything changes and it beccomes a new file and hence new uuid. ; AJ - can we specifiy this isn the defintion? ; EA - implicit; JG - can take the rest of the meeting talking about this. Good idea, but are not settling on an agreed definition. ; TH - 'THIS file' is cleaner; PJ - similar to id; JG - let's move detailed discussion of this item to later. (See table at end of notes.) It can be brought up after we have gone through the others, if someone thinks it is worth pursuing.

row 21/22 Platform, platform vocabulary - Summary: Deferred, may be considered later.

PJ - ok with not addressing this today. given time; TH - has issues with terminology. ISO; platform, instrument. NASA adding sensors and might want to think about here. recommends changing to instrument and adding sensor. TBD - should we wait until ISO settles? ; TH - won't be settled for at least 3 years. don't wait for ISO.; GP - how to define platform and instrument for model data? ; TH - model results don't need to platform attributes. AJ - let's change field name to instrument. sensor has particular definition.; JB? - should add in all 3. ; JG - for this moment - move to end?

references - Summary: Accepted (pending CF citation)

PJ - already in CF, don't need to add in ACDD; JG - will add text saying it is from CF; First definition comes directly from CF.

EA -  With CF and ACDD having attributes with the same name, how do users know which model (CF/ACDD) to use when they have the same name. JG - Should be no difference in the models for those names. ACDD provides further detailed guidance in its definition. it does not contradict anything in CF; if it does, we need to fix that.

creator_type: Summary: Accepted (later accepted a modification to change 'role' to 'position')

creator_institution: Summary: accepted with wording changes

The term user is awkward. This definition should line up with the terms used earlier. "The institution of the creator; should uniquely identify the creator's institution. This attribute's value should be specified even if it matches the value of publisher_institution, or if creator_type is institution." Some discussion about why we need this, and whether it would be simpler to have a person, an institution, and a project, so fewer terms. But we'd also need emails and URLs for each of those, and the reader/developer couldn't count on creator_name always having the name of the creator in it. 

JB - For creator_name, what about multiple authors? JG: Discussed extensively in last call; decision was that this attribute should not allow multiple authors, for reasons of history and consistency with other standards

*_info: - Summary: The *_info attributes will not be added.

JG - let's just vote on *_info attributes. Only 66% voted to add. so not enough to approve -- they are going away.

contributor_name: Summary: Accepted

contributor_role: Summary: Accepted

BS - what does the statement 'conversion to ncML' mean?; JG - it means white space not preserved when strings in the binary are converted to ncML, then converted back. The wording about ncML is a bit awkward, could be modified if that's desired. (Not desired.)

publisher_type: Summary: Accepted, with change of 'role' to 'position' (also need to make that change to creator_type)

publisher_institution: Summary: Accepted

publisher_project - Summary: Dropped

Several commented that this doesn't seem necessary.  JG - let's vote. how many people want this one.  66% voted for, so it won't be included.

variable level attribute definitions  - Summary: Accepted
 long_name
 standard_name
 units

geospatial_bounds - Summary: To be resolved

JG: We have only a few minutes, we probably can't resolve this unless everyone agrees it is perfect.

AJ - don't think this is figured out yet. "took his dog for a walk and thought". do we think ACDD should EVER specify a CRS ? this is the key question. ; TH - Other metadata standards that use bbox never talk about coordinate system. it is always in lat/lon. discovery independent of crs is well known. the problem that I think we have is the order of the values. lat lon alt/depth (?). AJ - probably not going to write our own software for dealing with coordinate systems, in 2014 we'll use some open source library.. suggest when we can, include CRS. TH: add attribute: srs_name. This definition of  bounds should specify the order of the lat lon when crs is not specified;  AJ - layered approach.; JB - setting ourself up for some complex scenarios.; AJ - ; EA - people are not going to specify crs usually.; TH - the problem is lat lon or lon lat. need to be specified. Could use ogc or epsg identifiers; AJ - geojson...(?) follow your own rules; JB - can we provide links to where the ordering is specified; TH - search esip wiki for CRS specification or for the name LOTT. ; AJ - will provide link in chat (http://wiki.esipfed.org/index.php/CRS_Specification)

There seems to be acceptance that having geospatial_bounds without CRS could work. Details need to be proposed and considered.

Logistics

JG - We're past the 2 hour time limit. Lots of progress, only two significant ones left. Next meeting we need to address: date/time attributes, and various geospatial bounds attributes.

JG - can we add a meeting before next thurs? or include next thurs? TH - no agenda currently for next thurs.  deadline for ESIP sessions is this friday. JG -  should plan on presenting on this assuming that this will be resolved. 

JG - so, we can deal with this next (a) with another adjudication meeting before next Thursday, (b) at next Thursday's regular call, or (c) after next Thursday's regular call. ? - Can we set up a time before next Thursday's call?

can we meet on Tues at the same time? Two people are unavailable. but everyone seems content with this schedule. but we will still have meeting at 11 PT / 12 MT / 2 ET  on tues.

Items raised but deferred (possibly indefinitely)