Introduction

Making the data, hidden in various cloud platforms, available and understandable so that it can be processed by software services as well as human beings is one of the key challenges. Tim Berners-Lee coined this challenge “Linked Data”. However, he remained rather vague on how this data should be linked technically. An initiative of major software vendors, such as Citrix, IBM, Microsoft, Progress Software, SAP and WSO2, addressed this problem by proposing the Open Data Protocol (OData) standard to the Organization for the Advancement of Structured Information Standards (OASIS). All kind of software can leverage OData, but it is particularly interesting for business software, such as business process management systems, business rule systems and complex event processing middleware. OData can be seen as the technical foundation for open data, which comprises initiatives from various governments and organizations to make data publicly available.

Foundations

OData is inspired by the Representation State Transfer (REST) approach. Basically, REST is about clients creating, accessing, deleting or modifying resources, identified by Unique Resource Identifiers (URI), from the server. A resource can represent any concept in form of any data structure. Data structures can be described in a plethora of formats, such as the JavaScript Object Notation (JSON) or the eXtended Markup Language (XML). REST was becoming more and more popular with the emergence of complex web applications using HTML5 and Javascript.

Although not limited to any specific protocol between clients and servers, REST has been originally described and is now mostly implemented using the Hyper Text Transfer Protocol (HTTP). This allows creating, modifying, deleting or reading resources. Furthermore, we can create more sophisticated Internet based architectures for managing the data (e.g. proxies or IT security concepts).

Example (REST) We assume that a client (C) communicates with the server (S) using HTTP. The client requests the data of a book identified by the following URI: http://example.com/library/book/ISBN978-3787316502. The server answers with basic book data using the JSON format. The protocol can be described as follows:

(C) Request:

GET http://example.com/library/book/ISBN978-3787316502 HTTP/1.1

(S) Response:

HTTP/1.1 200 OK

{

“title”: “Kritik der praktischen Vernunft”,

„author“: „Immanuel Kant“,

„year“: „1788/2003“

}

Similarly, we can create, modify or delete resources.

OData

It has been shown that REST provides a lot of flexibility for managing data over the Internet. This can be seen from the plethora of web applications using it. However, it has some limitations. For example, we can only do simple data update or retrieval operation via the URI, but we cannot articulate more complex queries in our web application or for representing media streams. An example for a complex query is the following (using OData notation):

http://example.com/travelshop/Customer?$filter=Revenue gt 1000.00

This query asks for all the customers with revenue greater than 1000.00 Euro. The query can be executed similarly to the REST example presented before.

OData standardizes a wide range of different queries on the service level, which makes it very easy to reuse Odata services or do add enhanced flexibility/agility to your business processes.

Of course, we can use this query language also to update or delete resources.

Selected OData Concepts

OData can leverage and extend the Atom Syndication format or the Atom Publishing Protocol. You probably know these standards from web feeds (e.g. news) in your browser. They basically describe semantics for news, such as headlines, pictures or full-text. These standards can be used to represent answers to queries containing more than one entity (e.g. multiple customer records).

OData services can articulate what data they understand and produce. Clients can use this information to compose one or more OData services to fulfill their intents. For example, OData services are described using the metadata document and the service document. The first one is conceptually similar to the Web Service Description Language (WSDL). It describes operations and data provided by the OData service. The service document describes a set of entity collections that can be queried from the services. For instance, all customers that have a pay-tv subscription.

Unfortunately, it is not clear if OData is supposed to support queries requiring constructing a transitive closure. These type of queries are, for instance, useful to retrieve all the indirect flights between two airports. It may be supported by OData functions or on the client side, but not as part of the standard.

Conclusion and Outlook

OData has a lot of benefits. It leverages well proven internet concepts. HTML5 web applications can immediately start using it without changes to existing browsers. Finally, it has support by major vendors for business software.

There have been some competing proposals for managing data over the internet, such as GData by Google, but they seem to be deprecated by now.

However, some elements are missing in the OData proposal. For example, it is difficult to describe temporal queries, such as “Provide me all activities that have finished at the same time in the production process”. A lot of research has been done on representing temporal data in information systems (e.g. I used it to provide information system support for managing highly dynamic processes in the crisis response). Thus, I think this would be a beneficial feature. In fact, there have been proposals for extending the OData standard with temporal data. However, they remain rather simple and would not allow dealing with qualitative temporal queries (“finish at the same time”) as I have described before.

The same holds for geospatial queries. An example for a geospatial query is “Provide me all the warehouses in the disaster affected area”. Luckily, we have also here some proposals to extend the OData standard to support these types of queries.

What is next?

We have a lot of redundant and related data provided by different organizations. OData is focusing on single data sources and at the moment it is unclear how to relate and integrate many different sources from different information providers. This is mostly a semantic problem. For instance, a manager can be described as a director in different companies and vice versa. A solution could be to agree on OData Metadata documents to define semantics. This has to be done by domain experts as it had occurred in the area of reference models, such as the one I explained before about humanitarian supply chain management (cf. also the Humanitarian eXchange Language). Finally, we may use translation languages, such as XSLT to automate integration of semantically different information.

Further references

• OData software support (open source and commercial servers as well as client libraries)