Discovery Cluster Planning

Abstract/Agenda: 
  1. Discuss the status and plans for the Discovery Request For Comments to be submitted to NASA's Standards and Processes Group.
  2. Develop, review and populate the Discovery Implementation Coverage Matrix that summaries the feature set of capabilities. 
  3. Discuss plans for going forward with the ESIP Geoportal
  4. Prepare for Grand Challenges Session (link
  5. Other Topics?
Notes: 

Discovery Planning Breakout Session Notes
 
I. Lynnes
Discovery RFC; Memo for NASA Earth Science Data Systems on standards
 
Section 7: description of what doing, OpenSearch document but also data casting
Yoshi commented so added data casting. Need Ruth to check data casting is correct; can make changes directly in document
 
Added more introductory material: data casting is whole framework without the query, which is provided by provider
 
Atom is still preferred syndication format
 
[comments in doc show required/optional components for cliff's notes on document]
 
Search terms: optional, but expect at data set level but not granular 
multiple search terms separated by '+' which is equivalent to boolean 'AND' 
Discussion: why not use space? Default behavior versus special keywords. So the plus should be in URL
Put a plus, or put a plus or a space
Agreed 'AND'…but need to take back to labs, keep figuring out string
Default behavior for multiple terms is 'AND'
 
Time extension: optional. If use follow OpenSearch extension
slash in response to separate date range
 
Spatial extension: optional
having a minimum bounding box
 
Recursive OpenSearch queries: optional
drilling down to more specific queries
 
Characterizing atom link elements
How deal with versions of netCDF? --> see what rest of community is doing. Does client care that much? Most can handle 4. Matt: look around to see if acceptable way to encode (by next week)
 
Characterizing OpenDAP link elements
Make note: don't have to send back all 6
new code
 
Versioning: required
Parser resolves namespace so lose version. Added space to enable xpath discovery. Redundant about the version, but not a big deal
what version getting is not specified 
disambiguate notion of version: not the dataset, left to providers
 
Error handling: required
resolves error for success with no returns
 
Implementation
make bulleted list names (no URLs)
need to name check
add something about conformity; not up to standards yet bc didn't have them
 
II. Hua
 
Implementation coverage matrix
fill out which feature sets are being used/popular/planned but not implemented
add column root suffix OPeNDAP link elements
add columns for 'or' and 'not'
 
Anything else should add?
 
every time have RFC have reference implementation: useful?
simple enough to already implement in applications where need to use it
but an aspect of compliance testing useful if can do cheaply: gain v. cost
a quick sanity test. Need default: grand default of what to do if ask to do something canon (circle search)
have a template of capabilities
Not sure ultimately…accumulate some compliance resources
Propose writing up, Funding Friday this summer….
 
ESIP Discovery mail list for questions/issues/ambiguity
Put in RFC, explain ongoing change processes 9end of implementation section]

Actions: 

 

RFC Action Items

  • Ruth and JPL Representative(s) - check the Datacasting section in RFC 
  • Ruth (or other) - update document to state Datacasting as an "advertisement" and "page rank" in RFC
  • OpenSearch Focused Members - take a look at the Datacasting section in RFC
  • JPL DAAC Rep - Write RSS specification in RFC
  • Eric - "+" is in URL, not in the data that gets parsed by the server (create DCP?)
  • Eric - Find default behavior for searchTerms in OpenSearch ("space-delimited")
    • Note, Chris was correct in stating there is no default "boolean" behavior, but the default delimiter is a "space" character
  • Chris - update spec to explicitly state that recursive OpenSearch queries imply subsetting operations (as opposed to broader or related search)
  • Matt - look for different ways of representing MIME types for netCDF3 vs netCDF4 (or HDF4 vs HDF5)
  • Chris - For OPeNDAP, make a change to denote that not all 6 response types are required
  • Chris - Disambiguate notion of versioning to ensure we're not talking about dataset version (which is left up to the providers)
  • Chris - Add bulleted list of implementations (with or without URLs)
  • Chris - Acknowledge in Implementation section that most servers and clients "loosely conform"
  • All - Update the Implementations section of the RFC with your implementations
  • Chris - Add note at end of implementations section that any issues should be reported to the ESIP Discovery mailing list

Implementation Matrix Action Items

  • Hook - add "root" entry point column for OPeNDAP link to Google Doc
  • Hook - add columns for "OR" and "NOT" for boolean search capabilities 
  • Chris - Reach out to Pedro and Yoshi to try and get more implementations on the Google Doc
  • ??? - add AEROSTAT to Google Doc
  • Chris - Reach out to UAH and SCS (Ken Keiser or Helen) for Google Doc contribution
Citation:
Hua, H.; Lynnes, C.; Discovery Cluster Planning; Winter Meeting 2013. ESIP Commons , November 2012