LeeJieun1,2
GilaniKomal1
KhatoonNargis1
JeongSeungMyeong3
SongJaeSeung1
-
(Department of Computer Security and Convergence Engineering for Intelligent Drones,
Sejong University / Seoul, Korea {love9ly, G2017SFE052, nargiskhatoon}@sju.ac.kr,
jssong@sejong.ac.kr
)
-
(EGM / Sophia Antipolis, 06560 Valbonne, France jieun.lee@egm.io)
-
(Autonomous IoT Research Center, Korea Electronics Technologies Institute / Gyeonggi-do,
Korea sm.jeong@keti.re.kr)
Copyright © The Institute of Electronics and Information Engineers(IEIE)
Keywords
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.
|
Methods
|
Central Graph-based Semantic Filtering
|
Graph Division-based Semantic Filtering
|
|
Representation
|
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.
|
|
Optimization
|
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.
ACKNOWLEDGMENTS
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)
REFERENCES
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.
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.
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.
A. Palavalli et al., “Semantic Internet of Things,” in 2016 IEEE Tenth International
Conference on Semantic Computing (ICSC), IEEE, pp. 91-95, 2016.
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.
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.
E. Kovacs et al., “Standards-based Worldwide Semantic Interoperability for IoT,” IEEE
Communications Magazine, vol. 54, no. 12, pp. 40-46, 2016.
oneM2M, “Semantics support,” oneM2M Technical Specification, TS-0034-V4.2.0, pp. 1-72,
2020.
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.
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.
A. Katasonov et al., “Smart Semantic Middleware for the Internet of Thins,” Icinco-Icso,
vol. 8, pp. 169-178, 2008.
A. Sheth et al., “Semantic Sensor Web,” IEEE Internet Computing, vol. 12, no. 4, pp.
78-83, 2008.
G. Narula et al., “Ontology Mapping and Merging Aspects in Semantic Web,” Int Rob
Auto J, vol. 4, no. 1, 2018.
A. Maedche et al., “Ontology Learning for the Semantic Web,” IEEE Intelligent Systems,
vol. 16, no. 2, pp. 72-79, 2001.
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.
T. Raimbault, “Overviewing the RDF(s) Semantic Web,” in 2010 International Conference
on Computational Intelligence and Software Engineering, IEEE, pp. 1-4, 2010.
D. Brickley et al., “RDF Schema 1.1, W3C Recommendation,” 2014.
K. Ashton, “That ‘Internet of Things’ Thing,” RFID Journal, vol. 22, 2009.
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.
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.
E. Prud’hommeaux et al., “SPARQL Query Language for RDF, W3C Recommendation,” Springer
US, 2008.
B. Quilitz et al., “Querying Distributed RDF Data Sources with SPARQL,” in European
Semantic Web Conference, Springer, pp. 524-538, 2008.
D. Gerver et al., “Real-time RDF Extraction from Unstructured Data Streams,” in International
Semantic Web Conference, Springer, pp. 134-140, 2013.
L. Atzori et al., “The Internet of Things: A Survey,” Computer Networks, vol. 54,
no. 15, pp. 2787-2805, 2010.
E. Borgia, “The Internet of Things Vision: Key Features, Applications and Open Issues,”
Computer Communications, vol. 54, pp. 1-31, 2014.
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.
R. Mehta et al., “Internet of Things: Vision, Applications and Challenges,” Procedia
Computer Science, vol. 132, pp. 1263-1269, 2018.
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.
D. Uckelmann et al., “An Architectural Approach Towards the Future Internet of Things,”
Springer Berlin Heidelberg, pp. 1-24, 2011.
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.
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.
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.
oneM2M, “Base Ontology,” oneM2M Technical Specification, TS-0012-V3.7.3, pp. 1-77,
2019.
Author
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 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 G2017SFE052@sju.ac.kr.
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 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 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.