Friedrich Lindenberg

Hakuna your data - data bootcamp in Nairobi

2012-01-30T00:00:00-08:00

My Name is XXXX, I am a member of the Kenyan parliament for the constituency of XXXX in the 2007-2012 election cycle. During my time in parliament, I have positioned myself against taxes for MPs.

Of the Development Funds allocated to my constituency, I have spent 12mn KSH in 2010 and 8mn KSH in 2009. Since 2007, I've funded 201 projects, of which 72 (9mn KSH) related to Education, 56 (7.2mn KSH) related to Health and 20 (4.2mn KSH) to Infrastructure. The largest projects I have funded include...

Auto-generated, spending data-driven campaign speeches like this are just one of the many ideas of the Data Bootcamp that took place in Nairobi last week. Invited by the African Media Initiative and the World Bank Insititute, about 70 participants - both journalists and developers - met on Strathmore University's campus to learn and practise both the skills and tools required for data-driven reporting.

The four-day programme combined tools training with practical work in small groups. Elena Egawhary (BBC NewsNight) gave a workshop on data analysis in Excel, Sreeram Balakrishnan (Google Fusion Tables) introduced both Refine and Fusion Tables. Team members from both the Kenya open data portal and the World Bank finance site presented their respective offerings, while Gregor and myself from the OpenSpending team gave intros to web scraping and advanced map visualisation.

During group work, journalists and developers teamed up to try their newly learned skills in different domains ranging from sports (football player profiles) to education (missing toilets in schools, "The Shit Ordeal") and the financial transparency story-telling mentioned above.

The workshop also served as a community-building event for Kenya's young and impressive Open Data initiative. Future events, aimed at civil society organisations and polictical actors will help to further promote the re-use of government information released through the initiative.

All this is happening in a place where transparency is an essential tool to be developed: Not only is the access to information now guaranteed by the 2010 Kenyan consitution, there are also major political issues that deserve close attention from local and international watchdogs. These include not only the ongoing incursion of Kenyan troops into Somalia in an effort to fight Al-Shabaab terrorist groups, but also the upcoming nationwide elections in December 2012. The elections will instate a new bicameral system of government, with many previously unknown candidates standing for office. In the previous 2007 vote, bad polling station data had quite literally led to widespread unrest and thousands of deaths across the nation.

In all, it was a fantastic to get in touch with the Kenyan participants of the workshop and to see how the organizers of the event - a brilliant team including Craig Hammer, Justin Arenstein and Jay Bhalla - are working to foster an open data community in this bustling developing nation. Given the great ideas generated during the team sessions, I'm sure this work will soon bear its first fruits.

Open Data Hackday Hamburg - Fazit

2012-01-16T00:00:00-08:00

Am vergangenen Wochenende fand in den Räumen des CCC Hamburg der erste Open Data Hackday des Jahres statt. Zum abendlichen Kick-Off am Freitag erschienen rund 25 Teilnehmer, an den beiden Coding-Tagen lichtete sich die Runde leider ein wenig. Dennoch entstanden in der spannenden Diskussion eine gute Anwendungs-Ideen (Original-Pad, Links folgen sobald verfügbar!):

fukami scrapte die Belegungsdaten aller Parkhäuser in Hamburg, die sich so leicht in einer mobilen Karten-App darstellen lassen. Die Sammlung der Daten über einen längeren Zeitraum dürfte zudem für spannende Analysen nützlich sein.
mtu entwickelte die RatsInformationsSchleuder, ein einfaches Dokumentensystem für die Fraktionen von Piraten und der Linken in der BVV Hamburg Mitte.
nexus scrapte das Dokumentensystem des Landtags Niedersachsen, um ein Push-System zum Monitoring der Sitzungsthemen zu entwickeln.
Die Luftmessnetze von Hamburg und Niedersachsen scrapte, Achim, der sich dabei gleichzeitig in Python einarbeitete.
Mit einer Java-Anwendung konnte StreetDogg die Worthäufigkeiten einzelner Terme in den Plenarprotokollen des Bundestages messen, um so Themen-Histogramme bereit zu stellen.
Ich selbst habe einen Prototypen für ein kleines Crowdsourcing-Projekt gehackt, das jedoch noch einen Medienpartner im Hamburger Raum benötigt.

Insgesamt: eine besonders entspannte Atmosphäre im Hamburger Chaos, einige wirklich spannende Diskussionen mit den Anwesenden und viele Anfänge, die es nun fortzuführen gilt. Deshalb habe ich nun eine Open Data Hamburg-Liste angelegt um weitere Hackdays und Projekte zu verknüpfen.

EC-Studie zu Bezahldaten mit Fallstudien aus Deutschland

2012-01-13T00:00:00-08:00

Im Rahmen der Initiative zur Erneuerung der Public Sector Information-Direktive hat die Europäische Kommission nicht zur einen spannenden ersten Entwurf vorgelegt (unsere Kommentare bereitet aktuell Hauke vor), sondern auch verschiedene Studien zum Thema PSI veröffentlicht. Eine besondere Erwähnung verdient dabei ein Papier zum Pricing Of Public Sector Information.

Nicht nur kommen die Autoren - Deloitte, Citadel und Tech4i2 - zu dem Fazit, dass eine Preissenkung von PSI ökonomisch sinnvoll ist - im Rahmen der Studie werden auch die in Deutschland üblichen Verdächtigen als Case Studies durchgegangen. Das Resultat ist ein spannender Einblick in die finanzielle Struktur deutscher Bezahl-Staatsdaten:

