Multiple Locations in GeoRSS

Sean Gillies

2008-03-18 00:00

Andrew Turner has 2 new GeoRSS proposals: External geometry includes an idea I posted to Geo-Web-REST after reading Benjamin Carlyle's XML Semantic Web proposal, and Multiple locations tries to address entries that have several related locations.

I'm having an immediate negative reaction to the multiple locations proposal. It looks to me like a proposal to extend RSS by embedding items (or entries) within items, something that could have unpredictable consequences for syndication architectures. Instead, I recommend rolling with syndication architecture as it is. Feed entries are cheap: if you need more locations, add more entries. Here's my multiple entry take on Andrew's proposed single entry (omitting the external location):

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  >
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>Cedarburg Trip</title>
    <summary>We went to visit downtown Cedarburg before the
    conference. Had some great sandwiches at Joe's. If you
    haven't been to Cedarburg, Wisconsin, then you haven't
    really experienced the MidWest...</summary>
    <content type="html" src="http://example.org/entries/1"/>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Downtown Cedarburg, Wis.</title>
    <summary>Went to visit downtown Cedarburg...</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>43.296700 -87.98750</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>
    <title>Convention Center</title>
    <georss:where>
      <gml:LineString>
        <gml:posList>43.296700 -87.987500 43.3 -88 -44 -89</gml:posList>
      </gml:LineString>
    </georss:where>
  </entry>
</feed>

(Yes, I used to recommend the GeoRSS "Simple" encoding, but now I use and endorse only the GML encoding.)

Early GeoRSS discussions were not so much about syndicating GIS data as they were about "geo-tagging" feeds and feed entries. Geographic annotation, in other words. There's no need to invent new mechanisms for annotation because syndication architecture already has one: commentary. People (hopefully) will leave comments via this blog post that correct my mistakes, offer different interpretations, ask for clarification, tell me that GML already does all this, or remind me about Manifold's incredible value. I don't think geographic commentary – "by the way, downtown Cedarburg is at (43.296700,-87.98750)", and "furthermore, the Convention Center is demarcated by the line (43.296700,-87.987500,43.3,-88,-44,-89)" – is a different category. If I were in the business of parsing and geocoding locations from documents and syndicating the results, I'd have my code engage the document as if it were a blog post and drop a geo-referenced comment for each location.

There is even a formal document about comment entries: RFC 4685, the Atom Threading Extension. Its in-reply-to element could be used in the feed above (highlighted with a little extra whitespace) to clarify the relationship between content and annotation entries:

<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss"
  xmlns:gml="http://www.opengis.net/gml"
  xmlns:thr="http://purl.org/syndication/thread/1.0"
  >
  <entry>
    <id>urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942</id>
    <link href="http://example.org/entries/1"/>
    <title>Cedarburg Trip</title>
    <summary>We went to visit downtown Cedarburg before the
    conference. Had some great sandwiches at Joe's. If you
    haven't been to Cedarburg, Wisconsin, then you haven't
    really experienced the MidWest...</summary>
    <content type="application/xhtml+xml" src="http://example.org/entries/1"/>
  </entry>
  <entry>
    <id>urn:uuid:53664db3-4598-45d4-a727-022c6203322e</id>
    <link rel="related" href="http://example.org/entries/1"/>

    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />

    <title>Downtown Cedarburg, Wis.</title>
    <summary>Went to visit downtown Cedarburg...</summary>
    <georss:where>
      <gml:Point>
        <gml:pos>43.296700 -87.98750</gml:pos>
      </gml:Point>
    </georss:where>
  </entry>
  <entry>
    <id>urn:uuid:2528d1b4-b5a9-415c-be69-f83974e3e6af</id>
    <link rel="related" href="http://example.org/entries/1"/>

    <thr:in-reply-to
      ref="urn:uuid:7e8ee974-9181-4eae-ad65-55d29175d942"
      type="application/xhtml+xml"
      href="http://www.example.org/entries/1"
      />

    <title>Convention Center</title>
    <georss:where>
      <gml:LineString>
        <gml:posList>43.296700 -87.987500 43.3 -88 -44, -89</gml:posList>
      </gml:LineString>
    </georss:where>
  </entry>
