ESIP 2012-01 Discovery Workshop
<< Back to the Discovery Cluster page
<Back to Jan 5, 2012 Program
General Info
- What: ESIP 2012 Winter meeting, Discovery Workshop.
- This is the first of two Discovery sessions. See our other planning session on Friday.
- When: Thursday, January 5, 2012 at 2:00pm-3:30pm. Track 3.
- Where: Renaissance Washington, DC Dupont Circle Hotel, Room: MT. VERNON
- Description: The set of ESIP Discovery services encompass the overlapping conventions of Earth science federated OpenSearch, Collection Casting, Granule Casting, and Service Casting feed standards. This workshop will cover some technical discussions of how Discovery services and specifications can be practically applied to facilitate collaborations by enabling sharing of services and data.
- Session Lead(s): Chris Lynnes, Hook Hua
- ESIP Collaboration Areas: Discovery
- Expertise Level: Apprentice
- Topic tags: Tech
- Note: This session is focused on making progress as a community in coordinating conventions and interoperability of discovery services.
Agenda
Interoperability for OGC services (50-minutes, Chris Lynnes)
- Slides on "OGC and ESIP Discovery, OR Can't we all just get along??"
- OGC proposing OpenSearch specification.
- we need to converge with OGC specification as much as possible.
- OGC's approaches are intended to be compatible with the mass-market
- Key Differences in Atom Response
- time
- ESIP: OpenSearch time request extension adopted to response.
- OGC: dc:date, which is soft type and schema-less
- link identification
- time
- to determine best approach to link identification, best to identify first the key issues trying to solve.
- Link identification approaches
- DCP-1
- to be deprecated
- DCP-2
- withdrawn
- DCP-3
- under debate
- return IANA rel + ESIP-specific attributes
- OGC had a problem with this approach since ignored by mass-market tools.
- mime-type
- IANA rel + extend type
- primary and secondary type delimited with "+" is formally supported in mime-type values.
- mime-types also support services via "application/" prefix.
- "DCP-3"-style + mime-type combined approach
- DCP-1
Interoperability for OpenSearch in various types of casting (45-minutes, Brian Wilson and Jess Lacy)
- Casting at NSIDC
- increasing need for adding semantics
- Links between casts
- need to decouple service (e.g. opensearch) and encoding type response (e.g. application/atom+xml)
- Interoperability
- custom request parameters
- NSIDC has custom Query attributes in OSDD to codify the custom parameter types.
- Error handling
Notes
Action Items
(List potential business activities and who is responsible.)
- DCP-4 for <dc:date> replacement of <time:start> and <time:end>?
- DCP-5 for valid parameters specification through <opensearch:Query>?
- DCP-6 or best practices for error handling?
Key Topics
(List any key topics covered.)
DCP-3 and <link> specifications
Chris Lynnes presents on convergence of OGC and ESIP Discovery specifications. The presentation covers some of the players involved in the specs being converged (Discovery Cluster, OGC, OSGeo, GENESI-DR). It also summarizes the various specs (DCP-1,2,3, OGC Geospatial Extensions Draft).
There are some similarities in the OGC and ESIP Discovery approaches. See slides from link below for a comprehensive list.
There are key differences between the Discovery and OGC specifications. Namely,
- Atom Response Time Representation:
- Discovery repurposes the OpenSearch time extension parameters for XML elements.
- OGC uses a Dublin Core approach.
- Paging isn't explicitly recommended in the Discovery approach (although it is part of the OpenSearch specification).
- OGC uses IANA only for link tag "rel" attributes.
There are a number of options for <link> tags and the "rel" attributes.
- DCP-1 uses ESIP namespaced values for "rel".
- The problem was that DCP-1 could not distinguish OPeNDAP links from regular data links
- DCP-2 uses a specific "rel" value for each service type (e.g., OPeNDAP).
- DCP-3 uses IANA standards for "rel" values and some ESIP specific (namespaced) attributes.
- MIME type
How the ESIP Conventions have helped with NSIDC work.
Some concerns (maybe lack in what ESIP has).
- Should the "more" link be acknowledged in the Discovery spec.
- Dimensionality of casts?
- Integrating semantics into casting.
Linking between casts
How do you describe within a service cast which datasets are served? Or how do you link from datasets the services that search over that data?
Also covered custom parameters and metadata collection standards.
Contributions
DCP-3 and <link> specifications
James G. - MIME types are intended to describe the response, not the service Chris M. - You are using the MIME type correctly Steve - Atom is extensible, why not use any of the standards and allow the clients to pick and choose what they want to use. Brian Wilson - Using MIME types has the potential to have exponential growth. What about versioning? (Chris) We don't need to worry about MIME types at this time. Eric - Who is creating the tools that use these specs? (Chris) We are. (Eric) Then does it really matter if we use extra attributes, other clients can just ignore them? Hook - We are trying to keep things as simple as possible. ?? - I thought service casting covered most of these use cases. (Chris) Service casting is more complex than the Discovery Cluster wants to go (requiring a dereference) Ruth - Ultimate goal is to be able to aggregate as much data as possible. So as much alignment with GENESI-DR as possible is optimal.
Related Projects
- The Open Source Geospatial Foundation (OSGeo) is leading the OpenSearch spec. for the OGC.
- GENESI-DR is a consortium of Earth observation repositories that will be applying the OSGeo spec.
Other
Straw poll
- DCP-3 - 5
- MIME type - 7
- "Double Abomination" - 5
Original Notes
