• Anna wants to compare real estate prices in Bern and Zurich. She stumbles upon an open data portal of Switzerland. There is a dataset of the Statistical Office of the City of Zurich covering the real estate prices, unfortunately there is no such dataset for Bern. Anna will try to find those using the search.
• Thomas wants to have a look at the Outcomes of the recent votings (“Ständeratswahlen”) in Zürich and wants to know how each of the prominent politicians performed.

We have taken the assumption, that a user of such a portal is interested in certain data, but doesn’t know where to find it. They are not familiar with the portal nor are they considered “power users” with special knowledge about the data or metadata.

To make things more exciting we have written this blog post with two authors: Stefan Oderbolz and Thomas Ebermann. Stefan will try to convince you that a search based on metadata will help Anna greatly to find her the right dataset to compare real estate prices. Thomas will try to convince you that a search on primary data will work better for Thomas and allow him to quickly find the right dataset.

While we rolled a dice who will have to write which part, we will try as hard as we can to convince you - the reader - that our opinion is the best. Buckle up and enjoy the ride.

Why we need Metadata-based search

by Stefan Oderbolz

Metadata-based search means, the search engine, that powers a portal search has indexed documents based on a specified metadata schema. Documents have metadata fields like title, description, keywords or temporal and spatial coverage.

In its most basic form, a query for “Zurich real estate” will return all documents, that have metadata values matching the “Zurich” “real” and “estate”.
“Zurich” will be covered by the spatial coverage field. “Real” and “estate” resp. “Real estate” are either found as keywords or as part of the title and description of the dataset.

Anna’s search will return 2 results:

• The aforementioned dataset of the Statistical Office of the City of Zurich
• A dataset of the Canton of Zurich, that contains the real estate data for the whole Canton (incl. The City of Zurich)

No further results are shown. The analogous search “Bern real estate” doesn’t return any datasets.

This example shows the strength of the metadata-based search: if the metadata has good quality, you get the correct datasets. And if the search does not return anything, you can be confident, that the dataset does not exist (by-the-way: this would be a good time to start a “data request” for this data, so next time you search, you’ll find both datasets right away).

I think this is an important message: getting zero results is actually a good thing. You know it’s not there. This heavily relies on the assumption that the metadata is good and correctly indexed.

A neatly organized catalogue helps the users to browse it, without even entering search terms. You can show categories for your datasets, to give information about what kind of things you can find on the portal.

A neatly organized catalogue helps the users to browse it, without even entering search terms. You can show categories for your datasets, to give information about what kind of things you can find on the portal.

With keywords on each dataset you can even create this on a more fine-grained level. A user might discover similar datasets, that share the same keyword (see screenshot below). Like this a user has the possibility to “move” seamlessly in the catalogue and discover the available datasets.

Last but not least the metadata-based approach forces data publishers to deliver high quality metadata for each dataset. Otherwise nobody will find and use the datasets. This incentive is important to keep in mind. If we simply outsource the task to the computer, we lose all the valuable knowledge the publishers have of their data. For the closed world of a data portal, this is a source we can not afford to lose.

The catch-all primary-data approach might be the right choice for something vast like the web, but not for the small-ish, precise area of a data catalogue. But I’ll let Thomas take it from here and convince you otherwise.

Why we will need primary-data search

By Thomas Ebermann

Let's go back in time. Let’s go way back, even before pokemon go was popular, maybe let's go even to a time where pokemon didn’t even exist. In that distant past somewhere around 1996 we lived in a different world. In a world without Trump and chaos. In a world where there things were somewhat ordered.

If you wanted a book you went to your local library - and if you had an old library like me: without a computer, then could go to an even then weird place, called an index-catalogue, where you could look for books containing a certain author, or you could look at books for a certain genre, for example fantasy literature. If you felt even a bit adventurous you could as well wonder through the library only to find that all of the books were nicely put into categories and have been alphabetized by the authors name. It was a nice experience. But it was also a tedious one.

The web was no different. We were living at the time, where looking for a website was really easy. You just had to do the same things that you did in your library. Go to an index-catalogue - I mean Yahoo - and then select the right category, for example Recreation - Health and Sports and there you would find all of the websites about soccer or american football. It was simple, it was effective, life was good.

But of course someone had to ruin it. It was us, we just liked making websites too much. More and more websites emerged, and soon there was no simple fast way to categorize them all. It was like a library that instead of receiving 10 new books a day all of a sudden received 1 Million a day. Nobody could categorize it all, nobody could read it all.

And then Google came to save us. It was drastic. They had thrown away all of the categories, folders and myriads of subfolders, that librarians had worked so hard on. Instead they just gave us a search box. That was it. And the most ridiculous thing happened. People actually liked it. The results were relevant and fast. It was almost magic, like a librarian that knew it all. Like a librarian that had actually read all the books and knew what was inside them.

Moving forward 20 years here we stand, and I still feel reminded of my good old library when I think of opendata.swiss. Looking at the nearly 7000 datasets on opendata swiss it makes me proud how fast the amount of datasets has risen. In 2016 the amount of datasets was nearly half that number, I still remember that website having a big two...something on the frontpage.

While we cannot simply assume that the amount of open datasets will rise as quickly as the amount of websites or internet users, I still expect that rather sooner than later we will have 100 000 datasets on open data worldwide. At this point it will definitely be a burden to go and find these datasets via a catalogue. We will definitely rely on the big search box more.

We will probably expect even more from that searchbox. Similarly to Google, who has become a librarian who has read all the websites, we probably will also want a librarian who has read all of our datasets.

So when I type in “Limmatstrasse” into that box, I will somehow expect to find every dataset that has to do with Limmatstrasse. Probably those that are really popular to be on the top of my search results and those that are less popular to be at the back.

While I eventually might want to facet my search, so for example just have datasets on related to politics, I might as well enter “Limmatstrasse Kantonsratswahlen 2018 Mauch” or something into the box and find what I needed, when I am looking for a dataset containing the candidates and some sort of breakdown on the regions.

Being a lazy person I might expect, that a click on that search result will take me directly into the relevant rows of the dataset, just to verify that that's the right thing that I want.

Yet all of these things are not possible when relying only on a metadata for my search. First of all, I will probably get lost in the catalogue when trying to go through 100 000 datasets. Second, I probably won’t find even one dataset containing Limmatstrasse, because nobody cared to enter myriads of different streets into the metadata. It's just not practical. The same goes for all involved candidates. Nobody has the time nor resources to annotate the dataset that thoroughly. Finally it's simply impossible to point me at the right row in a dataset when all I have is just some metadata.