</feed>

RFC 4685's in-reply-to might even be useful outside of Atom.

Multiple locations represented as multiple entries is something that works (even if non-geographically) in our news readers right now. A good enough reader will find the geographic annotations in my examples, even if they are not completely understood, and see that they are related to the first entry.

Comments

Re: Multiple Locations in GeoRSS

Author: Ian Turton

I think that this misses the point of why some (many) of us want to add multiple locations to an entry. The entry is about multiple places but it is only one entry I don't want to insert it into my database 8 times just because it mentions 8 places, I want one item with 8 places referenced.

Re: Multiple Locations in GeoRSS

Author: Sean

What I propose doesn't require anyone to change the way they store data at all. It's about cheap entries and geographic annotation that works with syndication right now.

Re: Multiple Locations in GeoRSS

Author: Gerd Kamp

Sean, Your reasoning would also call for having only one image associated with a feed entry. Being not able to do so properly within RSS2.0 (only one enclosure) led to the Yahoo MediaRSS extension . Multiple locations are an inherent part of a news story, eg when reporting on a car accident happening at place b with the driver coming from a.Or a series of bank robberies in a,b,and c being discussed at a court in d. Or a report on a tour with concerts/stops in a,b,c,d, ... I also first thought, that one location would be sufficient for geocoding our news, until i had a close look at the news on our wires. Putting them into separate feed entries within the same feed is IMHO wrong. Stetting up a separate locations feed (similar to a comments feed) for each geocoded News story sounds more reasonable but having the ability to have multiple locations assigned to a story is the best way. For more information on our geocoding efforts for our agency newswires: http://relations.ka2.de?tag=goingplaces

Re: Multiple Locations in GeoRSS

Author: Sean

Thanks for the feedback. I am not arguing against multiple locations, just proposing a different way to represent them. One enclosure only? That's an RSS 2.0 problem. Multiple locations are an inherent part of a news story? Agreed, absolutely. I propose that one represent a news story in a feed using 1 or more entries: a conventional media entry with an optional summary location, and 0 or more geographic location/annotation/footnote entries with links that relate them back to the main media entry. I disagree completely about the wrongness of this. The draft-snell-atompub-feed-thread memo proposed that mixing post and comment entries in a feed is useful and the IETF approved it (RFC 4685). I'm inclined to go with it, extending the comment concept to geographic annotation or "geo-comments".

Re: Multiple Locations in GeoRSS

Author: Gerd Kamp

Sean, i'm mainly objecting to use in-reply-to only because it is technically working. in-reply-to definitely does not caption the semantics of a set of locations defined by the original author of the entry. The location information is part of the entry, not a comment on it. We can discuss if it's data or metadata of the original entry for sure, but it is definitely not a comment on the entry. How would you in your scheme then distinguish between an original location designated by the author and a comment on the original entry commenting on the designated locations? Hence i still favor either an in entry solution as proposed or a separate feed linked to from the entry. There are arguments for both solutions but i'm in favor of the first.

Re: Multiple Locations in GeoRSS

Author: Andrew Turner

Another simple, but very pertinent use-case is when geoparsing non-geo-encoded entries. Say when converting RSS-to-GeoRSS. Splitting these into multiple entries breaks the original entries up, and links and ID's no longer make sense.

Re: Multiple Locations in GeoRSS

Author: Sean

Andrew: why would it necessarily break up the original entry? My thought is that a parser would *comment* on the original entry, producing new related entries, and leave the original entry alone.

Re: Multiple Locations in GeoRSS

Author: Sean

Gerd, I've adapted your soccer match example from "going places" to use in this discussion. See the update at the top of this page. It's interesting that both feeds make it through Google Maps with 3 locations, but only because the GMaps parser looks for any geometry regardless. Only in my multi-entry feed do the relationships survive, and that's due to the "related" link. How to distinguish between media and annotation entries? Categories or tags. I'm not sure it's even necessary in most cases. Granted, I'm taking a very broad view of comments. I should write the Atom list to find out if my idea is certifiably sane or not. At the very least, it doesn't invent any new syntax, which is a big plus.