This multi-part series addresses the need for a single semantic data model supporting the Internet of Things (IoT) and the digital transformation of buildings, businesses, and consumers. Such a model must be simple and extensible to enable plug-and-play interoperability and universal adoption across industries.

Part three discussed the role of a top-level ontology in solving the metadata challenge. In part four, we discuss the intersection of business and device ontologies, and how elements of both can improve scalability.

This is intended to be a living series that incorporates relevant emerging concepts and reader comments over time. The community's participation is encouraged.

Navigate to other parts of the series here:

• Cross-industry semantic interoperability: Glossary
• Cross-industry semantic interoperability, part one
• Cross-industry semantic interoperability, part two: Application-layer standards and open-source initiatives
• Cross-industry semantic interoperability, part three: The role of a top-level ontology
• Cross-industry semantic interoperability, part five: Towards a common data format and API

“Good design is good business.” – Thomas Watson Jr.

Evolving into an IoT-centric business

For users, the true value of IoT isn’t remotely controlling smart devices; it’s when the devices work well with each other. Any door sensor should be able to trigger any light to turn on – regardless of the device manufacturer. And any HVAC unit should be able to trigger a service request or trigger an order for a replacement air filter.

This extends the need for semantic interoperability between smart devices and business systems. It also requires a new architecture that can support business processes, device processes, and eliminate the cost and complexity of custom systems built around the proprietary middleware of system integrators. 

This new architecture must properly align IoT models and concepts with those of business application platforms. Gartner predicts that, by 2020, the majority of new platform-as-a-service (PaaS) applications will be IoT-centric. This will disrupt conventional practices, as PaaS platforms will be used to implement business applications built around event-driven architectures and IoT data rather than traditional master data[10]. These IoT-centric business applications will, in turn, transform application design practices to focus on real-time, contextually rich decisions, event-analysis, lightweight workflow, and broad access to web-scale data.

In parallel, “IoT standards” and “business standards” consortia need to properly align their data models, concepts, and terminology. These assets must converge on a scalable center point of semantic interoperability and distributed data management within the application (information) layer.

Cross-industry need for a Common Business Ontology

Semantic interoperability relies on a designated ontology to interpret the meaning (context) of exchanged data, and apply it to a valuable end. This can span multiple systems, environments, and industries.

Industry-specific business ontologies (such as FIBO for the finance industry) and data models (such as ARTS ODM for the retail industry) have overlapping concepts that can form a Common Business Ontology. The concepts within this Common Business Ontology should align with a top-level ontology (discussed in part 3), like a root object class, such that all objects across all domains of knowledge have inherent interoperability. These Common Business Ontologies provide the basis for facilitating cross-industry semantic interoperability.

Abstraction (ignoring inessential details and dealing with a generalized model) and object-oriented decomposition (breaking a large system down into progressively smaller classes or objects) have proven their worth time and again in resolving inconsistencies in distributed systems. To properly align a Common Business Ontology with the classes of a top-level ontology, general business concepts need to be abstracted and decomposed by tracing business-related data to its originating object class, which could be part of an industry-specific ontology or another knowledge domain. For example, to be aligned with a top-level ontology, the data elements shown on a business card would not be considered attributes of an independent “Contact” class. Instead, they can be decomposed into attributes of related top-level classes (such as System, Location, or Party).

As shown in Figure 25, a telephone number, street number, Internet domain, and email address all originate as a unique “address” attribute for an endpoint in a type of routing system, and are administered by system operators (organizations). Rather than defining a “Telephone Number” attribute for a “Contact” class, a telephone number can be defined as an attribute of a type of system, which can be assigned to a device. That device can be assigned to a party, which can have a relationship with another party.

Figure 25. Decomposition of a business card to align with a top-level ontology.]

In this example, “Bob Smith” represents an instance (object) of person, which is a type of party. “Smart by Design” represents an organization object, which is also a type of party. Bob has been assigned the role of “Systems Engineer” by “Smart by Design.” He has also been designated a mobile device that was assigned a system address by an organization, which itself has been assigned the role of a “Telephone System Operator.”

While this level of abstraction and decomposition may appear complex, it actually simplifies semantic interoperability and prevents fragmentation. In turn, it eliminates the need for complex data mappings among independently conceived object classes.

Location > Location > Location

A top-level “Location” class and hierarchy (Figure 26) can support geolocation containment (e.g., Haystack’s geolocations), as well as space subdivisions within a home or building site (for example, a Zone, Floor, Suite, or Room). A location can be assigned to an asset.

