<div dir="ltr">Hi All, <div><br></div><div>Just wanted to point you to the Summer Meeting site where I've added some info on the hackerspace: <a href="http://commons.esipfed.org/2015SummerMeeting#Hackerspace" target="_blank">http://commons.esipfed.org/2015SummerMeeting#Hackerspace</a></div><div> If you'd like to block out some time, please let me know!<br></div><div><br></div><div>Cheers, </div><div>Annie</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . </div><div><b><font size="2">Annie Bryant Burgess, PhD<br></font></b></div><font size="2">Community Director<br>Federation of Earth Science Information Partners<br></font><div><font size="2">www: <a href="http://esipfed.org/" target="_blank">http://esipfed.org/</a></font></div><div><font size="2">twitter: @esipfed</font></div><div><font size="2">mobile: <a href="tel:585.738.7549" value="+15857387549" target="_blank">585.738.7549</a></font></div><div>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .</div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 24, 2015 at 9:24 PM, Erin Robinson <span dir="ltr"><<a href="mailto:erinrobinson@esipfed.org" target="_blank">erinrobinson@esipfed.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Will you respond to all below on how they could connect in hacker space?<br>---------- Forwarded message ----------<br>From: <b>Soren Scott via Esip-discovery</b> <<a href="mailto:esip-discovery@lists.esipfed.org" target="_blank">esip-discovery@lists.esipfed.org</a>><br>Date: Tuesday, June 23, 2015<br>Subject: [Esip-discovery] Service description use cases<br>To: Steve Richard <<a href="mailto:steve.richard@azgs.az.gov" target="_blank">steve.richard@azgs.az.gov</a>><br>Cc: esip-discovery <<a href="mailto:esip-discovery@lists.esipfed.org" target="_blank">esip-discovery@lists.esipfed.org</a>><br><br><br><div style="word-wrap:break-word"><div>Steve,</div><div><br></div><div>It did’t look like there was an open session that didn’t conflict with break-outs one or many of us would be likely to attend (or lead). But there’s the newfangled hacker space set up and this might be a good use of that? I go from zero to specific line numbers with this stuff anyway.</div><div><br></div><div>Annie mentioned having a scheduling something running this week-ish if we’re all still amenable. No one seems to think the golf course is appropriate for this kind of thing :).</div><div><br></div><div>Soren</div><div><br></div><br><div><div>On Jun 2, 2015, at 9:18 AM, Steve Richard <<a>steve.richard@azgs.az.gov</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-size:14pt;font-family:Calibri,Arial,Helvetica,sans-serif;background-color:rgb(255,255,255)"><div style="margin-top:0px;margin-bottom:0px">Soren-- I'll be there as well.  Let's at least have a BOF or some other informal sit down to review use cases/requirements.</div><p style="margin-top:0px;margin-bottom:0px"> </p><div style="margin-top:0px;margin-bottom:0px">Erin-- can we set aside a room/time before hand or just do it ad hoc at the meeting?</div><p style="margin-top:0px;margin-bottom:0px"> </p><div style="margin-top:0px;margin-bottom:0px">steve</div><div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px"><br></div><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:14pt;background-color:rgb(255,255,255)"><div style="margin-top:0px;margin-bottom:0px">Stephen Richard</div><div style="margin-top:0px;margin-bottom:0px">Chief Geoinformatics Section</div><div style="margin-top:0px;margin-bottom:0px">Arizona Geological Survey</div><div style="margin-top:0px;margin-bottom:0px">416 E. Congress #100, Tucson 85745</div><div style="margin-top:0px;margin-bottom:0px"><a>steve.richard@azgs.az.gov</a></div><div style="margin-top:0px;margin-bottom:0px"><a href="tel:520-209-4127" value="+15202094127" target="_blank">520-209-4127</a></div></div></div><div><hr style="width:792px;display:inline-block"><div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b><span> </span>Esip-discovery <<a>esip-discovery-bounces@lists.esipfed.org</a>> on behalf of Soren Scott via Esip-discovery <<a>esip-discovery@lists.esipfed.org</a>><br><b>Sent:</b><span> </span>Monday, June 01, 2015 2:03 PM<br><b>To:</b><span> </span>esip-discovery<br><b>Subject:</b><span> </span>Re: [Esip-discovery] Service description use cases</font><div> </div></div><div><div>Well, I will be at Asilomar and am more than happy to talk about what we’ve been running into with Swagger even without an official session. If anyone knows of some interesting use cases related to EO or less-than-RESTful services, I’m all ears.</div><div><br></div><div>Cheers,</div><div>Soren</div><div><br></div><div>_____________________________</div><div><br></div><div>Soren Scott</div><div>Science Software Developer</div><div>National Snow & Ice Data Center</div><div>Boulder, CO</div><div><br></div><br><div><div>On May 18, 2015, at 5:40 PM, Soren Scott via Esip-discovery <<a>esip-discovery@lists.esipfed.org</a>> wrote:</div><br><blockquote type="cite"><div><div>Steve,</div><div><br></div><div>We haven’t put any of it in the wiki. Sounds like we should do that soon.</div><div><br></div><div>I think that’s roughly where we’re headed, assuming we take advantage of Swagger as a spec and a representative interface. My concern over the last six months is that incorporating the changes for OGC and OpenSearch means a pretty big divergence from the Swagger bases. It’s a maintenance issue. For the last scenario, I would think that most of that would be better captured in some graph instead of the Swagger spec. A ServiceMatch kind of thing.</div><div><br></div><div>Would there be interest in taking one of the remaining sessions for a possible implementation discussion? It might be too much ground to cover in the one self-describing web services session.</div><div><br></div><div>Soren</div><div><br></div><br><div><div>On May 15, 2015, at 12:07 PM, Steve Richard <<a>steve.richard@azgs.az.gov</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr" style="font-style:normal;font-variant:normal;font-weight:normal;font-size:12px;line-height:normal;font-family:Helvetica;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:14pt;background-color:rgb(255,255,255)"><div style="margin-top:0px;margin-bottom:0px">Soren-- good points.</div><div style="margin-top:0px;margin-bottom:0px">Since I haven't been able to participate in the scoping discussions, and couldn't find any related docs on the ESIP discovery wiki, I'd like to get a clearer idea of the use cases.</div><div style="margin-top:0px;margin-bottom:0px">From your mail (paraphrased, embellished by me...)</div><div style="margin-top:0px;margin-bottom:0px">* basic documentation of a service: defining parameters, route elements (relative paths for resources at an HTTP service endpoint?). I'd add information models (RDA data types) for resources and available representations (interchange formats)</div><p style="margin-top:0px;margin-bottom:0px"> </p><div style="margin-top:0px;margin-bottom:0px">* enable client application to “Try it out” by generating a correctly formatted request from the method document. (I'm guessing this means generating a web page with example requests for a human to look at and learn from).</div><p style="margin-top:0px;margin-bottom:0px"> </p><div style="margin-top:0px;margin-bottom:0px">Amplified use scenarios based on discussions with you and Ruth</div><div style="margin-top:0px;margin-bottom:0px">--1. Discoverable (crawlable) documents describing service endpoints to allow automated discovery and cataloging of services; ideally be able to catalog the data offered by the service as well.</div><div style="margin-top:0px;margin-bottom:0px">-- 2.  generation of web pages from description documents (like the swagger UI, e.g.<a href="http://petstore.swagger.io/" target="_blank">http://petstore.swagger.io/</a>) to help people figure out how to use a web service</div><div style="margin-top:0px;margin-bottom:0px"> -- 3. provide links in Atom documents (or other metadata interchange docs, e.g. ISO) to enable clients to drill down from search results for aggregate resources (data series, dataset) to more granular search (granule, records, features). Currently based on openSearch descriptions, but this generalizes to providing a URI template with an associated description document that specifies the parameters (data type, domains, semantics...) in the template.  Sub cases:</div><div style="margin-top:0px;margin-bottom:0px"> 3.a.   Initial user search is broken into two steps by the query processor--find datasets meeting one set of criteria, then search within those based on additional criteria. The idea would be to automate such a 'chained' search process so its largely invisible to the user. Example-- find well logs for boreholes deeper than 500m.  First search is to find a service that provides well logs and includes a property for total depth of log; second search within the discovered datasets is to find logs with TD > 500m</div><div style="margin-top:0px;margin-bottom:0px">3.b. can't automate the chaining of the query process, but can identify datasets that include the information of interest for the granular search; present user with some kind of form interface to construct the 'drill down' queries against a discovered dataset service (related to case 2 above)</div><p style="margin-top:0px;margin-bottom:0px"> </p><div style="margin-top:0px;margin-bottom:0px">Additional scenario of interest--</div><div style="margin-top:0px;margin-bottom:0px">a hypermedia document provides a variety of affordances (links) for accessing some resource; a software application needs to parse those affordances to determine which one is appropriate for its requirements, and automate connection to the data source.  Basic requirements to address here would be a service protocol, information model and encoding scheme that the client application 'knows'.  Example: a dataset is distributed via file download in several formats (xls, csv, json), via WFS with some identified featureType(s), WMS, ESRI REST service with identified feature type, a GeoWS csv RESTful service.  The client is designed to consume GML features of a particular type, so it needs to identify the WFS with a matching featureType and get information necessary to connect and access data. </div><p style="margin-top:0px;margin-bottom:0px"> </p><p style="margin-top:0px;margin-bottom:0px"> </p><p style="margin-top:0px;margin-bottom:0px"></p><div><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:14pt;background-color:rgb(255,255,255)"><div style="margin-top:0px;margin-bottom:0px">Stephen Richard</div><div style="margin-top:0px;margin-bottom:0px">Chief Geoinformatics Section</div><div style="margin-top:0px;margin-bottom:0px">Arizona Geological Survey</div><div style="margin-top:0px;margin-bottom:0px">416 E. Congress #100, Tucson 85745</div><div style="margin-top:0px;margin-bottom:0px"><a>steve.richard@azgs.az.gov</a></div><div style="margin-top:0px;margin-bottom:0px"><a href="tel:520-209-4127" value="+15202094127" target="_blank">520-209-4127</a></div></div></div><div style="color:rgb(33,33,33)"><hr style="width:787px;display:inline-block"><div dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b><span> </span>Esip-discovery <<a>esip-discovery-bounces@lists.esipfed.org</a>> on behalf of Soren Scott via Esip-discovery <<a>esip-discovery@lists.esipfed.org</a>><br><b>Sent:</b><span> </span>Wednesday, May 13, 2015 10:23 AM<br><b>To:</b><span> </span><<a>esip-discovery@lists.esipfed.org</a>><br><b>Subject:</b><span> </span>Re: [Esip-discovery] Notification of next ESIP Discovery Telecon 1:00pm PST / 4:00pm EST today</font><div> </div></div><div><div>Doug and Chris (and Steve),</div><div><br></div><div>It might be useful to clarify the use cases for Swagger, RAML, or any of those RESTful API documentation frameworks and the alignment with OGC and OpenSearch at least. From our scoping round, there’s two main cases - there’s the basic documentation (defining parameters, route elements) and then there’s the promise (in Swagger) of being able to “Try it out” so generating a correctly formatted request from the method document. </div><div><br></div><div>The first is just data entry, really. The second one is where the dependencies in the OGC query parameters *and* their values or the OpenSearch parameters differences between datasets cause problems for any of these frameworks. For example, we’re describing a WMS so we enter WMS for the service and pick a supported version. There’s no place in Swagger to then say if you have selected SERVICE value WMS and VERSION value 1.3.0, the query parameter key is CRS instead of SRS for 1.1.1. Because it doesn’t grok those route or parameter dependencies, the actual generation of a correctly structured URL is back on the dev building the client or the user and not the more generic actionable self-describing services. And where having a solid Swagger and/or RAML OGC extension would be fantastic from a dev point of view. But it’s a modification of the spec and the interface and a conceptual understanding that the Swagger group, as of last fall, felt was an edge case that they wouldn’t support (not their idea of RESTful).</div><div><br></div><div>For OpenSearch, it’s a question of not having a way to access the enumerations for a parameter, ie I can’t get a list of dataset names without running the dataset search and understanding how to parse that - pull the granule links and, hopefully, get a new OSDD back or something. We have some numbers about OS services supporting that second level OSDD access. Nothing about differing parameter requirements, though.</div><div><br></div><div>I hear whispers of broader implementation of Swagger at different repositories but not of anyone handling the depency issues. And I am very much in favor of someone tackling the first case for things like OGC - just having some structured document that could be used to generate the docs for Swagger or RAML or 19119 or whatever would save so much time. But the second case is more what we’re all after. </div><div><br></div><div>My two cents,</div><div>Soren</div></div></div></div></div></blockquote></div><br></div>_______________________________________________<br>Esip-discovery mailing list<br><a>Esip-discovery@lists.esipfed.org</a><br><a href="http://lists.deltaforce.net/mailman/listinfo/esip-discovery" target="_blank">http://lists.deltaforce.net/mailman/listinfo/esip-discovery</a></blockquote></div></div></div></div></div></blockquote></div><br></div><br>
</blockquote></div><br></div></div>