So while everybody who submitted his dataset did a fairly good job at annotating it, it's simply not enough to fulfill my needs. I need a librarian who, similarly to Google back in the 90ties, has a radically different approach. I will need a librarian who has read all of the datasets that are in the library and can point me to the right dataset, even if my query very rather fuzzy. In other words I need a search that has indexed all of the primary data.

Conclusion: best of both worlds

So there we are, you have seen the high flying arguments from both worlds while each us us has swiped the negative aspects of each solutions under the table. So here they are:

• Downsides of Metadata for search:
  • It’s relevant when you want to make sense out of the primary data but it will never be as rich as the primary data. It obviously does not contain some aspects that a user might be searching for.
  • There is a constant dissonance between what the users are searching for and how we tag things (e.g. “weather” vs. meteodata, or “Lokale Informationen” vs. Zürich)
• Downsides of Primary Data for search:
  • On the other side primary data might match a lot of relevant search terms that the user is searching for, but it is simply not good for abstraction (e.g. I want all the data from all swiss cities).
  • Creating such ontologies from primary data is very difficult: Thus automatically tagging datasets based on primary data into categories like health or politics is hard.
  • Using only primary data we might also run into the problem of relevancy. When a user is searching for a very generic keyword like Zürich, and then finds myriads or results that have the word Zürich and yet cannot facet his search down only to political results is frustrating.

Precision and Recall

So of course from our perspective a perfect search will have to embrace both worlds. To formalize that a bit let's think about recall and precision.

• Recall: How many datasets that are relevant have been found? (If 10 are potentially relevant but the search returns only one, thats a low recall)
• Precision: How many datasets that have been returned are relevant? (If 10 datasets have been returned, but only 1 is actually relevant, thats a low precision)

So in an ideal world we would want a search to have both, but the reality today looks more like this:

So while metadata search has a high precision, because you only get what you search for, it lacks in recall, often not finding all of the relevant datasets, just because they have been tagged badly. On the other hand a primary-data search gives you a high recall, e.g. returning all of the datasets that somewhere have the word “Zürich” in it, but has a low precision because probably most of the search results are not really relevant for you.

There are also two other arguments where the primary data and meta-data approach differ: On one hand indexing primary data allows us to search for “Limmatstrasse Kantonsratswahlen 2018 Mauch”, so giving us a very fine grained information retrieval. On the other hand just using primary data to “browse” a catalogue is not useful. In contrast using metadata, searching for “Politics” or “Votings” we rather get a very broad result set. Yet using those tags to browse into “Politik” and “Abstimmungen” might give us a much wider overview of available datasets that go beyond our little search.

That's why we think that in the future we should embrace indexing primary data of our datasets while combining it smartly with the metadata information, to really get the best of both world. While this might not be easy, especially having a high precision and a high recall, we think it is a challenge worth trying. I am very sure that it will improve the overall user experience. After all we want all these precious datasets to be found and used.

CKAN is an open source management system whose main goal is to provide a managed data-catalog-system for Open Data. It is mainly used by public institutions and governments. At Liip we use CKAN to mainly help governments to provide their data-catalog and publish data in an accessible fashion to the public. Part of our work is supporting data owners to get their data published in the required data-format. We’re doing this by providing interfaces and useable standards to enhance the user experience on the portal to make it easier to access, read and process the data.

Metadata-Catalog

Out of the box CKAN can be used to publish and manage different types of datasets. They can be clustered by organizations and topics. Each dataset can contain resources which themself consist of Files of different formats or links to other Data-Sources. The metadata-standard can be configured to represent the standard you need but the Plugin already includes a simple and useful Meta-Data-Standard that already can get you started. The data is saved into a Postgres-Database by default and is indexed using SOLR.

Powerful Action-API

CKAN ships with an API which can be used to browse through the metadata-catalog and create advanced queries on the metadata. With authorization the API can also be used to add, import and update data with straight-forward requests.

Cli-Commands

The standard also includes a range of Cli-Commands which can be used to process or execute different tasks. Those can be very useful, e.g. to manage, automate or schedule backend-jobs.

Preview

CKAN offers the functionality to configure a preview of a number of different file-types, such as tabular-data (e.g. CSV, XLS), Text-Data (e.g. TXT), Images or PDFs. That way interested citizens can get a quick overview into the data itself without having to download it first and having to use local Software to merely get an better idea on how the data looks.

Plugins

While CKAN itself acts as a CMS but for data, it really shines when making use of its extensibility and configure and develop it to your business needs and requirements. There is already a wide-ranging list of plugins that have been developed for CKAN, which covers a broad range of additional features or make it easier to adjust CKAN to fit your use cases and look and feel. A collection of most of the plugins can be found on CKAN-Extensions and on Github.

At Liip we also help maintaining a couple of CKAN's plugins. The most important ones that we use in production for our customers are:

ckanext-harvest

The ckanext-harvest-plugin offers the possibility to export and import data. First of all, it enables you to exchange data between Portals that both use CKAN.

Furthermore we use this plugin to harvest data in a regular manner from different data-sources. At opendata.swiss we use two different types of harvesters. Our DCAT-Harvester consumes XML-/RDF-endpoints in DCAT-AP Switzerland-Format which is enforced on the Swiss Portal.

The Geocat-Harvester consumes data from geocat.ch. As the data from geocat is in ISO-19139_che-Format (Swiss version of ISO-19139) the harvester converts the data to the DCAT-AP Switzerland format and imports it.

Another feature of this plugin we use, is our DCAT-AP endpoint, to allow other portals to harvest our data and also serves as an example to Organizations that want to build an export that can be harvested by us.

ckanext-datastore

The plugin ckanext-datastore stores the actual tabular data (opposing to 'just' the meta-data) in a seperate database. With it, we are able to offer an easy to use API on top of the CKAN-Standard-API to query the data and process it further. It provides basic functionalities on the resource-detail-page to display the data in simple graphs.

The datastore is the most interesting one for Data-Analysts, who want to build apps based on the data, or analyze the data on a deeper level. This is an API-example of the Freibäder-dataset on the portal of Statistik Stadt Zürich.

ckanext-showcase

