<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>So Steve, </div><div><br></div><div>If we’re going for the URN approach, could we consider recommending a best practice for integrating those in the Dataset <a href="http://schema.org">schema.org</a> somehow? In this brave new world of harvesters and brokers, we will still likely miss this kind of service identification if it’s included only in XML/JSON representations. And, if we want to encourage polite crawling, having that reference on the link tags would make filtering much easier. No idea what that would mean for something like the embedded HTML info of the ATOM responses from ESRI (or other) platforms, but today I am an idealist so let’s not limit the URNs to ISO OnlineResources. </div><div><br></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>Sorry I missed the call yesterday--interesting topic.   It sounds like the idea is a scheme to facilitate web crawlers to discover service endpoints and be able to infer something about the kind of service?</div><div>If so, maybe something like the 'Home' document would make sense (<a href="https://tools.ietf.org/html/draft-nottingham-json-home-03">https://tools.ietf.org/html/draft-nottingham-json-home-03</a>, expired internet draft) is in order. </div><div>In the list Ruth compiled, several of the services already have self-description documents (OpenSearch, OGC services, OAI-PMH) and a couple are self-description document formats (OpenSearch description, WSDL, WADL).  </div><div>Maybe the critical thing here is a registry of strings to use that identify a particular service type/version and any relevant profiles. There's an OSGEO group that's made a start at this, perhaps we can build on that? </div><div><a href="https://github.com/OSGeo/Cat-Interop">https://github.com/OSGeo/Cat-Interop</a></div><div><br></div><div><br></div></blockquote>Just a note, I’ve been putting together notes for our own OpenSearch harvesting needs. I started with Doug’s list as “good” EO services and noted that two of the set are now down or not publicly reachable (apologies if this is in the Google Drive version already): CCMEO (access forbidden) and ORNL (404). The guess work is around URL encoding support (or not), Accept headers support (or not or in certain circumstances), and whether a service would return an error for an empty searchTerms request at the catalog level. I will note that the includsion of a link with rel=“search” at the root of the dataset-level response is not always present or a reference to the parent catalog search.<div><br></div><div>Is anyone working on some OpenSearch to Swagger Doc generator?</div><div><br></div><div>Soren</div><div><br></div><div>————————————————————</div><div>Soren Scott</div><div>Science Developer</div><div>National Snow & Ice Data Center</div><div>Boulder, CO<br><div><br></div><div><br></div></div></body></html>