If web 2.0 was all about users generating content, and folksonomies, then Openstreetmap would fit very snugly into web 2.0, just like Wikipedia. But it’s much more, and I want to help more people to see the potential.
It’s web 3.0, where the view and interface becomes less important, and the data and the interpretation becomes central.
OSM is different from Wikipedia. Wikipedia’s data and the data’s interpretation is one-to-one. One view of the data, you edit the page, and it’s shown on that page. OSM is different, you can edit the data for an area, and different renderers, interpretators can show (or not show) that in different ways.
This thinking was inspired by recent mailing list discussions [here and here] about an “edit war” over placenames in Northern Cyprus, and by some talks at BarCamp Leeds. I won’t go into the details, but will quote (very heavily edited) some old OSM thinking here:
OSM should present a snapshot of the state of play at the time a mapper maps an area… After all, OSM is used is a navigational aid.
OSM is a navigational aid rather than a history book.
Whoever tags a place first gets to keep their name in first place.
Are there any lessons, learnt from wikipedia?
OSM is for english speakers.
The future will see me hosting the map itself in a non editable form
and some future thinking ideas:
OSM should accurately represent all legitimate points of view. While at the same time, fairly and without provocation.
isn’t the real issue that there’s really no “fundamental truth”.
Does osm have the ability to present multiple views of the database, for a given region? rather than try and put all the (variant, disputed) data in one place, perhaps the data should be (effectively) put in two (or more) places/views, and when such a region is requested, the user should be forced to choose which view of the region they wish to see.
OSM is a break with the past. There is the possibility to somehow represent all points of view.
the decision needs to lie with the renderer (or other user) and not with the mapper – what we currently see is mappers trying to force their world view onto the renderer (or user), instead of allowing him to chose; this is wrong.
Editing OSM is at the moment, mainly done using a google maps model of mapping. Linear editing, change something using the editor, and it’s reflected on the Map.
Editing OSM with web 3.0 model. Multiple possible paths, change something using the editor, and it may or may not be reflected on multiple different Maps, according to the interpretation / rendering rules.
So some notes for a manifesto:
- One to Many – One database – Multiple views.
- Tagging system accommodates multiple representation.
- Whoever renders (interprets) the data (map) should have the say on what is rendered.
- Encouragement of alternative views, renderers, servers. We need more custom map servers. This is not forking, as it’s the same underlying database, but the interpretation is different. Here’s a real example: Cycle Map for OSM: http://www.gravitystorm.co.uk/osm/
- Maps are representation of reality. Community should debate folksonomy, correct tagging procedures as before, allowing for alternate representations of the same object, as before.
- Example, an Ethical OSM map, showing recycling, cyclepaths, and names of buildings, business according to their ethical behaviour.
- Example, Roman OSM map, showing places and roads, ruins, temples, that only existed during Roman times.
- Example, a insert-country-here OSM map, showing boundaries and placenames that the Country’s administration consider authoritative.
- Example, already up and running, the Cycle Map, renders the data for cyclists, and publishes guidelines for contributors, on how to edit OSM so it will show up on their Cycle Map
Note, I have not touched on how, technically, these things can be solved (the threads linked to above have some suggestions) but they are something to reach for.
For one, I welcome more edit wars – they shake up old “OSM as a wiki” thinking, and I welcome more servers showing different views, as a starting point.