We use ckanext-showcase to provide a platform for Data-Analysts by displaying what has been built, based on the data the portal is offering. There you can find a good overview on how the data can be viewed in meaningful ways as statistics or used as sources in narrated videos or even in apps for an easier everyday life. For example you can browse through the Showcases on the Portal of the City of Zurich.

ckanext-xloader

The ckanext-xloader is a fairly new plugin which we were able to adopt for the City of Zurich Portal. It enables us to automatically and asynchronously load data into the datastore to have the data available after it has been harvested.

CKAN Community

The CKAN-Core and also a number of its major plugins are maintained by the CKAN-Core-Team. The developers are spread around the globe, working partly in companies that run their own open-data portals. The community that contribute to CKAN and its Plugins is always open to developers that would like to help with suggestions, report issues or provide Pull-Requests on Github. It offers a strong community which helps beginners, no matter their background. The ckan-dev-Mailing-List provides help in developing CKAN and is the platform for discussions and ideas about CKAN, too.

Roadmap and most recent Features

Since the Major-Release 2.7 CKAN requires Redis to use a new system of asynchronous background jobs. This helps CKAN to be more performant and reliable. Just a few weeks ago the new Major-Release 2.8 was released. A lot of work on this release went into driving CKAN forward by updating to a newer Version of Bootstrap and also deprecating old features that were holding back CKAN's progress.

Another rather new feature is the datatables-feature for tabular data. Its intention is to help the data-owner to describe the actual data in more detail by describing the values and how they gathered or calculated.

In the Roadmap of CKAN are many interesting features ahead. One example is the development of the CKAN Data Explorer which is a base component of CKAN. It allows to converge data from any dataset in the DataStore of a CKAN instance to analyze it.

Conclusion

It is important to us to support the Open Data Movement as we see value in publishing governmental data to the public. CKAN helps us to support this cause by working with several Organizations to publish their data and consult our customers while we develop and improve their portals together.

Personally, I am happy to be a part of the CKAN-Community which has always been very helpful and supportive. The cause to help different Organizations to make their data public to the people and the respectful CKAN-Community make it a lot of fun to contribute to the code and also the community.

In the area of Open Government Data (OGD) the metadata standard that is widely used is DCAT. Especially the application profiles (“DCAT-AP”), which are a specialization of the DCAT standard for certain topic areas or countries. For CKAN the ckanext-dcat extension provides plugins to expose and consume DCAT-compatible data using an RDF graph. We use this extension on opendata.swiss and data.stadt-zuerich.ch, as it provides handy interfaces to extend it to our custom data model. I’m a regular code contributor to the extension.

When Dan Brickley working for Google, opened an issue on the DCAT extension about implementing schema.org/Dataset for CKAN, I was very excited. I only learned about it in December 2017 and thought it would be a fun feature to implement over the holidays. But what exactly was Dan suggesting?

With ckanext-dcat we already have the bridge from our relational (“database”) model to a graph (“linked data”). This is a huge step enables new uses of our data. Remember the 5 star model of Sir Tim Berners-Lee?

Source: http://5stardata.info/en/, CC-Zero

So with our RDF, we already reached 4 stars! Now imagine a search engine takes all those RDFs, and is able to search in them and eventually is even able to connect them together. This is where schema.org/Dataset comes in. Based on the request from Dan I built a feature in ckanext-dcat to map the DCAT dataset to a schema.org/Dataset. By default it is returning the data as JSON-LD.

Even if you’ve never heard of JSON-LD, chances are, that you’ve used it. Google is promoting it with the keyword Structured Data. At its core, JSON-LD is a JSON representation of an RDF graph. But Google is pushing this standard forward to enable all kinds of “semantic web” applications. The goal is to let a computer understand the content of a website or any other content that has JSON-LD embedded.
And in the future, Google wants to have a better understanding of the concept of a “dataset”, or to put it in the words of Dan Brickley:

It's unusual for Google to talk much about search feature plans in advance, but in this case I can say with confidence "we are still figuring out the details!", and that the shape of actual real-world data will be a critical part of that. That is why we put up the documentation as early as possible. If all goes according to plan, we will indeed make it substantially easier for people to find datasets via Google; whether that is via the main UI or a dedicated interface (or both) is yet to be determined. Dataset search has various special challenges which is why we need to be non-comital on the details at the stage, and why we hope publishers will engage with the effort even if it's in its early stages...

This feature is deployed on the CKAN demo instance, so let’s look at an example. I can use the API to get a dataset as JSON-LD. So for the dataset Energy in Málaga, I could build the URL like that:

• Append “.jsonld”
• Specify “schemaorg” as the profile (i.e. the format of the mapping)

Et voilà: https://demo.ckan.org/dataset/energy-in-malaga.jsonld?profiles=schemaorg

This is the result as JSON-LD:

