Mobile QR Code QR CODE

  1. (Department of Computer Security and Convergence Engineering for Intelligent Drones, Sejong University / Seoul, Korea {love9ly, G2017SFE052, nargiskhatoon}, )
  2. (EGM / Sophia Antipolis, 06560 Valbonne, France
  3. (Autonomous IoT Research Center, Korea Electronics Technologies Institute / Gyeonggi-do, Korea

Internet of things, Semantic web, Semantic interoperability, oneM2M standard, Semantic framework

1. Introduction

The Internet of Things (IoT) interconnects the vast number of uniquely identifiable devices that collect and deliver information to various smart applications and services. The IoT is one of the fastest growing technology sectors, and is used in many domains, such as smart cities, industries, transportation, health care, and manufacturing, to improve energy usage and provide cost efficiencies. However, many IoT applications are currently implemented in a domain-specific and insufficient manner to provide knowledge acquisition and sharing capabilities [1]. Such vertically tailored applications and systems lack interoperability for horizontally collaborative platforms. The heterogeneous nature of these various applications, which utilize information from a particular domain, introduces a strong need for defining an innovative standard way of abstracting vertical-specific data models [2,3], which will help to realize the full potential of IoT systems.

Data aggregation is a major challenge in an IoT environment, particularly when horizontal collaborations are needed between IoT platforms. Because the IoT is characterized by various data sources having different characteristics, such as being time- and location-dependent, continuous, or noisy, it is difficult to share meaningful information across such diverse vertical environments. Accordingly, a semantic approach adding additional meaning to IoT data is getting attention as a potential solution for sharing useful information and inferring new knowledge from data in the IoT on a global scale [4]. IoT service layer platforms are mainly designed to connect huge amounts of IoT devices and to manage data collected from managing devices. However, most of these platforms provide a simple way to store IoT data, so it is difficult to add additional meaning to those stored data. As a result, IoT applications have limited accessibility to the collected data set because they cannot understand the data's meaning and context.

The situation is even similar on standardized IoT platforms. If standardized IoT service platforms do not provide any means to add meaningful IoT data information, together with raw sensor data such as geolocations, units, and producers, stored IoT applications cannot exploit those IoT data. Semantic web technologies have been widely used for the development of rich and interactive web applications in various domains. For example, the semantic web has been used in environmental and automation domains to solve data interoperability problems [5,6] through context-aware applications and services [7]. Similar to the semantic web, applying semantic technologies to IoT service layer platforms can improve data accessibility, data discovery, and the ability to extract knowledge from the data. Because managing data in the IoT is different from on the Web, the development of a standardized mechanism for adding semantic information to IoT data becomes an important issue in many IoT standards. Global IoT standards such as oneM2M and FIWARE have already introduced semantic technology to add additional metadata to raw IoT sensor data [8]. This research demonstrates how semantic technologies can be enabled on IoT service layer platforms in a standardized manner.

In this paper, we propose the Semantic-enabled IoT Service Framework (SEIF) that provides a common set of semantic services for IoT data storage, knowledge discovery, and access control. SEIF is designed and implemented as part of a standardized IoT service layer that an IoT application can utilize for semantic discovery, knowledge retrieval, and sharing of data across various vertical domains.

The semantic features provided by SEIF, which are the main contributions of this paper, are:

· a mechanism to enable semantic technologies on the oneM2M IoT platform

· an updated oneM2M IoT architecture to support semantic resources and ontologies

· a mechanism to apply the oneM2M access control policy to semantic data with Resource Description Framework (RDF) triples

The rest of this paper is structured as follows. Section 2 explains the need for semantic technologies in the IoT, and how these technologies can make IoT data meaningful to IoT applications. Section 3 presents specific semantic technologies that can be used on the oneM2M IoT platform, such as a semantic web, ontology, and the RDF. Section 4 discusses the technical flow of semantic enablement in IoT service layers, and Section 5 explains the implementation of the proposed semantic IoT platform. Section 6 shows the evaluation results with various sematic approaches. Finally, we conclude the paper in Section 7.

2. Literature Review and Background

Different data models and formats are used in different IoT nodes, which is one of the main challenges to defining a data format with a minimal set of requirements for consumer applications and IoT nodes. Semantic technologies provide various capabilities to describe and manipulate meaningful IoT data, such as the purpose/type of a device, the manufacturer, and the device’s relationship with other devices/things in a machine-interoperable way. To utilize semantic technologies, the data format should be compatible with existing semantic web tools. Semantic web communities like W3C have established the specifications for knowledge representation, such as RDF, OWL, RDFS, and N3. These formats for information description can be used to represent IoT data in a meaningful manner. The representation of an IoT node, such as a sensor value in RDF form, can be constructed by denoting the IoT node as the subject while denoting the unit of measurement and the value of the sensor as properties [9]. As we introduce why semantic technologies are required for IoT service layer platforms, we give an overview of core semantic technologies and recent semantic technology trends in the next subsection.

2.1 Semantic Technologies

Semantic web tools such as a common data representation and description framework produce data in a machine-readable and interoperable manner so they can be employed in the IoT domain, which is producing remarkable results on the web. Semantic technologies (e.g., ontology applications) are the best pathways to allowing the exchange of information, and automatic interpretation can be conducted at the receiver based on the results [10]. Semantic technologies can be used for descriptive specifications, such as the discovery of heterogeneous resources and data integration across multiple domains. Additionally, they support behavioral control and coordination of the agents representing those resources [11]. Overall, semantic technologies can be implemented technically using ontologies and structured data descriptions [12]. Semantic technologies have played a critical role in data and knowledge management for context awareness.

1) Ontology: The ontology is a set of formal specifications that represent concepts like objects that have properties and relationships with other objects. In general, information and operations in each IoT system can be described by ontologies, which provide a common vocabulary with a structure. These ontologies, which can be written as common vocabularies such as OWL and RDF, can be used between different systems through ontology integration or mapping [13]. For example, if a new domain (say, a drone) is added to a smart city environment where various services are provided, the domain is expanded by connecting the drone ontology to the existing base ontology of the smart city through integration. Doing so helps to support semantic exchange and context-driven communications between people and machines by defining shared and common theories for various domains [14,15].

2) RDF/RDFS and OWL: RDF is a standard model and language for describing resources in a more integrated manner. It represents the ontological level of facts about a resource or an individual, such as the types of individuals and their respective relations [16]. It provides a common data structure that can be used for interoperable data exchange. RDFS [17], on the other hand, provides a vocabulary language for structuring RDF resources and describing relationships between resources. OWL was introduced to provide expressiveness and support reasoning over the limitations of RDF and RDFS. OWL features include ease in making common statements, new constructs, extended support for data types, meta-modeling, and annotation capabilities, along with other minor features. To overcome the expressiveness of cardinality constraints in RDF, OWL can cater to issues such as a parking garage having more than 10 unoccupied parking spots, or showing a conjunction of classes such as cars and parking lots.

