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

From Earth Science Information Partners (ESIP)
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Discovery_Telecons|<< Back to the Discovery Telecons page]]
 
[[Discovery_Telecons|<< Back to the Discovery Telecons page]]
 +
 +
* Tuesday, March 8, 2011. 4:00pm ET / 1:00pm PT
 +
* Phone number: 1-866-509-1626
 +
** Meeting Code: 3851033#
  
 
== DCP-1 review ==
 
== DCP-1 review ==
Line 5: Line 9:
 
* Review final changes to [[Discovery Change Proposal-1 | DCP-1: ESIP Discovery Cast Atom Response Format v1.1]]
 
* Review final changes to [[Discovery Change Proposal-1 | DCP-1: ESIP Discovery Cast Atom Response Format v1.1]]
 
* Answer some questions posted on the [[Talk:Discovery_Cast_Atom_Response_Format_v1.1|DCP-1 Discussions]].
 
* Answer some questions posted on the [[Talk:Discovery_Cast_Atom_Response_Format_v1.1|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 ==
 
== Decide on Voting Method ==
  
* What are we voting for? yes/no?
+
* What are we voting for?
* anonymous voting?
+
** From last month's minutes, "Also done via Discussion pages, with thread named "Voting"; people can leave their signatures with Yea or Nay".
 +
* James G: GDAL has a group of 5 or so people on the board. Any one of them can veto. But the intent is that they generally won't.
 +
** Chris: 3/5 majority of Yays to Nays, and the editors can veto.
 +
* Anonymous voting?
 +
** Most agreed that better not to do it anonymously.
 
* Where to vote?
 
* Where to vote?
** esipfed.org wiki
+
** esipfed.org wiki, new Drupal-based [http://www.esipfed.org/ ESIP Federation website], [http://www.doodle.com Doodle], etc.?
** new Drupal-based [http://www.esipfed.org/ ESIP Federation website]?
+
** Settled on using [http://www.doodle.com Doodle] and then copy/paste the final results into the wiki when done.
** [http://www.doodle.com Doodle]?
 
** ...?
 
  
 
== Next DCP ideas ==
 
== Next DCP ideas ==
  
*  Specific extensions to Discovery Atom Response format for Granule-level, Collection-level, and Service responses. Simply builds upon DCP-1.
+
* Due to time constraints, decided to handle this offline on the mailing list.
* Discovery RSS Response Format?
+
**  Specific extensions to Discovery Atom Response format for Granule-level, Collection-level, and Service responses. Simply builds upon DCP-1.
* OpenSearch Request Format. adopt OGC OpenSearch spec?
+
** Discovery RSS Response Format?
* ServiceCasting Request Format?
+
** OpenSearch Request Format. adopt OGC OpenSearch spec?
* DataCasting Request Format?
+
** ServiceCasting Request Format?
* Mashup conventions?  
+
** DataCasting Request Format?
 
+
** Mashup conventions?
  
 
== ESIP Summer Discovery Session planning ==
 
== ESIP Summer Discovery Session planning ==
  
* demos?
+
* Next meeting in July, so not many telecons left. The theme is Information Quality.
* ...
+
* Two things could do:
 +
# Technical workshops
 +
# Educational outreach. demo various implementations.
 +
* Would have to request time at ESIP first.
 +
* First, do we want something relevant to the Information Quality theme?
 +
** James G: may be better off to stick with out main message on Discover service capabilities. more working meeting.
 +
*** second by Jeff.
 +
* Curt and Hook agreed about need for outreach.
 +
* Talk to Carol about outreach.
  
 
== Attendees ==
 
== Attendees ==
Line 36: Line 65:
 
* C. Lynnes
 
* C. Lynnes
 
* C. Tilmes
 
* C. Tilmes
 +
* W. Sonntag
 +
* H. Hua
 +
* B. Wilson
 +
* J. Gallagher

Latest revision as of 16:22, March 8, 2011

<< Back to the Discovery Telecons page

  • Tuesday, March 8, 2011. 4:00pm ET / 1:00pm PT
  • Phone number: 1-866-509-1626
    • Meeting Code: 3851033#

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 last month's minutes, "Also done via Discussion pages, with thread named "Voting"; people can leave their signatures with Yea or Nay".
  • James G: GDAL has a group of 5 or so people on the board. Any one of them can veto. But the intent is that they generally won't.
    • Chris: 3/5 majority of Yays to Nays, and the editors can veto.
  • Anonymous voting?
    • Most agreed that better not to do it anonymously.
  • Where to vote?

Next DCP ideas

  • Due to time constraints, decided to handle this offline on the mailing list.
    • 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

  • Next meeting in July, so not many telecons left. The theme is Information Quality.
  • Two things could do:
  1. Technical workshops
  2. Educational outreach. demo various implementations.
  • Would have to request time at ESIP first.
  • First, do we want something relevant to the Information Quality theme?
    • James G: may be better off to stick with out main message on Discover service capabilities. more working meeting.
      • second by Jeff.
  • Curt and Hook agreed about need for outreach.
  • Talk to Carol about outreach.

Attendees

  • J. McWhirter
  • M. Cechini
  • C. Lynnes
  • C. Tilmes
  • W. Sonntag
  • H. Hua
  • B. Wilson
  • J. Gallagher