Lorcan Dempsey is thinking about URIs, with some good links. Among other things, he points at this tidbit from Richardson and Ruby:

a resource and its URI ought to have an intuitive correspondence

Sean's been a positive influence in this area for Pleiades. Here's what we're doing:

Places

We surface information about our place records under the intuitive URL fragment http://pleiades.stoa.org/places. We elaborate URLs below that level using various intuitive labels for thematic, non-hierarchical groupings of records, as well as the unique identifiers for specific place records. So, for example you get:

• places by time periods, e.g.: http://pleiades.stoa.org/places/archaic
• places by type, e.g.: http://pleiades.stoa.org/places/temple
• individual place records (by their unique numeric ids), e.g.: http://pleiades.stoa.org/places/638924/

Geographic Names

Names are trickier. We'd like to provide users with an intuitive lookup of names like http://pleiades.stoa.org/names/apollonia, but that's problematic because names (whether geographic or personal) are non-unique proxies for identifiers (see recent excellent postings from Karen Coyle and Stuart Weibel). For example, when conversion of our legacy dataset is complete, we'll have 17 places with the name Apollonia.

Our names interface at http://pleiades.stoa.org/names/ points users first to our search form. Individual name records are surfaced there too, using ASCII (sic) transliterations of the name strings (our model aims at one record per unique attested variant in original language and script). Duplicates are presently handled by postfixing a hypen plus a one-up numeral (e.g., http://pleiades.stoa.org/names/apollonia-1). I should point out here that right now we lack backlinks from the name records to the associated place records; that's an urgent to-do. At the main names page, we do have a link to a complete list, which will get unmanageably huge; we'll probably need to add alphabetic and/or max-per-page chunking of that list soon. But I digress ...

URL-wise I'm thinking we could do more to help our users get at the name records. Perhaps we should take a page from Wikipedia and implement name disambiguation pages. Under such a scheme, a URL like http://pleiades.stoa.org/names/apollonia would take a user either to the one-and-only record appropriate record or to a disambiguation page containing links to all the relevant records.

These disambiguation pages would have to surface enough additional information from the records themselves (including their associated places and locations) to facilitate selection of the desired name record. Here we'd want to echo long-standing practice in print works for classical geography. When name ambiguity is a problem, add a regional qualifier (something like "Antioch in Pisidia" or "Pisidian Antoich"). Would that look something like http://pleiades.stoa.org/names/antioch-in-pisidia? When we implement place-to-place relationship tagging, maybe we can leverage that information for this purpose. It probably won't be foolproof for certain edge cases though: some unlocated places with common names may require an alternative or more verbose mechanism for disambiguation.

Locations

The right kind of intuitive access to locations (i.e., feature geometry and coordinates) is a geographic one. I'll table that for a separate future post.

Bibliographic Records

URLs for our bibliographic records are constructed on the basis of human-friendly short titles. For most modern works, these are either abbreviations or author-year combinations. For ancient literary works we follow conventional humanist practices for author and work short titles. For example:

Now, I don't really know a thing about this sort of thing, but this aspect of the Huntsville Fallout Shelter Plan (most recently covered by the Associated Press) seems like a recipe for trouble:

Unlike the fallout shelters set up during the Cold War, the new ones will not be stocked with water, food or other supplies. For survivors of a nuclear attack, it would be strictly "BYOE" — bring your own everything. Just throw down a sleeping bag on the courthouse floor — or move some of the rocks on the mine floor — and make yourself at home.

"We do not guarantee them comfort, just protection," said [Kirk] Paradise, who is coordinating the shelter plans for the local emergency management agency.

Hmmmm .... 20,000 people in Three Caves with no cots, water, food, diapers or formula above and beyond what they snatched and grabbed on the way in.

And that's not even a comment about the overall goodness of the plan.

In a future random post, I may explore just how accessible Three Caves would be for a freaked-out crowd of 20,000 North Alabamians.

All the usual IANABOHSE caveats apply.

Sebastian Heath is in the house!