A “Site” subclass (similar to Haystack’s site entity) can include unique attributes supporting a postal address (that can appear on a business card). A site can be assigned to a party and a transaction (order, shipment).

Figure 26. Location class hierarchy.]

The example instances of Location in Figure 27 show a “Conference” Room contained within a Suite “401” contained within a “Fourth” Floor contained within a Site contained within a City, and so on.

An “Air Temperature” attribute of the Location class can accommodate a value (77.4 ºF) from a temperature sensor assigned to a Location instance (Fourth Floor).

The Location instances that comprise a postal address can reflect ownership (Owner Party) by the operator organization (USPS) of the postal system.

Figure 27. Example instances of Location showing containment and ownership.

A Party for Object ownership

A top-level Party class and hierarchy (Figure 28) can comprise Person and Organization subclasses. An Organization can comprise Business Unit and Team subclasses.

A party is capable of legal ownership, and can be assigned to a transaction and designated the owner of an object (“Owner Party” attribute of the Object class). With this approach, every object is owned by a party and is assigned to an owner party when it is created. An owner party can be the person who creates the object or an organization associated with the person or device. The owner party is given all the authorities to the object.

A party can also assume one or more roles related to one or more processes. A "Party Role” class (similar to ARTS ODM) can be modeled as a subclass of the top-level Relationship class.

Figure 28. Party class hierarchy and relationships.

As shown in Figure 29, an instance of a Party Role can assign a role to a party, in relation to another party (the Owner Party). For example, Bob Smith (an instance of person, which is a type of party) can be assigned a “Systems Engineer” role (appearing on his business card) and an “Employee” role, both in relation to Smart by Design (the owner party of the relationship). Smart by Design can be assigned a reverse “Employer” role in relation to Bob Smith (the owner party of this relationship, which appears on his resume).

A trade relationship can be established when a “Vendor” role is assigned to a party (Arrow Electronics), and a reverse “Customer” role is assigned to another party (Smart by Design).

Figure 29. Example instances of Party Role showing reverse relationships.

A Transaction for commerce

A top-level Transaction class and hierarchy (Figure 30) can support semantic interoperability of business-to-business and business-to-consumer transactions, including order, shipment, and payment objects. As an alternative approach to electronic data interchange (EDI), this object-oriented hierarchy can leverage an interoperable data exchange mechanism that is common to all Object classes.

An instance of a Transaction can define a commerce interaction (EDI document) between one party in relation to another party (the Owner Party) with whom it has a trade relationship.

A Transaction Item class can be modeled as a subclass of the top-level Relationship class. Multiple instances of a Transaction Item can be contained within a Transaction instance to reflect the products (goods and services) being traded.

Figure 30. Transaction class hierarchy and relationships.

A System of systems

Businesses of all sizes implement information and automation systems to efficiently and accurately control their operations. Each of these systems incorporates an ontology or data model to manage, process, and store information objects.

An accounting information system (financial/order management system) is a core cross-industry business system. By leveraging a Common Business Ontology, this system can inherently interoperate with other internal and external systems that also incorporate this ontology.

This approach can enable businesses to effectively transition to multi-party data sharing to meet changing customer demands and industry compliance (such as supply chain traceability).

A top-level System class and hierarchy (Figure 31) can support the management of a system of systems. Each “constituent” system can be defined as “independently operable,” but can be connected for a period of time to achieve a certain higher goal[11]. For example, connecting a Warehouse Management system to an Order Management system can eliminate duplicate data entry and streamline order fulfillment operations.

Event processing for automation systems

Each System instance can contain a collection of Process instances, which can contain a collection of Rule instances. A Process instance can consume Event instances based on its rules and produce Event instances from its actions. For example, a change in the status of an order (an Event instance) can trigger an automated process to generate a shipment or payment.

Figure 31. System class and relationships.

An Internet domain for the root System of systems

An Internet Domain subclass of System (Figure 32) can assign a party (registrant) to an Internet domain (similar to IETF’s EPP), which can provide the party with a root system for its System of systems. For example, the Internet domain “Smart-by-Design.com” can be assigned to the organization “Smart by Design.” All subsystems of Smart by Design can connect (directly or indirectly) to the “Smart-by-Design.com” root system.

Figure 32. Domain Name System assigns a party to the root System of systems.

A System Attribute class and System Connection class can be modeled as subclasses of the top-level Relationship class. Multiple instances of both classes can be contained within a System instance.

As shown in Figure 33, System Attribute instances can reference the class attributes within one or more ontologies that represent the internal input/output of the system’s processes or the data shared with other systems. For example, an Order Management system can reference a “Status” attribute of the Transaction class and the “Product” attribute of the Transaction Item class, both contained within a Common Business Ontology.

