Open Data Format (O-DF), an Open Group Internet of Things (IoT) Standard – O-DF Objects
The XML Schema “odf.xsd” provides a formal specification for the O-DF. The schema contains annotations for Attributes and Child Elements that are identical to the ones in this standard. If there is any conflicting information between the schema file and this standard, then the information in the schema file is to be used.
The following units or formats SHALL be used in the O-DF to express the listed quantities. The xs namespace is defined in XML Schema Part 2: Datatypes Second Edition.
Value |
Unit/Format |
Date |
Use xs:Date |
Time |
Use xs:dateTime |
Duration |
Use xs:duration However, it is defined in the schema where xs:duration should be used. For other durations, such as Time-To-Live (TTL), xs:double may be used and then the unit is seconds. |
Other Values |
SI units used by default. |
As shown in Illustration of O-DF Element Hierarchy, all O-DF structures SHALL have Objects as their root element. An Objects element SHALL only have Object sub-elements. The most important attribute of an Object is type, which specifies what kind of object it is. An attribute MAY be used for specifying the object class. If an object class taxonomy is used, then it SHALL be indicated with the type attribute as a URL that points to the definition of the type; e.g., such as http://www.somewhere.com/taxonomy#theType. O-DF Structure shows a simple example of an O-DF structure.
Every Object SHALL have at least one sub-element called id that identifies the Object. An Object MAY have additional id elements. Such an identifier is known as an object identifier. An object identifier SHOULD be globally unique or at least unique for the specific application, domain, or network of the organizations involved. An optional description sub-element MAY also be included for providing a description of the Object, usually intended for human users.
The Object’s properties are included with an arbitrary number of InfoItem elements. Object elements MAY also include an arbitrary number of Object sub-elements; see Object Element. The reason for calling properties “InfoItem”, rather than using the name “Property” or some similar concept that is familiar from object-oriented programming, is that in the IoT an InfoItem can also be an event of some kind rather than just a simple value. The name attribute SHALL be used for defining the name of the InfoItem. Additional names – that is, synonyms or alternative names in different systems – MAY be provided as name sub-elements. As for Object, an attribute MAY also be used for specifying what the InfoItem represents.
InfoItem elements MAY contain optional sub-elements, as shown in InfoItem Element:
- name: Additional names for the same InfoItem. This feature may be used, for instance, if the same InfoItem is known under different names in different organizations or software.
- description: Text that explains what the InfoItem represents, mainly intended for human users.
- MetaData: Sub-element that provides metadata information about the InfoItem, such as value type, units, and other similar information.
- value: Arbitrary number of values for the InfoItem, possibly with timestamps; see Value Element.
Even though it is possible to include description, MetaData, and value element(s) simultaneously for an InfoItem, it is usually not practical to do so. Metadata is typically requested only once when encountering a previously unknown InfoItem. The MetaData element MAY contain an arbitrary number of InfoItem elements. MetaData sub-elements are of InfoItem type because they are syntactically similar to Object InfoItem sub-elements, even though MetaData InfoItems are conceptually different from Object InfoItems. The description element could also be considered as metadata. However, it has been left as a separate element mainly due to earlier experience that has shown the utility of including a simple-to-use “free-form” text element for user interface and debugging purposes.
O-DF Structure shows an O-DF structure that transmits two electrical power consumption measurements with timestamps for a refrigerator instance.
<Objects>
<Object type=”Refrigerator Assembly Product”>
<id>SmartFridge22334411</id>
<InfoItem name=”Consumed Electrical Power Measure”>
<description>Power consumption values with timestamp.</ description >
<value dateTime=”2001-10-26T15:33:21”>15.5</value>
<value dateTime=”2001-10-26T15:33:50”>15.7</value>
</InfoItem>
</Object>
</Objects>
In object-oriented programming, objects are aware of each other by object containment hierarchies as shown in Illustration of O-DF Element Hierarchy and by reference or pointers. In the O-DF partial object descriptions in different structures are linked using the Object id sub-element; see Object Element. In the IoT the id does not refer to a specific memory location but to an IoT object whose information may be spread over several information systems and organizations. Different methods and systems have been proposed for the discovery of such distributed information. The simplest mechanism is to include a URL in the id itself. Other methods are still being developed for solving this issue. However, those are not in the scope of this standard.
Object identifiers and InfoItem names are specified using the qlmID type – see qlmID Type. The attributes of qlmID make it possible to express what standard or coding scheme the id/name uses, on what kind of media it is written (e.g., RFID tag, barcode, stamped, …), and the beginning and end of validity of the identifier. Other information CAN be conveyed using attributes that are not defined in this standard. Especially for objects, the possibility to use more than one id is a common real-life requirement because the same “Thing” can often carry several different identifiers. For instance, a postal package may end up with several company-specific tracking numbers, an SSCC code, and other identifiers before reaching its destination.
