When Eric MacKnight pointed me to Ewan McIntosh’s reflections on Stuart Meldrum’s mapping project, he said: “This struck me as an idea that would interest you.”
It does. These folks are reaching for ways to build maps collaboratively — in this case, maps of the locations of schools in Scotland. One option would be to rely on a central authority that publishes the whole set of locations. Another would be to divvy up the work such that districts publish subsets of locations, or schools publish their own individual locations.
Division of labor aside, there’s the question of locus of control. Should there be a central registry to which contributors are granted access? Or should there be small pieces loosely joined?
Both, actually. Although we see this as an either/or choice, the two strategies can be complementary, and not just in the realm of collaborative mapping. All kinds of collective data management scenarios will benefit from combining these approaches.
Ewan McIntosh offers an example of an easy way to implement a central registry: a mashup of Google Spreadsheets and Google Maps. The spreadsheet is used as a lightweight, multi-user, versioned database of locations that populate the map. A central authority can control the registry, granting access to districts or schools.
In a comment on Ewan’s entry, John Johnston points to another mashup that’s conducive to a decentralized strategy based on tagging and syndication. John’s mashup scans his Flickr account for geotagged photos and sprays them onto the map. Whenever he geotags a new photo, a new point appears on the map.
To build a collaborative map using John’s approach, you still need a central registry. But it needn’t manage primary data such as locations. Instead it need only manage metadata: identifiers for schools, identifiers for authorized contributors. If John were a school administrator he’d register as a contributor, geotag a photo of the school, and tag it with the school’s identifier.
Now that’s a contrived example, because geotagged photos are a circuitous way to federate location data. But this model supports other and more natural approaches equally well. Instead of looking for tagged photos on Flickr, for example, the registry might look for resources (e.g. schools’ domain names) tagged on del.icio.us or elsewhere.
With this scheme you have a nice separation of concerns. Schools are the authoritative sources for data about themselves. Registries define the protocols for syndicating that data, and the sources they’ll syndicate from.
If there’s only one registry the benefits aren’t overwhelming. But in fact there are many registries.
Consider a school that belongs to a variety of regional academic and athletic associations. Today, each association’s view of its member schools requires yet another centrally-controlled database. Many facts about individual schools will be duplicated across those databases. The location won’t often change, but other facts will. When that happens there’s no way to publish one authoritative change about a school that flows to many subscribing registries.
The alternative I’m sketching is really a variation on the lifebits theme. Like individuals, organizations have an interest in declaring authoritative facts about themselves. Aggregate views shouldn’t require singular control of a database, but rather singular definitions of tagging, syndication, and membership protocols.
There is, of course, a huge problem with this scheme. It presents a formidable conceptual barrier. For example, my experiment in community information hasn’t gone very far yet. To me, it makes perfect sense. No need to plug your photos or your events into my database. Instead, just reuse your photos on Flickr and your events on Eventful. But nobody expects things to work that way. In principle the indirection of tagging and syndication creates all sorts of useful effects. In practice most people aren’t comfortable with that indirection. If Jeanette Wing has her way, such computational thinking will become much more prevalent. I hope she’s right, and I wonder what we can do to encourage it.
Hi John — I greatly recommend you check out OpenStreetMap [http://openstreetmap.org. — Mikel
I was going to suggest you check out Mapufacture [http://mapufacture.com] as well. You can bring in geo-feeds from any location and aggregate them together into a map. Like your example of “School registry” – any school or district could publish it’s own feed of locations, and then states or governments could just aggregate these together.
Or within a school or community, allow each group to maintain their own data source: soccer team game locations, community gardening centers, interest groups, clubs, etc. and then build a community map from these various data sources.
As soon as you propose a communal information base you’re into a largely non-technical design space. The database is a commons, and its creation and sustenance invokes all the public goods and commons issues well known in economics and sociology. Overcoming those problems requires all the social equity you can muster, and it would seem that organizing around that need – mirroring any extant social networks, for instance – is going to trump architectural purism, or at least should be taken as an overriding requirement on that architecture.
For my examples, I’d suggest a look at the GPS games Waymarking [http://www.waymarking.com] and Geocaching [http://www.geocaching.com]. Both are based on community construction of a shared data space layered over real space, and differ in whether the ‘mark’ is purely virtual or involves placing a physical object. Other than being a similar design problem, it’s also interesting to note that both have developed much the same layered delegation of authority and responsibilities to the user community that also appeared years ago in the form of mods/sysops in settings like BBS’, Usenet, The Well and online services. That’s a form of layering that’s probably as important as separation of technical concerns.