3) SPARQL and the Semantic Graph Store (SGS): SPARQL is a query language to process and support ontology reasoning and semantic discovery on stored RDF triples. The triple store or SGS usually provides an interface and an internal SPARQL engine. The execution of a SPARQL query requires efficient processing techniques depending on the number of stored triples, such as supermassive IoT data. Note that most existing IoT platforms do not support SPARQL and its corresponding functionalities. The SGS or triple store keeps the set of triples in central graphs or division graphs (named graphs). The named graphs are extensively beneficial in associating resources with semantic meanings. The triple store can be document-based storage or graph-based storage (e.g., MarkLogic, Jena, AllegroGraph, and Stardog). We use a MarkLogic triple store for our semantic data collection.

2.2 oneM2M on an IoT Service Platform

oneM2M utilizes a resource-based approach (i.e., RESTful) for all components in an IoT system. Every function and all the data from the devices, the backend, and management system are represented as resources in a tree structure. These resources can be discovered, retrieved, and updated following Create, Retrieve, Update, Delete, and Notification (CRUDN) principles. For example, the common entities that play a vital role in the oneM2M system design are the Application Entity (AE) and the Common Service Entity (CSE). The CSE is a logical entity in an IoT node with a set of service functions, such as registration and discovery. An AE, such as remote blood pressure monitoring, is also a logical entity that provides an application's business logic.

Embedding semantic technologies into IoT platforms has been used as one of the key solutions in recent years to replace applications tailored in vertical domains with horizontal and common services. Several research studies have been conducted to identify semantic functions and services in the IoT [18-23]. In addition, semantic technologies have been adopted in various vertical domains that use IoT platforms for managing devices and services, such as smart cities, smart homes, smart health, and energy [24-32].

The oneM2M standard, which is used for managing IoT devices and data in various domains such as smart cities, smart factories, and smart homes, also utilizes semantic technology to integrate large-scale data and develop standards to maximize data utilization.

1) Semantic Annotation: The oneM2M service layer defines a <semanticDescriptor> resource (Fig. 1) in order to store semantic-related information. The semantic information contained in <semanticDescriptor> resources can be leveraged by the semantic functionalities of IoT platforms as well as end-user applications.

Semantic annotation is a process of adding semantic information to resources, e.g., <semanticDescriptor>, in oneM2M IoT platforms so that an annotated resource can be discovered semantically by heterogeneous IoT applications. In other words, this annotation process provides more meaningful descriptions of IoT data and allows them to be discovered by many IoT applications, compared to traditional IoT systems that do not support semantic annotation. In the oneM2M system, semantic information is represented using RDF/RDFS (or OWL) as RDF triples. For example, semantic information could be related to IoT things, which can easily be encoded into RDF triples.

2) oneM2M Base Ontology: Descriptions using an ontology and OWL are used in oneM2M to provide interoperability based on the meaning of information and the data between oneM2M and external systems. For this, oneM2M developed a standard specification for its oneM2M Base Ontology (oneM2M TS-0012 [33]) that abstracts the IoT domain. The oneM2M Base Ontology describes key classes, relationships, and properties relevant to adding semantic information to oneM2M resources, and provides interoperability between applications as well as interworking with non-oneM2M technologies. If IoT data are given with a semantic description according to the oneM2M Base Ontology, the oneM2M system can automatically create a proper resource structure through semantic interpretation. The vocabulary provided by oneM2M Base Ontology is suitable for describing the capabilities and functions of IoT devices and is small enough to work well with constrained IoT devices. In oneM2M, the <ontologyRepository> resource allows the holding of various reference ontologies, including the oneM2M Base Ontology. This resource represents an ontology repository that can contain ontologies represented as <ontology> child resources.

3) Other Semantic Technologies: oneM2M supports various semantic technologies, such as semantic reasoning and an access control policy. Semantic reasoning is a mechanism to derive new knowledge from semantically annotated IoT data. This allows IoT platforms to answer complex queries. A set of rules for semantic reasoning defines some logic for deriving new knowledge based on existing information stored and annotated in the <semanticDescriptor> resources.

oneM2M defines a process to directly enforce access control policies (ACPs) when executing a semantic query from the triple store by adopting existing oneM2M ACPs in RDF triples. In oneM2M, the access control policy can be applied to <semanticDescriptor> resources by adding ACPIDs to <semanticDescriptor> resources. In this way, semantics-related operations to be executed directly on the RDF triples stored in the SGS follow those access control policies. At the moment, the oneM2M system only defines a basic means to add an access control policy to the <semanticDescriptor> resources.

Performance optimization and advancement have not yet been made in the case of semantic functions defined in oneM2M. In particular, in an access control policy, it is necessary to apply it to various semantic functions (for example, semantic search, semantic mashup, semantic query, etc.) for efficient use within the IoT platform. Therefore, the next section introduces how to implement semantic functions in the oneM2M standard-based IoT platform and how to apply effective ACP functions to semantics.

Fig. 1. The <semanticDescriptor> resource in oneM2M to store semantics-related information.

3. SEIF Overview

