Charles Cumming's The 21 Steps supports my thesis that not only is one location not enough to tell a story, one narrative or analytical chunk is not enough to tell a story. Entries and placemarks are cheap: break that story up and serialize it.

Via O'Reilly Radar.

I saw several references to "GeoRSS 2.0" recently by people who are attending the OGC TC meeting in St. Louis. Here's my 2 cents on 2.0:

• Deprecate the simple geometry encoding and just go with GML in a georss:where element already. Yes, this is a complete about face from my position in 2006. Nevermind XML Schema, I'm just saying that the GML encoding is more expressive, more clearly defined, and not significantly more difficult to produce or parse. I've even contributed a GML parsing patch for the Universal Feed Parser. If I can do it, how hard can it be?

• Specify cardinality: an entry should have 0 or 1 geometry (see following comments about multiple locations).

• According to the 1.0 spec: "GeoRSS geometry is meant to represent a real feature of the Earth's surface". Why not above the surface, or below? Do you really think that's going to stop Satan from using GeoRSS to geo-tag news from the hellish center of the Earth? I think this language can go in 2.0 and take elev, floor, and radius along with it. We're all better off using 3D coordinate reference systems, and the quick adoption of KML shows that a third dimension isn't a serious stumbling block.

• In the next paragraph, it is written: "GeoRSS is a way of relating Web content to Earth features". That statement is more dense and chewy that it seems. To me, it seems like specifying nothing more than how to add location to entries is a worthy enough effort. The relationship of entries to the real world is really more of a semantic web concern.

• The semantics of featuretype tag and relationship tag better belong to entry entities than to location entities. The fact that they are not significantly used is, in my opinion, tacit acknowledgement of the truth of that statement. Atom and RSS already allow you to categorize entries and items, which makes featuretype tags unnecessary. Atom also provides a mechanism to relate entries to other entities on the Web: links obviate the need for relationship tags.

• Multiple locations I have already blogged. Entries are cheap.

• The 1.0 spec only considers literal geometries. Referencing external geometries is something else that's being considered for a future version. I'm -0 on the first option (inspired by http://rest.blueoxen.net/cgi-bin/wiki.pl?XMLSemanticWeb) and -1 on the second (inspired by http://tools.ietf.org/html/rfc4287#section-4.1.3.2). I now prefer an approach that first came up on the GeoRSS list here, and which Tom Elliot and I had also been discussing that fall: using Atom links and custom relations. The equivalent of that first option could instead be something like:

<entry>
  ...
  <link
    rel="http://www.georss.org/relations/is-colocated-with"
    href="http://pleiades.stoa.org/places/639166.atom"
    type="application/atom+xml;type=entry"
    />
</entry>

Update (2008-03-28): Notes on my adventures in this direction are at http://atlantides.org/trac/concordia/wiki/AtomLocationByReference.

If you push more semantics from the location up into the entry, using Atom and its extensions, the ground that GeoRSS has to cover shrinks, a good thing for any specification. But what about RSS 1.0 and 2.0? The former can draw on RDF, of course. Maybe the latter needs links from SSE.

Dear Jeremy, Dave, Tom, Dan, and the CHNM crew, thank you for having me out for the inaugural THATCamp! I met 50 of the most thoughtful and computer-savvy people in the humanities, many of whom have digital projects that intersect with Pleiades or its technology choices in interesting ways, and all of whom had knowledge and experience to share. Digital humanities newbie me, I tried to soak up as much as I could, and kicked off a useful session on neo-geography featuring great stuff from Mikel Maron (Mapufacture), Josh Greenberg (New York Public Library), and Shekhar Krishnan (MIT).

Here are a few blog posts from other attendees:

Dan Cohen: 1.

Mills Kelly: 1, 2, 3.

Lisa Spiro: 1.

Karin Dalziel: 1.

I'll point to more as I find them.

Tom and I get to continue the kind of academic research that James Fee so loves.

Searching for "geoweb architecture" turns up some interesting stuff, like this "GeoWeb" "based on a hierarchy of servers whose domain names represent geographic areas":

What is needed instead is a coordinated global infrastructure with participating organizations from around the world. We call this open standards-based infrastructure the GeoWeb, which could be realized as a new top-level domain (e.g., .geo) that would enable anybody to publish and search for all metadata referring to a given area (Leclerc et al., 2001a; Leclerc et al., 2001b; Leclerc et al., 2000). The infrastructure is based on a hierarchy of servers whose domain names represent geographic areas. An example hierarchy, described below, is nominally of the form minutes.degrees.tendegrees.geo. (For convenience, we use ".geo" as the top-level domain name in all of our examples of the GeoWeb hierarchy, although existing top-level domains could be used such as ".dotgeo.net".)

Hierarchy. Metadata. Order. What might have been. Instead, we've been colonized by Google, and are made to publish geographic resources directly on the lame old WWW using HTTP, KML, GeoRSS feeds, and a bewildering range of software, with hypertext links to other such resources whereby they are found and indexed.

(Note: this post is rated I for ironic language.)

Look on the bright side, Alamosans: you may be puking your guts out, perhaps hospitalized, and can't drink your municipal water for a couple weeks yet, but at least it wasn't bio-terruh!

Nevermind the Swallows of Capistrano: the surest sign of spring is when the Turkey Vultures return to 920 West Mountain Avenue in Fort Collins.

The first arrived yesterday, and today there are 3. Soon there will be 50 or more roosting in that tree.

It is important to upgrade from Rtree 0.4 to 0.4.1 if you're using it within long-running Python processes. No upgrade from spatiaindex 1.3.0 is necessary.

Sounds like this REST stuff just might catch on. Resource oriented architecture, state transfer, entity tags ... ESRI is putting the Web back in "GeoWeb". Congratulations to Jeremy Bartley, Keyur Shah, and their team. Meanwhile, here in FOSS4G land, it's a different story. Christopher Schmidt and I have proof-of-concept (or better in the case of FeatureServer) RESTful services, but otherwise it's still all W*S, all the time.

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.