Das Bundesamt für Kartographie und Geodäsie (BKG) verwaltet die Geodaten des Bundes und unterstützt - gegen Provision - die Länder beim Vertrieb ihrer Daten. Das ist auch notwendig, denn die elfeinhalb Mitarbeiter im Geodatenvertrieb erwirtschaften aus den Beständen des Bundes nur etwa 70000 Euro (S. 145). Bei einem Budget von 33.8 Millionen Euro sind das dann 0.2% des Finanzbedarfs des BKG.
Ähnlich geht es dem Deutschen Wetterdienst (DWD), der immerhin 50.5 der 215.9 Millionen Euro des eigenen Haushalts aus wirtschaftlichen Tätigkeiten bezieht. Auf den Verkauf von Daten gehen davon allerdings nur 9 Millionen zurück - 2 Millionen davon für Rohdaten. Immerhin 4.2% der Betriebskosten sind also von PSI abhängig. Im Verkauf sind zweieinhalb Planstellen vorgesehen.
Am erfolgreichsten betreibt den Verkauf von Staatsdaten die Berliner Senatsverwaltung für Stadtentwicklung (SenStadt), die in der Studie stellvertretend für die Bundesländer untersucht wird: immerhin 10.3% des Haushalts von 9.14 Millionen - also 945000 Euro - werden durch den Verkauf von Daten erwirtschaftet (S. 155). Spannend ist dabei die Einkommensstruktur: 600000 Euro erwirtschaftet die Senatsverwaltung mit Katasterauszügen, 95000 Euro durch Verkäufe einer Mietpreisdatenbank. Die verbleibenden 250000 Euro gehen auf Geodaten zurück, also den berühmten FISBroker. Wie viele der 120 Mitarbeiter mit dem Verkauf von Daten beschäftigt sind, geht aus der Studie leider nicht hervor.

Einigermaßen gut kommt unter den deutschen Beispielen in der Studie lediglich das Bundesamt für Statistik weg, die vor einigen Jahren auf ein Bereitstellungskosten-Modell gewechselt haben (und seither den Zugriff auf die eigenen Statistiken um den Faktor zehn steigern konnten, S. 334).

Was den Verkauf von Geodaten angeht wird die Situation noch ärmlicher, wenn man sich verdeutlicht, dass die Qualität von freien Angeboten wie OpenStreetMap die von vielen kostenpflichten Quellen mittlerweile deutlich hinter sich lässt. Zeiten, in denen die Erlöse - wie aktuell - stagnieren, werden bald die good old days sein.

A good social network analysis tool for advocacy & journalism

2011-12-19T00:00:00-08:00

Some of the most interesting transparency and journalism-related datasets are those in which the relations of various actors and institutions are portrayed over time: corporate ownership, lobbying or organized crime networks all present similar challenges.

And yet there seems to be no good off-the-shelf package to display such data. Sure, there are things like UCINet for classic SNA and Gephi for graph data visualization. But I think they're inadequate. The gold standard for graph presentation in 2011 is not graphviz, its Facebook. I don't mean to imply that networks need to be stored as massively centralized, ad-powered dotcoms, but there are a couple of lessons to learn:

It needs to be fully web-based and not overtly about graph management. Rich attributes for both nodes and edges need to be stored and presented in a task-specific form.
Some level of access control enables more interesting use cases.
Network effects apply to networks. Ha.

