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.

In IE8 Beta 1 we also increased our per-server connection limit from 2 to 6. What this means is that in IE7 and below pages could only download 2 elements from a given server at any one time. Increasing that limit to 6 allows sites to download 3 times as much content in parallel, which should translate into faster page download times when bandwidth is available.

And it will. Today web pages contain many more references to stylesheets, images and external javascript files than they used to. Increasing the number of parallel connections will make pages complete more quickly on the user side. However, the HTTP protocol specification says this about concurrent connections:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

Granted, the HTTP specification was written a long time ago; internet connections and servers have become much more powerful. So, will it matter?

My main problem is that the decision has moved from server administrators to browser developers. If you are a server administrator it is easy to split up content so that it appears to be coming from multiple hosts to get the same result. You know more about the content that needs to be delivered and how it should be partitioned.

If IE8 uptake is quick I guess some popular sites will see some negative effects of the 300% increase in the number of connections.

At the heart of the issue is the lack of reference implementations. ISO is way behind W3C in this area. Could someone please tell ISO that open source reference implementations are an absolute necessity when working with standards for information exchange?

From the W3C technical report development process section 7.4.4:

Preferably, the Working Group should be able to demonstrate two interoperable implementations of each feature.

It is simple really. The benefit of a standard is created when it is used. Open source reference implementations shortens the time to market for everyone implementing the standard in their products and also disambiguate interpretation of the standard specification.

Tim, please tell me you know someone at ISO that can fix the process.

The typical response seem to be status 500 (internal server error) on a lot of IIS sites. So, now is a good time to check your own sites to see what you get back from a:

curl --head http://www.mysite.com

Seriously? Can’t Microsoft get their own implementations to cooperate better? And this has just been approved as an ISO standard?

Said the monk:

If you give me non-standard markup, I will render it according to standards.

If you give me standard markup, I will not render it according to standards.

What do you do?

The student sat for a long time and said nothing. Then, without looking up, he raised one finger and said, “There is only one web.” Many years later, the monk was enlightened, but by then it was too late.

I thought the whole idea is that a standard is a contract that tool makers and content producers should be able to rely on. And now you are saying that the standard isn’t enough but that I specifically must inform a particular browser that I want standards standards mode?

Also see Ian Hixie’s entry Mistakes, Sadness, Regret.

The member countries have had six months to consider if the Office Open XML (OOXML) format should become an ISO standard. In Sweden, SIS arranged a working group that have looked through the material. As you may know the OOXML format has been heavily criticized (by many e.g. Google (PDF)) for allowing embedding of closed Microsoft-specific objects in the document standard and thus making it difficult for non-Microsoft software to read OOXML documents.

Unfortunately, SIS is an organisation where anyone can become a member. Member organizations can send participants to a working group for a fee. The current rate is 17,000 SEK (~$2,500). The day before the vote that decided if SIS would say yes to OOXML in the ISO there were a couple of new members in the SIS/TK321/AG17 working group:

And so, Sweden will be voting yes to make OOXML an ISO standard.

For more information see:

• Patrik Fälström’s post “Microsoft managed to buy the vote of Sweden in ISO?“.
• Slashdot.
• Dagens Nyheter (in swedish).
• noooxml.org.
• Matusow: Open XML – The Vote in Sweden

.

Having recently recieved a brand new MacBook Pro from my employer I needed to get basic things such as mail and calendaring working. We use Microsoft Exchange 2003 which is great if everyone is using Outlook. Since I work with various clients I am subjected to their respective firewall policy which typically only allows HTTP(S) traffic. This leaves us with Outlook Web Access (dumbed down interface for everyting but IE). Reading e-mail works fine in OWA. However, the calendar becomes useless as reminders won’t appear.

Unfortunately, Apple’s iCal doesn’t work with Exchange. iCal does, however, store data in the standard icalendar format. Having som experience working with WebDAV access to Exchange (which is available if you can reach OWA) I decided to write an Exchange API in Ruby to read calendar items and convert these to the icalendar format. So, I was about half-way through when I discovered that Sam Smoot had created RExchange. That gave me most of the API:s required for connecting to Exchange.

RExchange did not contain a class for working with appointments (only mail and contacts), so I had to add that. Also, RExchange uses the Time::parse method to convert strings to time representation which doesn’t work for dates after 2037.

Anyway, to export your Exchange calendar to iCal through WebDAV, download the rexport script, unpack the files and modify the rexchange.rb file with your login credentials and OWA URL. Execute rexchange.rb from the terminal. It will create an iCal storage file corestorage.ics in the same directory. This can be opened directly in iCal.

Future options may include a synchronization mode. Suggestions and patches are welcome.