Figure 33. Example instances of System Attribute for business systems.

As shown in Figure 34, a system connection instance can reflect the connection between a base system (Smart-by-Design.com) and a subsystem (Order Management). This subsystem can, in turn, be the base system in another System Connection instance. Mirrored System Connection instances can reflect the connection between cross-party systems. For example, the Order Management system of Smart by Design can be connected to the Order Management system of Arrow Electronics to enable cross-party data sharing of the common attributes defined in their System Attribute instances (such as the status of a transaction).

Figure 34. Example instances of System Connection for business systems.

A Product and Asset class for a device

Top-level Product and Asset classes and hierarchies (Figure 35) can support production units (instances) that are manufactured from processes and become assets that are traded, transformed, used, or consumed.

Most ontology models (for example, OMG’s UML, Schema.org) allow multiple inheritance in the class hierarchy: a class can be a subclass of multiple classes. This enables a production unit, such as a device, to be both a product and an asset. It can inherit a “Model” attribute from the Product class and a “Location” attribute from the Asset class. The production unit usually begins as an inventory asset of the manufacturer and transitions to an equipment asset of a customer.

Figure 35. Product and Asset class hierarchy and multiple inheritance.

A Common Product Ontology for e-commerce

A Common Product Ontology (similar to GS1’s Global Product Classification) can classify products based on their essential attributes and their relationships to other products. This ontology can enable trading partners to group products in the same manner for comparisons across multiple e-commerce sites.

The Product ontology can include a Device subclass and hierarchy (Figure 36) that defines attributes for specific classes of devices. For example, a “Pin Count” attribute can be contained within the Device class (applicable to all devices) and a “Maximum Output Voltage” attribute can pertain to a Sensor subclass of Device. An e-commerce site (Arrow.com) can display the inherited attributes of sensor instances as feature comparisons among sensor models.

Figure 36. Device class attributes for e-commerce.

A Product Component class (Figure 37) can be modeled as a subclass of the top-level Relationship class. Instances of Product Component can define a bill of materials or subassemblies that form a “product of products.” For example, instances can define components of a thermostat (sensor and actuator), which itself is defined as a component of a refrigerator.

Figure 37. Example instances of Product Component that define a refrigerator as a “product of products.”

Consortia concepts can be aligned to this Common Product Ontology (Figure 38), which incorporates a root Object class with Identifier, Class, and Owner Party attributes.

Figure 38. Consortia class/attribute alignment for a Common Product Ontology.

An attribute for an alternate identifier

An object can be identified by a universally (globally) unique identifier (UUID) that can be generated by any party in accordance with standard methods (ISO, IETF), without dependence on a central registration authority. While the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible. Adoption of UUIDs and GUIDs is widespread, with many compute platforms that provide support for generating them.

Yet, the same object can also be uniquely identified using identifiers generated from numbering schemes that are controlled by registration authorities (organizations). For example, GS1 is an organization that maintains numbering schemas for “ID Keys.” These keys uniquely identify instances of Product, Asset, Location, and Transaction classes supporting the distributed systems of a global supply chain. Further, any organization (for example, a product manufacturer, retailer, or business unit) can maintain its own numbering schema (for example, a product model) that uniquely identifies objects within its internal systems.

To effectively manage these “alternate identifiers,” an Attribute instance can define a unique class attribute to support a specific numbering schema controlled by a party (the owner party). In Figure 39, an Attribute instance, contained within the Product class and owned by GS1, is defined for each length derivative of a Global Trade Identification Number (GTIN) that identifies a Product instance.

Figure 39. Example attribute instances supporting alternate identifiers.

As illustrated in Figure 40, a Product instance can then be identified by the Identifier attribute within its inherited Object class as well as the alternate identifier attributes within the Product class (Model, GTIN-8, GTIN-12, GTIN-13, etc.).

Figure 40. Example Product instance with attributes representing alternate identifiers.

Extending a Common Business Ontology to IoT

The evolution of products into intelligent, connected devices – which are increasingly embedded in broader systems – is radically shaping companies and competition[12].

Smart, connected products require a rethinking of design. At the most basic level, product development is evolving from largely mechanical engineering to true interdisciplinary systems engineering that can support a system of systems, as illustrated in Figure 41[13].

Figure 41. Moving IoT to a System of systems.

Like a system of systems, IoT components are heterogeneous, autonomous, able to communicate, often distributed, and operationally and managerially independent. Both domains are evolving and operate in dynamic situations, leading to emergent behaviors. In this context, the IoT can be regarded as a system of device systems[14].