{
  "@context": {
    "adms": "http://www.w3.org/ns/adms#",
    "dcat": "http://www.w3.org/ns/dcat#",
    "dct": "http://purl.org/dc/terms/",
    "foaf": "http://xmlns.com/foaf/0.1/",
    "gsp": "http://www.opengis.net/ont/geosparql#",
    "locn": "http://www.w3.org/ns/locn#",
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "schema": "http://schema.org/",
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "time": "http://www.w3.org/2006/time",
    "vcard": "http://www.w3.org/2006/vcard/ns#",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@graph": [
    {
      "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9",
      "@type": "dcat:Dataset",
      "dcat:contactPoint": {
        "@id": "_:N71006d3e0205458db0cc7ced676f91e0"
      },
      "dcat:distribution": [
        {
          "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/c3c5b857-24e7-4df7-ae1e-8fbe29db93f3"
        },
        {
          "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/5ecbfa6c-9ea0-4f5f-9fbe-eb39964c0f7f"
        },
        {
          "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/b74584c7-9a9a-4528-9c73-dc23b29c084d"
        }
      ],
      "dcat:keyword": [
        "energy",
        "málaga"
      ],
      "dct:description": "Some energy related sources from the city of Málaga",
      "dct:identifier": "c8689e49-4fb2-43dd-85dd-ee243104a2a9",
      "dct:issued": {
        "@type": "xsd:dateTime",
        "@value": "2017-06-25T17:02:11.406471"
      },
      "dct:modified": {
        "@type": "xsd:dateTime",
        "@value": "2017-06-25T17:05:24.777086"
      },
      "dct:publisher": {
        "@id": "https://demo.ckan.org/organization/f0656b3a-9802-46cf-bb19-024573be43ec"
      },
      "dct:title": "Energy in Málaga"
    },
    {
      "@id": "https://demo.ckan.org/organization/f0656b3a-9802-46cf-bb19-024573be43ec",
      "@type": "foaf:Organization",
      "foaf:name": "BigMasterUMA1617"
    },
    {
      "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/b74584c7-9a9a-4528-9c73-dc23b29c084d",
      "@type": "dcat:Distribution",
      "dcat:accessURL": {
        "@id": "http://datosabiertos.malaga.eu/recursos/energia/ecopuntos/ecoPuntos-23030.csv"
      },
      "dct:description": "Ecopuntos de la ciudad de málaga",
      "dct:format": "CSV",
      "dct:title": "Ecopuntos"
    },
    {
      "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/c3c5b857-24e7-4df7-ae1e-8fbe29db93f3",
      "@type": "dcat:Distribution",
      "dcat:accessURL": {
        "@id": "http://datosabiertos.malaga.eu/recursos/ambiente/telec/201706.csv"
      },
      "dct:description": "Los datos se corresponden a la información que se ha decidido historizar de los sensores instalados en cuadros eléctricos de distintas zonas de Málaga.",
      "dct:format": "CSV",
      "dct:title": "Lecturas cuadros eléctricos Junio 2017"
    },
    {
      "@id": "https://demo.ckan.org/dataset/c8689e49-4fb2-43dd-85dd-ee243104a2a9/resource/5ecbfa6c-9ea0-4f5f-9fbe-eb39964c0f7f",
      "@type": "dcat:Distribution",
      "dcat:accessURL": {
        "@id": "http://datosabiertos.malaga.eu/recursos/ambiente/telec/nodos.csv"
      },
      "dct:description": "Destalle de los cuadros eléctricos con sensores instalados para su gestión remota.",
      "dct:format": "CSV",
      "dct:title": "Cuadros eléctricos"
    },
    {
      "@id": "_:N71006d3e0205458db0cc7ced676f91e0",
      "@type": "vcard:Organization",
      "vcard:fn": "Gabriel Requena",
      "vcard:hasEmail": "gabi@email.com"
    }
  ]
}

Google even provides a Structured Data Testing Tool where you can submit a URL and it will tell you if the data is valid.

Of course knowing the CKAN API is good if you’re a developer, but not really the way to go if you want a search engine to find you datasets. So the JSON-LD that you can see above, is already embedded on the dataset page (check out the testing tool with just the dataset URL) . So if you have enabled this feature, every time a search engine visits your portal, it’ll get structured information about the dataset it crawls instead of simply the HTML of the page. Check the documentation for more information, but most importantly: if you’re running CKAN, give it a try!

By the way: if you already have a custom profile for ckanext-dcat (e.g. for a DCAT application profile), check my current pull request for a mapping DCAT-AP Switzerland to schema.org/Dataset.

Generally disagreeing about any kind of data sharing, I realized my behavior was mostly based on fear. Fear is a major impediment to anything innovative and to any kind of change. Why did I change my mind about open data? It is about differentiating between public and private data, and about the fact that data made public are first of all edited.

New work – new ideas

In November 2015, I started working at Liip and I had a lot of new projects and inputs. The core of my work is the same, I completely changed field though. I stand now in the middle of a flow of innovative ideas and energy, which is very motivating and helps me be constantly open-minded.

One of my projects, last spring, was the coordination of Liip's involvement at the annual opendata.ch conference. No, I cannot communicate about anything if I don't understand it! Otherwise I would write complete bulls**t, people would notice it and Liip would lose all credibility on the subject. In other words, I had to know what I was talking about in order to be able to talk about it.

Fear & suspicion, people will be stalking me and CFF tickets will get more expensive

I used to completely disagree on any kind of open data. I mean, why, on Earth, would I be okay to share my personal data with the rest of the world?

Seriously, I was sure that, if I collaborate with the CFF surveys, tickets will get more expensive between Geneva and Lausanne, because they will know my commuting habits. I was convinced that Swisscom will soon be selling my personal data to private polls. If I use a MBudget Card, some people will be stalking me as they know that I always go grocery shopping at the same Migros.

Fear brings fear. It is a major impediment to anything innovative and to any kind of change. The first step to any change of perspective was me realizing that my reaction was based on some purely irrational feeling instead of rational information.

Let's get started with some reading!

Knowledge the best enemy of fear: What is actually ‘open data' ?

My education to open data started with learning about the projects that Liip developed (like the open data catalogue of the city of Zurich or the project with the Swiss Federal Archive). I discussed with my colleagues, but the concept of open data remained difficult to grasp.

What is concretely open data?

Step 1: A definition:

The definition of open data as given by the opendefinition.org

“Open data and content can be freely used, modified, and shared by anyone for any purpose”

As it is very general, the full open definition gives a detailed list of attributes. It is a bit of an unfriendly reading, the open data handbook provides a summary of the most important aspects:

“Availability and Access: the data must be available as a whole and at no more than a reasonable reproduction cost, preferably by downloading over the internet. The data must also be available in a convenient and modifiable form.

Re-use and Redistribution: the data must be provided under terms that permit re-use and redistribution including the intermixing with other datasets.

Universal Participation: everyone must be able to use, re-use and redistribute – there should be no discrimination against fields of endeavor or against persons or groups. For example, ‘non-commercial' restrictions that would prevent ‘commercial' use, or restrictions of use for certain purposes (e.g. only in education), are not allowed.”

The important thing to remember is that it is a type of content completely available to anyone – public or private sector or even an anonymous quidam – and for any kind of purpose .

Step 2: Private data is not public data

I find important to differentiate between private and public data. When I heard about open data, I felt my privacy instantly threatened. However, opening public data poses no threat to my privacy.

Take the example of cadastral plans, they are available on request. A formal petition to the right administrative service would provide you the info. Opening cadastral plans merely mean saving people working with it the time necessary for the administrative hurdle.

In other words public data is often already available through an administrative process and in an inconvenient format. Opening public data mostly signifies processing and editing them in a convenient format and leaving them in a digital library. Opening public data is about creating a digital library, allowing people to find them without the administrative process.

Private data is one's individual data, for example, the data-gathered by your period application, your MBudget card, your mobile phone's GPS tracking. This data is usually under confidentiality.

