1. The benefits appear when a vocabulary is used.
2. An important factor is how a vocabulary and its parts can be published, discovered and referenced.
3. There needs to be one and only one vocabulary artifact.
4. The vocabulary artifact must be machine processable to allow aggregation and automatic generation of other artifacts.

Background

The need for interoperability arise in scenarios with many contributing actors. In the old days this was solved by hiring a (large) consulting organization that (hopefully) had experience from glueing together many products from their vast product portfolio. Everyone involved was happy if it worked. Being able to swap out a part of this system or connect it to a third party that had a different technical platform was considered a risk.

Today more work is being done but in my experience there are still issues in keeping it all together. Domain experts create terminology in Word documents and architects draw UML class diagrams. They all talk about the domain but each type of artifact does not describe the domain sufficiently. In a different room developers merge domain concepts with coding practices to form software that may express fragments of a domain.

Little work is done to define vocabularies in a way that worked both for software developers and for domain experts. Typically you would find a Word document with a flat terminology that was ignored by the software developers, or, you could find class diagrams in UML or software documentation that was impossible for domain experts to understand. And when you look at the code or interfaces of the system there are no references to the correct item in a vocabulary.

How can we make them work together?

Requirements and challenges

I like to think of semantic interoperability as a state where the same cognitive processes kicks in for two persons studying a specific artefact from the domain they are working in.

In order to work with this in a structured way we need to simplify it. One way to look at interoperability can be found in the draft of the European Interoperability Framework version 2. It introduces four interoperability levels. If we remove the European cross border services context they can be described in more general terms:

1. Technical interoperability: issues involved in linking computer systems and services together (e.g. transport and serialization of data).
2. Semantic interoperability: the meaning of information specified in a way understood by all parties (e.g. definitions, relations and structure of terms used to describe data).
3. Organizational interoperability: coordination of processes in the context where data is used/transformed. (e.g. shared definitions of the roles, responsibilities and interactions of/between participants).
4. Legal interoperability: shared interpretation and understanding of laws regulating information exchange and cooperation (e.g. can we transfer information about people? What about privacy?).

There are other models that could be used to discuss levels of interoperability (e.g. LCIM – Levels of Conceptual Interoperability Model) but let’s stick with the EIF 2 model above.

If you have a scenario with only two parties everything is simple. You could just do the minimum amount of work to make sure systems talk to each other and that people share a common image of the various levels of interoperability. Enabling more parties to participate requires more work though.

If you have a scenario with many parties (where some may not yet exist) you have to create a framework describing how interoperability should work by harmonizing a set of solutions at each level of interoperability. In a dictatorship this is easy. Just evaluate a few solutions, choose one and make everyone use it. In other contexts it is more complicated.

If we consider the EIF 2 model above as a set of requirements we should also make sure that the solutions we propose:

1. scale down: If the parties (organizations, departments etc) vary greatly in size (as they will if the number is sufficiently big) some may consider that the solution you propose in a framework is unnecessary complex. They are right. In order to maximize the number of parties and processes that can participate in an interoperability scenario you will have to make sure the proposed solutions scale down.
2. are technology neutral: Given a large number of organizations you will find almost every technology platform you can imagine. There will also be a number of ways to send and receive information. Some like to force a specific set of transport mechanisms as part of a interoperability framework but this will quickly put you on a path where you can’t make use of new standards and technologies. Forcing participating organizations to use a specific tool or platform will fail.
3. give a reasonable amount of flexibility: This may require the framework to contain partly overlapping standards.
4. facilitate an emerging semantic interoperability: The idea of having a central organization defining everything only works in a dictatorship. We should enable the decentralisation of participating in vocabulary work.
5. are discoverable and referencable: If the artefacts that are created are difficult to find for a newcomer you can give up now. By lowering the threshold to participate more parties can be involved and more information can be reused.

This proposal is aimed at semantic interoperability only.