The problem in building this is simple: its a trap. For any coder, our greatest dream is to transfer some new domain of knowledge into a perfect graph (I'm guilty myself, having worked on liquid democracy). In this case, the temptation is almost irresistible: the data is already a network.

Yet as we work to translate things into this graph, we tend to lose sight of the goal. A nice example of this is OWNI's InfluenceNetworks: while it is supposed to be the the tool this whole post is about, they ended up just building a snazzy graph management app. Nice, but useless.

Even more dangerous: doing this internally. The linked data community seems to be crippled by graph fever. More than once have I sat through an hour-long presentation on the use of linked data in which no actual use for an end-user facing application was mentioned. While I'm not saying its impossible to build good applications on RDF, it seems like a huge distraction from actually tackling the domain.

But the problem remains: we need some easy-to-use solutions for advocates, journalists and other investigators to map out networks. The best effort towards this I've seen so far seems to be andoc, but even this does not feel like it is hitting the right trade-off between abstract graphness and concrete modelling yet. But: how do we find that trade-off? Seems some conrecte use cases and a nice agile process is needed...

World-wide privatizations collected by the World Bank

2011-12-18T00:00:00-08:00

The World Bank has collected a database of major (i.e. at least one million USD) privatizations in developing countries from 1988 to 2008. The dataset - which is classified by country, sector and privatization type - is a fascinating view into the development of countries such as China, Russia and many states in South America.

I've imported this dataset into OpenSpending to be able to generate custom aggregates. This is of course risky, as the list is unlikely to be comprehensive and does not include smaller privatizations on a local level, which are likely to make up the bulk of the financial volume.

Some interesting views include the breakdown by sector and by nation. But the import into OpenSpending is problematic in other ways: the dataset does not contain information on who bought the privatized entities and therefore isn't a generic spending dataset.

I've therefore decided to model it in a reverse mode. The individual entries do not represent financial transactions but the transferred assets - the source is given as the source country, while the recipient is the newly formed company. This may be an interesting preview into the problems OpenSpending will face as it begins to include balance sheet information.

Organisational IDs inside government - publicbodies.org

2011-10-24T00:00:00-07:00

The final event of last week's Open Government Data Camp in Warsaw was a workshop on organisational identifiers. While the bulk of the conversation revolved around IDs for companies and charities, this also prompted me to continue work on publicbodies.org. I had proposed and registered this site a few months ago after cleansing the UK's departmental spending data.

While the 25k data is a great source of information, the data quality is very low. In particular, it has two fields called "Department Family" and "Entity" that reference the responsible department and public body disbursing the funds, respectively. The content of these fields is just text, leading to a large number of different spellings not only of the word "Health" but of department and entity names in general.

The solution to this is obviously Chris Taggart's OpenCorporates.com: generate a unique REST resource for each public body and provide a reconciliation API to fuzzy match surface forms to these entities. So, let me present to you: publicbodies.org. The site currently contains data from the best sources on public body identities I could find, freedom of information request sites. With a quick bit of research, this gave me German public bodies, UK entities and EU insitutions (with names in multiple languages).

While the service is very usable as is (I've just reconciled the EC's Financial Transparency System and a sample of the UK spending), there are still some tasks left:

Map national identifier systems to the scheme and support their resolution. Currently, the site is using random IDs prefixed with the country code of the entry.
Creating redirects to similar resources, such as data.gov.uk's reference project.
Needs to look nicer.

If you have public body information from another jurisdiction (or would be willing to merge additional information into the existing dataset), have a look at the main schema and the alias table to see how the data should be formatted. I'm happy to add other fields to the entity schema, though.

Kleine Charta der Beteiligten

2011-07-22T00:00:00-07:00

(Scribble vom Collaboratory OHU Open Government) Wer im Netz an einem Beteiligungsverfahren teil nimmt, der investiert einiges: die eigene Zeit, Kreativität, eigenes Wissen und viel Geduld. Beteiligung ist Arbeit, die freiwillig und unvergütet geleistet wird. Für uns, die Betreiber solcher Angebote, muss das heißen: wir müssen die Teilnehmer mit ein wenig Respekt behandeln, ihnen in ihrer Rolle einige Rechte eingestehen:

Das Recht, etwas zu bewirken. Was hilft das schönste Verfahren, wenn es nichts bewirkt?
Das Recht, mein Gegenüber kennen zu lernen. Niemand will mit dem Bundesministerium für oder der Partei X im Ganzen reden: das bietet keine Gesprächs- sondern nur eine Anklagemöglichkeit (vgl. Cluetrain #84).
Das Recht, zu wissen worum es geht. Transparenz des Prozesses und Informationen zu Sachlage. Wenn ihr es selbst nicht wißt, dann sagt wenigstens das.
Das Recht, mitzubestimmen worum es geht (und die Spielregeln zu hinterfragen). Der Rahmen, den ihr für die Sache gesetzt habt, passt vermutlich euch viel besser als uns. Machen wir also zusammen einen neuen.
Das Recht leise zu sein und zu spät zu kommen. Nicht jeder ist Sascha Lobo. Sascha Lobo hat nicht immer Recht.
Das Recht mit anderen in Kontakt zu kommen und zusammen zu arbeiten. Euer Verfahren ist unsere Plattform.
Das Recht, eine ehrliche Reaktion zu erhalten. Reagiert. Und wenn ihr uns alle für Idioten haltet, dann lasst es uns wissen - wir tun das ja auch.
Das Recht, in menschlicher Sprache zu kommunizieren. Planfeststellungsverfahren, 'nuff said.
Das Recht, anonym zu sein. Es gibt keinen Grund, für meine Meinung meinen Perso vorzuzeigen. Ihr verratet mir nur, dass ihr mir misstraut.
Das Recht, meine Meinung zu ändern. Wieder was gelernt.

Kommentare, Änderungen, Erweiterungen und Kürzungen?

Zentralarchiv politischer Meinungen: delegierte ePetitionen

2011-06-22T00:00:00-07:00

NB: Dies ist kein Projekt des Liquid Democracy e.V. oder der Open Knowledge Foundation. Es gibt Ideen, die sind einfach schlecht. Gemüsebratlinge etwa, oder Immobilienhypotheken. Das Zentralarchiv politischer Meinungen fällt vermutlich in diese Kategorie. Ziel der Seite ist es, eine Suchmaschine für das Petitionen-System des Bundestags bereit zu stellen. Durchsucht werden dabei jedoch nicht die Petitionen (siehe hier), sondern deren Mitzeichner. Warum? Das erklären die Verfahrensgrundsätze des Ausschusses ganz gut:

"Öffentliche Petitionen sind Bitten oder Beschwerden von allgemeinem Interesse an den Deutschen Bundestag. Sie werden im Einvernehmen mit dem Petenten auf der Internetseite des Petitionsausschusses veröffentlicht. Mit der Veröffentlichung erhalten weitere Personen oder Personengruppen über das Internet die Gelegenheit zur Mitzeichnung der Petition oder zur Abgabe eines Diskussionsbeitrages hierzu."

Die Gelegenheit zur Mitzeichnung ist dann am besten gegeben, wenn alle Informationen über die Petition - also auch die Unterschriftenliste - direkt verfügbar sind. Duct Tape Delegation Kennt man diese Listen, dann ist es einfach dem geneigten Slacktivisten noch eine weitere Hilfe an die Hand zu geben: die Delegation. So kann das Mitzeichnungsprofil eines beliebigen Teilnehmers in Zukunft 1:1 übernommen werden - das Zentralarchiv übernimmt den Abgleich. Legal? Verfahrensgrundsätze: "Öffentliche Petitionen können von jedermann einzeln oder in Gemeinschaft mit anderen unter Verwendung des hierfür vorgesehenen elektronischen Formulars an den Petitionsausschuss eingereicht werden." - ich denke mal, Delegation fällt unter "in Gemeinschaft". Leider kennt jedoch das Petitionensystem keine Token-Authentifzierung - für einen Delegationsservice sind daher Benutzname und Passwort erforderlich. Auch sind die Mitzeichnerlisten nur begrenzt eindeutig: sind etwa zwei Hans Müller im gleichen Bundesland gemeldet, dann werden beide Mitzeichenprofile vermischt. Schließlich bleibt auch die Gefahr, dass die Nutzung von Delegation den Wert der Mitzeichnung untergraben - manuelle und automatisierte Abgaben sind nicht zu unterscheiden. Doch genau das ist der spannende Punkt: der Kontakt eines analogen politischen Verfahrens mit einer algorithmischen Arbeitsebene. Das Projekt ist natürlich im Quellcode verfügbar und auf Anfrage stelle ich einen Datenbank-Dump bereit - der bietet gutes Material z.B. für eine Netzwerkanalyse.

Worklog April 2011

2011-04-27T00:00:00-07:00

Weil es mich zur Zeit selbst ein wenig verwirrt und auch sonst nicht schaden kann, habe ich mir vorgenommen einmal im Monat eine grobe Liste meiner aktuellen Vorhaben ins Netz zu stellen. Zur ersten Ausgabe hier der Monat April im Schnelldurchlauf:

4.4./5.4.: Workshop zu Data and its use in advocacy, organisiert vom Tactical Technology Collective in Berlin - spannende zwei Tage zu den strategischen und institutionellen Herausforderungen, die der Umgang mit Daten für advocacy groups mit sich bringt. Unter anderem vieles über die Arbeit von Menschenrechtsorganisationen in Burma und Kenya gelernt.
Import zusätzlicher Datensätze in OpenSpending.org: Italienischer Haushalt, Haushaltsdaten von Argentinien und Mexiko vorbereitet, umfangreiche Aufräumarbeiten an den Ausgabendaten der britischen Ministerien und am rekonstruierten Haushalt von Uganda.
12.4. Präsentation der Visualisierungen von EU-Haushalt und FTS beim Netzwerk Europäische Bewegung in einem Workshop zum Web 2.0
13.4-15.4.: re:publica 11, Berliner Bloggerkonferenz, diesmal mit einem eintägigen Track zu Open Data und Open Government und auch sonst vielen spannenden Kontakten und Gesprächen.
Gespräch mit Boris Hekele und stf über Zusammenarbeit und Datenaustausch zwischen AbgeordnetenWatch, OffenesParlament und Weurstchen. Zusammen mit AbgeordnetenWatch hoffe ich in der nächsten Zeit eine Initiative zum Datentagebau an Landesparlamenten und kommunalen Ratssystemen lostreten zu können.
Zwei Tage Hackday an parltrack, einem Scraper, der die Daten von Bundestag, Bundesrat und europäischem Parlament in ein gemeinsames Format konvertiert und in Solr indiziert. Soll zum neuen Backend für Weurstchen und OffenesParlament werden.
Gespräche mit Chris Taggart von OpenlyLocal und OpenCorporates über die Verknüpfung von Firmeneinträgen und Ausgaben der lokalen Regierung in England zwischen OpenCorporates, OpenlyLocal und OpenSpending.
Eine Liste mit Datenwünschen auf Bundesebene verfasst, auf der Basis im Netz erwähnter Datenquellen - mithilfe gewünscht!
28.4.: Chaosradio 167: Open Data - Gebt die Bits frei! mit Michael Hörz und wetterfrosch.
30.4.: Transparency Camp bei der Sunlight Foundation in Washington.

GeoBusiness Lizenz: Open Data und die sieben Zwerge

2011-04-23T00:00:00-07:00

IANAL: I am not a lawyer, was folgt ist Laienmeinung vom allerübelsten. Durch einen freundlichen Hinweis von Michael Fanning wurden wir in der letzten Woche auf die GeoBusiness Lizenz aufmerksam gemacht, an der zur Zeit die Kommission für Geoinformationswirtschaft des Wirtschaftsministeriums arbeitet. Auf der Seite werden zur Zeit acht unterschiedliche Lizenzmodelle vorgestellt: eine Lizenz (Ia), welche grob mit der Open Definition vereinbar ist und damit potentiell zur Bereitstellung von Open Data geeignet wäre, sowie sieben abgeleitete, nicht-offene Modelle. Dabei werden verschiedene Eingrenzungen durchgespielt, die vermutlich typisch für die Open Data-Diskussion in Deutschland sind:

Mit einer Eingrenzung auf "geschlossene Nutzergruppen" wird ein de-facto Publikationsverbot für die Daten angesprochen. Es wäre dann nicht möglich Anwendungen auf der Basis der Daten überhaupt Dritten zugänglich zu machen. Damit mag zwar einigen Landkartenfetischisten geholfen sein, von einer Weiternutzung der Daten muss da aber natürlich nicht mehr gesprochen werden. Die Lizenz entspricht grob der Idee von Freeware - ein Konzept, das nicht ohne Grund im Web mittlerweile fast ausgestorben ist.
Zudem wird das Verbot der Weiterverarbeitung für Daten diskutiert. Genau genommen ist Entwurf das Wort "verarbeiten" durchgestrichen, womit auch schon so ziemlich alles gesagt ist. Was dann übrig bleibt: runterladen, anklicken, ausdrucken, angucken. Die Idee von "no-derivatives"-Lizenzierung mag man bei künstlerischen Werken noch aus den Rechten des Autors ableiten, bei Geodaten verhindert sie jedoch schon die rudimentärsten Operationen - ganz zu Schweigen von einer aktiven Weiternutzung, wie sie das Ziel von Open Data ist.
Und schließlich wird auch die Forderung diskutiert, die uns vermutlich in Deutschland noch eine ganze Weile begleiten wird: das Verbot kommerzieller Nutzung der lizenzierten Daten. Nicht-kommerziell ist dabei nur, wer "weder unmittelbar noch mittelbar auf die Erzielung von Erlösen und sonstigen wirtschaftlichen Vorteilen gerichtet ist". Darunter fallen in der Realität leider der Papst und die Pfadfinder - schon wer einen flattr-Button auf der eigenen Seite platziert ist raus. Zur Abgrenzung kommt aber noch ein grundsätzlicheres Problem: Zweck einer Datenfreigabe sollte es sein, eine gemeinsame Wissensressource zu schaffen. Solche gemeinsamen Güter sind die Quelle der sozialen und wirtschaftlichen Innovation die wir mit dem Begriff "offen" beschreiben - nicht die pure Publikation von Daten im Internet. Das Verbot einer kommerziellen Nutzung verhindert jedoch das Entstehen solcher Allmenden, indem gegen die Mehrzahl der potentiellen Teilnehmer diskriminiert wird. Während man eine Parallellizenzierung mit der Hoffnung auf direkte Erlöse betreiben kann, ist die Idee informationsökonomisch also ein wenig überkommen und angesichts starker Konkurrenz durch bestehende Projekte wie OpenStreetMap auch nicht wirklich realistisch. Nicht umsonst greift mittlerweile z.B. die Deutsche Flugsicherung auf OSM zurück, anstatt die Daten des Nachbarressorts zu nutzen.

Es bleibt also zu hoffen, dass auf diese Einschränkungen bei der tatsächlichen Lizenzierung verzichtet wird. Ebenso wäre zu wünschen, dass bei den weiteren Nutzungsbedingungen - die in allen Lizenzvarianten vorgesehen sind - noch aufgeräumt wird: so verletzt die Lizenzbestimmungen, wer mit Hilfe der Daten andere in die Irre führt - ein Vorgang der ja nicht immer wissentlich erfolgt. Auch auf den Luxus eines BSI-konformen Rechenzentrums haben wohl die wenigsten potentiellen Nutzer Zugriff. Insgesamt ist es jedoch überaus ermutigend, dass das BMWi eine Diskussion führen, in der Open Data zumindest als eine der Alternativen zur Wahl steht. Die könnte man dann treffen.

Notes on Data Catalogue Federation

2011-04-22T00:00:00-07:00

Over the past six months, I've been involved in the LOD2 projects use case for open government data, an effort to prototype a data catalogue federation platform for data from within the European Union. On May 3/4, OKF will be running a workshop on the same topic in Edinburgh. As I won't be able to attend it, here are some notes on requirements and technical alternatives (perhaps as a "scene setter") for the meeting. Purpose, Objectives The interest in exchanging catalogue metadata can be explained through various use cases, some of which include:

The aggregation of metadata across hierarchies, for example from regional government catalogues towards state and trans-national (EU) levels of administration. This can also be applied within government, where several department catalogues might be aggregated into a common database.
Domain-specific catalogues might cover only specific types of content or data format, e.g. data on scientific, financial or legal documents. Still, they might want to retrieve metadata from more generic catalogues or provide updated dataset descriptions upstream.
Another common scenario is the interface between institutionally operated catalogues (such as government sites) and those operated from within a civic context: while government has much better information on updates of data and similar source information, the community may be abe to contribute better knowledge on re-use opportunities, examples or fully established workflows. As it is not easy for government to allow the direct and wiki-like enrichment of metadata, this enrichment could be done in an external, community-driven catalogue (such as CKAN.net) and then fed back into the main catalogue through a guided process.
Aside from many use cases for full metadata, the centralization of access points in the form of search federation can support users in finding the right information without having to find the right search box first.

These use cases motivate the exchange of metadata, in order to allow widespread re-use of metadata, make specific capacities of different catalogues available to each other and to guarantee up-to-date information in data catalogues. The following is a somewhat random list of issues that need addressing for such exchange and federation to yield useful results. Scope and basic concepts of catalogues As with almost any other technology, various people expect and implement data catalogues to do many different and often mutually exclusive things. Any kind of exchange mechanism will have to bridge at least some of these gaps:

The first aspect may be the granularity of data referenced from within the catalogue. A particularly plastic example is bibliographic information where one might reference the whole database or each individual work. This is also true of statistical databases and, in particular, geospatial information. In the case of the US data.gov portal, 3000-odd normal datasets are met by 290000 pieces of geographic information. Trying to define a dataset (in Richard Cyganiak's words: "a set of data") is probably not helpful, perhaps marking packages as large, medium or small would be more practical.
A second aspect is the scope of the involved sites. While we're talking about data catalogues (as opposed to repositories) for the most part, this distinction is soft and often not of great help. Many catalogues (such as Data Publica, Socrata) include the data itself, some even standardize on a specific format. Including those also means looking at actual data stores which provide metadata, i.e. sites like Talis, FreeBase, Google Public Data and other statistics databases.
Exchanges will have to be aware of licensing both of the datasets referenced or contained within the catalogue and of the metadata itself. A government catalogue may only contain open data and release its metadata into the public domain, while a data mart would also contain commercial data and claim DB rights on their index. While I'm not sure we need to support machine-provided assessments of compatibility, having markers for some key pieces of information (BY, SA, NC, (C), PD) would be useful.

Metadata Formats JSON, HTML, XML/OKFN, XML/GMC, XML/DC, RDF/DC, RDF/DCat, MARC Exchange and Harvesting Mechanisms Push or pull? OAI-PMH, CSW et al., RSS/Atom, RDFa, SDMX, DVCS (Git, Mercurial, Bazaar) SPARQL or specific (RESTish or RPC-type/SOAP) interfaces Best choice at the moment is possibly the Atom Publishing Protocol as it is widely understood, implemented, tested. Distribution of Changes Given both an exchange format and a mechanism for harvesting or pushing metadata, the possibility to merge divergent metadata must be created. I also think its helpful to tackle the question of metadata provenance in this context, rather than as an isolated and theoretical concept. This involves:

Establishing and documenting institutional workflows for the processing of external or internal changes to metadata in a distributed environment.
Matching equivalent or related datasets from different sources, merging them or expressing relationships between them; deciding on a threshold for the distinction.
Exposing and merging differentials to data catalogue maintainers through a user interface to allow manual or guided reconciliation in a reproducible way.
Tracking technical metadata provenance across different systems, some of which may have their own concepts of versioning and tracking; recording the process of exchange and chains of sources.

Alignment of Metadata Once a basic architecture for federation is available, more effort can be invested into the creation of common metadata contents. Challenges here include:

Expressing advanced dataset relations and types such as time series and derived datasets.
Using common tagging schemes, and taxonomies. Especially for basic concepts where EUROVOC might be useful and then in a per-domain fashion. We should also give thought to how this can benefit form the kind of work that is being done on SEMIC. In LOD2, we've basically decided to focus on three content domains: energy-related datasets, financial spending and budgetary data and legislative documents.
Geo-spatial relationships, scope and context.
Institutional origin (incl. URIs for public bodies, companies) and paths of publication, including responsible persons.
Handling of languages and translations, Licensing and usage rights criteria, see above.
For outbound references, advanced URL schemes, data format conventions and specifications for external services such as SPARQL endpoints, REST/SOAP/XML-PRC APIs etc.

Open Data-Taktik

2011-04-17T00:00:00-07:00

Während nach dem britischen Vorbild nun auch in Frankreich ein Portal für offene Regierungsdaten angekündigt ist, lautet in Deutschland die offizielle Losung immer noch: bis 2013 wird erst mal eine Strategie entwickelt, danach geht's endlich los.

Wer - wie zuletzt auf der re:publica - die zuständigen Vertreter des Innenministeriums sprechen hört, weiß aber, dass durchaus einiges in Bewegung ist. So werden nicht nur Grundpositionen erarbeitet, es werden auch Allianzen zwischen den Ressorts und Ländern gebildet, die an mehr Transparenz und Zweitnutzung interessiert sind. Es ist also klar, dass der Open Government-Strategie von 2013 schon einiges an Handlung vorausgehen wird - nur was? Dazu einige Ideen, die ich zur Diskussion stellen möchte:

Es muss eine Open Data-Lizenz für Deutschland benannt werden. Damit meine ich nicht, dass sofort alle amtlichen Daten unter dieser Lizenz freigegeben werden müssen - wir brauchen nur das richtige Werkzeug für diejenigen, die schon mal anfangen wollen. Zum einen wird so eine einfache Möglichkeit geschaffen, bestehende Ressourcen als 'offen' zu markieren. Zum anderen steigt sonst das Risiko, dass verschiedene Behörden und Länder sich auf die Suche nach jeweils eigenen Lösungen machen und dabei im schlimmsten Fall rechtliche inkompatible Ansätze finden.
Auf OpenDefinition.org gibt es zudem hervorragende Vorlagen, um eine Entscheidung in diesem Bereich zu vereinfachen. Wenn dabei am Rande noch bestätigt wird, dass die Nutzung von CC-Lizenzen bei der Veröffentlichung von urheberrechtlich geschützten Dokumenten aus dem staatlichen Umfeld in Ordnung ist, dann wäre das auch nicht schlimm.
CSV beißt nicht. Diese grundlegende Erkenntnis muss durch deutsche Behörden und Ämter verbreitet werden. Wenn Ministerien heute IFG-Anfragen mit der Floskel "Die Übersendung kann nur als PDF-Dokument erfolgen." und einem frisch generierten PDF-Anhang (Erzeuger: "Microsoft® Office Excel® 2007") beantworten, dann stellt sich doch die Frage: Warum? Die Gründe sind oft eine Mischung aus Unwissen und Unwillen. Wir müssen also klar machen, dass eine Bereitstellung von Daten im Web nicht durch Druckvorstufen gegeben ist, sondern erst wenn ihre weitere Nutzung zumindest rudimentär möglich ist. Und natürlich wollen wir möglichst bald eine Veröffentlichung in Offenen Standards erreichen, auf dem Weg dahin stellen jedoch die Formate der Bordmittel (oft: Excel) einen wertvollen ersten Schritt dar. Dafür müssen wir den Unterschied zwischen online und offen klar machen: die wenigsten amtlichen Webinhalte sind bisher offen, dabei ist der Schritt von einfacher, digitaler Bereitstellung oft gar nicht unüberwindbar groß.
"Einige Leute aus eurem Laden kennen wir. Online verstehen wir uns ganz gut. Habt ihr noch mehr von der Sorte? Dürfen sie rauskommen und spielen?" These 84 des etwas antiken Cluetrain-Manifests muss auch auf öffentliche Stellen zutreffen, damit Open Government in Deutschland eine Chance hat. Diejenigen in der Verwaltung, die nach außen kommunizieren wollen, müssen das auch dürfen - grade auch dann, wenn sie nicht von der Pressestelle sind. Die deutsche Vorstellung, Behörden hätten immer als Ganzes aufzutreten, ist überkommen. Erfolg haben Öffnungsversuche immer dann, wenn in flachen Strukturen gedacht und gehandelt wird.

Neben diesen Punkten, die sich an Regierung und Verwaltung richten, steht ein weiteres Arbeitsprogramm: das für uns, die zivilgesellschaftlichen Teilnehmer dieser Entwicklung. Für uns muss es das Ziel sein, Open Data - Projekte, Hack Days, Gemeinschaft - als Praxis zu entwickeln. Bisher erschöpfen wir uns viel zu oft in allgemeinen Diskussionen, hohlem Argumentationstraining und dumpfem Spott. Was nützt uns das beste policy-making wenn es nicht auf der Basis konkreter, gelernter Lektionen geschieht?

Open Data Search: finding useful datasets, worldwide

2011-03-25T00:00:00-07:00

Recently, there has hardly been a week in which there hasn't been an announcement of a new local, regional or national open data initiative - including ever more extensive catalogues of data that is being opened up (CKAN alone now runs in 20 or more places). While this is great news for those of us interested in re-using the data, it also means it becomes increasingly hard to keep a good overview of what kind of data are available for which places. To get a better overview we've now started a meta search engine for open data, opendatasearch.org.

opendatasearch.org is a global version of the prototype publicdata.eu site we announced in January: it's an aggregator for datasets, providing a simple and unified search interface to all of the catalogues contained. At the moment, this includes all known instances of the CKAN software, the Sunlight Foundation's National Data Catalog (and with it a large number of US-based data sources), the World Bank data catalogue, Sweden's DCat-enabled OpenGov.se and Nexedi's Data Publica portal. We've also put up search.ckan.net which provides access to the combined index of all CKANs only. Behind the scenes, opendatasearch.org is web spider with a twist: all collected data is converted to DCat, DERI/W3C's RDF-based ontology for dataset descriptions. While this convention is still in early development, it's interesting to see how well different kinds of catalogues can be expressed in it already (the harvested data can be found here). By harvesting a growing set of existing dataset descriptions, we hope to gather a comprehensive picture of the dataset properties that are widely used and that should be represented in a common format. Our goal with this is to establish some degree of interoperability between different data catalogues, leading into a federated catalogue architecture for Europe and perhaps beyond. These standardization concerns aside, we want to make opendatasearch.org useful on its own. For the immediate future this means adding support for more filter options, including licenses (and their compliance to open data principles), languages used in metadata and the data itself and geographic scopes of the collected information. This, of course, is an open source development effort and we'd glad to welcome those interested in contributing comments, catalogue data or functionality on the ckan-discuss mailing list!

Vorlage für IFG-Anfragen

2011-01-11T00:00:00-08:00

Man braucht es ja doch ab und zu: das Informationsfreiheitsgesetz. Weil ich bei einer oberflächlichen Google-Suche keine Vorlage finden konnte, hier mein Entwurf:

Sehr geehrte Damen und Herren, ich möchte Sie (im Sinne des §7 IFG) um die Zusendung der folgenden Informationen auf elektronischem Weg und in einem maschinenlesbaren Format (etwa: Excel, CSV, XML, HTML; nicht: PDF) bitten: [...] Falls diese Informationen in angemessener Form bereits Online verfügbar sind wäre ich Ihnen für einen Link sehr dankbar. Sollten für die Bereitstellung dieser Daten Kosten jenseits von 20 Euro entstehen, bitte ich Sie mir dies vor der Bereitstellung mitzuteilen. Falls Sie nicht der angemessene Empfänger dieser Nachricht sind, so bitte ich sie um eine Weiterleitung. Ich darf Sie bitten mir den Eingang dieser Anfrage baldmöglichst zu bestätigen. Mit freundlichen Grüßen,

Im Mittelteil sollte das erfragte Dokument natürlich möglichst präzise beschrieben werden (bei Daten etwa durch Angabe der notwendigen Spalten und Detailtiefe). Danke an Guido Strack vom Whistleblower-Netzwerk für die Tipps beim verfassen der Anfrage (die im Orginal ans BMBF ging)!

Der Herbst im Parlament

2010-10-26T00:00:00-07:00

Mapping-Projekt des Abends: mit welchen Themen hat sich der Bundestag in den vergangenen Monaten beschäftigt? Auf der Basis des parlamentarischen Dokumentenservers, eines kleinen Scripts und theJit hier die visuelle Agenda des bisherigen Spätsommers/Herbsts: Im Prinzip kann man vier große Debatten ausmachen: Hartz 4, Atomkraft, Stuttgart 21 und die Gesundheitspolitik. Die Grafik gibt es auch in Interakt, allerdings basiert sie auf einem fetten Datenbrocken, den ich niemandem in den Browser laden will. Einen Datenbank-Dump der Themencluster gibts natürlich gern. Die Visualisierung basiert zwar nicht auf compuccino-Code, allerdings durfte ich dort im Juli viel Erfahrung mit dem DIP-System (aus dem die Daten stammen) sammeln. Danke.

Offener Haushalt

2010-09-13T00:00:00-07:00

Eines der naheliegendsten Projekte zum Thema OpenData ist die Analyse der öffentlichen Haushalte und der Staatsausgaben. Bei diesem Thema kann klar gezeigt werden, welchen Wert Transparenz für staatliches Handeln haben kann - denn der Haushalt ist in seiner konventionellen Aufbereitung vollkommen unzugänglich. Einen ersten Anfang haben wir jetzt mit der Seite offenerhaushalt.de gemacht, die einen Teil der Haushaltsdaten aus den Jahren 2003-2010 aufbereitet und visualisiert. Das ganze ist - vor allem in der Darstellung - noch recht rudimentär und eher als ein Angebot zur Weiterentwicklung denn als ein fertiges Portal zu verstehen. Offenerhaushalt.de soll, wenn das so klappt wie wir es uns aktuell vorstellen, nicht nur eine Basis für weitere, komplexere Visualisierung und Analysen bieten, sondern auch eine Art Knotenpunkt für journalisitische und politische Arbeit rund um den Haushalt werden. Nicht nur erhält durch die Seite zum ersten Mal jeder Haushaltsposten eine URL, wir wollen zu jedem Punkt auch gezielt eine Linksammlung, Pingbacks und in Zukunft auch eine Wikiseite zusammenstellen. Das alles funktioniert natürlich nur dann, wenn es uns gelingt andere für die Seite und das Projekt zu begeistern. Dazu sollen auf der technischen Ebene neben dem offenen Quellcode auch umfassende Exportfunktionen einen Beitrag leisten: so ist jeder Interessierte eingeladen, selbst mit den Informationen zu spielen und eventuell zu eigenenen Resultaten zu gelangen. Auch können so sehr einfach die Anpassungen vorgenommen werden, die für Landes- oder Gemeindeadaptionen der Seite notwendig wären. Seit das Projekt zum ersten Mal durchgesprochen wurde hat es fast neun Monate bis zum Start gedauert. Auch das müssen wir noch besser hin bekommen, denn technisch stecken in der Seite kaum mehr als zwei Wochen Arbeit.

Gesetze: What's an App for that?

2010-08-15T00:00:00-07:00

Wenn ich zur Zeit interessante Menschen treffe (und das passiert ziemlich oft), nerve ich sie nach durchschnittlich zehn Minuten mit der Frage:

Ich habe hier Daten, was sollen wir daraus bauen?

Das betrifft konkret zum Beispiel die aktuellen Texte der deutschen Gesetze auf Bundesebene. Auf meiner Platte schimmelt nämlich ein guter Scrape der Texte vor sich hin. Natürlich kann man die einfach ins Netz dumpen, aber das hilft niemandem. Also schreie ich es jetzt ins Internet: Was ist die Killer-App für Gesetzestexte? Ein paar Ideen:

Schicke Darstellung und Volltext-Suche: gibt es. Juris tut es, LexisNexis tut es, dejure tut es. Und obwohl ich ein politisches Problem mit deren Praktiken habe (vor allem mit meinen Freunden beim Bundesanzeiger-Verlag), ist die Umsetzung oft nicht völlig grottig (außer die vom Bundesanzeiger-Verlag).
Kommentare: das müsste irgendwie aufs iPad (oder seine politisch korrekten Geschwister), um dann von lauter Jura-Erstsemestern zusammen-crowd-gesourced zu werden. Aber ich weiß nicht wie ich 5000 Jungjuristen für diesen Plan begeistern kann.
Prozesstool: Zu jedem Gesetz werden zusätzlich alle Aktivitäten angezeigt, die auf eine Änderung des Gesetzes abzielen. Das können wirkliche Initiativen in Bundes- oder Landtagen sein, aber auch Gesetzentwürfe von Fraktionen und sogar Bürgerbegehren. Das ist gewissermaßen die nerdige Version von Liquid Democracy - anstatt den Zugang über ein politisches Ziel zu wählen, würde hier eine politische Debatte über die sachliche Ebene gegliedert. Eben wegen dieser Nerdigkeit habe ich auch hier meine Zweifel, dass das Projekt viele Fans finden würde.

Deshalb also die Frage: was ist die App dafür? Was macht man mit Gesetzen - und vor allem: wofür würden sich Juristen so richtig schämen?

Ein neues Blahg, ein besseres Blahg.

2010-08-15T00:00:00-07:00

So, hier mal wieder ein Blog. Diesmal unter anderem mit dem guten Vorsatz, hier ab und zu Texte zu den Projekten zu veröffentlichen, an denen ich aktuell Arbeite. Dazu gehört aktuell neben dem Thema Liquid Democracy/Adhocracy zum Beispiel das Datenpaketmanagement in CKAN (und dem kleinen Brudet datapkg), die OpenData-Fassung des deutschen Bundeshaushalts sowie OpenData-Vorhaben zu bundesdeutscher Statistik und Gesetzen. Aber zu all diesen Punkten wird es in der nächsten Zeit nochmal einzelne Postings geben.

Aktion Datenpaten

2010-08-15T00:00:00-07:00

Die gute Nachricht: Anfang September wird die Stadt Berlin in einem Wettbewerb zur Entwicklung spannender Stadt-Anwendungen aufzurufen. Ein Thema wird dabei Demokratie sein, also die Nutzung öffentlicher Daten für partizipative Projekte. Die Idee hatten wir auch schon, deshalb würden wir das Projekt gerne unterstützen. Die schlechte Nachricht: Wer dafür eine gute Stadt-App oder einen Mashup bauen will, braucht Daten. Andernorts haben deshalb Städte im Rahmen von Apps4Democracy-Wettbewerben einige ihrer Datenbanken zur Verfügung gestellt. Nicht so Berlin, hier fehlt der Open Data-Aspekt bisher: eine offizielle Freigabe von Daten ist bislang nicht vorgesehen. Das wollen wir ändern. Um eine Datenbasis für Berlin zu schaffen müssen wir erst mal wissen, was wo bereit steht. Und das weiß niemand so genau. Dank Fraunhofer FOKUS haben wir jedoch zumindest ein paar Hinweise, wo man mal Fragen könnte. Weil das Nachfragen aber eine Menge Arbeit ist, brauchen wir Hilfe: Wir brauchen Datenpaten, die sich einer bestimmten Informationsquelle in Berlin annehmen und herausfinden, welche Daten unter welchen Bedingugnen verfügbar sind. Wie geht das? Eigentlich ganz einfach:

Wählt euch aus dieser Liste eine Informationsquelle, die ihr adoptieren wollt. Tragt euch in die Tabelle ein.
Auf der verlinkten Seite findet ihr Kontaktinformationen, normalerweise E-Mail oder Telefonnummer. Von denen brauchen wir folgende Informationen:
- Welche Informationen sind verfügbar?
- In welchen Formaten liegen die vor? In welchen Formaten könnten sie bereit gestellt werden? (wir mögen: CSV, JSON, XSL, XML, RTF, sogar DOC. Nicht so gut: PDFs, kaputte Webinterfaces)
- Unter welchen Bedingungen dürfen die Daten genutzt werden? Sind die Daten vollkommen offen? Ist eine Quellennennung notwendig? Ist wenigstens eine private Nutzung gratis möglich?
Bitte seid höflich. Wenn euer Gesprächspartner interessiert ist, könnt ihr ihnen ja gleich etwas über Open Data erzählen. Heizdecken verkaufen wir aber nicht.
Tragt das Resultat eures Gesprächs wieder in die Datenseite auf offenedaten.de ein. Falls ihr Daten zugeschickt bekommt (Spreadsheets etc.): die können wir gerne bei den Open Data Labs - unserem Archiv-Server - speichern. Kontakt.

Was wollen wir damit erreichen? Wir brauchen erstmal eine Liste aller verfügbaren Informationen in der Stadtverwaltung. Auf dieser Basis können wir dann für die Freigabe bestimmter Datensätze eintreten und mit Politik und Verwaltung in ein Gespräch kommen. Leider hat nicht mal die Stadtverwaltung selbst eine solche Liste, das heißt: was wir tun ist also nicht nur für das OpenData-Anliegen dringend notwendig, sondern auch für die Stadt interessant. Denn wer weiß: vielleicht wird so noch der eine oder andere Beamte auf die Information aufmerksam, die in der Abteilung nebenan gehalten wird. Eine EU-Richtlinie aus dem Jahr 2003 verpflichtet im übrigen alle Behörden der europäischen Mitgliedstaaten solche Inhaltverzeichnisse (Information Asset Register) vorzuhalten. Diese Minimalforderung ist in Berlin, ja in ganz Deutschland fast nirgends umgesetzt. Welche Schätze liegen also in den Datenbeständen der öffentlichen Verwaltung in Berlin verborgen? Helft uns, es herauszufinden: ein Telefonanruf dauert nicht fünf Minuten - und zusammen können wir so bis Anfang September das erste Berliner Informationsregister schaffen!