Opening private data, is not only about making it accessible, but also about editing it, to make sure that it cannot be linked to anyone.

What if open data was beneficial to the community?

Commuting to Geneva, I used to be angry with the CFF, because my Intercity Train was poorly connected to my inter-regio train which lead to me losing 15 to 20 minutes twice a day. Spending 2 hours, 2 hours 30 minutes or 3 hours to commute makes a huge difference. What if the CFF knew that a significant amount of commuters take these same trains as I did? They could delay the train 5 minutes and I would be happier everyday because my travel would be shorter! What if a mobile company shared its data about the mobility of people and made these data available to the CFF? What if I answered the poll? Or better, what if, instead of spending money on a poll, the CFF could access data of commuters? The data quality might be higher and more relevant!

Urbanism: Pully as a case study

The city of Pully is pioneering in the domain with its urban project in collaboration with Swisscom. The project team is analysing the traffic – car, public transportation, bike or pedestrian – based on data provided by Swisscom's mobile network. ( More info in French about this project).

The city of Pully saved the investment necessary for a poll and had reliable data available. Processed to be anonymized, this kind of data is not a threat to my privacy. In this case, opening the data is beneficial to the whole community.

The objective of this project is to develop the urbanisation of the city according to people's real needs and not to any lobby. It could result in the creation of bike lanes or an improvement of traffic flows.

Pully – Photo Credit l'Avenue Digital Media

Conclusion : open data supports innovation

Sometimes I hear people disagreeing strongly against the concept of open data. I hear fear and threat. The discussion very often goes towards an emotional level rather than staying pragmatic. I find it difficult to rationally fight against emotional argument. First of all, I wish people against open data could make the difference between public and private data. Opening public data means the digitalisation of an already existing public data, ultimately saving public institution's time.

Secondly, I wish they could realise that sharing information is beneficial to the community. The potential benefit of open data is greater than its threat. Opening data means, processing data, editing and anonymising it to make it available. Open data is the necessary basis of innovation and of a general increase of our quality of life.

At the moment, data can be made available, mostly by investing money (for a poll or negotiating with a company belonging data). In other words, universities, start-ups or associations are restricted to the data they can find or buy. Do we want to live in a world where innovation is driven by companies having the budget to pay for data?

Further Information:

Listen to this podcast, welcoming Pia Waugh, an open data expert and advocate who explains all to Genevieve Jacobs on ABC Radio Canberra.

When the Apple Watch came out, a few Liipers had the idea to make an app for it because having the next departures on the wrist was a perfect use case for this kind of device. The app received quite a lot of attentions in Swiss newspapers and received a Silver in the best of swiss apps in the category “Wearables & New Devices”. Since the Android world deserved also our attention, we made the app available for Android and Android Wear watches. The app is downloadable on the Play Store.

Do you have time for coffee before your next public transportation? Get the app!

Departures at a glance

The particularity of the app is to focus on giving the quickest and easiest look at the timetable of all the means of  transport that are next to you. The app should require very few user interactions : we don't want to enter the start station on the keyboard. This idea fits really well with a smartwatch: you look at you watch and quickly have the information you need. The Android app has extended features with the ability to favorites stations or to search stations.

Departures on Android Wear

Nearby stations on Android Wear

Departures on Android

Nearby stations on Android

Real time timetable thanks to Open Data

Timetable data come from the Open Data platform. The objective is to give the most precise information with real time data if they are available (currently all SSB trains, Zurich area, Lucerne, Geneva, North-Western and Eastern part of Switzerland). More regions are coming with the integration of the new open data portal of SBB

Open source

The code is open source and available on Github under the MIT licence. The plan is to improve continuously the app in the next months. The mains objectives are to make the app working outside of Switzerland and to develop a Widget for the Android home screen. We are very open to contributors if you are interested!

To conclude

Time for Coffee has started first as a web project and is now also an app for the iOS and Android world. It brings a lot of fun to contribute to the open source community with an idea that is useful for everyone in their daily life. The iPhone / Apple Watch app is regularly improved and we want to make the same for the Android version. To know more about the project, you can follow us on twitter. We would be very happy to receive your feedbacks.

More information on app.timeforcoffee !

June 14 at the Casino de Montbenon in Lausanne, business executives, politicians, public officals, researchers and open data enthusiasts from all over Switzerland will meet! As a pioneering company in the area of open data in Switzerland, we will be there with our famous Smoothie Bar.

We are a leading partner of open data

“As a pioneering company in the area of open data in Switzerland, we have helped government agencies, educational institutes and individuals to open their data conceptually and provided them with technical support. Our experience shows: open data is not primarily a technical challenge; it is predominantly a cultural challenge. We are passionate about promoting Switzerland technologically as well as culturally in this area in accordance with international standards. The aim is clear: all of us deserve more open data than what is currently available”, says Andreas Amsler, Business Developer (Liip).

Recent achievement

At the start of 2016, with the Swiss Federal Archives, opendata.swiss, the open data portal of the Swiss public administration. 

In 2015, the catalogue open data for the city of Zurich.

Join us at the Casino de Montbenon and take part in the national debate about open data!

Consult the conference programme.

Daten verändern unsere Welt. Ganz konkret, wenn jemand mit ihnen eine Frage beantworten oder ein Problem lösen kann. Wer Zugang zu Daten hat und berechtigt ist, sie zu nutzen, ist privilegiert. In unserer modernen Informationsgesellschaft können es sich weder die öffentlichen Verwaltungen noch wir als Bürger, Arbeitnehmer und -geber leisten, dass der Zugang zu Behördendaten unnötig beschränkt ist.Öffentliche Amtsstellen und von der öffentlichen Hand finanzierte Leistungserbringer sammeln, erstellen, verwalten und publizieren Daten im Rahmen ihres gesetzlichen Auftrages. Von allen Seiten unbestritten ist, dass diese Daten über ihren Primärnutzen hinaus oft ein hohes gesellschaftliches wie wirtschaftliches Potenzial haben. Unternehmen, Organisationen und einzelne Nutzer können diesen Sekundärnutzen allerdings nur erschliessen, wenn diese Daten für die Allgemeinheit offen zugänglich und frei – das heisst auch kommerziell – wiederverwendbar sind.

