ESIP Discovery Cluster 2011 Winter Meeting

From Earth Science Information Partners (ESIP)


Abstract

The set of ESIP Discovery web services encompass the overlapping conventions of Earth science data-oriented OpenSearch, Data-Collection Casting, Data-Granule Casting, and Service Casting feed standards. With multiple distributed Earth science data systems already implementing these casting standards, a need has arisen to develop interoperable and community-driven conventions. We will cover interoperability use cases, setup a governance process for moving forward, discuss key issues, and settle on an initial ESIP Discovery Cast Response format.

Objective

To settle on a set of discovery-oriented cast/feed services (OpenSearch, data collection casting, data granule casting, service casting) that are interoperable with one another. We are targeting an audience that is familiar with federated discovery services. This session will be less on tutorial, more on getting stuff done.

Tentative Agenda

  • Interoperability Use Cases (45-minutes)
    • Extend OpenSearch to service casting (Chris Lynnes, 10-minutes)
    • Service casting and data (granule and collection) casting (Ruth Duerr, 10-minutes) File:Integrated portal.pdf
    • Coastal data visualization data casting. (Ken Keiser, 10-minutes)
    • Discussion on interoperability (15-minutes)
  • Setup governance mechanism (30-minutes working session)
    • there is a need to move forward.
    • there exists multiple data centers involved in Discovery services.
    • we need it since interoperability, different centers, standards.
    • agree on process, and then follow it.
    • if we agree up front how decisions is made, can make progress quickly. urgency, it's happening now.
    • appoint folks.
    • tracking issues.
    • proposing, ratifying, changing standards
    • document what's happening. transparent trail on wiki.
  • Discussion on key issues. (20-minutes)
    • identify the issues.
    • could assign to people.
  • Atom vs RSS comparative. (10-minutes) ???
  • Settle on specification of response format (10-minutes working session)
    • Review Discovery Cast Atom Response Format
    • Namspace
    • ESIP extensions to Atom Response
      • Temporal extents
      • Spatial extents
      • rel links type vocabulary
      • Pagination support
      • Custom tags (with namespace!) at top-level of <entry>

Next Steps

  • Continue discussions and developments on ESIP Discovery mailing list and telecons.
  • Settle on specifications.
  • Follow up with demos in ESIP Summer meeting.
  • many more...

Slides from Session

Notes from Session

Discovery Feed Services Hook Hua
More of a working session rather than a tutorial, covered tutorials in New Orleans. This is a discovery cluster that works with OpenSearch, Data Casting, and ServiceCasting.

  • Discovery service history highlights; created data casting funding in 2005, 2009 jan 6, FROST concept proposed at ESIP in DC.
  • July 7 FROST demo at ESIP based on XSLTdemoed by Chris.
  • July 14th ESIP fedsearch cluster startup
  • OCT 21 presentation at ESDSWG
  • 2010 July 20th ESIP Knoxville, second datacasting, service casting.
  • OCT 04 ESDSWG New Orleans federatedness casting session.
  • NOV 30 Discovery feed Atom wiki
  • First discovery cluster in dec
  • ESIP federated search+service casting + data casting = ESIP Discovery
  • Decided to change to a discovery cluster compared to the old federated search same wit mailing list decided at new Orleans

Ruth
These projects are attempting using Libre portals to obtain data and services using spatial, temporal, and free text What they want is the contents of a cast to be the contents of a opensearch result entry. It is applicable for Atom and hopefully KML.


Chris Lynnes
Brian Wilson funded to do service casting, but had developed it before that. Chose to use atom as the response format. When creating federated open search chris followed brian and used Atom for service casting, deals with service registry problem. Service cast links in Opensearch Dataset Level Response; provices alts to granule-level search such as searchlight. Works also with Top-level of dataset trees such as THREDDS catalogs and Toplevel Hyrax directory for a dataset. Scast in a granule-level response allows the discovers services that can be applied to individual granules. More useful for “unique” services Has the ability to uniquely associate with a granule is needed. Finally would scast of OpenSearch service, help to distinguish up front between opensearch following ESIP federation conventions, other conventions, and simple OpenSearch Similar to web services, Rest based web service RSS style services and better than soap. Original ideas of this was Federatedness concept. Step 1 was interoperability. Attempts to target smaller data centers or Pis that don’t put data in repositories for various reasons. Maybe able to get access to a wider set of repositories.

Ken Keiser
Attempting to promote interactions between projects, regional extent along gulf coast and southeastern us regions focus on decision support and get information out to the end-users. Each project is a data/info producer Limited level of it capabilities Data/info should be available to variety of end-user apps and tools Should be looking for interoperable access for visualizations Attempt to use data casting and KML along all the projects they are attempting Feed aggregation services to pull together data casts from multiple sources. Benefits include easy level of technical participation, puts technical burdeon on app developers, and casts and KML are discoverable on the web for other uses Example of cast aggregation shows a drupal module and give the url of their feed and show their data. Trying to adopt data casting of Andy Bingham? Data cast points to KML file that has the data encapsulated Plans include to make it even easier for data producers by giving: data cast authoring tools KML authoring Tools, Integrated aggregations. Also integrating more cast technologies with apps, such as Open Search and several other cast technologies. KMl was the easiest way to use and show the data from the applications. Extended the data casting ideas of bingham, allows to link and provide metadata.


Hook
Governance: want open and interoperable Discovery standard, need to move forward Multple data centers involved, issues with interoperability, different centers and standards, agree on a process and follow it. Process needs; proposing, forum, ratifying, changing standars, must be documented on wiki, Appoint people?, Examples such as java community process, committers work with community implement changes, accept input, apache model Best example of what is wanted in OPM editors act as committers to the OPM specs, bootstrap with initial editors, new community and participants will become editors over time. Avoid splintered community, prevent branching with an open consensus driven processes Chris for open search brian Wilson for service casting, and andy bingham for data casting, trying to avoid splintering Process to change OPM : All steps posted to mailing list and wiki Calls for change of proposals, editors invite community to submit proposals Proposal review period, time limit should be set to avoid indefinite arguments Finally do a vote. Community wiki account holders vote, change proposal with majority community and agreed majority of editors Document all the edits and end with a final review of everything. Discovery needs something along these lines.

  • Initial editors: possibly be Hook, Ruth Duerr, Chris, Andy, Brian, maybe EPA editor and should be an odd number.
  • Governance process? Prolly follow the OPM without extending deadlines.
  • Adopt OPM governance with changes including: deadlines a minimum of 2 weeks and 8 weeks.
  • Set up governance page on wiki proposed community standard, follow OPM governance
Retrieved from "https://wiki.esipfed.org/w/index.php?title=ESIP_Discovery_Cluster_2011_Winter_Meeting&oldid=31131"
GNU Free Documentation License 1.2
Powered by MediaWiki
Powered by Semantic MediaWiki