Representing OGC Services in Atom Feeds

After reading Jeroen's latest post I have a better understanding of what he's trying to accomplish. I too have a use case for representing OGC services in feeds. I'm a critic of the OGC service architecture but can't deny that they are being used and referenced in academic studies, and that there is therefore a need to model and represent them in an ORE resource map feed. I'm going to propose a way to do that and then work back toward Jeroen's use case.

Consider this feed, an ORE-like aggregation that Tom is using to demonstrate how we can form a federation of digital classics projects using a syndication architecture:

http://homepages.nyu.edu/%7Ete20/examples/nearby/cyrene.atom

How does one represent an OGC web map service (WMS) in this feed? As an entry:

<feed>
  ...

  <entry>
    <title>Cyrene WMS</title>
    <id>urn:uuid:56b8421c-5150-458d-ac92-ee9e698593b5</id>
    ...
    <link rel="alternate" href="???"/>
  </entry>

</feed>

What's the link href to be? My interpretation of the alternate link relation is that it should be the URI to the closest thing a WMS has to a "home page". Ideally that would be its capabilities document. (Aside: making an OWS capabilities document a plain old web resource instead of an RPC call would greatly improve the OGC service discovery story. I'm not the first to make this suggestion.)

The entry then becomes something like:

<entry>
  <title>Cyrene WMS</title>
  <id>urn:uuid:56b8421c-5150-458d-ac92-ee9e698593b5</id>
  ...
  <link
    rel="alternate"
    href="http://example.com/?service=WMS&request=GetCapabilities..."
    type="application/vnd.ogc.wms_xml"
    />
</entry>

It would also be very useful to aggregate into an ORE resource map specific images from a WMS, particularly if they are used as illustrations in publication:

<entry>
  <title>Figure 8: Cyrene Overview</title>
  <id>urn:uuid:408cdb6c-185d-4c45-862b-2809158e0c4f</id>
  ...
  <link
    rel="alternate"
    href="http://example.com/?service=WMS&request=GetMap&format=image/png&bbox=..."
    type="image/png"
    />
</entry>

There's less need for extra metadata in this case: specifying image/png says it all. It's implicit that clients will address the link href with a GET request, and that you can get a map image directly like this is one of the redeeming features of WMS.

So, that's how I see OGC services represented in an ORE-like feed. Jeroen's use case is different: he'd like to use a feed as a lite capabilities document. I'm not sure this is a great idea. Bypassing the service capabilities seems a bit dangerous. If it's only that capabilities documents are too big (and I've run into some that are 4 megabytes, which is ridiculous), providers should be encouraged to break these down into smaller collections of logically related feature types, coverages, and layers. Still too big? Take advantage of HTTP's built-in caching mechanisms. Provide ETags and Last-Modified times to help clients limit fetches and parsing. Implement caching proxies.

If you still need to represent GetMap (or other functions) in a feed, there are some possibilities, and some limitations. URI templates don't belong in atom:link. Instead, Joe Gregorio has proposed a link_template element. It's not official by any means, but in combination with a new relation (allowed by Atom), it could let you make an entry like so:

<entry>
  <title>GetMap Endpoint</title>
  <id>urn:uuid:09e7a48a-428a-4418-aef4-ea157806d9db</id>
  ...
  <t:link_template
    rel="http://opengis.net/relations/getmap-endpoint"
    href="http://example.com/?service=WMS&request=GetMap&format={format}&bbox={bbox}"
    />
</entry>

I think that a custom link relation could be the hint Jeroen is looking for. The OGC's content type problem still needs to be fixed.