Google.ch, local.ch und search.ch nutzen mittlerweile offen verfügbare Sollfahrplandaten der SBB. Apple und andere Dienste verwenden Daten von Swisstopo via OpenStreetMap, und Medien wie Tamedia, NZZ und SRF erstellen regelmässig datenjournalistische Inhalte, die auf offenen Daten basieren. Ebenfalls weitherum bekannt sind Vergleichsdienste wie Comparis.ch, die Sekundärnutzen aus den vom Bundesamt für Gesundheit verwalteten Prämiendaten der Krankenkassen ziehen. Aber nicht nur grosse, etablierte Unternehmen profitieren, sondern viele Startups und KMU, die dank offenen Daten neue Geschäftsmodelle erproben und -felder erschliessen.

Innovative Anwendungen von Anwendern

Das Statistische Amt der Stadt Zürich hat es in der Schweiz auf Gemeindeebene vorgemacht und veröffentlicht seit 2012 pro-aktiv Daten der Stadt Zürich zur freien Wiederverwendung. Die Stadt Zürich stellt die Daten in maschinenlesbarer Form und unter offenen, einfach verständlichen Nutzungsbedingungen zur Verfügung. Einzelne Bürger, Organisationen und Firmen haben aus ihnen verschiedenste . innovative Anwendungen und Dienstleistungen entwickelt. Die Dienstabteilungen der Stadt kümmern sich weiterhin um die Pflege der Rohdaten und beantworten bei Bedarf inhaltliche Fragen der Nutzer. So können Anwender die für ihre Bedürfnisse passenden Anwendungen selbst entwerfen, bauen und weiterentwickeln.

Grundsätzlich sind alle mittels Software interpretierbaren Daten maschinenlesbar. Im Zusammenhang mit offenen Daten stehen aber insbesondere Formate wie CSV, JSON, XML und ähnliche im Fokus. Offene Daten müssen möglichst strukturiert verfügbar sein, um maschinelles Suchen und Sortieren zu erleichtern. Während Formate wie HTML und PDF für den Menschen als Nutzer gedacht sind, lassen sich die dahinter liegenden Informationen nur mit relativ hohem Aufwand für Maschinen nutzbar machen. Anstatt dass die Nutzer bei jeder Aktualisierung von Websites und PDF-Dokumenten im Web selbst die daraus maschinell nutzbaren Daten generieren – und dabei potenziell Fehler machen –, ist es sinnvoll, dass die Daten-Lieferanten immer auch die Rohdaten veröffentlichen. Diese liegen meist schon vor und ihre Veröffentlichung bedeutet keinen substanziellen Mehraufwand.

Auf der Ebene von Bund und Kantonen sind seit 2013 verschiedene Bundesämter und der Kanton Zürich unter Leitung des Schweizerischen Bundesarchivs aktiv. Anfang Februar hat diese Allianz der Willigen als nächsten Schritt opendata.swiss, das zentrale Portal für Schweizer Open Government Data, lanciert. Ihr Wille, Primärdaten in maschinenlesbarer Form, unter einheitlichen Nutzungsbedingungen und standardisierten Metadaten zu erschliessen, verdient Anerkennung und weitere Unterstützung. Mit Genf ist ein weiterer Kanton und mit der SBB auch eine erste Organisationen mit einem staatlichen Auftrag hinzugekommen.

Austausch steigert Qualität und Effizienz

Organisationen, die geeignete Daten offen zu Handen der Allgemeinheit publizieren, profitieren nicht nur von Sekundärnutzungen, sondern auch zugunsten ihres Primärauftrags. Denn die Nutzer geben ihnen inhaltliche Rückmeldungen zur Qualität ihrer Daten. Dass Daten unvollständig, missverständlich oder fehlerhaft sein können, ist normal. Entscheidend ist, dass Fehler bemerkt und behoben werden. Die vergangenen vier Jahre haben gezeigt, dass die Open-Data-Nutzer hier bereit sind, mit zu helfen, wenn ihr Engagement wiederum allen dient. Die konkrete Praxis offener Daten verändert so in der Tendenz die Beziehung zwischen unseren Behörden und uns als Bürgern: aktive Zusammenarbeit ersetzt passive Anspruchshaltung.

Aber nicht nur Private finden offen verfügbare Daten leichter und können sie nutzen, sondern auch die Amtsstellen selbst. Auch diese Erfahrung aus anderen Ländern hat sich in der Schweiz bewahrheitet. Daten werden nicht erst auf einzelne Anfrage hin zusammengestellt und übergeben, sondern stehen jederzeit in einem Katalog zur Verfügung. Daten-Nutzer wie -Lieferanten müssen sich nicht mit immer denselben Anfragen nach Daten beschäftigen, sondern können sich über ungleich spannendere Fragen ihrer Anwendung austauschen. Mich erstaunt nicht, dass dieser Austausch zwischen Daten-Spezialisten auf Lieferanten- und Nutzerseite meist gut funktioniert. Beide arbeiten leidenschaftlich mit Daten und sprechen dieselbe Sprache.

Schaffen wir den Wandel?

Nichtsdestotrotz sind in der Schweiz heute noch viel zu viele für eine offene Publikation geeignete Behördendaten nicht offen zugänglich. In seiner “Open Government Data Strategie 2014–2018” hat der Bundesrat festgehalten, dass Behördendaten ohne unnötige Verzögerung publiziert werden sollen. Dass sich die Entwicklung in diese Richtung beschleunigt, hängt vom guten Willen von Exekutive, Verwaltung und datenpublizierenden Stellen, von der gesetzgeberischen und budgetären Weitsicht der Parlamente, aber auch vom politischen Druck zivil-gesellschaftlicher Akteure und uns Nutzern ab. Egal ob Entwickler, Designer, Journalist, Unternehmer oder Forscher – das Bedürfnis nach offenen und maschinenlesbaren Daten nimmt weiterhin nicht ab. Im Gegenteil.

Benutzerfreundliche Web- und Mobile-Anwendungen beruhen auf offenen Methoden, Interoperabilität sowie Wiederverwendbarkeit von Daten. In der Kombination dieser Faktoren schlummert das grösste Potenzial für Innovation im öffentlichen Sektor.

