Well, I'll be a monkey's uncle (via Peter Batty):

Clemens gave an excellent and very frank talk on "The gap between SDIs and the GeoWeb". A couple of quotes that I noted were "So far the impact of SDIs on the integration of data as a ubiquitous component of the web seems low" and "There is not evidence that SDIs have increased the market volume of government data by a significant amount". He noted that OGC web services are based largely on an architecture and approach to web services developed around 10 years ago, well before many recent web innovations.

The WxS specifications began coming out 10 years ago, but the OGC's approach certainly predates the web.

At the 2007 FOSS4G conference, Charlie Savage (not, I think, intentionally invoking Ziggy Stardust) gave the OGC's WxS architecture 5 years. It seemed ridiculous then to say even what now appears, coming from Clemens, to be conventional wisdom. What will 3 more years bring?

What do the people pushing "GeoWeb" at Google, a company founded on links, think about geographic data and web architecture? It's not so clear. I've been waiting for a post like this from Mano Marks:

Is that the nature of geographic data? Or have we just not found the true linkability of it? I tend to think it's the former. Geographic data is heirarchical, it is ontological, it is content rich, it is combinable. It is linkable through common ontologies. But geographic data doesn't lend itself to easy linking in the same way. It's the nature of structured data, it must relate to a structure. Ontologies are almost the antithesis of linkablity outside the domain.

I think he's overlooking another form of linking in KML: the combination of "network links" and "regions". In practice, KML applications use this to implement pyramids of increasing resolution for data from a single domain, but one should be able to network link in the same way to KML applications from other domains that best serve a particular view. It might even be feasible to implement an agent that would crawl network links. Some changes to the network link to make it more like other web links would probably help. Linked geographic data [1] could be right here under our noses, in KML, already.

[1] Yes, I know I'm abusing the linked data brand.

This little place is a gem, and its immediate environs the most pleasant spot we've found in Montpellier. According to the Routard, it was cleared to make way for a new church in the early 17th century. When that project was abandoned, the grounds became public.

It appears as a little green patch in OpenStreetMap and from the Googlesat. The Google has a decent street view too, but tonight it looked like this:

Update (2009-08-01): I don't know my way around OSM very well, and just now stumbled onto another representation of Place de la Canourgue at http://api.openstreetmap.org/browse/way/8105279. This one has links to its nodes and connected ways. Are these "browse" URLs as cool as they look like they could be?

I'd sure like to see this:

Herodotos Encoded Space-Text-Imaging Archive

Elton Barker (Oxford) & Leif Isaksen (Southampton)

Digital Classicist/ICS Work in Progress Seminar, Summer 2009

Friday 31st July at 16:30, in room STB3/6, Senate House, Malet Street, London WC1E 7HU

HESTIA (the Herodotus Encoded Space-Text-Imaging Archive) is an interdisciplinary project, involving the collaboration of two classical scholars, a modern political geographer and an IT consultant, that aims to enrich contemporary discussions of space by developing an innovative methodology to the analysis of Herodotus’ History. Combining a variety of different methods, it investigates the ways in which space is represented in Herodotus’ History in terms of places mentioned and geographic features described, and develops visual tools to capture the ‘deep’ topological structures of the text, extending beyond the usual two-dimensional Cartesian maps of the ancient world.

There are three reasons to syndicate geographic resources:

• To allow users or other agents to track updates or edits

• To make synchronization with other systems cheap and easy

• To generate a sitemap for search engine optimization

The third is a special case of the second. In all cases, GeoRSS permits some simple spatial analysis, filtering, and indexing of the entries in your feed. The basic recipe for syndicating geographic resources using GeoRSS follows:

• Implement just one feed for changes and one more for deep sync and site-mapping. The different versions of RSS are interchangeable enough. Pick one format and go with it.

• Choose Atom. There's a well designed payload element that can easily carry any media, a link relation registry, and a matching publishing protocol (used in Google Data APIs, including the Maps Data API). It's better.

