Technorati is totally busted for doing this kind of analysis. As I wrote on Gorman's blog, almost all of my blog's "authority" comes from automatic linking in the sidebars of several other blogs, blogs which never ever engage mine in any other way. In sum: Technorati's authority is a worthless measure of my blog's interestingness. Look closely at the authority of other blogs and I'm certain you'll see the same pattern.

Update (2008-09-10): It was all for nothing after all, which is good because the last thing we need is more gatekeepers to the blogosphere.

It's great to see others like Vish continuing to write about REST in geospatial (I continue to stalk the term). With a couple exceptions, he's right on. The principles of REST to which he refers are:

• Give every “thing” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly

Do read and recommend Stefan Tilkov's Brief Introduction to REST, from which the tenets above are taken. It's excellent. Vish focuses on the third of these -- standard methods and their use -- and highlights the risks of unsafe GET. Unfortunately he's crossed up the methods a bit. The actual uses of the different standard methods are:

• DELETE: delete a resource
• GET: get a representation of a resource
• POST: submit data to a resource
• PUT: update the state of a resource

There is little lost by thinking of DELETE, GET, and PUT in CRUD terms. One well known use of POST is in resource factories, creating new placemarks or features in a collection, for example:

# Request
POST /features/new HTTP/1.1
Host: gis.example.com
...

[New entity]

# Response
HTTP/1.1 201 Created
Location: http://gis.example.com/features/1
...

Sometimes people refer to this as POST(a) (as in "append"), but POST is more than CRUD's "Create". It can also be used to process data and return it without necessarily creating any new server-side resources. Call this POST(p) (for "process"). Vish is considering POST(p) as a larger volume GET, but that's not quite right because GET requests should be safe and POST requests should be treated as unsafe. Rather than try to switch between GET and POST requests to a single resource (like /features in the example above) depending on the size of the request data, I'd add a new resource to handle POST(p) requests and make it distinct from the ones that are taking POST(a) and GET requests.

Call it a pet peeve, but it's "resource", not "REST endpoint". It's pretty hard to fully grok REST while clutching to the web services endpoint concept.

Update (2008-09-08): I knew Vish had simply transposed entries in his list, and he's fixed up the methods.

I'm going on a trip next month to help my wife with her meetings at Neobiota, scout for next year's sabbatical, and workshop with the Concordia principals. I'd enjoy meeting up with open source GIS, archaeology, or classics programmers along my route:

• 24-25 September: Prague, CZ
• 27-29 September: Colmar, FR
• 01-08 October: Arles and Montpellier, FR
• 12-15 October: London, UK

In other words: Praha, Argentorate, Argentovaria, Lugdunum, Arelate, and Londinium, with a side trip to Aquae Sulis. Looks like I could even bump into Andrew Turner.

I've tuned up the http://gispython.org page; adding links to similar enterprises, highlighting the email list, and exposing project news items. Note that I'm using the Python Package Index's Topic :: Scientific/Engineering :: GIS as the canonical list of open source geospatial software for Python. I hope the update is helpful.

$ easy_install noaadata

Kurt, I have in fact seen mapping integrated with Zotero. Shekhar Krishnan used the GeoNames database to locate items by their place of publication in a demo at THATCamp.

This is better, as I was saying. It's nice to see Python catching on in my home state's GIS department, and also to see ESRI users catching on to the power of more idiomatic Python. It's more than just an open source Avenue, after all.

Speaking of better Python things, yesterday I found out about Tarek Ziade's Atomisator project. It's the kind of framework for feed processing that is entirely lacking in my Mush application. A comment on his entry then led me to TOPP's Melkjug, which has a slick web UI for creating feed filters that is also not to be had from Mush. I think I'll borrow liberally from each, and maybe Mush can provide some geographic processing and filtering inspiration in return.