In an IoT service layer, enabling semantic support provides semantic data management, smart data retrieval, and data sharing. For this purpose, we propose the Semantic-enabled IoT Service Framework, which is comprised of services such as semantic discovery, annotation of sensors and data, semantic query, access control, and semantic validation. In the SEIF architecture, the data can be collected from various IoT domains, such as a smart city, a smart office, a smart farm, and health care in a smart home. According to the oneM2M standard, data from devices is received through communication gateways to IoT platforms. In this section, we describe how SEIF works to support various semantic services, along with detailed configurations and operation flows.

3.1 The SEIF Architecture

SEIF supports services such as semantic data retrieval and semantic validation at the IoT service layer. SEIF was designed based on the oneM2M standard. Therefore, all IoT devices managed by SEIF are created as resources, and IoT applications can then access them using the CRUDN operational principles. When data are generated from IoT-enabled devices composed of multiple sensors and actuators built into smart cities and smart buildings, they can be collected as a service framework through a gateway. SEIF can integrate collected data in different formats by forming semantic data through semantic annotation.

Fig. 2 shows the SEIF system architecture. SEIF provides various semantic functions as common services of an IoT platform through a semantic resource manager. Functions of the semantic resource manager include common ontology management, annotation and mashup of semantic information, validation of annotated semantic information, and managing access to the information. Since semantic-related information and data are stored and managed in a SGS rather than an existing relational database, SEIF uses a separate SGS. To enable semantic capabilities on IoT service platforms, SEIF provides five core semantic functions as follows.

· Semantic Annotation supports adding semantic information to resources in SEIF IoT platforms so that an annotated resource can be discovered semantically by heterogeneous IoT applications.

· Semantic Validation can be carried as an individual process to validate creation and deletion of semantic resources. The validation function guarantees that an issuer, such as an application, that creates or updates semantic information will always provide consistent and correct information. If the semantic description (triples in the descriptor attribute) is not compliant with the referenced ontology, it means the semantic information is not valid and cannot be used properly by the application for semantic queries or reasoning.

· Semantic Mashup is a process to discover and collect data from more than one input source, conduct business-logic-related mashup functions on collected data, and eventually generate meaningful mashup results. For example, the mashup function can generate a metric called weather index based on collected data from multiple IoT sensors (e.g., temperature and humidity) in SEIF.

· Semantic Reasoning can be used to provide new information inferred from an existing knowledge base. The reasoning process can be used to manage the data, share information, and generate new information. In SEIF, the task requires mashup services in the sense that knowledge can be combined from various resources, and reaching a conclusion is easy.

· Semantic Access Control ensures that for a given semantic query, the access control policy defined in oneM2M is enforced in the sense that only RDF triples stored in semantic resources (i.e., allowed by the access control policy) can serve as an RDF database for the query.

Each semantic capability is integrated into SEIF as a logical function. The description of each logical function is explained in the next subsection.

Fig. 2. Semantic annotation in SEIF using the <semanticDescriptor> resource.

3.2 Logical Semantic Functions

1) Semantic Annotator: Since the SEIF system uses a hierarchical tree structure based on oneM2M standards to store and manage its resources, semantic information needs to be added as a special semantic resource. The <semanticDescriptor> resource and its attributes are used for this purpose, as shown in Fig. 2. This resource is used to add semantic information to an existing normal resource, such as a container resource or an <AE> resource. It is done by adding <semanticDescriptor>, SD,} as a child resource of a normal resource. The semantic information contained in <semanticDescriptor> can be leveraged by the semantic functionalities of SEIF as well as end-user applications.

The <semanticDescriptor> resource shown in Fig. 1 contains the following attributes to facilitate semantic information management:

· ontologyRef containing the URI of the ontology used for semantic descriptors

· descriptorRepresentation indicating the format of the semantic information, such as application /rdf+xml:1

· relatedSemantics containing the URIs of relevant <semanticDescriptor> resources

· Descriptor containing semantic information in the format indicated by the dspr attribute (e.g., in RDF triples)

Semantic information is represented using RDF/RDFS (or OWL) as RDF triples. For example, semantic information could be relations among IoT things, which can easily be encoded into RDF triples. This resource can appear anywhere in the resource tree as a child resource of an existing oneM2M resource.

The <semanticDescriptor> resource is stored in the semantic graph store. The SGS is also triple store data in the form of graphs. The <semanticDescriptor> resource is stored as a triple set under various resources, as mentioned above.

2) Semantic Validator: The <ontologyRepository> contains ontologies represented as <ontology> child resources, as shown in Fig. 1. Because resources are semantically described based on the referenced ontology, an IoT platform should provide a semantic validation function via the <semanticValidation> virtual child resource. Typically, the triple relationships stored in <semanticDescriptor> should be compliant with the ontology referenced by the ontologyRef attribute. If an issuer of the <semanticDescriptor> resource maliciously crafted the contents of the resource, because of the non-compliant semantic information, various semantic functions such as semantic query or reasoning cannot be performed properly.

Under SEIF, the Semantic Validator determines whether the semantic data (RDF, the information generated by the semantic annotator) is correctly generated according to the syntax of the ontology corresponding to the <ontologyRef> resource.

3) Semantic Reasoner: Semantic reasoning in SEIF is a method of obtaining facts that are not explicitly expressed in existing knowledge/facts (such as RDF triples) using a set of rules for reasoning. Adding a <semanticRule> resource to each <semanticDescriptor> resource will help an IoT application retrieve smart data to support semantic reasoning. The information is stored in the <semanticDescriptor> and <ontology> resources in order to derive implicit facts by leveraging a set of semantic reasoning rules. For this purpose, the semantic reasoner creates <reasoningRules> as a child resource of <semanticRuleRepository>, which is a type of resource that stores different reasoning rule sets.

4) Access Control Policy for Semantics: ACPS is a function to be executed only when an <accessControlPolicyIDs> resource exists in a <semanticDescriptor> resource. The ACPS discovers the identifiers of the access control policy included in the <accessControlPolicyIDs> resources, and reads the access control rules as well as the privileges of each ACP. Then, the ACPS checks whether access to the target semantic data is permitted according to the access control rules corresponding to <semanticDescriptor>, such as Discovery and Delete, and according to the privileges. If access is permitted, the relevant module is notified to perform tasks, such as semantic data generation and search.