Leider lässt die Benutzbarkeit von vielen digitalen Behördendiensten noch zu wünschen übrig – sowohl aus Nutzer- wie auch aus Betreibersicht. Das will die US-Regierung ändern. Im «U.S. Digital Services Playbook» hat sie dreizehn bewährte Praktiken aus Privatwirtschaft und öffentlicher Verwaltung zusammengestellt. Gemeinsam angewandt helfen sie Behörden effektive digitale Dienste zu konzipieren, zu bauen und zu betreiben. Basierend auf unserer eigenen, langjährigen Erfahrung mit Behördenprojekten haben wir drei Punkte identifiziert, die entscheidend sind, um zeitgerecht und kostengünstig bessere digitale Dienste zu schaffen.

Verstehen, was Nutzer brauchen

Erfolgreiche digitale Projekte beginnen immer mit der Ermittlung der wahren Benutzerbedürfnisse von Endnutzern wie Verwaltungsangestellten. Sie müssen von Anfang an in den Konzeptionsprozess einbezogen werden. Die Nutzerbedürfnisse sind für die Benutzbarkeit und damit den Erfolg eines digitalen Dienstes weit massgeblicher als eine kompromisslose Rücksichtnahme auf Zwänge von Verwaltungsstrukturen und -silos. Dass konzeptionelle und technische Entscheidungen in geschlossenen Projektgruppen gefällt werden, sieht man vielen digitalen Behördendiensten an. Darum testen wir Annahmen und Prototypen laufend mit echten Menschen und gewährleisten, dass ein Konzept auf dem richtigen Weg ist.

Iterativ bauen, laufend testen

Mit einem inkrementellen, zügigen Entwicklungsstil reduzieren wir Projektausfallrisiken massiv. Funktionierende Software wird früh in die Hände von Nutzern übergeben. Das Auftraggeber- und Entwicklerteam kann so prompt und laufend Anforderungen und Entwicklungspläne aufgrund von Beobachtungen des Nutzerverhaltens anpassen. Immer gilt es, Entscheide nicht auf eigene Vermutungen und blosse Wünsche abzustützen. Zudem muss die Stück um Stück entstehende Software laufend in Betrieb genommen und einfach automatisch getestet werden können. Professionell angewandt, auf spezifische Bedürfnisse und Situationen angepasst, sichern agile, iterative Methoden den Projekterfolg.

«Open» ermöglicht Innovation

Schaffen Behörden auf diese Weise digitale Dienste und machen generell geeignete Daten öffentlich verfügbar, schaffen wir zusammen Mehrwert. Der Zugang zu öffentlichen Dienstleistungen und Informationen wird vereinfacht, die Öffentlichkeit kann auf einfache Weise Korrekturen anbringen und Beiträge leisten, und die Wiederverwendung offener Behördendaten durch andere Behörden und Dritte wird gefördert. Von den dadurch geschaffenen digitalen Diensten profitieren wir als Bürger, die Zivilgesellschaft und die Wirtschaft wie auch die Behörden selbst. Die Öffnung von Behördendaten in der Schweiz schreitet 2015 weiter voran. Offene Behörden haben erkannt, dass Innovation nicht primär eine Frage der Technik ist, sondern der eigenen Einstellung zum gesetzlichen Auftrag.

Image: playbook.cio.gov

Im Sommer 2012 ging die Stadt Zürich voran, Bund und Kantone folgen: Open Data ist dabei, sich als Grundsatz zu etablieren. Für Entwickler und Betreiber von Apps und Sites werden mehr und mehr frei verwendbare Rohdaten verfügbar, die mit Mehrwert genutzt werden wollen. Das Thema Open Data bewegt eine grosse Vielfalt von Akteuren in Behörden, Medien, Firmen und der wachsenden Schweizer Community einzelner Entwickler, Designer und Aktivisten. Die Dynamik ist da, der politische Wille entsteht, Austausch findet statt. Nach wie vor sind auf allen Seiten Unsicherheiten vorhanden – ganz ähnlich wie am Anfang anderer grosser Entwicklungen zwischen Gesellschaft und Technologie – aber auch grosser Elan, und die Chance für einen echten Innovationsimpuls und einen bleibenden Kulturwandel.

Eine gemeinsame Infrastruktur

Das unter der Leitung des Bundesarchivs entwickelte Pilotportal ist bewusst so konzipiert, dass es offene Behördendaten von Datenherren auf allen föderalen Ebenen aufnehmen und nutzbar machen kann. Dabei verbleibt die Hoheit über die Daten aber bei den jeweiligen Datenherren. Diese haben verschiedene Möglichkeiten, “ihre” offenen Daten über das Portal verfügbar und nutzbar zu machen: Minimal notwendig sind die Bereitstellung von Metadaten – sei es über eine Datei auf einem zugänglichen Server oder über einen Dienst wie beispielsweise bei Geo-Daten. Die Rohdaten zum Herunterladen können via Links auf die Quellsysteme des Datenherren zur Verfügung gestellt werden oder – falls solche Systeme unter Umstände beim Datenherren fehlen – auch physisch in einem Datenspeicher des Pilotportals. Dienste werden selbstverständlich via Link eingebunden.

Offene Lizenzen

So speziell die Schweiz auch sein mag, und es einen schweizerischen Weg zu Open Data braucht: Es ist mehr als sinnvoll, die erprobte Praxis anderer Länder zu nutzen. Das von WWW-Erfinder Tim Berners-Lee formulierte “Five Star Deployment Scheme for Open Data” ist weltweit Grundlagentext, und seine erste Bedingung lautet: Offene Daten sind unter offenen Lizenzen publiziert. Das Portal der Stadt Zürich kam dieser Bedingung von Beginn weg nach, auf Bundesebene besteht hier nach wie vor Handlungsbedarf: Die überwiegende Mehrheit der Datensätze ist mit den bisherigen Lizenzen auf dem Portal verzeichnet. Geschlossene, unklare oder widersprüchliche Lizenzen sind eines der grössten Hindernisse bei der Nutzung. Während hierzu beispielsweise im Bereich der öffentlichen Statistik rechtliche Grundlagen anzupassen sind, ist dies in anderen Bereichen nicht nötig. Das Pilotportal erlaubt es, die Find- und Nutzbarmachung von Daten, deren Öffnung keine rechtlichen Anpassungen nötig machen, mit geringem Aufwand zu fördern.

Die von WWW-Erfinder Tim Berners-Lee aufgestellten Anforderungen für die Publikation von Open Data haben weltweit Gültigkeit.

Gemeinsam Erfahrungen sammeln

