Open Data Format (O-DF), an Open Group Internet of Things (IoT) Standard – Introduction

 

Objective

The Open Group Internet of Things (IoT) Standards have been developed to fill an interoperability gap identified in the context of the IoT, as explained in the White Paper: An Introduction to Quantum Lifecycle Management (QLM).

A great number of useful standards exist on the level of communications within a local network, within a specific domain, or for a limited purpose such as remote management of computers. However, at the moment of writing this specification, we have not been able to identify an appropriate standard that would address the higher-level requirements of the IoT. Such requirements are notably the need for any data sources (devices, machines, server-based systems, etc.) to be able to publish their available data and provide access to it in an easy and secure way, which includes the possibility to filter the data provided depending on the requester’s identity, the context, etc.

The O-DF can be used for publishing the available data using ordinary URL (Uniform Resource Locator) addresses. O-DF structures can also be used for requesting and sending published data between systems, notably when used together with the O-MI standard.

In the IoT, information about a product or a “Thing” is often distributed over many different devices, systems, and organizations. The O-DF is intended to represent information about things in a standardized way that can be understood and exchanged in a universal way by all information systems that need to manage such IoT-related data. A data format structure typically does not contain complete information about a particular thing. Information about the same thing may be contained in several different data format structures. Object identifiers make it possible to link the data about a single thing that may be located in different information systems. An object identifier may be the only information that a data format structure contains about a particular thing.

The visibility and the access to data may depend on the object identifier used, as well as on the identity of the requesting party, as well as on the context of the request. This is why the object identifier data structure is of particular importance in any universal IoT standard.

Overview

The O-DF is specified using XML Schema. It defines a simple and extensible ontology that allows the creation of information structures that are similar to those of objects and properties in object-oriented programming. It is thereby generic enough for the representation of any object and information that is needed for information exchange in domains such as the IoT, lifecycle information management, etc.

An O-DF structure is a hierarchy with an Objects element as its top element, as shown in Illustration of O-DF Element Hierarchy. The Objects element can contain any number of Object sub-elements. Object elements are identified by at least one id sub-element. An Object may also have an optional description sub-element. Object elements usually have properties, which are sub-elements called InfoItem, as well as Object sub-elements. The resulting Object tree can contain any number of levels. O-DF Objects provides detailed, normative descriptions of these elements.

Illustration of O-DF Element Hierarchy

The O-DF is intended to be used for expressing information about “any” identifiable object (products, services, humans, …). How the information is communicated is not a part of this standard. The communication media might be a file sent as an email attachment, on a USB stick, or any other kind of media. O-DF content can also be sent using REST-based services, SOAP, Java Message Service (JMS), the O-MI, and other kinds of messaging protocols. The O-DF can be used as a query and response format in such messaging; for instance, the O-MI specifies that a “read” request with an O-DF structure should be responded to with the next level in the hierarchy shown in the figure above. As an example, a request with only an “Objects” element should return an O-DF response with the list of Object elements available, including at least the compulsory attributes and sub-elements (notably at least one id element).

Conformance

This standard specifies conformance requirements for the O-DF and its specification and use.

O-DF Objects, RESTful Use of the O-DF, and Inheritance Mechanism for Domain-Specific Data Models, and O-DF XSD Schema are normative. Example O-DF Structures and JSON Mapping and Examples are informative.

Normative References

The following standards contain provisions which, through references in this standard, constitute provisions of the O-DF standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards.

Terminology

For the purposes of this standard, the following terminology definitions apply. When used in this way, these terms will always be shown in ALL CAPS; when these words appear in ordinary typeface they are intended to have their ordinary English meaning.

Can Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.
May Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.
Must Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.
Shall Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.
Should For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. For an application, describes a feature or behavior that is recommended programming practice for optimum portability.
Will Same meaning as “shall”; “shall” is the preferred term.

Future Directions

The Open Group IoT Standards will continue to be maintained by the QLM Work Group of The Open Group Platform 3.0™ Forum. They may be revised to correct errors or to incorporate changes based on implementation experience.