5) Semantic Mashup: The process of collecting data from multiple IoT applications and introducing a new application using the collected data is called a semantic mashup. In the oneM2M context, a common resource can be annotated with semantic descriptions, and they can be discovered and identified as a potential data source for a specific mashup application through semantic resource discovery. The Semantic Mashup Function (SMF) is a logical entity responsible for collecting data from data sources, i.e., container resources in oneM2M, and generating mashup results based on business logic.

The <semanticMashupJobProfile> resource in oneM2M represents a semantic mashup job profile (SMJP), which can be provided to the host CSE that provides the semantic mashup function. A CSE/AE as a Mashup Controller can request the creation of a <semanticMashupInstance> resource in another oneM2M CSE that implements the semantic mashup function. Each created <semanticMashupInstance> matches the semantic mashup job profile (i.e., a <semanticMashupJobProfile> resource) and performs a mashup operation to calculate the results of the mashup in the corresponding <semanticMashupJobProfile>. The result will be stored in the child resource, <semanticMashupResult>, of the corresponding <semanticMashupInstance>.

6) Semantic Resource Manager: The semantic resource manager controls semantic IoT resources, such as creating and updating oneM2M resources. All oneM2M resources, such as <semanticDescriptor> and <ontologyRef>, are derived from the corresponding semantic resource manager. The semantic resource manager creates oneM2M resources based on semantic information generated by each semantic module, such as a semantic annotator, a semantic validator, and a semantic reasoner, and builds them in the IoT Resource Repository.

7) IoT Resource Storage: The IoT resource storage used in this paper is Mobius, an open source IoT server platform based on the oneM2M standard. As oneM2M specifies, Mobius provides common service functions (e.g. registration, data management, subscription/notification, security) as middleware to IoT applications from different domains—not just oneM2M devices—and non-oneM2M devices can connect to Mobius.

4. Semantic Annotation and Discovery

SEIF provides various services such as semantic discovery, knowledge retrieval, sharing of semantic data across different vertical domains, and an access control policy for semantic data. These semantic services require additional meaningful information embedded in raw measurement data. For example, in order to describe body temperature measurements, additional information (such as the name of the patient, and the times and places of the measurements) should be stored with the actual measured values. Therefore, semantic enablement on IoT platforms requires efficient data storage mechanisms. SEIF uses the semantic graph store to hold semantic-related data.

Fig. 4 shows two approaches that can be used for storing semantic data in the SGS. For association of original triples with access control triples of semantic data, as shown in Fig. 4(a), all triple data can be included in the central graph and stored in the SGS, or they can be included and stored in individual graphs, as shown in Fig. 4(b).

Fig. 4(a) is the central graph approach, in which access control can be applied using an internal ontology with class SD and atomDescription, and the properties describedIn, hasSubject, hasObject and hasProperty. The binding triples provide an association of original triples in the semantic graph store with semantic information in the <semanticDescriptor> resource. Each original triple is expressed in the form of four triples, which include the reference to the <semanticDescriptor> resource URI described in the data property. Then, access control triples are added to the resulting binding triples and are stored in the SGS. This approach works well for a small number of triples or for static use cases, such as representation of indoor sensors in a room recording temperature, and humidity. It results in a huge number of triples in the semantic graph store.

On the other hand, the approach in Fig. 4(b), the graph division approach, has multiple RDF graphs in a single document/repository, naming them with URIs that provide a useful additional functionality on top of the RDF recommendations. The binding of the <semanticDescriptor> triples using atomDescription can overcome issues of association with efficient management of triples in the semantic graph store and fast retrieval of data.

For access control on semantic data, atomDescription and ACP binding triples are required. List 1 shows the triples required for semantic data access control in the SGS. The attribute <semanticDescriptor> contains the original triple, and the instance of the <semanticDescriptor> resource is described by the atomDescription class that is binding triples. Binding triples involves four properties (hasSubject, hasObject, hasProperty, and describedIn) and provides a correlation with the semantic information of the original triple and the <semanticDescriptor> resource stored in the SGS. Each original triple is expressed in the form of four triples, which include reference to the <semanticDescriptor> resource URI described in the data property. Then, access control triples are added to the resulting binding triples and are stored in the SGS. This results in a huge number of triples in the semantic graph store. The semantic information associated with the <semanticDescriptor> resource can all be stored in a named graph linked inside the SGS, as opposed to storing all triples in one huge single graph store like the central graph approach. Direct access control applications incur overhead from associating semantic triples in the original <semanticDescriptor> with relational triples created to bind with corresponding triples stored in SGS in the central graph approach, but this can be overcome using the graph segmentation approach. A comparative analysis of both approaches is provided in Table 1.

Fig. 3. The <semanticDescriptor> resource in oneM2M to store semantics-related information.
Fig. 4. Enforcement of access control using the <ACP> on the <semanticDescriptor> resource.
List 1. Sensor representation in singular and binding triples.
Table 1. Compare analysis of the central graph approach vs. the graph division approach.


Central Graph-based Semantic Filtering

Graph Division-based Semantic Filtering


Every <SD> in the SGS in one central graph

Each <SD> in the SGS using named graphs

Storing data

SD relationship triples and ACP binding triples are created to show associations of triples stored in the SCS with <semanticDescriptor> and <ACP> stored in the resource tree.


1. A huge number of triples in one graph

2. Slow semantic query or discovery over SGS

1. Fewer triples in one graph

2. Quick and easy semantic discovery to retrieve semantic resource URI

4.1 Annotation Flow

Fig. 5 illustrates the procedure to create SD and ACP triples in the SGS when the semantic annotator and several modules create a new <semanticDescriptor> resource at the hosting CSE. The following steps have to be performed.

· Step 1: To go through the annotation process to create semantic data, you need the ontology suitable for the domain of the semantic data you want to create. When the hosting CSE receives a request to create a new <semanticDescriptor> resource, it requests the <ontology> resource required for resource creation of IoT resource storage.

· Step 2: The IoT resource storage returns the requested <ontology> resource to the semantic annotator.

