They Tell Stories

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.

Comments

Re: They Tell Stories

Author: Matt Priour

Google's LatLong Blog caught this and Andrew Turner suggested the "Choose Your Own Adventure" model would be an improvement over an already very intreguing idea. Personally, I was impressed at how the map interactions really added a great deal of anticipation, sense of urgency, and understanding of space & effort. The story itself without the map would be rather forgetable, however with it the story becomes alive and worth another read or two.

GeoRSS 2.0?

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.

THATCamp

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.

Comments

Re: THATCamp

Author: Dave Lester

Hey Sean, Glad you had a good time! You may also want to add Rob MacDougall's THATCamp post to your list as well (http://www.robmacdougall.org/index.php/2008/05/thatcamp/) See you in IRC. Dave

Re: THATCamp

Author: Jeanne

Sean, I have two THATCamp posts so far - with a couple more in the works (at least one of which will be about the GIS/Maps session). http://www.spellboundblog.com/category/thatcamp2008/ Thanks! Jeanne

The GeoWeb That Might Have Been

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.)

Comments

What about REST?

Author: Kirk

Hey Sean - Just glancing through the paper, I wonder if REST could be used to do some of this. I've been reading RESTful Web Services ... http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260 and really like how the authors have chosen to use Geography as a hypothetical case. Based on their examples, it seems like REST could move us in the direction discussed in the paper. I guess we would need some sort of standards for geographic URLs? Is anyone working on this? Kirk

Re: The GeoWeb That Might Have Been

Author: Sean

Kirk, I apologize for not clearly tagging my post as ironic. I actually think we're on the right track now.

Re: The GeoWeb That Might Have Been

Author: Kirk

Ahh, I should've realized the irony. Still, I wonder if there are any efforts underway to standardize URLs to make geographic resources more discoverable. Congrats on the grant!

The Wings of Spring

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

http://sgillies.net/images/vultures.jpg

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

Comments

Re: The Wings of Spring

Author: steven Citron-Pousty

They started staying year round in CT about 6 years ago and then we started getting black vultures - thanks global warming. Hope you don't live too close, that must be quite the smell...

Re: The Wings of Spring

Author: Sean

The stink plume isn't as bad as you'd think, and doesn't quite reach our yard.

Re: The Wings of Spring

Author: Matt Priour

We have an odd phenomenon in Texas where in the praries both species occur year-round. However, in the more heavily wooded South Texas Brushland, Hill Country, & East Texas Forest, the Turkey Vultures are seasonal. In other parts of the state, the Turkey Vultures can also be opportunistic migrators with at least some members of the population remaining year-round. I have yet to really figure out the why of it all. My best guess is the expansion & mixing of once distinct population groups combined with the appearant increased ability of both species to find food in open prarie areas.

Rtree 0.4.1

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.

ESRI, Developers, REST

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.

Comments

Re: ESRI, Developers, REST

Author: Jason Birch

I don't disagree with you. MapGuide is planning to expose some of its MapAgent API RESTfully with the next release, but our current planning document is a bit wrong (in some important ways, like confusing post and put in a couple places) and in need of work I haven't made time to put into it. Also, there is some argument on how to implement filters. The current RPC-based MapAgent does support non-geo JSON responses (as of 2.0). I don't think that MapGuide will be able to directly support full GeoJSON for feature retrieval because if its insistance on a "one geometry column, called geometry" standard. Haris' original ideas: http://www.sl-king.com/mgrest/ Bob's original ideas: http://trac.osgeo.org/mapguide/wiki/Future/RESTfulWebServices JSON output RFC: http://trac.osgeo.org/mapguide/wiki/MapGuideRfc25

Multiple Locations in GeoRSS

Update (2008-03-31)

A related post.

Update (2008-03-18)

I've created 2 mock feeds, one using Andrew's multiple location proposal: http://sgillies.net/files/multi-location.atom, and one using multiple entries: http://sgillies.net/files/multi-entry.atom. Add each to your reader of choice. I believe the second, with 3 entries, comes through geographically "dumb" readers in much better shape. In other words: it degrades gracefully. There is more discussion of this in the comments.

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.