A lightweight semantic interoperability framework proposal

1. The Web Ontology Language (OWL) is used to express vocabularies

The primary reason for selecting OWL is not the features it has to express domain concepts but rather the possibilities of publishing it and referencing it on the web that come bundled with it. Using the web as a publishing platform enables us to make use of already existing standards for referencing a vocabulary and its parts.

Although plagued by research projects of poor usability and lack of longevity there are several tools to create vocabularies in OWL. The framework does not specify the process for creating a vocabulary as that may hinder small organizations form participating.

2. Vocabularies are published properly on the web

Putting an OWL vocabulary on the web means that it can easily be discovered, referenced and transformed. Not only will it help your own organization but it will lower the threshold for others who want to use parts of it in their own work. As soon as that happens you have the first step towards semantic interoperability.

By “published properly” I mean that you should choose your URI for the vocabulary wisely as it will be the reference string used in software interfaces and other artifacts down the road. Many get web publishing wrong by scrapping one of the best features: long term referenceability, as they dump information tightly coupled to the publishing tool they are using. When you change the tool (e.g. a content management system) you may break references for everyone else. Don’t do that.

To make the vocabulary human readable (nobody wants to read OWL/RDF-schema) generate at least an HTML-version of the vocabulary for users pointing their browser to the URL of the vocabulary and a class hierarchy overview to help users understand relations between things.

3. Use a standardized way of referencing vocabularies in other artifacts

Although OWL may seem to be only for semantic web scenarios it can be used in other areas. By standardizing how references from WSDL and XML schema are made it is possible to keep an unbroken chain of references. SAWSDL provides a mechanism to reference e.g. a class in the vocabulary. This makes it possible for developers to refer to the vocabulary in a consistent way from XML schemas and WSDL files and provides a way to keep the vocabulary closely connected to API implementations.

One important area missing is how to point to vocabularies from code. Code is a design artifact for a system and as such it is important that it is possible to keep an unbroken reference chain to it too. But we’ll leave that open for now.

4. Aggregate all vocabularies on a central website

Although vocabularies can and should be published under a URI in control by the authoring organization they should be aggregated on a central searchable website. This is easy as they are machine readable and will serve two purposes:

1. It helps people discover other vocabularies before creating their own. This is an important step in creating an environment for an emerging semantic interoperability.
2. The aggregated material will become a tool to find areas where harmonization efforts should be focused. By querying the aggregated information it is possible to find vocabularies that define similar things. Multiple classes called “Person”? Get going.

5. Express provenance in the vocabulary

Provenance provides a foundation for assessing authenticity and enabling trust. By standardizing information about provenance you also facilitate interaction between parties involved in the domain.

What do you think?

I believe this could be a lightweight approach to work with semantic interoperability in a way that scales (both up and down) and that provides for an emerging semantic interoperability over time. I guess it could work for government scenarios on country scale as well as for a small organization.

The only thing I miss is a standardized way of referencing a vocabulary from code.

Please leave your feedback.

On Sunday there were 12 teams presenting their apps. Some of the teams had used public transport data made available by the Viktoria Institute but many were scraping government websites for lack of proper API:s. In the 24 hours set aside for the competition the following apps were created:

• Slagkryssaren: Valkoll – an Android app to see election results where you are right now
• Slumptal: Lokalpolitik – geocoding city council docs to be able to present relevant decisions in your neighborhood.
• New and shiny things: @Myndighetskoll – a twitter bot that ansers questions about government agencies
• Popdevelop: Kollektivt.se – an API service and realtime display of buses in the city of Malmö
• Facebookpolitik: Svenska Riksdagen på Facebook – pushing government decisions and initiatives to Facebook
• First Blood: Engagemangsindex – visualization of government issues
• Boreda: Boreda @ Codemocracy – using public transport data as a selection criteria in finding properties for sale.
• Exjobbarna: CrimeTracker – a Windows mobile app to see crime stats
• Anyro: Tågtider till Android – an adroid app for train data
• Existic: Riksdagsdata i Ply – an extension to PLy to do drill-down in government data.
• Akvo Phone: Georapport – an Android app that geo-encodes and signs a picture that could be used in development aid projects or fix my street-scenarios.
• Kreativ Stuga: Edemokrat.se – An app that connects government documents in a way that makes it easy to navigate them.