· Step 3: The semantic annotator annotates the IoT data with semantic data based on the <ontology> resource.

· Step 4: The sets of triples are passed to the semantic validator to check whether what were generated by the semantic annotator are correctly formed according to the rules.

· Step 5: The semantic validator confirms the sets of triples. The validation process verifies syntactic validation and semantic validation in that order.

· Step 6: Verified triple sets and validated results are delivered to the IoT resource manager so that <semanticDescriptor> resources can be created.

· Step 7: The IoT resource manager creates or updates the <semanticDescriptor> resource with RDF data based on the sets of triples, and then, validates the results.

· Step 8: The created <semanticDescriptor> resource and its sub-resources are saved in IoT resource storage.

· Step 9: Confirm the access control policy.

· Step 10: Check the access control policy for the <semanticDescriptor> resource.

· Step 11: If the ACP resource is linked to the semantic resource, create ACP binding triple sets based on the ACP ontology.

· Step 12: Provide a set of ACP binding triples.

· Step 13: Create an <ACP> resource based on the ACP binding triple sets.

· Step 14: Store the resource in IoT resource storage.

· Step 15: The SGS stores all sets of triples as a named-graph URI.

Fig. 5. Mapping the flow in a semantic annotation service request to the platform.

4.2 Semantic Discovery

One of the key benefits of semantic descriptions, such as annotated semantic information, is enabling semantic resource discovery, which is discussed and exemplified in this subsection. Semantic resource discovery is basically the capability of an IoT application to discover resources based on certain specified characteristics of the resources it is seeking. Semantic resource discovery can be achieved using a SPARQL query.

A semantic query from an IoT application is targeted to a specific oneM2M resource. The platform then determines the scope of the semantic query, and executes it against all semantic information within the established scope to generate the results i.e., a list of discovered resources. Then, the IoT application is notified of the discovered resources, and it can retrieve the desired resources based on the returned URIs. Specifically, a semantic filter is specified in oneM2M, which is formulated as a SPARQL query and contained in a semantic resource discovery request. An IoT application that wants to discover resources using semantics has to form a semantic query statement using SPARQL based on its needs. The query is then sent to the IoT platform as part of the semantic resource discovery request (i.e., a RETRIEVE request message).

5. Semantic Use Case and Implementation of IoT Platform

This section specifies the process for establishing a semantic service environment based on the proposed system. The methodology for implementation and processing the scenario in the SEIF system is also explained.

5.1 The Use Case

It is important to show that semantic technologies can be used in real-world environments such as smart buildings, smart offices, and smart homes. Therefore, to see the feasibility of adopting semantic technologies on oneM2M IoT platforms, this section describes a smart building environment with typical sensor deployment, e.g., temperature, humidity, and CO2 levels.

For data collection, a smart office was designed, and sensors from different buildings and parking areas were used to gather values. The sensors measured temperature, humidity, CO2 levels, and parking lot status. The sensors were deployed in office buildings and connected to the office gateway. The office gateway communicates with a cloud service platform allowing the sensor information to be controlled by a smart application. The cloud service provides registration, discovery, data management, subscriptions, and notification of resources and semantic information. A smartphone application can communicate with the cloud service platform for resource discovery, to retrieve the state of the sensor data, and to receive notifications.

Fig. 6 illustrates data collection by the sensors through the Mca reference point (the communication interface between AE and CSE) to the IN-CSE with semantic capabilities. In this use case, temperature, humidity, CO2 levels, and smartphone applications each host an AE in an MN-CSE, and the MN-AE is hosted in a gateway deployed inside the office building. Applications used in the use case include the following.

· ADN-AEhumid: An application embedded in the sensor to measure humidity in the office.

· ADN-AEtemp: An application embedded in the sensor to measure the temperature in the office.

· ADN-AEco2: An application embedded in the sensor to measure the CO2 level in the office.

· ADN-AElight: An application embedded in the sensor to measure light and power in the office.

· ADN-AEpark: An application embedded in the sensor to check the status of parking spots in the office parking lot.

· ADN-AE: A smartphone application that interacts with a cloud service platform through an Mca reference point.

· MN-AE: An application embedded in the gateway that interacts with a cloud service to store sensor information that can be further processed by IN-CSE.

The office is registered as an application entity resource of an IoT platform. The data are collected from sensors and sent to IN-CSE. The reading from each sensor for every building and the parking spot is created as a content instance whenever new data are received and upon notification. Static resources such as container resources are only registered once but can be updated later. Dynamic resources can have multiple instances, for example, sensor information and semantic descriptions of buildings and parking spots.

5.2 Implementation

1) Implementation Choices: In order to provide semantic support, there are two possible solutions. One is to use a tailored solution to solve the lack of semantic enablement in a particular system for certain use cases. This would require reprogramming everything when a new requirement arises. The option does not scale, and is not suitable for new problems or the implementation of new use cases. The second option is to have a flexible solution that is easier to implement, does not require reprogramming, and supports quick implementation of new business rules. The ideal solution requires the following characteristics:

· explicit expressiveness and conditions to manage semantic capabilities of sensors/devices

· a deployment requirements strategy

· efficient execution of requirements

· flexibility to support semantics for new use cases and device/sensor descriptions

· ease of use, and a modular design to implement new features

The necessary functions are provided by the framework’s API module. It provides support to upload semantic queries on issues such as IoT application entities, for semantic discovery, and for rule execution. SEIF is expected to run as a cloud service platform. It can be integrated with a common service entity to enhance semantic features in the resource base. However, it can also function as an independent framework or a base template to extend the implementation of new services. In the current solution, we extend existing IoT platforms with semantic capabilities based on the IoT standard. There are quite a few choices for a semantic graph store, such as Jena, MarkLogic, and Virtuoso. However, MarkLogic was selected owing to the following factors:

· semantic support in the existing IoT platforms implemented in a NodeJS environment

· open source with a strong user base, because its support for semantic data interpretation is available in several languages such as C, Java, and NodeJS

· easy-to-use syntax

· easy implementation and integration of semantic queries, discovery, and reasoning under semantic rules