As business systems and platforms are being re-designed to become IoT-centric, smart devices can be engineered to be system-centric and leverage a Common Business Ontology to provide inherent interoperability between business and device systems.

A controller is a device (typically a microprocessor or computer) that monitors and alters the operating state (for example, temperature or speed attributes) of component devices (sensors, actuators) connected to its control system.

The controlled attributes of these devices can be defined within the classes of a Common Device Ontology (Figure 42). And a “System” attribute within a Controller subclass of Device can enable a system to be assigned to a Controller instance.

Figure 42. Including device system attributes in a Device Ontology.

The System Attribute class can include instances that support systems for controller devices (Figure 43). These instances can reference the class attributes within a Common Device Ontology that represent the internal input/output of the system’s processes or the data shared with other systems. For example, an Air Flow Control system can reference a “Temperature” attribute of a Sensor subclass, a “Clock” attribute of a Controller class, and a “Speed” attribute of an Actuator subclass.

Figure 43. Example instances of System Attribute for device systems.

The System Connection class can include instances that support device systems connected to business systems (Figure 44). For example, instances can reflect the connection between an Air Flow Control system and an HVAC system that are connected to a Building Automation system that is connected to a Facility Management system implemented by Smart by Design.

Figure 44. Example instances of System Connection for device and business systems.

The Building Automation system can contain a process that changes the “Speed” attribute of a fan motor (a component device) controlled by the connected Air Flow Control system assigned to a controller device. The process can produce an Event instance that changes the fan speed when a triggering Event instance occurs (such as an air temperature change), which can be monitored by process rules. For example, when the “air temperature” attribute of the “Fourth” floor location of the Site location managed by the Building Automation system exceeds a setpoint value of 74 ºF and the time is between 7:30 AM and 6:30 PM (the process rules), change the fan speed to 30 revolutions per minute.

Aligning consortia data models to common ontologies

Consortia can accelerate the adoption of common ontologies by abstracting and decomposing their disparate data models to be system-centric and aligning their concepts and terminology. For example, Zigbee “clusters,” Open Connectivity Foundation (OCF) “resources,” and Bluetooth “profiles” can move towards a common “system” concept/term that comprises “attributes” and “processes.”

• Consortia concepts can be aligned to form a Common System Ontology (Figure 45)
• Consortia objects can be aligned to form instances of a Common System Ontology (Figure 46)
• Consortia concepts can be aligned to form a Common Device Ontology (Figure 47)

Figure 45. Class alignment for a Common System Ontology.

Figure 46. Object decomposition and alignment for a Common System Ontology.

Figure 47. Class and attribute alignment for a Common Device Ontology.

A map for semantic annotation of IoT data

Data maps can relate data elements between two distinct data models or ontologies. For example, a business needing to transmit and receive business transactions with trading partners can create data maps from the data model of its business system to a data model of an EDI standard.

A data map can also be used by a controller device receiving data from a sparsely resourced sensor that requires “semantic annotation” to provide full context within a standardized time series.

A Data Map class (Figure 48) can be modeled as a subclass of the top-level Relationship class. A Data Map instance can relate a sensor object (zn3-wwfl4) and attribute (Temperature) to a location object (Fourth Floor) and attribute (Air Temperature). Referencing this Data Map instance, a controller can annotate the semantics it receives from the sensor with the semantics included in the Data Map instance to populate the metadata of the time series.

Figure 48. Data Map of Object attributes supporting semantic annotation.

A Common Time Series for device and business events

To create value, data generated by IoT devices is increasingly being normalized to time series data (data marked with a timestamp) and transmitted in regular intervals (interval-based), or upon state (or value) changes (event-based).

A Time Series class (Figure 49) can be modeled as a subclass of the top-level Event class. Time Series instances can be efficiently indexed, shared, stored, queried, and analyzed. As business applications (systems) become increasingly IoT-centric and built around event-driven architectures, data from business events can also be normalized to time series data. A Common Time Series class can support both device and business events that reflect object state (attribute value) changes.

For example, a Time Series instance can reflect a location’s air temperature change from a sensor value, which generates an instance reflecting a cooling fan’s speed change, which generates an instance reflecting a fan motor’s failure, which generates instances reflecting a manufacturer’s replacement part order and service work order. A Time Series instance can also reflect a value change of a Conversion Factor (currency exchange rate) associated with a Monetary unit that impacts the price of the replacement part.

Figure 49. Example instances of a Common Time Series for device and business events.

Collectively, the concepts (classes) discussed in this article can form common cross-industry ontologies that support both business and device semantics and processes. This can eliminate the cost and complexity of custom systems integrations.