More info at the official Codemocracy website. Many CC pictures are in the Codemocracy Flickr group.

I am already looking forward to the next event!

A third recommendation

An important value of public sector information is the increased transparency in government decision making. A European Union directive only affects member states and not EU institutions. We are therefore at risk of missing out on increased transparency in EU institutions that the PSI directive may bring to governments in the member states. Also, government transparency is often considered to be a contributing factor in reducing corruption.

Therefore, it would be great if there was a plan, similar to the PSI directive, that made sure that EU institutions also started providing machine readable data in order to increase transparency and reduce the risk of corruption.

Currently, it seems to be up to each institution to do what they want. Maybe that is why the Publications Office of the European Union decided to charge  for access to electronic versions of the EUR-Lex database (that contains the directives and other legal acts). This move makes it difficult for new actors in the legal information industry to include EU data in their products which leads to reduced competition.

Use of social media tools in the public sector is in its infancy in Sweden. In a study conducted by the Stockholm Chamber of Commerce in 2009 (PDF) , around 12% of agencies reported that they were using social media channels in their communication. In another study by the Swedish Public Relations Association 75% of PR managers were evaluating the use of social media but only 5% had involved social media in the communication strategy. Many agencies are trying out new tools to see how they fit in their communication strategy. Most are using them as a news feed (one-way communication) and do not reply to questions. The number of followers varies greatly. Some examples:

Some agencies have also started using Facebook. The National Heritage Board (Riksantikvarieämbetet) on Facebook has close to 1200 fans. They have also used Flickr to increase access to parts of their archives. Currently the images are low-res only but that may change in the future.

Municipalities on Twitter

Many municipalities have started using Twitter to push information to citizens. Most are using it as a one-way communication channel, but some are engaging in dialogue. The number of municipalities on twitter is increasing almost on a daily basis. In my list of swedish municipalities on twitter there are currently 71 (out of 290). Many of them are not publishing any tweets and may only have registered the account to get a proper twitter handle.

In he following visualization you get an overview of how the municipalities compare with regards to number of tweets, followers and “early adopter”-status (“Age” as in number of days on twitter). Uppsala (north of Stockholm) has over 500 followers and published 941 tweets in their 367 days on Twitter. See here for a larger chart.

Observations

Some organizations are following citizens on Twitter and may not have realized that people may feel uncomfortable having an agency following them.

There are also some fake agencies on twitter. Swedish national authority for signals intelligence, FRA, has a twitter feed (with the correct logo), but looking at the tweets it is likely a fake. How should agencies relate to this? The police has several twitter feeds it seems. But they are not managed by the agency itself. How can citizens trust the information in these channels when it is difficult to see if they are managed by the agency or some personal initiative?

Recommendations from the government

On March 23 the government published a proposal saying (my translation):

Social media tools create new possibilites for communication with citizens and businesses. The E-government delegation will create guidelines for the public sector use of social media tools.

This means that we will likely see more agencies trying out social media channels in the future.

Do you have more information? Please comment!

The Internet is the public space of the modern world, and through it governments now have the opportunity to better understand the needs of their citizens and citizens may participate more fully in their government. Information becomes more valuable as it is shared, less valuable as it is hoarded. Open data promotes increased civil discourse, improved public welfare, and a more efficient use of public resources.

…and this is why I have launched opengov.se – an initiative to bring swedish public sector data online in open formats. Initially the website contains a catalog of public data sources and information about licensing and formats used.

You can help out by suggesting datasets form the swedish public sector.