Representing OGC Services in Atom Feeds

2008-03-05T20:28:48Z | Comments: 2

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.

Categories: Web Atom Data Standards

del.icio.us

<< The Fear and Insecurity Industry | Main | Frugosapalooza Wrap Up >>

Comments

Re: Representing OGC Services in Atom Feeds

2008-03-12T17:09:30Z

I have been considering the same problem lately, wishing to expose a synopsis of deeper metadata records in catalogs to commercial search engines. It appears that the GeoRSS/Atom track is the appropriate one, especially with the ability to represent the geo:box or gml:envelope, and the fact that Atom is extensible.

While the majority of our synopsized resources are describing data, some number will also be describing services to access or present the data. In fact, multiple links could be described with the resource. For describing resources in the GEOSS Service Registry, where they exist, entries include fields for a URN to the service type (from ISO or OGC or other), a ServiceInfo field (to link to capabilities or WSDL or narrative), and a ServiceURL (aka the endpoint). The latter two may not always be different but not distinguishing them could lead to breaks in usability. See: http://geossregistries.info .

I agree with the proposal for having a link property or two but would rather generalize the problem to flag 1) that it is a service resource, 2) that it is of a certain type, 3) where service information is located, and 4) the location of the service entrypoint stub. Obviously, this link could be repeated for various flavors of access -- data source, WMS access, WFS access, DVD order.

By: Doug Nebert

Re: Representing OGC Services in Atom Feeds

2008-03-12T20:44:00Z

The ORE-Atom authors suggest using rdf:type elements within an entry to indicate the type of the linked resource. So, if there was a URN for "OGC WMS capabilities request" (and it looks like there is), you might just add <rdf:type>urn:ogc:service:wms:...</rdf:type> to your entry. I don't know if there is a good solution to your #4: it's implicit that link hrefs should be requested using GET, and WxS implementors don't generally have any resource to be fetched at the online resource URL. The capabilities response is the closest thing you have to a service home page.

By: Sean

Comments are closed after 13 days.

Sean Gillies Blog