2) Resource Structure: The IN-CSE resource tree starts with a CSEBase, as depicted in Fig. 7. The root CSEBase has one direct child resource, which is <AE> (termed building). This resource has five child resource representations for each sensor, such as <container> (<CNT>). <CNT> is directly relevant to semantic annotation and the discovery use case, which are humidity, temperature, parking spot status, and CO2 level. Each container will have containers called measurement and metadata where the content instances are stored. Implementation is followed by storing <semanticDescriptor> resources in different settings.

Fig. 6. Data collection in IN-CSE from the sensors.
Fig. 7. Resource structure created in IN-CSE.

5.3 Annotation and Discovery Requests

A request from the annotator should contain semantic information in base64 encoded format and the target resource information under which a semantic resource will be created. The simple Hypertext Transfer Protocol (HTTP) triggers the request to the IoT platform, and the data are stored in the resource base. The request for semantic data storage in the triple store is implemented as an abstract layer, which is beneficial for annotating the data inside the IoT platform without additional programming or implementation. The set of triples is stored in the semantic graph store connected to the abstract semantic service layer in the platform (as described in List 2) as an annotation request.

The request via the semantic discovery message should contain the resource information and the SPARQL query to find information from the sensors. For instance, to find the current measurement of the light and humidity sensor, the SPARQL query described in List 3 was sent by the AE to the hosting CSE in encoded format. The query response is based on a semantic query filter for either semantic resources URIs or semantic resource descriptions.

List 2. HTTP request/response for semantic annotation.
List 3. HTTP request/response for semantic discovery.

6. Evaluation

This section is composed of a performance matrix and an evaluation series with different configurations of results followed by the implementation explained in the previous section. The evaluation of the framework mainly focuses on the impact of the different approaches to semantic annotation, and discovery of the semantic data size and query execution time.

The implementation was a modular design, and SEIF was implemented as one of the IoT platform components. It runs on a Linux-based system that is capable of huge amounts of data storage because new readings from the sensors are frequently updated and stored. Semantic knowledge is also updated accordingly. SEIF performance was assessed in terms of triple size, graph size, and query execution time (QET). QET, in milliseconds, measured the time needed to execute semantic queries, including the time needed to parse the query, limiting the search of the graph store according to the originator URI. For the performance evaluation, we selected the following set of test cases to exhibit the problems (identified in semantic enhancement of the IoT standards) and the potential solutions. For experimental study and evaluation, data from 177 sensors were collected, and their semantic descriptions stored in triples. For each representation, the sets of triples were stored in various named graphs based on system configuration. The evaluation series comprised the following test cases.

· Semantic Annotation: Data Distribution

· Store <semanticDescriptor> in different resources: without or with ACP

· Semantic Discovery (content-related, and resource-related)

· Resource-based semantic discovery

· Attribute information is unknown

· Attribute information is known

6.1 Semantic Annotation with/without ACP

Comparative analysis of ACP by graph division over atom description and semantic association triples is demonstrated in Fig. 8. Three classifications, which include triples without ACP, with ACP using a graph (the proposed solution), and ACP using binding triples, were implemented following the oneM2M standard. The results clearly demonstrated a high number of triples in the third category for each resource.

It is recommended to apply ACP logic at the resource base level. Nevertheless, ACP access using a graph is more efficient in retrieving applied access control along with semantic data in an interoperable environment. However, the binding triples increased the size twofold by creating ACP triples using the ACP ontology and SD-relationship triples using an atom description class on the original triples. In semantic discovery, the evaluation was distributed into two categories: semantic discovery over different data distributions and semantic discovery on ACP-enabled triples. The following semantic queries were used to benchmark semantic discovery with different scales and parameters.

Fig. 8. Access Control based Semantic Annotation in SGS.

6.2 Semantic Discovery in Different Data Distributions

Semantic discovery was evaluated based on data stored in different resources. The graph in Fig. 9 illustrates the average QET from SPARQL queries executed on the SEIF module with different configurations. In the first configuration, the AE-resource-based request took less than 68.3 ms on five target graphs, which was less than all the other resource-based SPARQL query requests. Other resources took more time for SPARQL query execution (79 ms and 88.8 ms for <CNT> and <CIN>, respectively), which showed that resource-based selection discovery optimized the query time when base-level resources were used to store triples. <AE> and <CNT> represent the semantic annotations of sensors in a smaller number of graphs and triple sizes, compared to the <CIN> resource, which resulted in a huge number of triples.

Fig. 9. Semantic discovery from a data distribution in different resources.

6.3 Semantic Discovery of ACP-enforced Semantic Data

The average QET time for SPARQL query execution on semantic discovery for GT triples (semantic triples without ACP), ACP_GT, and ACP_BT with respect to <AE>, <CNT>, and <CIN> was evaluated as shown in Fig. 10. In AE, access control policy enablement, which used an atom description, took more time for semantic data discovery (1221 ms on average for nine AE graphs) compared to more efficient discovery with minimum time (944 ms) in graph-based triples in ACP_GT. The increase in QET is directly proportional to the increase in the number of graphs.

For a target graph, GT and ACP_GT consumed less time than ACP_BT. The consistent trend in query time versus the number of graphs demonstrates that ACP_BT took more time in each scenario. The discovery request from triple access with no access control (GT) was faster than access control enforcement triples (ACP_BT). Intervals of five and twenty were considered for performance on a selected range of target graphs named under the <CNT> and <CIN> URIs. In a comparative analysis based on resource type, discovery using <AE> and <CNT> was much more efficient and consumed less time, compared to <CIN>. It is recommended to apply ACP using a named graph and discovery of semantic data using <AE> and <CNT>, because the target resource will consume less execution time when the target resource is unknown, and the request relies on the information of the application entity only.

Fig. 10. Semantic Discovery for GT, ACP_GT, and ACP_BT with respect to each resource.

6.4 Insights from the Performance Evaluation

