Ton's Interdependent Thoughts: March 2009

January 2009 | Main | April 2009

Say After Tim: Raw Data Now!

In the presentation below, that Tim Berners Lee gave last February at the TED conference, the creator of the Web talks about what needs to come next: linked data. This is Berners-Lee's explanation of the semantic web.

The internet used to only connect servers to eacher other. I remember how in the very late '80s I logged onto a Unix machine at some US University to get some material from that machine using command line entries.
Berners-Lee thought it frustrating that you would find documents and files in all kinds of formats for which you might not have the right software to read it. Out of that frustration came the Web. It didn't look all that great initially (see pic below), but it meant you could open a document from any machine, and have it link to other documents. The Web connects documents.

Een vroege versie van de CERN website.

Now he proposes to link data to eachother, much like we now link documents, and used to link servers to eachother. As the next step in the evolution of the internet.
How he imagines that you can see in the video. It needs loads of raw data however. Data that follows three rules: it is available in open formats, it has an URI, and it links to other data. Hence his call to arms: Raw Data Now!

Given the work I currently do on opening up public service information (PSI) in the Netherlands, I can only subscribe to that call. In his presentation Berners-Lee talks a bit more about what is important about opening up government data.

Technorati Tags: opendata, openoverheid, timbernerslee, ted, openoverheidsdata

0 Comments and 0 Trackbacks | Permalink
(posted by Ton Zijlstra at March 31, 2009 10:29 PM)

Location Based Services Can Do Without Maps

At the Communia Workshop (organized by the Open Knowledge Foundation) yesterday and today we talked about opening up government data sources for the wider public, so others can build their own mash-ups and applications with that data. Most of the existing examples shown were map-based one way or another. That led to some discussion, with some asking why (Google-)maps were so prominent in the examples, and why not focus on some of the other great data sources out there, and others saying that your geographic location is so central to most of what you do that maps are logically the center piece of most mash-ups, and therefore the starting point for opening up government data.

Example of a random Google-maps based representation of information: European Songfestival songs

Now of course, mobile applications are all over geo-data as well, under the collective name of location based services.
I would like to propose a slightly different approach to location based services, by looking at them as context based services (a term I also heard Felix Petersen of Nokia/Plazes use at Shift last fall). Now, your geographic location is always part of your context. But it might not be the most important part of your context in a given situation. Elements in a context are often more interesting because of their relative position to you or each other, not so much because of their absolute position. So let's make a distinction between geographic location as an important part of my context, and maps.

For me as I write this, it is relevant to know where the nearest Tube-station is, and how far in which general direction I need to walk to get there. I don't care where exactly on the map I am however. If I had a map, I could infer how far I need to walk etc, but if I can know directly, I do not need to know my location nor a map to see where to go.

Screenshot of Google Latitude, showing 2 contacts in Amsterdam

Also, if you look at e.g. Google's Latitude, it is interesting to know where my friends and contacts are. But I really don't care where exactly they are. I only really want to know when they are near me, especially when they are nearer than usual, and inversely when they are further away from me than usual. It is relevant for me to know if a friend from North America is currently in the Netherlands, as that is an opportunity to meet up, or if we happen to find ourselves in the same city or region somewhere (Dopplr is an excellent example of this, which really does not need maps). It is relevant for me, when I try to phone somebody, to know I will not be reaching them in their normal location or time zone but half a world away. It possibly leads to a different decision on how important and relevant it is to call them. But to make that revised decision I do not need to know an exact location and look them up on a map. Jaiku's status messages about location or availability e.g. are good enough for that. In the same way, I would be interested to know which of my LinkedIn contacts are in the same building as I am, but that does not imply I need to know where the building is, or where the other person was before (s)he entered the building.

So let's look at context more than mapped location when it comes to building our apps and mash-ups. That will free us from our current heavy map-focus, while not ignoring the underlying importance of our geographic location to our current context. A promising example is Wikitude AR (see video above), that gives you info on your immediate surroundings without resorting to maps (though it can show you a map as well)

Also it allows us to think of more context based services, moving beyond immediate geographic location.
What other factors in your context are worth considering, comparing, sharing, interacting with?

Technorati Tags: communia, locationbasedservices, contextbasedservices, googlelatitude, googlemaps, opengovdata, opendata, jaiku, wikitudear

0 Comments and 0 Trackbacks | Permalink
(posted by Ton Zijlstra at March 27, 2009 05:39 PM)

Open Government Data in the Netherlands

Mid January I blogged about the project on open government data I am currently involved in for the Dutch Ministry for the Interior. Meanwhile James Burke and I are in the midst of it, and I thought it would be nice to share a few insights we gained, as well as some examples we found.

First of all, just as Chris Messina expressed recently, there is a lot going on around government opening up and transparancy. We found the same when we started scouting here in the Netherlands. There are quite a few initiatives going on in different sectors, bumping into different obstacles and problems, and generally not being aware of eachother and the opportunity to learn from eachother.

RIVM Smog Prognosis, example of opening up data with presentation layer

The results we're looking for
What we set out to do in this project is fourfold:

create an overview of existing government data sources that may be made accessible, and the network of people around those data sources

create a manual for civil servants interested in opening up a data source they administer on how to do that, and what kind of steps to take to do that responsibly

create a scenario for growth, on how to move forward after the project stops

create two API's opening up two government data sources, and add some interesting visualizations, to show people what we're talking about.

CFI data on education, example of data with limited export possibilities

First impressions
We talked to lots of people these past weeks. People from different government ministries, as well as more operational branches (such as RWS, responsible for the national roads and waterways, or RIVM, a research body for health and environment data), or organisations that are formally independent but working on government mandates (such as CBS, the central bureau for statistics). What stood out for me was that currently only two forms of data sharing seem to be on the radar of most people we talked to. One is the publication of data 'as is' with no explanation at all, just the database tables, usually for static or historic data. At the same time people have a lot of reservations around doing it this way as people might misinterpret the meaning of database fields. The other is the publication of data by adding their own presentation layer (and no actual access by others to the data). While interesting usually a lot of costs are involved, and data is presented in a way that made sense to the people owning the data and not necessarily to people looking at the site. API's are basically in the middle of those two options, giving regulated but otherwise open access to the real live data. So that people can come up with uses for it that the originator of the data could not imagine, or would not put up resources for.
There are some exceptions, that choose that middle road. There are XML interfaces e.g. to the Dutch State almanac (xml), giving all addresses of public institutions, as well as to all waste transports across the country (Web app).
In several instances also we found eagerness to create API's but no means to do it. That's where our project is glad to help, even if we are not sure creating an API is our own preferred option.

Dataportal.nl, data on traffic and water ways, extensive export possibilities for some of the data

Different issues to deal with
There is a number of issues that we come across in all conversations we talked to. Sometimes these issues are used to excuse inactivity, or a source of confusion as to what is possible and allowed. In general however when opening up data sources you have to always make some decisions on these issues. They are privacy, copyright, technology, organisation, and markets. I will go into these issues in more detail in other postings.

Network forming is the way forward
We've found a lot of different initiatives around opening up data in different places within government. None of them are connected or necessarily aware of each other. They do all have experiences that augment each other, and it is worth sharing them by connecting the people we met. Bringing the network together, and possibly form a core that can grow into a community of open data practices is I think the way forward. Part of the project is providing a path forward, and it will be based on network forming.

Bringing people together around Open Data, at Ministry for the Interior. Photo: Anne-Marie IJsenbruk