This entry is an attempt to get more structure in my head and get more feedback and insight from others that hopefully leads to a solution worthwhile implementing.
Sean Gillies left a comment(eaten by the moderation filter) on the first entry and more directions in his blog entry.
I read some of the documents on the ORE site and did not find a solution there yet.
The problem
There are a couple of aspects that I need to write down to explain the problem faced when working on a general solution for linking OGC services in news feeds.
OGC Services in practice
OGC services allow clients (users or better, applications) to construct a URL with some variables and get something in return; A map graphic for instance from a Web Map Service. The workflow on such service has been designed so that the client first does a GetCapabilities, parses that document and starts interacting with the service to actually get something done. Drawing a map for instance, identify an object, interrogate a catalog and so on and so forth. I will stick to Web Map Services in this blog and may thus miss the ball when it comes to other OGC services ;)
This is cool and has allowed us to make a big step forward in sharing spatial information through the internet.
GetCapabilities can be used on all OGC services and are thus the natural entry point. But... the capabilities document can become BIG. So big that it has become an obstacle that some applications now, by design have decided to completely skip it. They would directly use for instance the GetMap requests to start interacting with the service. Since it is fairly easy to assume default values in these requests, it actually works in most cases and makes the interaction much quicker and easy to implement.
Drawback: The application may be unaware of interesting or even vital aspects of the service. What if the service offers a temporal dimension? Since it did not request Capabilities it wouldn't know that property existed, or at least it wouldn't know how to use it. Not to speak of the complete failure that will occur when the GetMap URL is different from the GetCapabilities URL, something that is completely valid according the the OGC specification.
Conclusion: A usable compromise has to be found that allows (some) clients to use a GetMap operation directly without the requirement to first request a full Capabilities document, while at the same time that client should be made aware that (a) the URL he found/ was passed to him is a map service and (b) that he is aware of some of the variables he could play with which he can't assume based on only the OGC specification. This means the client should be given some useful hints.
Providing simple links
When a client parses a news feed, be it in Atom or RSSx.x format, it can obtain links from the feed that might be suitable for that client to exploit.
- How will that (OGC aware) client know that for example http://geonetwork3.fao.org/ows/1 is a valid URL that he could exploit?
- If the client would know it deals with an OGC service, how can it know what layer it should use to display?
Providing a full GetCapabilities URL will not solve the previously described problem for clients that skip the capabilities step.
Providing a full GetMap request will require the client to parse every URL for known OGC parameters. This adds extra complexity for clients that work with the Capabilities request, it would exclude clients that prefer to work with POST or SOAP and so on...
The content-type problem
So we could use the content-type attribute of a link. This is something exploited extensively in news feeds and indeed very useful to understand the content of a resource without the need to rely on the resource extension in the first place.
Here's your content-type problem:
- OGC services have only defined an optional content-type for the capabilities document, namely something like application/vnd.ogc.wms_xml and this is not very widely used otherwise (you can only invent the others for WMC, WFS, WCS, CSW and so on).
- Retrieving the content-type of http://geonetwork3.fao.org/ows/1 will not return such content-type (If it could it would be a great asset! I could see web browsers automatically be aware that they deal with a map service and start exploiting it like they do with HTML pages in the first place).
- When I provide a full GetMap URL, I should (rightly so) put the proper content-type of what is returned by the server, namely a PNG, GIF, JPEG image or some other format. But when I find a link with a content-type image/png, my first reaction is not to start interacting with that URL as if I dealt with a Web Map Service.
Conclusion
Good question ;)
Well, at least I could conclude that I want my GeoNetwork catalog to provide your client with just enough information to allow you to interact with the service described in my catalog. Nothing more, nothing less.
So I could decide to tell you hell, the only way you can ever deal with me to know that is to use OGC Catalog Services for the Web. Take it or leave...
I could also tell you here's my list of catalog interfaces, pick what you want. If you want CSW, use it and you can exploit all ISO, FGDC or what other metadata elements have you. If you want Open Archive Initiative access, you also can (but until I found a proper solution to my link problem, you will be unaware of my service offerings!). The same is true for news feeds, be they RSS or Atom, using Object Reuse and Exchange (ORE) or not, the above problem first needs a solution.
What could we use as a solution? Do URI templates provide the answer? Do we have another method to include hints in a link that do not affect the href content!?
My ideal solution?
A link that provides the base URL, a content-type that makes me understand what service type this is and a (set of) hint(s) that tells me I'm dealing with layer X, could use bbox Y as initial bounding box, possibly tell me I best use format Z or give me a time pattern T I could use when dealing with a temporal map service.
Your client can now safely ignore all hints if it uses the GetCapabilities request. It would know, based on the content-type that it deals with an OGC WMS, WFS, WCS (or whatever other service acronyms OGC comes up with). It can also use the hints to immediately operate on a specific layer instead of first having to ask that to the user. (your client could actually build a smart interface that offers some of the options to the user, and the only thing it needed to get started was the news feed output).
Your other client (the one that ignores capabilities) can do with the Hints provided to directly access a specific layer, specific time, bounding box etc... It does not have to ignore interesting properties of the service only because it didn't know about the supported 200000 different projections or 2000 other layers described by the Capabilities document.
So something like this:
<link title="Occurrence of forest"
rel="alternate"
type="application/vnd.ogc.wms_xml"
href="http://geonetwork3.fao.org/ows/14066"
hints="{ogc:layer=occurrence_forest},{ogc:bbox=-180,-90,180,90},{...decide your hints...}"
/>
Obviously there is a need to standardize the names of the hints, but it would seem logical to use the same names as the parameters used in for instance the GetMap request.