• Pick one GeoRSS flavor. Simple or GML. I prefer the "where" semantics of the latter. I wouldn't put a "time" element in any entry without specifying what time it was (created? modified?) and so I feel uncomfortable when I put an ambiguous "point" element in an entry. Granted, there aren't any location semantics other than "where" currently in use, but it feels risky (to me) to have such latent ambiguity.

• Use zero or one location or "where" element per entry. Don't duplicate locations within an entry using different GeoRSS flavors. Your entry's content may have a geographically rich context, but that's to be described within the content using KML, GML, or whatever. GeoRSS specifies the location of the entry within feed space, and it should be as simplified a location as can be.

There's no consensus on how the concept of cartographic scale is to be applied in the context of a feed. If your feed has a global scope, you should probably use small scale representations of locations. If your feed is local, or hyper-local, scale up accordingly. Perhaps it would be helpful if GeoRSS feeds specified their spatial scale. Not in the form of a ratio as we do for paper maps, and not in the form of "zoom levels", but a form that's useful to internet engineers. Numerical precision? Surely, someone has their spatial thinking cap on and has already figured this out. I'd appreciate being clued in.

Do GIS paradigms and processes scale infinitely inward and outward? I like geeking out on geography as much as the next, but this raised my eyebrows (emphasis mine):

spatial@ucsb seeks to position spatial concepts as the driving force for spatial thinking and for the selection and use of spatial tools. We are initiating the collection with eight concepts that are the focus of spatial reasoning in the use of geographical information. These concepts are demonstrable at all levels of space and time (from sub-atomic to galactic, past through future, and microseconds to ions). They can be rendered understandable through simple illustrations to young children but they are also sufficiently engaging at advanced levels for thinking about scientific and social problems.

All levels of space and time? The so-called "first law of geography" explains only classical phenomena. At small scales its applicability vanishes, and you need quantum physics to explain phenomena like atomic spectra, scattering, and tunneling. Even at the relatively large scale of cells and ice crystals, chemical and physical processes dominate, which makes me skeptical about the application of GIS to the nanoscale (emphasis mine):

When spimelike devices are built at very small geographies, capable of sensing and even manipulating objects at exceptionally fine scales, they become useful for nanoengineering. In recent years, there has been a massive fueling of interest in nanoscale science and development of motors, actuators, and manipulators at nanoscales. With these developments have come a veritable land grab and gold rush for scientific inquiry at hitherto relatively underexplored scales: within the earth, within the body, within objects, within anything to be found between 1 and 100 nanometers. Geographers missed out on the last bonanza at fine scales and were mostly absent from teams tasked with mapping the genome. The cartography required to visually map the genome is trivial and the processes that govern genomic patterns are completely alien to most geographers' skill sets, so their exclusion from these endeavors is understandable. The science and engineering surrounding nanotechnology differ from this situation, however, in that they are primarily concerned with spatiotemporal patterns and processes and the scaling of systems to new dimensions. These areas of inquiry are part of the geographer's craft and fall firmly within the domain of geographic information technologies. Process models with spatial sensing and semantic intelligence could play a vital role in future nanoscale exploration and engineering

The usefulness of spatial thinking fades at larger scales, too: it tells you nothing, for example, about the redshift of distant objects, you must use general relativity. It fails to explain some important phenomena at even modestly large scales, such as the planetary-scale waves that shape the Earth's climate system.

Geography isn't (in my probably biased opinion) a predictive science like physics. It's more like non-experimental branches of sociology or psychology -- relying on and often contributing to advances in fundamental fields, but powerful only in explaining bulk or ensemble features of the world. I should put scare quotes around the word 'only' in the previous sentence, because that's no small thing. Physics alone can't explain the way of the world at scales of human life, so geography will always be an important field, but a return to temperance in its rhetoric might be in order.

Gustavo Niemeyer wonders about collections, queries, and REST:

Now, we want to implement a feature which allows people to access the list of all recent editions of books in their home library, given that they know the URIs for the books because a client program stored the URIs locally in their machines. How would we go about implementing this? We certainly wouldn’t want to do 200 queries to learn about updates for 200 books which a given person has, since that’s unnecessarily heavy on the client computer, on the network, and on the server. It’s also hard to encode the resource scope (as defined in the book) in the URI, since the amount of data to define the scope (the 200 books in our case) can be arbitrarily large. This actually feels like perfectly fit for an RPC: “Hey, server, here are 200 URIs in my envelope.. let me know what are the updated books and their URIs.” I can imagine some workarounds for this, like saving a temporary list of books with PUT, and then doing the query on that temporary list’s URI, but this feels like a considerably more complex design just for the sake of purity.

The sake of purity? Who are these dreaded purity police, anyhow? And how exactly does someone make a "pure" use of the "Whoopee Cushion of Internet protocols"?

This library application already has one collection, the global one, and presumably exposes a number of useful web resources around it: search forms and feeds of several flavors (changesets and archives). The solution, IMO, is not the temporary query resources Gustavo imagines, but smart, permanent user collection resources. Without these, users have no way to share the collections with others or compare their collections to others, and no way to access their collections when away from their desktop library app. Take a look at LibraryThing, Zotero, or OpenLibrary: each have user collections, of books or articles in the first two cases, and changes to book records in the third. User collections, the states of which are stored on a server, are a must-have feature of any application in this class.

Create a new resource for each user collection that exposes a list of the most recent editions of each book, along with links to the new and currently held editions, formatted using Atom so that you can track updates in a feed reader, and you're all set. Using RPC here seems an attempt to route around a problem that doesn't exist, or worse: routing around a must-have feature.

I took our highly energetic older daughter on an expedition to find the Gallo-Roman site of Ambrussum yesterday. It's easy to find coming from Montpellier: exit the A9 at Lunel, pay € 1.30, follow the D34 direction Lunel (South) and take a left on D 110 direction Villetelle. Not shown in Google's streets is that you can bear right and continue parallel to the A9, then turn right again at the next intersection (no explicit sign to Ambrussum) amid vines. Continue past the museum under construction and adjacent excavation to parking at Le Pont. [map]

There's shade for picnicking at the Pont. Constructed around 30 BC, it was used up until the 14th century, then partially dismantled and wrecked by flood waters.

A long-gone embankment (my interpretation) connected this bridge to the nearby section of the Via Domitia.

That's limestone, not the hardest rock in the world, but still those ruts attest to the traffic on this road (view from above here). Uphill are found the remains of fortifications, buildings, a public edifice, and (best of all, in my daughter's opinion) a large patch of wild blackberries.

Taking the same frontage road back to the D34 and A9 entrance, you'll pass a backdoor to an autoroute rest stop ("aire" en français). A stop there to slip through and get ice cream bars from the gas station boutique is highly recommended.

That didn't take long: http://giscloud.appspot.com/.

We had an idyllic overnight flight from Denver, long slog through the mirror-world disasters of LHR (nice new terminal, but no jetways or gates, lots of hiking) and CDG (plenty of jetways and gates, dangerously decrepit terminal), and a with only 2 rough bedtimes are comfortably established in Montpellier. My wife, Ruth, has a sabbatical from CSU, a Fulbright, and an appointment at INRA (French equivalent of the USDA, more or less). I'm telecommuting to ISAW. This is our home for the next year.

It's an interesting city. We're in the quartier Les Cévennes which rather reminds me of some Albuquerque neighborhoods: dusty and somewhat scruffy, renting from a pair of teachers who are off on an exchange to Morocco. There's a fine bakery and a good pizzeria down the street, we hear the neighborhood école is excellent, and there's a reliable evening breeze. One trip to a suburban garden store, one trip to a kitchen boutique in the centre for the essential skillet and badass chef's knife, and British Airway's return of my oldest's car seat so we can get safely to the beach, and we'll be completely set for the summer.