Vergangenen Herbst hat der Bundesrat dem Informatikstrategieorgan Bund den Auftrag erteilt, eine Open Government Data Strategie Schweiz zu erarbeiten. Diese ist mittlerweile in der verwaltungsinternen Vernehmlassung und wird voraussichtlich im April im Bundesrat behandelt. Damit stehen die Zeichen auf Grün für einen gesamtschweizerischen, strategischen Wechsel vom “Pull”- zum “Push”-Prinzip bei der Veröffentlichung von Behördendaten. Das heisst, dass Behörden nicht-sicherheitskritische und nicht Drittrechten – beispielsweise Persönlichkeitsrechten – unterliegende Daten ohne eine konkrete Anfrage der Öffentlichkeit zur freien Wiederverwendung zur Verfügung stellen. Dazu müssen Ämter und Fachstellen wissen, wie und in welcher Form sie ihre Daten veröffentlichen sollen. Dieser Austausch über die gegenseitigen Bedürfnisse findet statt, an formellen wie informellen Treffen. Wobei letztere wie etwa die seit Herbst 2011 halbjährlichen stattfindenden make.opendata.ch-Hackdays oder die von Statistik Stadt Zürich im Oktober und November 2013 organisierten Hacknights eine wichtige Rolle spielen.

Nutzung nachhaltig fördern

Dass die Entwicklung von öffentlichkeitswirksamen “Leuchtturm”-Applikationen für die Öffnung weiterer Daten förderlich sein können, ist nachvollziehbar. Doch können sie bestenfalls Katalysator sein, nicht aber der Motor zur Öffnung der Daten. Denn was sich aus ihnen ergibt, lässt sich weder voraussagen noch voraussetzen – werden sie ja eben zur freien Wiederverwendung geöffnet und nicht zusammen mit einem konkreten Auftrag an einen Dienstleister, diese oder jene Applikation zu entwickeln. Klar ist, dass ihre Freigabe die Grundlage für Innovationen schafft, und damit Wirtschaftsförderung bei bescheidenen Aufwänden darstellt. Wie sich die Nutzung der Daten am besten gezielt und nachhaltig fördern lässt, darüber besteht noch keine Einigkeit und es wird immer verschiedene Ansätze geben. Unbestritten aber ist, dass hier dasselbe gilt wie bei der Öffnung der Daten an sich: Die Ansprüche und Potenziale lassen sich am zweckmässigsten im gegenseitigen, öffentlichen Austausch zwischen Datenherren und -nutzern ergründen und realisieren. Dabei ist das Partizipieren am Pilotportal für Gemeinden, Kantone und Bundesämter ein wesentlicher Schritt.

Die Nutzung von Open Data lässt sich gezielt fördern: nicht mit kurz wirkenden App-Wettbewerben, sondern im längerfristigen Austausch.

Weitere Informationen:

Datenportal Schweiz: opendata.admin.ch

Datenportal England: data.gov.uk

Schweizer Open Data Initiative: opendata.ch

Weltweite Open Data Initiative: okfn.org

** Veröffentlicht in: Swiss Made Software 2013

International ist Open Government Data, der offene Zugang zu Behördendaten, bereits seit zehn Jahren ein Thema unter IT-Profis. Die Politik brauchte etwas länger. Nach ersten Erfolgen im Ausland kommt jetzt die Schweiz.

Mit dem Projekt Open Government Data (OGD@Bund) ist Open Data in der Schweiz auch auf Bundesebene angekommen. Fünf Bundesämter geben seit September 2013 erstmals zentralen Zugriff auf ihre Daten in maschinenlesbarer Form. Durch diesen Zugang sollen drei Ziele verfolgt werden: Ankurbeln wirtschaftlichen Wachstums, mehr politische Transparenz und eine höhere Effizienz der öffentlichen Verwaltung. Umgesetzt wurde das Innovationsprojekt durch itopia und Liip.

International angestossen haben Open Data der ehemalige englische Premier Gordon Brown und der WWW-Erfinder Tim Berners-Lee. «Was kann ich für England auf IT-Ebene tun?», soll Brown Letzteren gefragt haben. Berners-Lee schlug vor, die Datensilos der Verwaltung zu öffnen und so Innovatoren zugänglich zu machen. Gesagt, getan. Das war 2007. Aber es lag wohl in der Luft. Barack Obama nutze kurz darauf seine Antrittsrede, um Open Data in den USA auf die politische Agenda zu bringen. Daraufhin folgten erste Bestrebungen in Österreich, Norwegen und Italien. Jetzt zieht die Schweiz nach.

Neue Entwicklungen

Portal. Kurz zuvor hatte sich der Verein Open Data gegründet, der die Interessen der Bewegung in der Schweiz vertritt. Zwar gibt es auf der Webseite des Vereins bereits viele interessante Projekte wie eine Simulation des Bahnverkehrs oder die Visualisierung der Stadtzürcher Finanzen – mit der Lancierung von OGD@Bund landet man man aber auf einer anderen Ebene.

Neben dem Bundesarchiv sind das Bundesamt für Statistik, swisstopo, MeteoSchweiz und die Nationalbibliothek Projektpartner. Unterstützt werden sie durch die Bundeskanzlei und das Informatiksteuerungsorgan des Bundes (ISB).

Kosten rechtfertigen

Dabei ist es nicht immer leicht, die Kosten zu rechtfertigen. Dennoch gibt es gute Beispiel aus dem Ausland: In England gelang es, durch eine kombinierte Veröffentlichung von Sauberkeitsprüfungen und Ansteckungsraten in Krankenhäusern bestimmte Ansteckungsfälle um 80 Prozent zu reduzieren.

Die Schweizer Regierungsdatenbank hat aber aus technischer Sicht bereits neuen Boden gebrochen. Liip entwickelte die Software im Bereich der Mehrsprachigkeit weiter. Aber auch an die Zukunft wurde gedacht: Weitere Bundesinstitutionen sowie Kantone, Städte und Gemeinden können sich einfach anschliessen und ihre Daten verfügbar machen. Gemäss Liip soll dies dank der föderalen Architektur von OGD@Bund mit vertretbarem Aufwand möglich sein. Eine Option, die genutzt wird: Mit Zürich hat sich ein erster Kanton angeschlossen. Bereits Interesse angemeldet haben weitere Kantone, Städte und Bildungsinstitutionen.

Alle Schotten auf: Mit OGD@Bund macht Bundesbern einen Schritt in Richtung Zukunft.