Since this blog has emerged (by virtue of its title's obscurity) as the top Google result for "horothesia", I'm surely obligated to explain the word!

I'm bummed that I'll be missing the Workshop on Volunteered Geographic Information this December in Santa Barbara. VGI is at the core of the Pleiades vision.

Mike Goodchild has recently posted a paper on the workshop site entitled "Citizens as Sensors: The World of Volunteered Geography" [pdf; 1.1MB]. In the 15-page treatment, G. provides background and context; overviews a number of recent trends, key services and sites and glosses various enabling technologies.

He also introduces or glosses several underlying issues and concepts, no doubt in part laying out tracks and themes for the workshop:

• Spatial data infrastructure patchworks (rather than comprehensive mapping strategies)
• Humans as sensors
  
• Citizen science
  
• Participant populations (the who-may-volunteer vs. quality axis)
  
• Early warning (e.g., of the magnitude of natural disasters)
• Motivating factors for participants
• Authority and assertion
  
• The digital divide

G. concludes with the following reflection:

VGI has the potential to be a significant source of geographers’ understanding of the surface of the Earth. It can be timely ... it is far cheaper than any alternative, and its products are almost invariably available to all ...

It is already clear in many fields that such informal sources as blogs and VGI can act as very useful sources of military and commercial intelligence. The tools already exist to scan Web text searching for references to geographic places, and to geocode the results. Thus the most important value of VGI may lie in what it can tell about local activities in various geographic locations that go unnoticed by the world’s media, and about life at a local level. It is in that area that VGI may offer the most interesting, lasting, and compelling value to geographers.

Am I asleep, or shouldn't I have heard about this first from the Huntsville Times (links mine):

Huntsville will outfit an abandoned mine capable of holding 20,000 people. Other residents will be housed in college dorms, churches, libraries and research halls. City planners hope they can develop enough shelter space to house 300,000 people; enough space to provide every person in Huntsville and the surrounding county a safe refuge.

Maybe Lee can find out what it's all about.

Shawn is trying out the Pleiades Atom+GeoRSS feeds in Yahoo Pipes, and is also thinking about geoparsing locational data from regular bibliography.

Seems to me it would be fun to throw something like Sean Gillies' Mush into the mix to get spatial correlations between the Pleiades gazetteer (if I can call it that in this context) and Shawn's geo-bib.

Then, if we could apply some version of the combined process to, say, the new acquisitions list of the Burnam Classics Library in Cincinnati, we'd have some nifty pre-processing that could speed identification of new works to cite in the Pleiades bibliography.

Technorati spiders, behold: Technorati Profile

Over at classics-l they're asking:

When is it ok to be incompetent?

Shawn Graham has tried pumping Pleiades data through Yahoo Pipes. That's exactly the sort of thing we want people to be able to do. In looking at his post, however, it's clear that we could be doing a better job of revealing our data interfaces to users. We've got a big rev coming up in October (we're moving to Plone 3), and we'll address this UI issue then. Meanwhile, maybe this post will help.

Shawn wanted to grab a feed and map its content. He did the obvious thing and navigated to our places section. Then he chose one of our pre-packaged subgroups: archaic places. Then he looked for a feed. Out of the box, Plone gives us a <link rel="alternate"> as well as an "RSS" button on the interface. Transiting the corresponding URL gets you an RSS feed listing titles, descriptions and other Dublin Core metadata for whatever Plone content is surfaced at that location.

As Shawn observed, pumping that list of ancient names through a presentist geocoder (like Yahoo!'s) gives you suboptimal results.

Pleiades in fact stores locations for every feature (at least when we can determine their locations). In our customization work on Plone for Pleiades, we've tacked on a couple of other interfaces that aren't as obvious to users as they should be. Anywhere Pleiades displays or lists spatial content, we also provide an Atom feed that's extended with GeoRSS tags, as well as a KML feed.

So, for those archaic places, Shawn could choose to use either of:

• http://pleiades.stoa.org/places/archaic/atom
• http://pleiades.stoa.org/places/archaic/kml

Both provide the coordinates, and therefore get you around the geocoding problem.

Pleiades needs to add <link rel="alternative"> tags for both our Atom and KML serializations, as well as clear UI hooks everywhere the feeds are surfaced. We do the latter in some places already, just not everywhere. See, for example:

• http://pleiades.stoa.org/places/373732/
  

Shawn: thanks so much for taking a hack at this! It's great to know that folks out there are interested in our data, and interested in using it in some of the same ways we've been thinking about. We'll try to meet you closer to half-way next time.