Part five discusses how a common data format and API can leverage common ontologies.

For term definitions, see the Glossary.

Victor Berrios is Vice President of Technology for Zigbee Alliance and has twenty years of experience in the wireless communication industry. He is a recognized expert in the short-range wireless industry as evidenced by his contributions to the RF4CE Network; Zigbee Remote Control, Zigbee Input Device, Zigbee Healthcare, and Zigbee Low Power End Device Specifications. He was recognized by the Continua Health Alliance as its Spring 2011 Key Contributor to the success of the Test and Certification Work Group.

Richard Halter was the Chief Technology Architect for the Association for Retail Technology Standards (ARTS) for over 18 years. In this role, Richard was responsible for all ARTS artifacts including Unified POS Devices, Operation Data Model, POSLog XML Schema, Integration Technical Reports, and best practices papers. In addition, he contributed to the ARTS Data Dictionary, describing thousands of retail technology terms. Richard was a member of Conexnus (convenience store group), HITIS – Hotel Industry, ARTS, and GS1.

Mark Harrison provides technical consultancy to GS1 in areas including end-to-end supply chain traceability and blockchain, Linked Data/Semantic Web, and the GS1 SmartSearch vocabulary. As former Director of Cambridge Auto ID Lab, Mark contributed to development of GS1 EPCglobal open standards for networked RFID (including EPC Information Services (EPCIS), Discovery Services, Networked/Event-based Electronic Pedigree, and EPC Tag Data Translation).

Scott Hollenbeck is Senior Director of Verisign's Registry Services Lab. Scott has developed expertise in the Domain Name System (DNS) and is the author of the Extensible Provisioning Protocol (EPP) for the registration and management of Internet infrastructure data, including domain names. He has contributed to several industry efforts including internationalized domain names, ENUM, public key cryptography, S/MIME, the Extensible Markup Language (XML), and the Transport Layer Security (TLS) protocol. He has served as a member of the Internet Engineering Steering Group of IETF.

Elisa Kendall has over 30 years of experience in the design and deployment of enterprise-scale information management systems in financial services, government, manufacturing, media, and travel domains. She represents ontology and information architecture concerns on the Object Management Group (OMG)’s Architecture Board, is co-editor of the Ontology Definition Metamodel (ODM), and a contributor OMG’s Financial Industry Business Ontology (FIBO) effort. She has participated in the ISO JTC1 SC32 WG2 Metadata working group and was a member of the W3C OWL and Best Practices working groups.

Doug Migliori has over 20 years of experience in supply chain and retail automation systems and mobile application development platforms. He has contributed to several open source consortia solving interoperability challenges including GS1, ARTS, OMG, CABA, IPSO Alliance, and OCF. Doug administers the IoT in Retail, IoT in Healthcare,  and IoT in Homes and Buildings LinkedIn Groups. He is a principal with ControlBEAM, which provides a Unified Commerce platform built on the BEAM common data service.

John Petze is a partner at SkyFoundry, the developers of SkySpark, an analytics platform for building, energy, and equipment data. John has over 30 years of experience in building automation, energy management and M2M/IoT, having served in senior level positions for manufacturers of hardware and software products including: President & CEO of Tridium, VP Product Development for Andover Controls, and Global Director of Sales for Cisco Systems Smart and Connected Buildings group, and is a member of the Association of Energy Engineers. He is the Executive Director of Project-Haystack.org.

J. Clarke Stevens is Principal Architect of emerging technologies at Shaw Communications. In this role, he analyzes emerging technologies and works with senior executives to develop product strategy. He is a public speaker on the IoT and an active technical contributor to the Open Connectivity Foundation (OCF). He has occasionally been a judge for the CES Innovation Awards. Clarke served on the board of directors of Universal Plug-n-Play Forum (UPnP), chaired the Technical Committee, and led the Internet of Things task force until UPnP was acquired by OCF.

References:

10. Lheureux, Benoit, Gartner Research, March 2016

11. Jamshidi, M., Systems of Systems Engineering: principle and applications, CRC Press, 2009.

12. Porter, Michael E. and Heppelmann, James E., "How Smart, Connected Products are Transforming Companies", Harvard Business Review, October 2015

13. Bleakley, Graham and Hause, Matthew, "Systems of Systems Engineering and the Internet of Things", OMG webinar Nov, 8 2016

14. Alkhabbas, F., Spalazzese, R., and Davidsson, P., IoT-based Systems of Systems, Malmo University, Sweden

eletter-09-11-2017 eletter-09-12-2017