Evaluation insights are based on resource selection in terms of semantic annotation and different approaches to access control over semantic data. In terms of resource selection, <semanticDescriptor> should be created inside <AE> and <CNT> for a smaller number of graphs and triples. The <CNT> resource is highly applicable to <semanticDescriptor> resource creation for complex modeling of resources. Based on the following approach to implementation, the application originator should create a semantic descriptor in <AE> and <CNT> for optimized semantic query execution when the request contains only basic entity information. The <CNT> resource should be utilized in the semantic descriptor representation for a semantic model that is comprised of a few triples, because it results in fast execution of limited semantic search queries.

In a centralized IoT environment, access control should be enforced in the resource base to avoid increased data sizes and to slow execution of semantic discovery requests. Access control over triples should be implemented in <CSEBase> and should connect <ACP> with <semanticDescriptor> to enforce access control. Access control on triples in the SGS should be implemented using graph-division-based semantic filtering (ACP_GT) rather than central-graph-based semantic filtering (ACP_BT). Better performance for optimized query execution was shown by using ACP_GT over ACP_BT. It is also a suitable approach for distributed setup of the resource base and the semantic graph store, such as when the resource base is hosted in a different IN-CSE, and the semantic graph store is hosted in yet another.

7. Conclusion

Semantic technologies aim to fulfill the promise of describing an object, sharing information, and inferring new knowledge based on machine-interpretable representation formalism. These technologies can be applied in the dynamic and resource-constrained nature of the IoT with consideration for overcoming existing challenges. One of the challenges in the IoT is lack of interoperability between IoT platforms using different standards. Therefore, there is a strong need to resolve the interoperability issue using semantic technologies inspired by the semantic web.

In this article, a semantic-enabled IoT service layer architecture was designed based on the oneM2M global IoT service layer standards, and the enhancement of semantic support with deep insight was studied based on the standard. In this architecture, semantic descriptor resources are introduced to represent semantic information in RDF triples. This semantic descriptor resource allows an IoT service layer or an IoT application to annotate existing IoT resources/data with additional semantic information that uses selected ontologies and RDF/RDFS. The added semantic information is then leveraged for semantic filtering/discovery and semantic mashup. The proposed semantic-enabled IoT architecture also supports a semantic repository to maintain all semantic information in a centralized triple store. Then, a SPARQL query can be executed directly on the triple store against the semantic information stored there. An evaluation of semantic annotation and semantic discovery was performed on an implemented SEIF to show the query execution time on different resources. The data stored in the single-named graph was retrieved in less time, compared to multiple graph storage. In a comparative analysis, annotation of the data in the AE resource and the <CNT> resource is recommended over <CNT>.

SEIF currently does not deploy semantic rules and inference over semantic data, which should be considered in enhancement towards semantic services. Ontology management and semantic extraction from data should be a concern in future work, which also includes advanced semantic annotation. Semantic annotation with other data models could expand information synchronization between the oneM2M service layer and the semantic service layer, for distributed semantic analytics and other functions, as well as interoperability with other standards. For future work, we plan to extend the introduced semantic framework with new technologies (e.g., linked data and license management) to improve the capabilities of semantic knowledge.


This work is supported by Smart City R&D project of the Korea Agency for Infrastructure Technology Advancement(KAIA) grant funded by the Ministry of Land, Infrastructure and Transport(MOLIT), Ministry of Science and ICT(MSIT) (Grant 22NSPS-C149388-05)


A. Gyrard et al., “Cross-domain Internet of Things Application Development: M3 Framework and Evaluation,” in 2015 3rd International Conference on Future Internet of Things and Cloud, IEEE, pp. 9-16, 2015.DOI
D. Bandyopadhyay et al., “Internet of Things: Applications and Challenges in Technology and Standardization,” Wireless Personal Communications, vol. 58, no. 1, pp. 49-69, 2011.DOI
C. Perera et al., “Context Aware Computing for the Internet of Things: A Survey,” IEEE Communications Surveys & Tutorials, vol. 16, no. 1, pp. 414-454, 2014.DOI
A. Palavalli et al., “Semantic Internet of Things,” in 2016 IEEE Tenth International Conference on Semantic Computing (ICSC), IEEE, pp. 91-95, 2016.DOI
P. Barnaghi et al., “Semantics for the Internet of Things: Early Progress and Back to the Future,” International Journal on Semantic Web and Information Systems (IJSWIS), vol. 8, no. 1, pp. 1-21, 2012.DOI
J. Song et al., “Connecting and Managing M2M Devices in the Future Internet,” Mobile Networks and Applications, vol. 19, no. 1, pp. 4-17, 2014.DOI
E. Kovacs et al., “Standards-based Worldwide Semantic Interoperability for IoT,” IEEE Communications Magazine, vol. 54, no. 12, pp. 40-46, 2016.DOI
oneM2M, “Semantics support,” oneM2M Technical Specification, TS-0034-V4.2.0, pp. 1-72, 2020.URL
X. Su et al., “Enabling Semantics for the Internet of Things – Data Representations and Energy Consumptions,” Springer Internet of Things Finland, vol. 1, no. 1, pp. 28-31, 2013.URL
M. Ganzha et al., “Semantic Interoperability in the Internet of Things: An Overview from the Inter-IoT Perspective,” Journal of Network and Computer Applications, vol. 81, pp. 111-124, 2017.DOI
A. Katasonov et al., “Smart Semantic Middleware for the Internet of Thins,” Icinco-Icso, vol. 8, pp. 169-178, 2008.URL
A. Sheth et al., “Semantic Sensor Web,” IEEE Internet Computing, vol. 12, no. 4, pp. 78-83, 2008.DOI
G. Narula et al., “Ontology Mapping and Merging Aspects in Semantic Web,” Int Rob Auto J, vol. 4, no. 1, 2018.DOI
A. Maedche et al., “Ontology Learning for the Semantic Web,” IEEE Intelligent Systems, vol. 16, no. 2, pp. 72-79, 2001.DOI
N. Meenachi et al., “A Survey on Usage of Ontology in Different Domain,” International Journal of Applied Information Systems, vol. 4, no. 2, pp. 46-55, 2012.DOI
T. Raimbault, “Overviewing the RDF(s) Semantic Web,” in 2010 International Conference on Computational Intelligence and Software Engineering, IEEE, pp. 1-4, 2010.DOI
D. Brickley et al., “RDF Schema 1.1, W3C Recommendation,” 2014.URL
K. Ashton, “That ‘Internet of Things’ Thing,” RFID Journal, vol. 22, 2009.URL
I. Lee et al., “The Internet of Things (IoT): Applications, Investments, and Challenges for Enterprises,” Business Horizons, vol. 58, no. 4, pp. 431-440, 2015.DOI
K. Whitehouse et al., “Semantic Streams: A Framework for Composable Semantic Interpretation of Sensor Data,” European Workshop on Wireless Sensor Networks, pp. 5-20, 2006.DOI
E. Prud’hommeaux et al., “SPARQL Query Language for RDF, W3C Recommendation,” Springer US, 2008.URL
B. Quilitz et al., “Querying Distributed RDF Data Sources with SPARQL,” in European Semantic Web Conference, Springer, pp. 524-538, 2008.DOI
D. Gerver et al., “Real-time RDF Extraction from Unstructured Data Streams,” in International Semantic Web Conference, Springer, pp. 134-140, 2013.DOI
L. Atzori et al., “The Internet of Things: A Survey,” Computer Networks, vol. 54, no. 15, pp. 2787-2805, 2010.DOI
E. Borgia, “The Internet of Things Vision: Key Features, Applications and Open Issues,” Computer Communications, vol. 54, pp. 1-31, 2014.DOI
Y. Qin et al., “When Things Matter: A Survey on Data-centric Internet of Things,” Journal of Network and Computer Applications, vol. 64, pp. 137-153, 2016.DOI
R. Mehta et al., “Internet of Things: Vision, Applications and Challenges,” Procedia Computer Science, vol. 132, pp. 1263-1269, 2018.DOI
P. Zhibo et al., “Ecosystem Analysis in the Design of Open Platform-based in-Home Healthcare Terminals Towards the Internet of Things,” in 2013 15th International Conference on Advanced Communications Technology (ICACT), pp. 529-534, IEEE, 2013.URL
D. Uckelmann et al., “An Architectural Approach Towards the Future Internet of Things,” Springer Berlin Heidelberg, pp. 1-24, 2011.DOI
L. D. Xu et al., “Internet of Things in Industries: A Survey,” IEEE Transactions on Industrial Informatics, vol. 10, no. 4, pp. 2233-2243, 2014.DOI
D. Gil et al., “Internet of Things: A Review of Surveys based on Context Aware Intelligent Services,” Sensors, vol. 16, no. 7, pp. 1069, 2016.DOI
A. Bikakis et al., “A Survey of Semantics-based Approaches for Context Reasoning in Ambient Intelligence,” in Constructing Ambient Intelligence, Springer Berlin Heidelberg, pp. 14-23, 2007.DOI
oneM2M, “Base Ontology,” oneM2M Technical Specification, TS-0012-V3.7.3, pp. 1-77, 2019.URL


