Difference between revisions of "Discovery Telecon 2011-03-08"
From Earth Science Information Partners (ESIP)
Line 8: | Line 8: | ||
*** Should add note that if there are geospatial information in the response item, then should always have a box. Could add other shapes. | *** Should add note that if there are geospatial information in the response item, then should always have a box. Could add other shapes. | ||
** James G: better to remove optional circle shape to increase interoperability. more options is bad thing. Circle doesn't bring more benefits. | ** James G: better to remove optional circle shape to increase interoperability. more options is bad thing. Circle doesn't bring more benefits. | ||
− | *** Chris: want | + | *** Chris: want to be simple as possible while as general as possible. |
** namespaces to use georss. | ** namespaces to use georss. | ||
** rel links and IANA. | ** rel links and IANA. | ||
Line 16: | Line 16: | ||
*** Brian advocates for supporting both rel "data" and "enclosure" (IANA) types. | *** Brian advocates for supporting both rel "data" and "enclosure" (IANA) types. | ||
*** Atom uses rel and alternate type links. | *** Atom uses rel and alternate type links. | ||
+ | *** To keep things simple, we decided to remove mapping to IANA for now. Stick with original rel link types: data, browse, documentation, metadata, collection, service, event, feed. | ||
+ | *** Feeds of feeds allows for hierarchy. Though there are real use case for it, we'll keep it in for now. | ||
** This is a 'baseline' specification of the OpenSearch response. Would need specifics for granule, collection, and service responses. | ** This is a 'baseline' specification of the OpenSearch response. Would need specifics for granule, collection, and service responses. | ||
** Should we specify that all discovery services must support the full GeoRSS-Simple spec? Note the support of box, circle, and polygon types. But radius, line, and point are not in yet. | ** Should we specify that all discovery services must support the full GeoRSS-Simple spec? Note the support of box, circle, and polygon types. But radius, line, and point are not in yet. |
Revision as of 15:57, March 8, 2011
<< Back to the Discovery Telecons page
DCP-1 review
- Review final changes to DCP-1: ESIP Discovery Cast Atom Response Format v1.1
- Answer some questions posted on the DCP-1 Discussions.
- Is a rectangular bbox in the response always required? Even if the 'natural' bounds are a circle or polygon?
- Should add note that if there are geospatial information in the response item, then should always have a box. Could add other shapes.
- James G: better to remove optional circle shape to increase interoperability. more options is bad thing. Circle doesn't bring more benefits.
- Chris: want to be simple as possible while as general as possible.
- namespaces to use georss.
- rel links and IANA.
- Predefined IANA namespaces do not need a namespace.
- Brian is concerned with needing more information for machine parsable rel types.
- We should play nice with the OGC types as well.
- Brian advocates for supporting both rel "data" and "enclosure" (IANA) types.
- Atom uses rel and alternate type links.
- To keep things simple, we decided to remove mapping to IANA for now. Stick with original rel link types: data, browse, documentation, metadata, collection, service, event, feed.
- Feeds of feeds allows for hierarchy. Though there are real use case for it, we'll keep it in for now.
- This is a 'baseline' specification of the OpenSearch response. Would need specifics for granule, collection, and service responses.
- Should we specify that all discovery services must support the full GeoRSS-Simple spec? Note the support of box, circle, and polygon types. But radius, line, and point are not in yet.
- Is a rectangular bbox in the response always required? Even if the 'natural' bounds are a circle or polygon?
Decide on Voting Method
- What are we voting for?
- from lat month's minutes, "Also done via Discussion pages, with thread named "Voting"; people can leave their signatures with Yea or Nay"
- anonymous voting?
- Where to vote?
- esipfed.org wiki
- new Drupal-based ESIP Federation website?
- Doodle?
- ...?
Next DCP ideas
- Specific extensions to Discovery Atom Response format for Granule-level, Collection-level, and Service responses. Simply builds upon DCP-1.
- Discovery RSS Response Format?
- OpenSearch Request Format. adopt OGC OpenSearch spec?
- ServiceCasting Request Format?
- DataCasting Request Format?
- Mashup conventions?
ESIP Summer Discovery Session planning
- demos?
- ...
Attendees
- J. McWhirter
- M. Cechini
- C. Lynnes
- C. Tilmes
- W. Sonntag
- H. Hua
- B. Wilson
- J. Gallagher