Difference between revisions of "Discovery Telecon 2011-03-08"

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.

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

@@ 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.
 ** James G: better to remove optional circle shape to increase interoperability. more options is bad thing. Circle doesn't bring more benefits.
-*** Chris: want ot be simple as possible while as general as possible.
+*** Chris: want to be simple as possible while as general as possible.
 ** namespaces to use georss.
 ** rel links and IANA.
@@ Line 16: / Line 16: @@
 *** 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.