Jieun Lee

Jieun Lee received B.S. in embedded systems engineering from Daegu University, South Korea, in 2017. Currently, she is a Ph.D. candidate in computer and information security at Sejong University, South Korea. She is also working as a researcher for Easy Global Market (EGM) in France. Prior to her current position, she was a researcher for the autonomous IoT research center, Korea Electronics Technology Institute (KETI), South Korea. She possesses five years of research and development experience in IoT, semantic web technologies, data platform testing, smart cities, and machine learning. In addition, she has taken part in standardization contributions for oneM2M and ETSI.

Komal Gilani

Komal Gilani received her M.S. in computer and information security at Sejong University, South Korea. Her research interests include IoT semantics, smart cities, and the industrial IoT. She has a B.S. in computer science from Arid Agriculture University, Pakistan. Contact her at

Nargis Khatoon

Nargis Khatoon received an MIT from Quaid-i-Azam University Islamabad, Pakistan, in 2013. She worked as a software developer for more than seven years. She is HL7 eLearning Certified from HL7 International (USA). She received an HL7 FHIR Interface developer contribution award for the collaboration project “Smart CDSS” from Kyung Hee University South Korea, NUST SEECS, and Shaukat Khanum Memorial Cancer Hospital Lahore. She worked as senior software engineer at Zigron Inc. in Pakistan and was chosen best employee for her hard work on the ABODE USA Project for Zigron. Currently, she is pursuing her master’s degree in information and computer security from Sejong University, South Korea. She is participating in various projects on smart cities, the oneM2M IoT, and AI research. She earned a 100% GPA in coursework at Sejong University.

SeungMyeong Jeong

SeungMyeong Jeong is a senior researcher in the IoT platform research center at Korea Electronics Tech-nology Institute (KETI). He received his B.S. and M.S. in computer science from Ajou University, South Korea, in 2009 and 2011, respectively. Before he joined KETI, he worked as a junior researcher at the Advanced Standard R&D Lab., CTO Division, LG Electronics, in Seoul, South Korea. His research interests are in the areas of IoT middleware platforms (e.g. oneM2M) and interworking technologies. He has been an active member of oneM2M standardization from the beginning, and is now vice-chairman of oneM2M Architecture WG. In addition to oneM2M standardization, he is also involved in R&D projects pertaining to semantic interoperability, collaborating with the EU consortium (i.e. FIESTA-IoT, WISE-IoT) and a cognitive IoT R&D project in Korea. Finally, he has recently focused on IoT-enabled smart cities with activities on the NIST IES (IoT Enabled Smart)-City Framework and the EU’s H2020 SynchroniCity in the Smart City Innovation Growth Engine Program.

JaeSeung Song

JaeSeung Song received a B.S. and an M.S. in computer science from Sogang University, and holds a doctorate in Computer Science from Imperial College London University, United Kingdom. He is an assistant professor in the Computer and Information Security Department at Sejong University, and is a visiting associate professor in electrical and computer engineering at the University of British Columbia (UBC). He is an IoT Series editor for IEEE Communications Standards Magazine, and an associate editor of the IEEE IoT Journal. He holds the position of oneM2M Technical Plenary Vice Chair. Prior to his current position, he worked for NEC Europe Ltd. and LG Electronics in various positions.