ACDD 1.3 Revisions/Adjudication - Mtg #4 12/11

Abstract/Agenda: 
  1. Section: Alignment with NetCDF and CF Conventions    (rewrite for clarity)
  2. Section: Maintenance of Metadata     (rewrite for clarity)
  3. Section: Comma-Separated Lists      (minor edits for clarity)
  4. Attribute: standard_name_vocabulary
    • Default outcome is no change, unless someone requests a vote 
    • Doodle poll of preferences is at http://doodle.com/9erdnp4ma74aa7ew
    • See my summary within Topic 1 and Appendix of this post
  5. Attribute: product_version         (modified proposal is in the document)
    • software_version has been withdrawn
  6. Attribute: cdm_data_type          (proposal is in the document)
    • see proposal, summary, and references email [3]
  7. Attributes: publisher* (details in email/below)
  8. An email list? that we can include in specification
  9. How to approve this specification
    • proposed: initial vote at brief ESIP Doc call next week, followed by 2-week poll
  10. Final comments and wrap-up
Notes: 
  1. Section: Alignment with NetCDF and CF Conventions    (rewrite for clarity)
    • Alignment with NetCDF and CF Conventions paragraph is approved - no concerns
  2. Section: Maintenance of Metadata     (rewrite for clarity)
    • Changes approved - no concerns
  3. Section: Comma-Separated Lists      (minor edits for clarity)
    • Example here is confusing. Should it be double-quotes around every element? No, that is an option but we didn't describe it in the details.
    • ncML-like XML can't handle the double-quote (because attributes are delimited with double-quotes), it handls single quotes OK. But that can't be right, that would mean any attribute with a quote in it would kill ncML XML. We think actually running these through the ncML process will produce escaped double-quotes, and that will be acceptable XML. If it doesn't, we think that's a bug in the ncML translator. Recognizing we could be shooting ourself in the foot if it is a bug that doesn't get fixed, we are sticking with double-quotes, because that's standard CSV comma-escaping mechanism.
    • Change approved, no (other) concerns.
  4. Attribute: standard_name_vocabulary
    • Based on the votes, the default plan is to leave this as is. Nothing got 70% vote or greater.
    • Upon review of the voting, the preference to add explanatory text seems harmless enough (since it is true). Philip would be OK with adding this, and so is the other person who voted no.
    • Would be better to add it in the affirmative, though.
    • The group agrees to add the modified text "Values for any standard_name attribute must come from the CF Standard Names vocabulary for the file or product to comply with CF."
  5. Attribute: product_version         (modified proposal is in the document)
    • If this version identifier changes with any change of the data (yes), then the algorithm or methdology is not very significant — reprocessing an updated stream also produces an updated product version. Yes, but algorithm or methodology changes are the most likely application. We could specify the algorithm or methdology part as an example. (yes)
    • Do we worry about how fine-grained this is? Let the data creator worry about how they want to apply it (words 'as assigned by the data creator' make this clear).
    • Group agrees to the revised wording "Version identifier of the data file or product as assigned by the data creator. For example, a new algorithm or methodology could result in a new product_version."
  6. Attribute: cdm_data_type          (proposal is in the document)
    • This definition was modified in recent weeks to eliminate the details, which were prone to becoming out of date.
    • Also removed the warning, because making it correct and specific was too fraught.
    • Some confusion about the new wording, getting the terms correct and unambiguous. Proposed new words for the first sentence: "The data type, as derived from Unidata's Common Data Model Scientific Data types and understood by THREDDS."
    • Can we move this to Suggested section? Yes.
    • Approved as reworded.
  7. Attributes: publisher* (details in email/below)
    • Brought up Nan's email concerns, John's alternates for consideration
      • In particular, with respect to publisher*, summarizing the issues: (a) circular definition, (b) file may be written before identify of publisher is known, and (c) it doesn't identify the writer of the data.
        So I will put forward the wordings  
        • "The name of the [entity] responsible for publishing the data [...] to users"  
        • "The name of the [entity] responsible for assembling or providing the data [...] to users"  
        • "The name of the [entity] responsible for disseminating the data [...] to users"
      • to get a read on what's desired. (Like Ken, I always thought the person running the web site IS the primary point of contact, because they should know who provided the data to the web site. And if someone has *assembled* a data set from other sources, I consider the assembler the creator. But I know different groups like to use these terms different ways—many use creator for the PI—and I hate circular definitions!)
    • There was some interest in fixing the circular definition. But of the people on the call, at least half preferred just distribution (= dissemination = provision) as the explicit meaning of this term, and did not like the assembly meaning. 
    • At this point, the concern was that making that change would break existing use cases like Nan's. (As with other attributes previously discussed, this is fairly unattractive.) Perhaps leaving the circular definition is the least disruptive approach at this point.
    • The group made no change to this definition.
  8. An email list? that we can include in specification
    • Yes, the ESIP Documentation list is appropriate, as it is archived.
    • Although it is a moderated list, the moderator can catch and direct these issues as appropriate.
    • Where do we put it, in the standard or in the wiki page at the next level up? Both.
    • Decided to put text at the end of Development section along the lines of "Users with questions about this specification may send mail to the ESIP Documentation mail list {...}." We'll want to double-check this is OK.
  9. How to approve this specification
    • Proposal: Recommend to whole Documentation call that an initial vote be held at the brief ESIP Doc call next week, followed by 2-week poll for final results. There to be no extended discussion at the Documentation call -- if it is felt extended discussion is needed, the discussion and agreement will have to be pushed to the next full Documentation meeting.
    • General agreement on this approach, everyone liked the Doodle poll idea.
    • Adjudication still possible in theory between now and next week's vote. But the group requested that we add language to discourage any new topics being raised next week.
  10. Final comments and wrap-up
    1. Question: Anna noted the netCDF validator looked for an attribute called time_coverage_units, which we no longer have (neither did 1.1). An issue? No, because the units are covered by the use of ISO 8601 durations for the time_* attributes. This should be a suggestion for the validator.
    2. Question: Could we reorganize attributes so like attributes are together?
      • Proposal: Anna wants to add alphabetic list of names and their recommendation levels (at the end), linked back to the term entries. Everyone found this idea agreeable.
      • For the organization, John thinks that is done, but within recommendation level sections. He thinks those sections provide an important prioritization.
      • Alternatives:
        1. Add columns to show which section an attribute is in.
        2. Reorder by topic, and add an "alphabetic list by section" in the front, complementing the index list in back.
      • Conclusion: Phil will look at current list and see if it feels "good enough", discuss with John if not.
Citation:
ACDD 1.3 Revisions/Adjudication - Mtg #4 12/11; Telecon Minutes. ESIP Commons , December 2014
Submitted by amilan on 2014-12-11 16:14.