Iot ontologies state of art$$$
1 like92 views
This document discusses the state-of-the-art of Internet of Things (IoT) ontologies. It begins by defining ontology and describing important design criteria for ontologies including clarity, coherence, extendibility, and minimal encoding bias. It then discusses the challenges of IoT, including large scale networks, deep heterogeneity, and unknown topology. Several existing IoT ontologies are described, including SWAMO, MMI Device Ontology, and SSN. The document concludes that while no single global IoT ontology currently exists, ontologies are needed to address the semantic interoperability challenges of heterogeneous IoT devices and domains.
![the use for real users or ii) it will be very complex i.e.
unrealizable. In the last a brief discussion is provided for the
future work.
2. ONTOLOGY
Ontology as a term comes from field of philosophy, which
means: study of being or existence. Historically [1] in
information science the term ‘ontology’ has been used as a
technical term denoting an artifact that is designed to enable
the modeling of knowledge about some domains real or
imaginary. The term was adopted by artificial intelligence
researchers (during 1980). AI Community used the term
‘Ontology’ to refer to both a theory of a modeled world and
component of knowledge system. In the early 1990's, an effort
to create interoperability standards identified a technology
stack that called out the ontology layer as a standard
component of knowledge systems [3]. A paper [2] associated
with that effort is credited with a deliberate definition of
ontology. The research paper [2] defines ‘ontology’ as a
formal, explicit specification of a shared conceptualization,
which is, used to represent knowledge within a domain as a set
of concepts related to each other. Formal ontologies are
designed. In order to guide and evaluate our design we need
design criteria for ontologies. A preliminary set of design
criteria [2] for ontologies:
Clarity: Ontology should effectively communicate the
intended meaning of defined terms (definitions should
be objective and complete).
Coherence: Ontology should be coherent: that is, it
should sanction inferences that are consistent with the
definitions. Ontology is incoherent if a sentence
inferred from axioms contradicts a definition or
example given informally.
Extendibility: Ontology should offer a conceptual
foundation, for a range of anticipated tasks, and
representation should be crafted so that one should be
able to define new terms for special uses based on the
existing vocabulary, in a way that does not require the
revision of the existing definitions.
Minimal encoding bias: Knowledge-sharing agents
can be implemented in different representation, so
encoding bias should be minimized, that is, the
conceptualization should be specified at knowledge
level without depending on particular symbol-level
encoding.
Minimal Ontology commitment: Ontology
commitment is based on consistent use of vocabulary.
So ontology should make few claims about the model.
Of course above design criteria will require making tradeoffs
among the criteria mentioned requirements. A computational
ontology is composed of [4] four main components: Classes,
relations, attributes and individuals. Concepts, also called
Classes, are the core component of most ontologies. A class
represents a group of different individuals (individuals are
instances of classes or their properties), that share common
characteristics. Classes are the main concept to describe.
Relations in ontology describe the way in which individuals
relate to each other. Now classes can have one or more
children known as subclasses, used to define more specific
concept. Classes and subclasses have attributes that
represents their properties and characteristics. Up till now we
have answered what is ontology? It’s design criteria? and
components of Ontology. In recent years we have seen rapid
progress in the development of ontologies as semantic model.
Ontology support semantic interoperability and integration.
But there is a natural need for having an ontology evaluation
criterion to ensure perspective user about its coverage,
concepts, effectiveness, semantic interoperability, content
and methodology. Two broader classification in evaluating
[5] ontologies is whether to perform a component-based or
task-based evaluation. Component based evaluation is often
seen as glass box evaluation, where it’s seen how much
effectively have ontology has been able to represent the
concepts. Task-based evaluation usually applied to ontologies
that are tightly integrated with an application performing
specific tasks. Task-based evaluation is often called black
box evaluation. Some key considerations, in evaluating an
ontology that need to be considered when evaluating an
ontology:
Expressivity vs. cost of computation: High expressivity
of ontology concepts is desired (keeping in mind the
computation cost). Ontology concepts are represented
by knowledge representation (KR) language. Some of
commonly used KR languages are i) CL (common
logic) representation language, ii) interoperable
knowledge representation for intelligence support
(IKRIS) language, and iii) Semantic web ontology
(owl) language. High expressivity and emphasis on
minimizing the cost of computation is manifested by
OWL-Lite, OWL-DL (description logic) and other
description logics. . Ontology, both covering the same
domain, expressed in different KR language will be
evaluated differently.KR languages define the syntax
and the semantics for the ontology models. Properties
of KR language also needed to be considered in
evaluating the ontology. Properties of KR language
includes i) soundness: expression derived from
knowledge base (KB) of the ontology implied by that
KB, ii) completeness: any expression that can be
logically implied by the KB can be derived, iii)
decidability: being both sound and complete, iv)
consistency: language is consistent, that is, there are
no missing concepts or redundancy of information
(more classes, relation or instances than needed) or
other semantic inconsistencies.
Competency Questions: Questions that ontologist
frames prior to the development of the ontology (like](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-3-320.jpg)
![nature of domain and data sources ontology will
encompass).
Semantic distance and semantic similarity:
Ontology can be represented in a graph-based form [4].
Now in this scenario two quite effective measures, that
is, i) semantic distance and ii) semantic similarity are
most commonly used to for ontology evaluation.
Semantic distance: it measures how closely two nodes
are topologically related in a graph; and semantic
similarity: captures to what extent two nodes might
represent the same entity in reality. These two measures
values are calculated mainly by path-length [5] in a
network taking into account link-weights. A high
quality ontology computation should compute semantic
distance as being minimal and semantic similarity as
being maximal.
The ultimate evaluation of an ontology is in terms of its
adoption and successful use. Future evaluation measures for
ontology will high rely on factors such as:
Measure of human consensus on classification
tasks, and semantic agreement
A formal, standard, and verifiable information
system
Well-defined engineering practices and standard
tested theories that allow predictions
Development of more successfully used
ontologies
With these requirements fulfilled, new ontology can be
evaluated by comparing it to the ‘reference’ ontology (suitable
reference ontology should be one created under similar
condition with similar goals). This process of evaluating
ontology by comparison is called ontology alignment. This
method is still also used in many scenarios where reference
ontology is available (mostly comparing two version of the
same ontology). But still fall short of providing full evaluation
metrics, as gold standard reference ontologies are still not
available. So far we had look into explanation of everything
related to ontology and had answered some of the key
questions related to ontology definition, design criteria,
components and evaluation criteria (consistency and coverage).
Now we shift our focus towards Internet of things and build a
conceptual foundation for the vision and challenges realizing
the internet of things.
3. INTERNET OF THINGS
After the World Wide Web (the 1990’s) and the mobile
Internet (the 2000’s), we are now heading to the third and
potentially most "disruptive” phase of the Internet revolution,
that is, “Internet of Things”. The earliest record mention of the
term internet of things (IOT) goes back to a presentation by
MIT’s Kevin Ashton in 1999. In it, he famously stated that
adding RFIDS to every-day objects would create an Internet of
Things. The Internet of Things links the objects of the real
world with the virtual world, thus enabling anytime, anyplace
connectivity for anything and not only for anyone. It refers to a
world where physical objects and beings, as well as virtual data
and environments, all interact with each other in the same
space and time. To start with getting oneself comfortable with
notion of a ‘thing’, let first concentrate [7] what do we mean by
it? In the context of “internet of things” a “things” could be
defined as a real/physical or digital/virtual entity that exists and
move in space and time and is capable of being identified.
Things are commonly identified either by assigned
identification number, names and/or location address. In
context to the concept of things as explained before, “internet
of things” is an integrated part of future internet and could be
defined as a dynamic global network infrastructure with self
configuring capabilities based on standard and interoperable
communication protocols where physical and virtual “things”
have identities, physical attributes, and virtual personalities and
use intelligent interfaces, and are seamlessly integrated into the
information network. In internet of Things, the term thing can
be perceived in a different way depending on the domain in
which it is used. There has been a broader classification of
Application domains in IOT [7] into three domains, i) Industry:
activities involving financial or commercial transactions among
companies (such as banking, service sector, manufacturing), ii)
Environment: activities regarding monitoring environment,
natural resources (such as agriculture, recycling), iii) Society:
initiatives in development of people, society (such as e-
inclusion, society structures). These domains are hard to
isolate, new applications and services that apply at inter- or
intra-domain level will affect all domains. Now with the
technological advancements, communication and processing
capabilities are becoming more and more accessible and cheap.
And with this notion of things encompassing everything
including not only RFIDs, but also sensors, mobile devices,
actuators and so on. In this new vision, all of these are
considered to be things and by assigning each thing
participating in internet of things a global unique identity
(UID) or several unique identities and giving them the
capability to communicate will create enormous large amount
of networks of things. And there most visible effect is that the
deployments and operation of these internets of things
networks are hard, costly and complex. More increases in these
devices (things) are predicted in future, as of recent
predictions1
from technology giants (such as Cisco) by 2020
there will be more than 50 billion devices (things) attached to
the existing network and communicating among each other or
several other devices: that is, these devices are creating
enormous amount of data and it need to be understood in order
to really benefit from IOT. In today scenario highly-specialized
field experts are needed to interpret the sensor data and come
up with actuation commands. This approach is clearly too
costly and time-consuming and will not scale as IOT pushes
into an era of more than 50 billion connected devices and is](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-4-320.jpg)
![going to affect the lives of general population. There comes a
natural need by now to explore what are really the core
challenges that we face today or in the future, following are
challenges underlying IOT summarized by research paper [6]
and CERP-IOT cluster [7] report:
Scale: Imagine a scenario, where one needs to sense
million of sensors and perform a certain act in response.
In this scenario it is normally not feasible to sense all
the sensors due to constraints such time, memory,
processing power, and energy consumption (What
should be alternate to it?).
Deep heterogeneity: In IOT domain many sensors and
actuators exhibits different operating systems
characteristics, different software platforms, different
vendors and different hardware implementation, and
there are many heterogeneous systems interacting. So
IOT typically have deep heterogeneity embedded by
default to its architecture.
Unknown Topology: Much like the existing internet, one
of the IOT’s main characteristics is the fact that its
topology is both unknown and dynamic. Consequences
that results because of this and results in not proper
functioning of application, i) applications will end up
demanding on services which are not actually available
from any single pre-existing component of the network
at that given time, ii) service might themselves rely on
devices that had once joined the network and left it
abruptly.
Unknown Data-Point Availability: Another consequence
of the unknown topology is that sometimes there will be
no suitable device at the desired geographical location
or, other times, the device has not collected/stored the
data-point that is desired.
Conflict resolution: dealing with actuators a situation
can arise where a conflict arise, for example, when
multiple application attempts to act on the device in
different ways.
Incomplete or inaccurate metadata: Many of the
challenges mentioned can likely be solved by extensive
use of metadata. But metadata entered by a human
operator at installation time, in a massive network will
result in incomplete or inaccurate information due to
human error. In addition, some of this information can
include characteristics that change over time (e.g.,
calibration parameters). Therefore, even discounting
human error, the state of the metadata in the network is
bound to degrade until it no longer represents reality. In
these scenarios, how can be missing metadata be
recovered? And how can be existing information be
monitored and updated when necessary?
So in totality future IOT poses many challenges and there is a
need for considerable steps to be taken for the solution of
these challenges. Heterogeneity of “things” makes
interoperability among them a challenging problem, which
prevents generic solutions from being adopted on a global
scale. Many researchers are focused, on resolving these
issues. Many research papers propose [9, 10, 8, 7] new
middleware, that is, an open source service-oriented
architecture for the middle-ware is proposed (details for
different middle-ware implementation is included in latter
section). As told before the primary goal of interconnecting
devices (e.g., sensors) and collecting/processing data from
them is to create situation awareness and enable applications,
machines, and human users to better understand their
surrounding environments. The understanding of a situation,
or context, potentially enables services and applications to
make intelligent decisions and to respond to the dynamics of
their environments. Data collected by different sensors and
devices is usually multimodal (temperature, light, sound,
video, etc.) and diverse in nature (quality of data can vary
with different devices through time and it is mostly location
and time dependent). Some of the core functionalities that
IOT need to have in order to flourish and fully benefit from
its full potential are:
It needs to automate “thing” (sensor or entity)
addressing and tracking
It also needs to exhibit interoperability (different
states holders can ambiguously access, interpret,
exchange or integrate data)
The IOT needs search mechanism and discovery
mechanism for locating “resources” (thing or entity)
or “services” that provide data related to an entity.
Now with these core requirements for IOT in mind and the
challenges of IOT mentioned above, we need to design useful
applications to get a meaning out of this large, raw, diverse,
volatile and ubiquitous data. And for this we need to transform
it into meaningful actionable data. This data transformation
process [11] can be better illustrated using the well known
“knowledge hierarchy” (shown in figure 2.3).
Figure 3.2 “Knowledge Hierarchy” in the context of IOT
Explanation of the “knowledge hierarchy”: The lower layer
refers to large amount of data produced by the IOT resources
and devices. The layer above helps create structured and
machine-readable information from the raw data of various
forms to enhance interoperability. However, what is required
by humans and high-level applications and services often is not
the information, but high-level abstractions and perceptions
that provide human and machine-understandable meanings and
insights of the underlying data. The high-level abstractions and](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-5-320.jpg)
![perceptions then can be transformed to actionable intelligence
(wisdom) with domain and background knowledge to exploit
the full potential of IOT and create end-to-end solutions. Now
in above section as you can see, we discuss key challenges and
core requirements for Internet of things. We also mentioned
some terms such as middleware or semantics, very briefly,
which we will explain in detail in latter section. In the next
section we will discuss about the research proposals and
solution to solve the IOT challenges and will also see, how the
semantic-oriented perspective towards IOT is use to solve the
problem core interoperability challenge. We would also see
that just by providing semantic description alone does not solve
the issue of semantic interoperability (as across different
domains, semantic description will be interpreted differently).
We would also discuss briefly about use of common ontology
and with semantic descriptions will make the data semantically
interoperable for users and stakeholders that share and use the
common ontology. In the last we will in detail review some
state-of-the-art ontologies for IOT domain.
4. IOT ONTOLOGIES
Issues related to interoperability, automation, and data
analytics naturally lead to a [12] semantic-oriented perspective
towards IOT. Applying semantic technologies to IOT
promotes interoperability among IOT resources [13, 7] and
facilitates effective data access and integration, resource
discovery, semantic reasoning, and knowledge extraction. As
stated in research paper [11] “Defining an ontology and using
semantic descriptions for data will make it interoperable for
users and stakeholders that share and use the same ontology.”
Now as we have seen before that in previous sections we
discussed about ontology and IOT, now it time we need to
explain what is ontology of the internet of things is all about-- ;
An ontology for the Internet of Things provides all the
necessary semantics for the specification of IOT devices as
well as the specifications of the IOT solution (input, output,
control logic) that is deployed using these devices. These
semantics include terminology related to sensors and
observations, reusing the one already provided by the other
ontologies, such as, SSN ontology (we will discuss about SSN
shortly) and extend them to capture also the semantics of
devices beyond sensors — i.e. actuators, identity devices
(tags), embedded devices, and of course the semantics of the
devices and things that are observed by sensors, that change
their status by actuators, that are attached to identity tags. Now
a natural next question would be in readers mind will be: risk
of moving into the IOT world without an ontology to ground
it? The lack of explicit and formal representation of the IOT
knowledge could cause ambiguity in terminology, hinder
interoperability and mostly semantic interoperability of entities
in the IOT world. Furthermore, lack of shared and agreed
semantics for this domain, that is, IOT (and for any domain)
may easily result to semantic heterogeneity — i.e. to the need
to align and merge a vast number of different modeling efforts
to semantically describe IOT entities, efforts conducted by
many different ontology engineers and IOT vendors (domain
experts). Although there are tools nowadays to overcome such
a problem, it is not a fully automated and precise process and it
would be much easier to do so if there is at least a partial
agreement between the related stakeholders — i.e. a commonly
agreed IOT ontology. Now we have discussed until now, that
semantics description in IOT promotes interoperability, and
also has seen that semantics alone cannot be enough to
guarantee interoperability and not solve all the issues regarding
discovery, management of data, and supporting autonomous
interactions. We need an ontology [11] and semantic
description in order to make data interoperable (for users in
same domain). Now we feel the need to also mention that most
of the current ontologies and semantic description frameworks
in the IOT domain are defined in the context of different
projects and applications or they are currently at an early stage.
To achieve global scale semantic interoperability, common
semantic annotation frameworks, ontology definitions, and
adaptation are key issues. Recent efforts, such as the W3C SSN
ontology (SSN ontology will be explained shortly), are
effective steps towards achieving this goal. For the current and
existing applications, it is also important that their ontologies
and knowledge base can be accessed and reused by large
groups of potential consumers. Developing and sharing
ontologies and contributing towards standard description and
standard annotation frameworks that can also support legacy
applications are effective steps in achieving semantic
interoperability on a large scale. Other solutions, such as
ontology mapping and matching (i.e. manual, semi-automated,
or automated) can help link the already existing resources
using different semantic annotation models. The ontology
designers can also reference existing common ontologies and
provide links to other upper-level ontologies to support
interoperability between different semantic descriptions in the
IOT domain. In above we have discussed the use of semantic
annotations. In IOT domain semantic annotations provides
machine-readable and machine interpretable metadata to
describe the IOT resources and data. However, there are some
concepts that needs to be understood is that machine
interpretable data: read carefully when I mentioned machine-
interpretable data, but not machine understandable data.
Annotations can make provide machine interpretable data but it
is still not machine understandable. Another key aspect is that
the semantic annotations can be added to the data at different
stages. Figure 4.1 shows that how semantics can be used at
different levels in IOT.
Figure 4.1: Semantics at different levels in IoT](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-6-320.jpg)
![The semantic Web technologies include well-defined standards
and description frameworks (e.g. RDF, OWL, SPARQL) and a
variety of open-source and commercial tools for creating,
managing, querying, and accessing semantic data. However,
this still does not eliminate the key role of information
analytics and intelligent methods, which can process and
interpret the data and create meaningful abstractions.It is
important to note here that semantic technologies and Ontology
Description are not new concepts. They have existed for long,
and have matured over the years. Ontologies and semantic
description frameworks provide an effective way to share and
agree on a common vocabulary and knowledge model for
describing the data, which can be machine-interpretable and
represented in interoperable and reusable forms.
Review of IOT ontologies:
Ontologies in IOT have been developed for a number of uses,
including the description of sensor and sensor networks, IOT
resources and services, smart “Things”, etc. In this section we
review some of the most important ontologies in the IOT
domain and give a brief overview of the recent activities on the
ontology developments in this field. We will also review
proposed IOT middleware architecture [16] which use
backbone of knowledge base composed of three ontologies
(device, physics, estimation ontology). Later in end part we
will briefly discuss about Machine-to-machine standards and
particularly will discuss about oneM2M architectural
consideration. Now we first begin by the reviewing Sensor and
Observation ontologies. These ontologies were evaluated by set
of questionnaire [14], which are very close to the evaluation
criteria mentioned in section 2 for ontology evaluation.
CSIRO Sensor Ontology: This ontology was created for
describing and reasoning about sensors, observations and
scientific models. Provide a semantic description of sensors for
use in workflows. This ontology is still in the process of
actively been developed. It is the ontology that became the
starting point for the development of the Semantic Sensor
Network ontology. It fairly describe key concepts behind the
ontology such as for grounding (location, mobility, range of
sensing), Operation Model and Process (and then Feature etc.
from a domain perspective). With respect to sensor this
ontology is reasonably broad, but there is more to include from
say from SensorML, O&M and OntoSensor. Ontology not a
hierarchy of concepts, has some restrictions etc. The ontology
was not adopted widely, only few examples. As we have
mentioned before that this ontology was used to develop SSN
ontology. So feature like plug-and-play and composition were
widely appreciated features for this ontology.
OntoSensor: This ontology was created to build a knowledge
base of sensor. This knowledge base can be queried via a
Protege plugin. The ontology is still incomplete, but it is
mainly organized around sensor, sensor capabilities
description. It is not very well featured ontology. It provides a
small taxonomy of sensors, but, it contains several complicated
properties. Downside of the ontology is that the organization of
concepts and properties is so messy to use in other application
or to extend.
SWAMO: Ontology was created to enable dynamic,
composeable interoperability of sensor web products and
services. It describe autonomous agents for system-wide
resource sharing, distributed decision making, and autonomic
operations. Ontology is actively maintained, and in progress
(not complete).The ontology provide maximum
interoperability. It focuses on the sensor domain, and
particularly on processes to control them. Ontology is
Sophisticated, and is interoperable with SWE descriptions. One
downside to it, is classes look a little mixed and the highest
level class (Component) does not appear to reference itself.
MMI device Ontology: This ontology was designed for
oceanographic specific devices, including both sensors (which
measure things) and samplers (which pick up things). The first
priority is to be able to broadly characterize the devices (i.e.,
sort them into groups). One significant use of such
characterizations is to help users (or web applications) discover
sensors or data of interest. The ontology is organized around a
system concept. System is a Process. System has capabilities,
like measurement capabilities (accuracy etc). Even though it
was meant to be for oceanographic sensor it could be used in
other contexts.
SensorML Processes: Ontology was created to represent
SensorML model and serve as a starting ontology for the MMI
device ontology. It is based on the SensorML schema.
SEEK OBOE: SEEK Extensible Observation Ontology
(OBOE) was developed for the SEEK project, and has since
been used by Spire. The comment documentation for the
ontology concept is good. The Ontology SEEK OBOE
comprise of a core observations ontology, a units extension,
and a further extension for domain use (coastal
ecosystems).The observation ontology separates observations
from the entity being observed: the observation has a
measurement while the entity has characteristics, and the
measurement is then of that characteristic. SEEK OBOE is
much of observation ontology, not device ontology.
Figure 4.2 - Overview of the OBOE ontology
Stimulus-Centric: This ontology aims at bridging between the
sensor-centric Sensor Model Language (SensorML) and the
user-centric Observations & Measurements (O&M)[14]
specification by focusing on stimuli as objects of sensing. It
does not require a strong link between sensors and features of
interests such as O&M. It also include humans as sensors
which are the key to volunteered geographic information. It is
actively maintained. As it is a top-level kind of ontology, it is](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-7-320.jpg)
![not complete in the sense of listing sensor (types) or
observations but focuses on establishing a common ground for
both. The key concepts are stimuli, observations and sensors. It
is based [14] on sensorML, O&M and Dolce.
Figure 4,3 - The role of stimuli as a proxy between the sensor
and the object of sensing
SENSEI Observation and measurement ontology: The purpose
for this ontology is to annotate sensor observation and
measurement data; The O&M ontology [14] is then
incorporated into the SENSEI resource model. Ontology is
hierarchical in concept. The ontology organized around the key
concepts of observing and measuring data (provided via a
resource) that can be related to an Entity of Interest (EOI).The
processes and services that make the O&M data available are
provided through a Resource End Point (REP).
O&M-OWL (SemSOS): The O&M-OWL ontology was created
so that we may reason over sensor data to infer "high-level"
concepts from "low-level" phenomena. These concepts were
then incorporated into a Sensor Observation Service (SOS) so
that users may query for events without requiring expert
knowledge of how events and phenomena are related. The
ontology is highly documented. The ontology is organised
around four major concepts: (1) Observation -- act of observing
a phenomenon (2) Process -- method, algorithm or instrument,
or system of these (3) Feature -- an abstraction of real world
phenomena, or "real-world" entity (4) Phenomenon -- property
of a feature that can be "sensed" or measured. The ontology
mostly deal how sensors can be combined. Semantics are found
in the relations between the four major concepts described
before. Using OWL to infer types of observations, phenomena,
sensors, etc., given partial annotation. Since our ontology is
based on O&M, it is already aligned with the SensorML
language [14], which is a major foundation for the SSN
ontology [14]. For example, the concept of process within
O&M is taken directly from SensorML.
The SEMANTIC SENSOR NETWORK ONTOLOGY: We will
discuss SSN ontology in detail here. Now we have seen in
previous sections about the IOT challenges. To solve those
challenges and meet IOT today’s and future requirements, SSN
ontology was proposed [14]. Back 11 years from now, Sensor
Web Enablement (SWE) [14] was created by Open Geospatial
Consortium (OGC). SWE main agenda, i) sensors reporting
position, ii) sensors connected to web and all readable
remotely, iii) all with meta-data registered and can be
controlled remotely. So what SWE came up was a service-
oriented architecture. So basically they define a set of services-
interfaces such as:
SOS (sensor observation service):which is a way to query and
access sensor descriptions and sensor data
SPS (sensor planning services): This allows you to task sensors
to engage in different behaviors.
SAS (sensor alert service): allow to subscribe to different
sensing events. So these different services communicate with
one-another through standard XML protocols [14]. There was
standardization in protocols, and because of that it solved
many problems such as sensor discovery. But still what it did
not allow us to do was integrate or interpret the data (We lack
interoperability). So 4 years ago from now W3C (World Wide
Web Consortium) brought together a group of researchers and
see if they can apply semantic technologies to help solve some
of these problems. An SSN incubator group was made, and
the first thing they did was build a SSN Ontology [14]. The
SSN ontology is based around concepts of systems, processes,
and observations. It supports the description of the physical
and processing structure of sensors. Sensors are not
constrained to physical sensing devices: rather a sensor is
anything that can estimate or calculate the value of a
phenomenon, so a device or computational process or
combination could play the role of a sensor. The
representation of a sensor in the ontology links together what
it measures (the domain phenomena), the physical sensor (the
device) and its functions and processing (the models). The
Ontology structure revolves around the central Stimulus-
Sensor-Observation pattern as shown in the figure 4.3. Several
conceptual modules (such as device, platform, data etc) build
on the pattern to cover key sensor concepts can be seen on the
figure.
Figure 4.4 SSN ontology structure
Explanation for this ontology structure can be explained
briefly: As we know sensors are often implemented within
device and these devices can be integrated into systems and
systems have particular operating restrictions, they can only
work in particular temperature and within particular location,
they have critical measurement limitations (example can only
measure certain irregularities). These system can be integrated
with platforms (like example the airplane internal control
system) and then deployed. So we set our modeling an
ontology in this fashion, that is very systematic fashion; and
the reason we did this, we wanted to make ontology as simple
as possible. For example If I have an application and I want to](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-8-320.jpg)
![use SSN ontology. I can pull in the modules we need, to add
more complexity or more concepts (but only when I need
them). But if we do not need some modules we just leave them,
and this facilitates simplicity and thus interoperability. The
figure4.5 shows us an overview of the main classes and
properties inside the ontology modules.
Figure 4.5 overview of main classes (SSN ontology).
One aspect to note here is that the main classes of the Semantic
Sensor Network ontology have been aligned with classes in the
DOLCE Ultra Lite (DUL) foundational ontology [14] to
facilitate reuse and interoperability. So SSN ontology is
backward compatible: so if you have an SOS or other services,
we can accommodate the data with the concepts from the SSN
ontology. (So we can have advantage of high expressivity
when we want to integrate with systems that are semantically
aware, otherwise we ignore backward compatibility). Since we
develop SSN ontology, we see a good adoption of the ontology
[15].
Figure 4.6 some of adopters of SSN ontology
Some of adopters that have adopted SSN ontology [15, 14]
include projects such as CSIRO, IOT.est, SPITFire etc. when
some of the groups using the ontology were contacted and
asked why they want to use this semantic technology? And
from there we came up with four major use cases that are
shown in the figure 4.7
Figure 4.7 Four major use cases
So four needs that people needed to use ontology for: data
discovery and linking, sensor device selection and discovery,
provenance and diagnostic and tasking, programming. Modules
that will be used to address these four major needs were
platform, system, deployment, and process. We know that
deployment and process is hardware centric and in IOT this
will be more interested modules.
IOT middleware architecture: As we have already mentioned
the challenges of IOT (such as scale, unknown topology etc)
for which we need to have a IOT middleware based on the
service-oriented paradigm [16] that abstracts things as services,
therefore allowing us to keep services loosely coupled in order
to increase reusability. The architecture will makes widespread
use of approximations and estimations in order to address the
IOT's challenges without requiring the intervention of domain
experts. For this, in the backbone of our middleware, lies a
knowledge base composed of three ontologies: a Device
Ontology, a Physics Domain Ontology, and an Estimation
Ontology. The overall architecture of our proposed IoT
middleware is shown in Figure 4.8
Figure4.8 Middleware architecture
The three ontologies that make the knowledge base are:](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-9-320.jpg)
![Device Ontology: The Device Ontology models actual
hardware devices that may exist in the network. For our
middleware, it can be regarded as the device description
repository that can be accessed for discovery.
Domain Ontology: The (Physics and Mathematics) Domain
Ontology models information about real world physical
concepts and their relations among each other. For our
middleware, it can be regarded as the main repository to access
for service composition.
Estimation Ontology: The Estimation Ontology contains
information about different estimation models (such as linear
interpolation etc.), the equations that drive them, the services
that implement them, and so on. For our middleware, it can be
mainly regarded as the repository describing the device's
quality of service, and provides information needed for service
composition.
OneM2M: Now after discussing some of the existing semantic
technologies, and IOT Ontologies in previous section, now it’s
the right time to discuss about functional architecture for
oneM2M. The purpose [19] and goal of oneM2M is to develop
technical specifications which address the need for a common
M2M Service Layer that can be readily embedded within
various hardware and software, and relied upon to connect the
myriad of devices in the field with M2M application servers
worldwide. A critical objective of oneM2M is to attract and
actively involve organizations from M2M-related business
domains such as: telematics and intelligent transportation,
healthcare, utilities, industrial automation, smart homes, etc.
Now here we now want to discuss [20] about the description of
functional components as well as a functional model to support
semantics for various machine-to-machine applications. Now
in this technical report [20] and keeping in mind the future
standardization perspective in oneM2M [21], the proposed
generic functional model to support semantics for various
M2M applications is shown in figure 4.9.
Figure4.9: Generic functional model for supporting semantics.
The functionalities of the model [20] are logically composed of
three main parts: i) Service access which provides an interface
with various M2M applications; ii) Abstraction & semantics
which perform main functionalities for semantics to M2M data
and resources; iii) Data access which provides connections
with a device and/or a gateway for accessing M2M data Now
we briefly explain the modules of the model: Any query
request from m2m application are analyzed semantically. And
to answer these semantic analyzer requests mechanism called
reasoning to derive a new implicit knowledge from
semantically annotated data and to answer complex user query
(note our is m2m application). Ontology repository is storage
of resources defined based on Ontology. Ontology modeling is
the process for building an ontology which is used to model a
domain and support reasoning about concepts. Semantic mash-
up provides functionalities to support new services through the
creation of new virtual devices. Semantic annotation of M2M
resources is a method for adding semantic information to M2M
resources. Device abstraction is a process of mapping between
a set of Device Application Information Models. Data
repository basically stores new data collected by m2m data
collection module.
5. RELATED WORK
There had been many studies been done on this specific topic
of semantic technologies and IOT ontologies. One study that is
particularly important: as it includes the review of SSN
ontology and existing standards for semantics from OGC [21].
The aim of this contribution [21] is to review the current
progress on semantics standardization and identifying new
work items for the standardization in oneM2M.The TR team
proposed to analyze existing standards for semantics from
OGC and W3C in some details for reference to identify new
work items for future standardization in oneM2M.
6. CONCLUSION AND FUTURE DIRECTIONS
In our study what we observed that having a main global
ontology that can be used to any device or service etc is still
not yet existent. If the ontology exists, there are two scenarios:
i) it would be very simple abstract ontology that will not
suffice the use for real users or ii) it will be very complex i.e.
unrealizable. Most of ontology that exist today are either
domain specific, and so the problem of having a simple global
ontology (able to model everything from sensors to services
and overcoming the issue of interoperability) always remains a
challenge. To achieve global scale semantic interoperability,
common semantic annotation frameworks, ontology
definitions, and adaptation are key issues. Recent efforts, such
as the W3C SSN ontology, are effective steps towards
achieving this goal. IOT ontology modeling and using
semantics in IOT are still in their early days. The IOT
community requires coordinated efforts to define more
vocabularies and description frameworks to represent
resources, data and services in the IOT domain. Also there was
a need felt for synergetic efforts from other fields such as
service computing, data mining and social science to enhance
the processing and utilization of semantic data in the IOT
domain.
Semantic Analysis and Query
Semantic Annotation
Ontology
Modeling
Semantic Mash-Up
Reasoning
Service
Access
Abstraction
&
Semantics
Data
Access M2M Data Collection
Device Abstraction
M2M Applications
Ontology
Repository
Data
Repository](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-10-320.jpg)
![7. REFRENCES
[1] Ontology by Tom Gruber in the Encyclopedia of Database
Systems, Ling Liu and M. Tamer Özsu (Eds.), Springer-
Verlag, 2009.
[2]Gruber, T. R., Toward Principles for the Design of
Ontologies Used for Knowledge Sharing. International Journal
Human-Computer Studies, 43(5-6):907-928, 1995.
[3] Neches, R., Fikes, R. E., Finin, T., Gruber, T. R., Patil, R.,
Senator, T., & Swartout, W. R. Enabling technology for
knowledge sharing. AI Magazine, 12(3):16-36, 1991
[4] Noy, Natalya F., and Deborah L. McGuinness. "Ontology
development 101: A guide to creating your first ontology."
(2001).
[5] Obrst, Leo, Werner Ceusters, Inderjeet Mani, Steve Ray,
and Barry Smith. "The evaluation of ontologies." In Semantic
Web, pp. 139-158. Springer US, 2007.
[6] T. Teixeira, S. Hachem, V. Issarny, and N.
Georgantas,Service oriented middleware for the internet of
things: A perspective," in Servicewave, to appear end of
Octobre 2011.
[7] CERP-IOT (Cluster o European research projects on
internet of things), annual report on “vision and challenges for
realizing the Internet of Things” published in March 2010
[8] M. Presser, P. Barnaghi, M. Eurich, and C. Villalonga,
The SENSEI project: Integrating the physical world with the
digital world of the network of the future," IEEE
Communications Magazine, pp. 1{4, 2009.
[9]L. Atzori, A. Iera, and G. Morabito, The internet of things:
A survey," Computer Networks, vol. 54, no. 15, pp.
2787{2805, 2010.
[10] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D.
Savio, Interacting with the SOA-Based internet of things:
Discovery, query, selection, and on-demand provisioning of
Web Services," IEEE transactions on Services Computing, vol.
3, no. 3, pp. 223{235, 2010.
[11] Barnaghi, Payam, Wei Wang, Cory Henson, and Kerry
Taylor. "Semantics for the Internet of Things: early progress
and back to the future." International Journal on Semantic Web
and Information Systems (IJSWIS) 8, no. 1 (2012): 1-21.
[12] Atzori, Luigi, Antonio Iera, and Giacomo Morabito. "The
internet of things: A survey." Computer networks 54, no. 15
(2010): 2787-2805.
[13] Selvage, M., et al. (2006), "Achieve semantic
interoperability in a SOA, Patterns and best practices", IBM
Technical library, Available at:
www.ibm.com/developerworks/webservices/library/ws-
soaseminterop/
index.html.
[14] (http://www.w3.org/2005/Incubator/ssn/XGR-ssn-
20110628) Final report of the W3C Semantic Sensor Network
Incubator Group.
[15]Cory Henson. W3C Semantic Sensor Networks:
Ontologies, Applications, and Future Directions. Plenary Talk
given at the IERC AC4 Semantic Interoperability Workshop,
Venice, Italy, June 19, 2012. Co-located with IoT Week 2012.
[16] Hachem, Sara, Thiago Teixeira, and Valérie Issarny.
"Ontologies for the Internet of Things." In Proceedings of the
8th Middleware Doctoral Symposium, p. 3. ACM, 2011.
[17] Cory Henson, Josh Pschorr,Amit Sheth, Krishnaprasad
Thirunarayan, 'SemSOS: Semantic Sensor Observation
Service', In Proceedings of the 2009 International Symposium
on Collaborative Technologies and Systems (CTS 2009),
Baltimore, MD, May 18-22, 2009.
[18]
(http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Suggested_
Key_Ontology_Intro_Attributes) Source attributes.
[19] Onem2m press release 2012 (http://www.onem2m.org/)
[20] (http://www.onem2m.org/library/index.cfm) Technical
Report - oneM2M Abstraction & Semantics Capability
Enablement (oneM2M Architectural Considerations for
Semantics).
[21] (http://www.onem2m.org/library/index.cfm) Technical
Report - oneM2M Abstraction & Semantics Capability
Enablement (Discussion about existing technologies for
semantics from other SDOs).
[22] Predictions (cisco): http://newsroom.cisco.com/feature-
content?type=webcontent&articleId=1208342](https://image.slidesharecdn.com/iotontologiesstateofart-171201083420/85/Iot-ontologies-state-of-art-11-320.jpg)
Iot ontologies state of art$$$
- 2. State-of-the-art of Internet of Things ontologies Jawad Munir Technische Universität Berlin jawadmunir713@gmail.com Matr No: 359022 ABSTRACT The internet of things will integrate an extremely large amount of heterogeneous entities, which need to be consistently and formally represented and managed. These issues have recently received considerable interest from both academia and industry that are working on technologies to develop the future Internet. In this paper we will discuss needs for semantic description and ontologies to solve the challenges that we face in IOT. We will also do some state-of-the-art analysis for some existing IOT ontologies and will discuss approaches for ontology evaluation. Keywords: ontology, Internet of things, semantic description. 1. Introduction: Challenges the Internet of Things (IOT) is facing are directly inherited from today's Internet. However, they are amplified by the anticipated large scale deployments of devices and services, information flow and involved users in the IOT. It is a joint and complex discipline that requires synergetic efforts from several communities such as telecommunication industry, device manufacturers, semantic Web, informatics and engineering, among many others. IOT consists of interconnected “Things” and their virtual representations addressable by using standard communication protocols. However, the large scale of IOT and heterogeneity of the “Things” makes interoperability among them a challenging problem. We will in this paper discuss in detail what are the challenges that today IOT faces, and what steps should be taken in order to solve them. We will begin our discussion in section 2: with the introduction to ontology? And what do we mean by it? Ontology is a term defined as specification of conceptualization. Design criteria for ontology include concepts coherence, clarity and extendibility. It is important to also evaluate ontology: evaluation can be done by asking competency question such as nature of domain, and resources of data etc. In section 3: we will describe about Internet of things and discuss in details the challenges such as large scale IOT network handling, deep heterogeneity and unknown topology. And will also dig deep into what the core functionalities for IOT (such as automate discovery and provide interoperability). As we know, that the volume, velocity and volatility of the IOT data impose significant challenges to existing information systems. And to design useful application for IOT we need to transform this raw data into meaningful intelligence. Also different IOT domains need to interoperate with each other in order to provide state- of-the-art IOT applications. Once we have already understood the IOT challenges and key functionalities of IOT we move to section 4: which discusses about the state-of-the- art IOT ontologies. The first part of this section has build the conceptual foundation for the need of semantic description and Ontology use. As we know Semantic technologies based on machine interpretable representation have shown promise for describing objects, sharing and integrating information, and inferring new knowledge together with other intelligent processing techniques. But semantics alone will not be able to solve fully the problem of interoperability among different domains inducing the need for the ontology design. But applying semantic technologies to IOT, however, has several research challenges, pointing out that IOT and using semantics in IOT is still in its early days. The second half of the section 3: discuss about the some of the state-of-the-art ontologies which includes swamo, mmi device ontology, ontosensor, CSIRO, SSN etc. Note that also a standard approach for service layer for M2M i.e. onem2m functional model is discussed. In section 5: some of the other related work found during the study is presented. In the last section 6, we discuss briefly the observation found during the study and what conclusions were made: like answer to questions such as, is there a common main ontology that can be implemented or used regardless of the domain? In our study what we observed that having a main global ontology that can be used to any device or service etc is still not yet existent. If the ontology exists, there are two scenarios: i) it would be very simple abstract ontology that will not suffice
- 3. the use for real users or ii) it will be very complex i.e. unrealizable. In the last a brief discussion is provided for the future work. 2. ONTOLOGY Ontology as a term comes from field of philosophy, which means: study of being or existence. Historically [1] in information science the term ‘ontology’ has been used as a technical term denoting an artifact that is designed to enable the modeling of knowledge about some domains real or imaginary. The term was adopted by artificial intelligence researchers (during 1980). AI Community used the term ‘Ontology’ to refer to both a theory of a modeled world and component of knowledge system. In the early 1990's, an effort to create interoperability standards identified a technology stack that called out the ontology layer as a standard component of knowledge systems [3]. A paper [2] associated with that effort is credited with a deliberate definition of ontology. The research paper [2] defines ‘ontology’ as a formal, explicit specification of a shared conceptualization, which is, used to represent knowledge within a domain as a set of concepts related to each other. Formal ontologies are designed. In order to guide and evaluate our design we need design criteria for ontologies. A preliminary set of design criteria [2] for ontologies: Clarity: Ontology should effectively communicate the intended meaning of defined terms (definitions should be objective and complete). Coherence: Ontology should be coherent: that is, it should sanction inferences that are consistent with the definitions. Ontology is incoherent if a sentence inferred from axioms contradicts a definition or example given informally. Extendibility: Ontology should offer a conceptual foundation, for a range of anticipated tasks, and representation should be crafted so that one should be able to define new terms for special uses based on the existing vocabulary, in a way that does not require the revision of the existing definitions. Minimal encoding bias: Knowledge-sharing agents can be implemented in different representation, so encoding bias should be minimized, that is, the conceptualization should be specified at knowledge level without depending on particular symbol-level encoding. Minimal Ontology commitment: Ontology commitment is based on consistent use of vocabulary. So ontology should make few claims about the model. Of course above design criteria will require making tradeoffs among the criteria mentioned requirements. A computational ontology is composed of [4] four main components: Classes, relations, attributes and individuals. Concepts, also called Classes, are the core component of most ontologies. A class represents a group of different individuals (individuals are instances of classes or their properties), that share common characteristics. Classes are the main concept to describe. Relations in ontology describe the way in which individuals relate to each other. Now classes can have one or more children known as subclasses, used to define more specific concept. Classes and subclasses have attributes that represents their properties and characteristics. Up till now we have answered what is ontology? It’s design criteria? and components of Ontology. In recent years we have seen rapid progress in the development of ontologies as semantic model. Ontology support semantic interoperability and integration. But there is a natural need for having an ontology evaluation criterion to ensure perspective user about its coverage, concepts, effectiveness, semantic interoperability, content and methodology. Two broader classification in evaluating [5] ontologies is whether to perform a component-based or task-based evaluation. Component based evaluation is often seen as glass box evaluation, where it’s seen how much effectively have ontology has been able to represent the concepts. Task-based evaluation usually applied to ontologies that are tightly integrated with an application performing specific tasks. Task-based evaluation is often called black box evaluation. Some key considerations, in evaluating an ontology that need to be considered when evaluating an ontology: Expressivity vs. cost of computation: High expressivity of ontology concepts is desired (keeping in mind the computation cost). Ontology concepts are represented by knowledge representation (KR) language. Some of commonly used KR languages are i) CL (common logic) representation language, ii) interoperable knowledge representation for intelligence support (IKRIS) language, and iii) Semantic web ontology (owl) language. High expressivity and emphasis on minimizing the cost of computation is manifested by OWL-Lite, OWL-DL (description logic) and other description logics. . Ontology, both covering the same domain, expressed in different KR language will be evaluated differently.KR languages define the syntax and the semantics for the ontology models. Properties of KR language also needed to be considered in evaluating the ontology. Properties of KR language includes i) soundness: expression derived from knowledge base (KB) of the ontology implied by that KB, ii) completeness: any expression that can be logically implied by the KB can be derived, iii) decidability: being both sound and complete, iv) consistency: language is consistent, that is, there are no missing concepts or redundancy of information (more classes, relation or instances than needed) or other semantic inconsistencies. Competency Questions: Questions that ontologist frames prior to the development of the ontology (like
- 4. nature of domain and data sources ontology will encompass). Semantic distance and semantic similarity: Ontology can be represented in a graph-based form [4]. Now in this scenario two quite effective measures, that is, i) semantic distance and ii) semantic similarity are most commonly used to for ontology evaluation. Semantic distance: it measures how closely two nodes are topologically related in a graph; and semantic similarity: captures to what extent two nodes might represent the same entity in reality. These two measures values are calculated mainly by path-length [5] in a network taking into account link-weights. A high quality ontology computation should compute semantic distance as being minimal and semantic similarity as being maximal. The ultimate evaluation of an ontology is in terms of its adoption and successful use. Future evaluation measures for ontology will high rely on factors such as: Measure of human consensus on classification tasks, and semantic agreement A formal, standard, and verifiable information system Well-defined engineering practices and standard tested theories that allow predictions Development of more successfully used ontologies With these requirements fulfilled, new ontology can be evaluated by comparing it to the ‘reference’ ontology (suitable reference ontology should be one created under similar condition with similar goals). This process of evaluating ontology by comparison is called ontology alignment. This method is still also used in many scenarios where reference ontology is available (mostly comparing two version of the same ontology). But still fall short of providing full evaluation metrics, as gold standard reference ontologies are still not available. So far we had look into explanation of everything related to ontology and had answered some of the key questions related to ontology definition, design criteria, components and evaluation criteria (consistency and coverage). Now we shift our focus towards Internet of things and build a conceptual foundation for the vision and challenges realizing the internet of things. 3. INTERNET OF THINGS After the World Wide Web (the 1990’s) and the mobile Internet (the 2000’s), we are now heading to the third and potentially most "disruptive” phase of the Internet revolution, that is, “Internet of Things”. The earliest record mention of the term internet of things (IOT) goes back to a presentation by MIT’s Kevin Ashton in 1999. In it, he famously stated that adding RFIDS to every-day objects would create an Internet of Things. The Internet of Things links the objects of the real world with the virtual world, thus enabling anytime, anyplace connectivity for anything and not only for anyone. It refers to a world where physical objects and beings, as well as virtual data and environments, all interact with each other in the same space and time. To start with getting oneself comfortable with notion of a ‘thing’, let first concentrate [7] what do we mean by it? In the context of “internet of things” a “things” could be defined as a real/physical or digital/virtual entity that exists and move in space and time and is capable of being identified. Things are commonly identified either by assigned identification number, names and/or location address. In context to the concept of things as explained before, “internet of things” is an integrated part of future internet and could be defined as a dynamic global network infrastructure with self configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are seamlessly integrated into the information network. In internet of Things, the term thing can be perceived in a different way depending on the domain in which it is used. There has been a broader classification of Application domains in IOT [7] into three domains, i) Industry: activities involving financial or commercial transactions among companies (such as banking, service sector, manufacturing), ii) Environment: activities regarding monitoring environment, natural resources (such as agriculture, recycling), iii) Society: initiatives in development of people, society (such as e- inclusion, society structures). These domains are hard to isolate, new applications and services that apply at inter- or intra-domain level will affect all domains. Now with the technological advancements, communication and processing capabilities are becoming more and more accessible and cheap. And with this notion of things encompassing everything including not only RFIDs, but also sensors, mobile devices, actuators and so on. In this new vision, all of these are considered to be things and by assigning each thing participating in internet of things a global unique identity (UID) or several unique identities and giving them the capability to communicate will create enormous large amount of networks of things. And there most visible effect is that the deployments and operation of these internets of things networks are hard, costly and complex. More increases in these devices (things) are predicted in future, as of recent predictions1 from technology giants (such as Cisco) by 2020 there will be more than 50 billion devices (things) attached to the existing network and communicating among each other or several other devices: that is, these devices are creating enormous amount of data and it need to be understood in order to really benefit from IOT. In today scenario highly-specialized field experts are needed to interpret the sensor data and come up with actuation commands. This approach is clearly too costly and time-consuming and will not scale as IOT pushes into an era of more than 50 billion connected devices and is
- 5. going to affect the lives of general population. There comes a natural need by now to explore what are really the core challenges that we face today or in the future, following are challenges underlying IOT summarized by research paper [6] and CERP-IOT cluster [7] report: Scale: Imagine a scenario, where one needs to sense million of sensors and perform a certain act in response. In this scenario it is normally not feasible to sense all the sensors due to constraints such time, memory, processing power, and energy consumption (What should be alternate to it?). Deep heterogeneity: In IOT domain many sensors and actuators exhibits different operating systems characteristics, different software platforms, different vendors and different hardware implementation, and there are many heterogeneous systems interacting. So IOT typically have deep heterogeneity embedded by default to its architecture. Unknown Topology: Much like the existing internet, one of the IOT’s main characteristics is the fact that its topology is both unknown and dynamic. Consequences that results because of this and results in not proper functioning of application, i) applications will end up demanding on services which are not actually available from any single pre-existing component of the network at that given time, ii) service might themselves rely on devices that had once joined the network and left it abruptly. Unknown Data-Point Availability: Another consequence of the unknown topology is that sometimes there will be no suitable device at the desired geographical location or, other times, the device has not collected/stored the data-point that is desired. Conflict resolution: dealing with actuators a situation can arise where a conflict arise, for example, when multiple application attempts to act on the device in different ways. Incomplete or inaccurate metadata: Many of the challenges mentioned can likely be solved by extensive use of metadata. But metadata entered by a human operator at installation time, in a massive network will result in incomplete or inaccurate information due to human error. In addition, some of this information can include characteristics that change over time (e.g., calibration parameters). Therefore, even discounting human error, the state of the metadata in the network is bound to degrade until it no longer represents reality. In these scenarios, how can be missing metadata be recovered? And how can be existing information be monitored and updated when necessary? So in totality future IOT poses many challenges and there is a need for considerable steps to be taken for the solution of these challenges. Heterogeneity of “things” makes interoperability among them a challenging problem, which prevents generic solutions from being adopted on a global scale. Many researchers are focused, on resolving these issues. Many research papers propose [9, 10, 8, 7] new middleware, that is, an open source service-oriented architecture for the middle-ware is proposed (details for different middle-ware implementation is included in latter section). As told before the primary goal of interconnecting devices (e.g., sensors) and collecting/processing data from them is to create situation awareness and enable applications, machines, and human users to better understand their surrounding environments. The understanding of a situation, or context, potentially enables services and applications to make intelligent decisions and to respond to the dynamics of their environments. Data collected by different sensors and devices is usually multimodal (temperature, light, sound, video, etc.) and diverse in nature (quality of data can vary with different devices through time and it is mostly location and time dependent). Some of the core functionalities that IOT need to have in order to flourish and fully benefit from its full potential are: It needs to automate “thing” (sensor or entity) addressing and tracking It also needs to exhibit interoperability (different states holders can ambiguously access, interpret, exchange or integrate data) The IOT needs search mechanism and discovery mechanism for locating “resources” (thing or entity) or “services” that provide data related to an entity. Now with these core requirements for IOT in mind and the challenges of IOT mentioned above, we need to design useful applications to get a meaning out of this large, raw, diverse, volatile and ubiquitous data. And for this we need to transform it into meaningful actionable data. This data transformation process [11] can be better illustrated using the well known “knowledge hierarchy” (shown in figure 2.3). Figure 3.2 “Knowledge Hierarchy” in the context of IOT Explanation of the “knowledge hierarchy”: The lower layer refers to large amount of data produced by the IOT resources and devices. The layer above helps create structured and machine-readable information from the raw data of various forms to enhance interoperability. However, what is required by humans and high-level applications and services often is not the information, but high-level abstractions and perceptions that provide human and machine-understandable meanings and insights of the underlying data. The high-level abstractions and
- 6. perceptions then can be transformed to actionable intelligence (wisdom) with domain and background knowledge to exploit the full potential of IOT and create end-to-end solutions. Now in above section as you can see, we discuss key challenges and core requirements for Internet of things. We also mentioned some terms such as middleware or semantics, very briefly, which we will explain in detail in latter section. In the next section we will discuss about the research proposals and solution to solve the IOT challenges and will also see, how the semantic-oriented perspective towards IOT is use to solve the problem core interoperability challenge. We would also see that just by providing semantic description alone does not solve the issue of semantic interoperability (as across different domains, semantic description will be interpreted differently). We would also discuss briefly about use of common ontology and with semantic descriptions will make the data semantically interoperable for users and stakeholders that share and use the common ontology. In the last we will in detail review some state-of-the-art ontologies for IOT domain. 4. IOT ONTOLOGIES Issues related to interoperability, automation, and data analytics naturally lead to a [12] semantic-oriented perspective towards IOT. Applying semantic technologies to IOT promotes interoperability among IOT resources [13, 7] and facilitates effective data access and integration, resource discovery, semantic reasoning, and knowledge extraction. As stated in research paper [11] “Defining an ontology and using semantic descriptions for data will make it interoperable for users and stakeholders that share and use the same ontology.” Now as we have seen before that in previous sections we discussed about ontology and IOT, now it time we need to explain what is ontology of the internet of things is all about-- ; An ontology for the Internet of Things provides all the necessary semantics for the specification of IOT devices as well as the specifications of the IOT solution (input, output, control logic) that is deployed using these devices. These semantics include terminology related to sensors and observations, reusing the one already provided by the other ontologies, such as, SSN ontology (we will discuss about SSN shortly) and extend them to capture also the semantics of devices beyond sensors — i.e. actuators, identity devices (tags), embedded devices, and of course the semantics of the devices and things that are observed by sensors, that change their status by actuators, that are attached to identity tags. Now a natural next question would be in readers mind will be: risk of moving into the IOT world without an ontology to ground it? The lack of explicit and formal representation of the IOT knowledge could cause ambiguity in terminology, hinder interoperability and mostly semantic interoperability of entities in the IOT world. Furthermore, lack of shared and agreed semantics for this domain, that is, IOT (and for any domain) may easily result to semantic heterogeneity — i.e. to the need to align and merge a vast number of different modeling efforts to semantically describe IOT entities, efforts conducted by many different ontology engineers and IOT vendors (domain experts). Although there are tools nowadays to overcome such a problem, it is not a fully automated and precise process and it would be much easier to do so if there is at least a partial agreement between the related stakeholders — i.e. a commonly agreed IOT ontology. Now we have discussed until now, that semantics description in IOT promotes interoperability, and also has seen that semantics alone cannot be enough to guarantee interoperability and not solve all the issues regarding discovery, management of data, and supporting autonomous interactions. We need an ontology [11] and semantic description in order to make data interoperable (for users in same domain). Now we feel the need to also mention that most of the current ontologies and semantic description frameworks in the IOT domain are defined in the context of different projects and applications or they are currently at an early stage. To achieve global scale semantic interoperability, common semantic annotation frameworks, ontology definitions, and adaptation are key issues. Recent efforts, such as the W3C SSN ontology (SSN ontology will be explained shortly), are effective steps towards achieving this goal. For the current and existing applications, it is also important that their ontologies and knowledge base can be accessed and reused by large groups of potential consumers. Developing and sharing ontologies and contributing towards standard description and standard annotation frameworks that can also support legacy applications are effective steps in achieving semantic interoperability on a large scale. Other solutions, such as ontology mapping and matching (i.e. manual, semi-automated, or automated) can help link the already existing resources using different semantic annotation models. The ontology designers can also reference existing common ontologies and provide links to other upper-level ontologies to support interoperability between different semantic descriptions in the IOT domain. In above we have discussed the use of semantic annotations. In IOT domain semantic annotations provides machine-readable and machine interpretable metadata to describe the IOT resources and data. However, there are some concepts that needs to be understood is that machine interpretable data: read carefully when I mentioned machine- interpretable data, but not machine understandable data. Annotations can make provide machine interpretable data but it is still not machine understandable. Another key aspect is that the semantic annotations can be added to the data at different stages. Figure 4.1 shows that how semantics can be used at different levels in IOT. Figure 4.1: Semantics at different levels in IoT
- 7. The semantic Web technologies include well-defined standards and description frameworks (e.g. RDF, OWL, SPARQL) and a variety of open-source and commercial tools for creating, managing, querying, and accessing semantic data. However, this still does not eliminate the key role of information analytics and intelligent methods, which can process and interpret the data and create meaningful abstractions.It is important to note here that semantic technologies and Ontology Description are not new concepts. They have existed for long, and have matured over the years. Ontologies and semantic description frameworks provide an effective way to share and agree on a common vocabulary and knowledge model for describing the data, which can be machine-interpretable and represented in interoperable and reusable forms. Review of IOT ontologies: Ontologies in IOT have been developed for a number of uses, including the description of sensor and sensor networks, IOT resources and services, smart “Things”, etc. In this section we review some of the most important ontologies in the IOT domain and give a brief overview of the recent activities on the ontology developments in this field. We will also review proposed IOT middleware architecture [16] which use backbone of knowledge base composed of three ontologies (device, physics, estimation ontology). Later in end part we will briefly discuss about Machine-to-machine standards and particularly will discuss about oneM2M architectural consideration. Now we first begin by the reviewing Sensor and Observation ontologies. These ontologies were evaluated by set of questionnaire [14], which are very close to the evaluation criteria mentioned in section 2 for ontology evaluation. CSIRO Sensor Ontology: This ontology was created for describing and reasoning about sensors, observations and scientific models. Provide a semantic description of sensors for use in workflows. This ontology is still in the process of actively been developed. It is the ontology that became the starting point for the development of the Semantic Sensor Network ontology. It fairly describe key concepts behind the ontology such as for grounding (location, mobility, range of sensing), Operation Model and Process (and then Feature etc. from a domain perspective). With respect to sensor this ontology is reasonably broad, but there is more to include from say from SensorML, O&M and OntoSensor. Ontology not a hierarchy of concepts, has some restrictions etc. The ontology was not adopted widely, only few examples. As we have mentioned before that this ontology was used to develop SSN ontology. So feature like plug-and-play and composition were widely appreciated features for this ontology. OntoSensor: This ontology was created to build a knowledge base of sensor. This knowledge base can be queried via a Protege plugin. The ontology is still incomplete, but it is mainly organized around sensor, sensor capabilities description. It is not very well featured ontology. It provides a small taxonomy of sensors, but, it contains several complicated properties. Downside of the ontology is that the organization of concepts and properties is so messy to use in other application or to extend. SWAMO: Ontology was created to enable dynamic, composeable interoperability of sensor web products and services. It describe autonomous agents for system-wide resource sharing, distributed decision making, and autonomic operations. Ontology is actively maintained, and in progress (not complete).The ontology provide maximum interoperability. It focuses on the sensor domain, and particularly on processes to control them. Ontology is Sophisticated, and is interoperable with SWE descriptions. One downside to it, is classes look a little mixed and the highest level class (Component) does not appear to reference itself. MMI device Ontology: This ontology was designed for oceanographic specific devices, including both sensors (which measure things) and samplers (which pick up things). The first priority is to be able to broadly characterize the devices (i.e., sort them into groups). One significant use of such characterizations is to help users (or web applications) discover sensors or data of interest. The ontology is organized around a system concept. System is a Process. System has capabilities, like measurement capabilities (accuracy etc). Even though it was meant to be for oceanographic sensor it could be used in other contexts. SensorML Processes: Ontology was created to represent SensorML model and serve as a starting ontology for the MMI device ontology. It is based on the SensorML schema. SEEK OBOE: SEEK Extensible Observation Ontology (OBOE) was developed for the SEEK project, and has since been used by Spire. The comment documentation for the ontology concept is good. The Ontology SEEK OBOE comprise of a core observations ontology, a units extension, and a further extension for domain use (coastal ecosystems).The observation ontology separates observations from the entity being observed: the observation has a measurement while the entity has characteristics, and the measurement is then of that characteristic. SEEK OBOE is much of observation ontology, not device ontology. Figure 4.2 - Overview of the OBOE ontology Stimulus-Centric: This ontology aims at bridging between the sensor-centric Sensor Model Language (SensorML) and the user-centric Observations & Measurements (O&M)[14] specification by focusing on stimuli as objects of sensing. It does not require a strong link between sensors and features of interests such as O&M. It also include humans as sensors which are the key to volunteered geographic information. It is actively maintained. As it is a top-level kind of ontology, it is
- 8. not complete in the sense of listing sensor (types) or observations but focuses on establishing a common ground for both. The key concepts are stimuli, observations and sensors. It is based [14] on sensorML, O&M and Dolce. Figure 4,3 - The role of stimuli as a proxy between the sensor and the object of sensing SENSEI Observation and measurement ontology: The purpose for this ontology is to annotate sensor observation and measurement data; The O&M ontology [14] is then incorporated into the SENSEI resource model. Ontology is hierarchical in concept. The ontology organized around the key concepts of observing and measuring data (provided via a resource) that can be related to an Entity of Interest (EOI).The processes and services that make the O&M data available are provided through a Resource End Point (REP). O&M-OWL (SemSOS): The O&M-OWL ontology was created so that we may reason over sensor data to infer "high-level" concepts from "low-level" phenomena. These concepts were then incorporated into a Sensor Observation Service (SOS) so that users may query for events without requiring expert knowledge of how events and phenomena are related. The ontology is highly documented. The ontology is organised around four major concepts: (1) Observation -- act of observing a phenomenon (2) Process -- method, algorithm or instrument, or system of these (3) Feature -- an abstraction of real world phenomena, or "real-world" entity (4) Phenomenon -- property of a feature that can be "sensed" or measured. The ontology mostly deal how sensors can be combined. Semantics are found in the relations between the four major concepts described before. Using OWL to infer types of observations, phenomena, sensors, etc., given partial annotation. Since our ontology is based on O&M, it is already aligned with the SensorML language [14], which is a major foundation for the SSN ontology [14]. For example, the concept of process within O&M is taken directly from SensorML. The SEMANTIC SENSOR NETWORK ONTOLOGY: We will discuss SSN ontology in detail here. Now we have seen in previous sections about the IOT challenges. To solve those challenges and meet IOT today’s and future requirements, SSN ontology was proposed [14]. Back 11 years from now, Sensor Web Enablement (SWE) [14] was created by Open Geospatial Consortium (OGC). SWE main agenda, i) sensors reporting position, ii) sensors connected to web and all readable remotely, iii) all with meta-data registered and can be controlled remotely. So what SWE came up was a service- oriented architecture. So basically they define a set of services- interfaces such as: SOS (sensor observation service):which is a way to query and access sensor descriptions and sensor data SPS (sensor planning services): This allows you to task sensors to engage in different behaviors. SAS (sensor alert service): allow to subscribe to different sensing events. So these different services communicate with one-another through standard XML protocols [14]. There was standardization in protocols, and because of that it solved many problems such as sensor discovery. But still what it did not allow us to do was integrate or interpret the data (We lack interoperability). So 4 years ago from now W3C (World Wide Web Consortium) brought together a group of researchers and see if they can apply semantic technologies to help solve some of these problems. An SSN incubator group was made, and the first thing they did was build a SSN Ontology [14]. The SSN ontology is based around concepts of systems, processes, and observations. It supports the description of the physical and processing structure of sensors. Sensors are not constrained to physical sensing devices: rather a sensor is anything that can estimate or calculate the value of a phenomenon, so a device or computational process or combination could play the role of a sensor. The representation of a sensor in the ontology links together what it measures (the domain phenomena), the physical sensor (the device) and its functions and processing (the models). The Ontology structure revolves around the central Stimulus- Sensor-Observation pattern as shown in the figure 4.3. Several conceptual modules (such as device, platform, data etc) build on the pattern to cover key sensor concepts can be seen on the figure. Figure 4.4 SSN ontology structure Explanation for this ontology structure can be explained briefly: As we know sensors are often implemented within device and these devices can be integrated into systems and systems have particular operating restrictions, they can only work in particular temperature and within particular location, they have critical measurement limitations (example can only measure certain irregularities). These system can be integrated with platforms (like example the airplane internal control system) and then deployed. So we set our modeling an ontology in this fashion, that is very systematic fashion; and the reason we did this, we wanted to make ontology as simple as possible. For example If I have an application and I want to
- 9. use SSN ontology. I can pull in the modules we need, to add more complexity or more concepts (but only when I need them). But if we do not need some modules we just leave them, and this facilitates simplicity and thus interoperability. The figure4.5 shows us an overview of the main classes and properties inside the ontology modules. Figure 4.5 overview of main classes (SSN ontology). One aspect to note here is that the main classes of the Semantic Sensor Network ontology have been aligned with classes in the DOLCE Ultra Lite (DUL) foundational ontology [14] to facilitate reuse and interoperability. So SSN ontology is backward compatible: so if you have an SOS or other services, we can accommodate the data with the concepts from the SSN ontology. (So we can have advantage of high expressivity when we want to integrate with systems that are semantically aware, otherwise we ignore backward compatibility). Since we develop SSN ontology, we see a good adoption of the ontology [15]. Figure 4.6 some of adopters of SSN ontology Some of adopters that have adopted SSN ontology [15, 14] include projects such as CSIRO, IOT.est, SPITFire etc. when some of the groups using the ontology were contacted and asked why they want to use this semantic technology? And from there we came up with four major use cases that are shown in the figure 4.7 Figure 4.7 Four major use cases So four needs that people needed to use ontology for: data discovery and linking, sensor device selection and discovery, provenance and diagnostic and tasking, programming. Modules that will be used to address these four major needs were platform, system, deployment, and process. We know that deployment and process is hardware centric and in IOT this will be more interested modules. IOT middleware architecture: As we have already mentioned the challenges of IOT (such as scale, unknown topology etc) for which we need to have a IOT middleware based on the service-oriented paradigm [16] that abstracts things as services, therefore allowing us to keep services loosely coupled in order to increase reusability. The architecture will makes widespread use of approximations and estimations in order to address the IOT's challenges without requiring the intervention of domain experts. For this, in the backbone of our middleware, lies a knowledge base composed of three ontologies: a Device Ontology, a Physics Domain Ontology, and an Estimation Ontology. The overall architecture of our proposed IoT middleware is shown in Figure 4.8 Figure4.8 Middleware architecture The three ontologies that make the knowledge base are:
- 10. Device Ontology: The Device Ontology models actual hardware devices that may exist in the network. For our middleware, it can be regarded as the device description repository that can be accessed for discovery. Domain Ontology: The (Physics and Mathematics) Domain Ontology models information about real world physical concepts and their relations among each other. For our middleware, it can be regarded as the main repository to access for service composition. Estimation Ontology: The Estimation Ontology contains information about different estimation models (such as linear interpolation etc.), the equations that drive them, the services that implement them, and so on. For our middleware, it can be mainly regarded as the repository describing the device's quality of service, and provides information needed for service composition. OneM2M: Now after discussing some of the existing semantic technologies, and IOT Ontologies in previous section, now it’s the right time to discuss about functional architecture for oneM2M. The purpose [19] and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. A critical objective of oneM2M is to attract and actively involve organizations from M2M-related business domains such as: telematics and intelligent transportation, healthcare, utilities, industrial automation, smart homes, etc. Now here we now want to discuss [20] about the description of functional components as well as a functional model to support semantics for various machine-to-machine applications. Now in this technical report [20] and keeping in mind the future standardization perspective in oneM2M [21], the proposed generic functional model to support semantics for various M2M applications is shown in figure 4.9. Figure4.9: Generic functional model for supporting semantics. The functionalities of the model [20] are logically composed of three main parts: i) Service access which provides an interface with various M2M applications; ii) Abstraction & semantics which perform main functionalities for semantics to M2M data and resources; iii) Data access which provides connections with a device and/or a gateway for accessing M2M data Now we briefly explain the modules of the model: Any query request from m2m application are analyzed semantically. And to answer these semantic analyzer requests mechanism called reasoning to derive a new implicit knowledge from semantically annotated data and to answer complex user query (note our is m2m application). Ontology repository is storage of resources defined based on Ontology. Ontology modeling is the process for building an ontology which is used to model a domain and support reasoning about concepts. Semantic mash- up provides functionalities to support new services through the creation of new virtual devices. Semantic annotation of M2M resources is a method for adding semantic information to M2M resources. Device abstraction is a process of mapping between a set of Device Application Information Models. Data repository basically stores new data collected by m2m data collection module. 5. RELATED WORK There had been many studies been done on this specific topic of semantic technologies and IOT ontologies. One study that is particularly important: as it includes the review of SSN ontology and existing standards for semantics from OGC [21]. The aim of this contribution [21] is to review the current progress on semantics standardization and identifying new work items for the standardization in oneM2M.The TR team proposed to analyze existing standards for semantics from OGC and W3C in some details for reference to identify new work items for future standardization in oneM2M. 6. CONCLUSION AND FUTURE DIRECTIONS In our study what we observed that having a main global ontology that can be used to any device or service etc is still not yet existent. If the ontology exists, there are two scenarios: i) it would be very simple abstract ontology that will not suffice the use for real users or ii) it will be very complex i.e. unrealizable. Most of ontology that exist today are either domain specific, and so the problem of having a simple global ontology (able to model everything from sensors to services and overcoming the issue of interoperability) always remains a challenge. To achieve global scale semantic interoperability, common semantic annotation frameworks, ontology definitions, and adaptation are key issues. Recent efforts, such as the W3C SSN ontology, are effective steps towards achieving this goal. IOT ontology modeling and using semantics in IOT are still in their early days. The IOT community requires coordinated efforts to define more vocabularies and description frameworks to represent resources, data and services in the IOT domain. Also there was a need felt for synergetic efforts from other fields such as service computing, data mining and social science to enhance the processing and utilization of semantic data in the IOT domain. Semantic Analysis and Query Semantic Annotation Ontology Modeling Semantic Mash-Up Reasoning Service Access Abstraction & Semantics Data Access M2M Data Collection Device Abstraction M2M Applications Ontology Repository Data Repository
- 11. 7. REFRENCES [1] Ontology by Tom Gruber in the Encyclopedia of Database Systems, Ling Liu and M. Tamer Özsu (Eds.), Springer- Verlag, 2009. [2]Gruber, T. R., Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal Human-Computer Studies, 43(5-6):907-928, 1995. [3] Neches, R., Fikes, R. E., Finin, T., Gruber, T. R., Patil, R., Senator, T., & Swartout, W. R. Enabling technology for knowledge sharing. AI Magazine, 12(3):16-36, 1991 [4] Noy, Natalya F., and Deborah L. McGuinness. "Ontology development 101: A guide to creating your first ontology." (2001). [5] Obrst, Leo, Werner Ceusters, Inderjeet Mani, Steve Ray, and Barry Smith. "The evaluation of ontologies." In Semantic Web, pp. 139-158. Springer US, 2007. [6] T. Teixeira, S. Hachem, V. Issarny, and N. Georgantas,Service oriented middleware for the internet of things: A perspective," in Servicewave, to appear end of Octobre 2011. [7] CERP-IOT (Cluster o European research projects on internet of things), annual report on “vision and challenges for realizing the Internet of Things” published in March 2010 [8] M. Presser, P. Barnaghi, M. Eurich, and C. Villalonga, The SENSEI project: Integrating the physical world with the digital world of the network of the future," IEEE Communications Magazine, pp. 1{4, 2009. [9]L. Atzori, A. Iera, and G. Morabito, The internet of things: A survey," Computer Networks, vol. 54, no. 15, pp. 2787{2805, 2010. [10] D. Guinard, V. Trifa, S. Karnouskos, P. Spiess, and D. Savio, Interacting with the SOA-Based internet of things: Discovery, query, selection, and on-demand provisioning of Web Services," IEEE transactions on Services Computing, vol. 3, no. 3, pp. 223{235, 2010. [11] Barnaghi, Payam, Wei Wang, Cory Henson, and Kerry Taylor. "Semantics for the Internet of Things: early progress and back to the future." International Journal on Semantic Web and Information Systems (IJSWIS) 8, no. 1 (2012): 1-21. [12] Atzori, Luigi, Antonio Iera, and Giacomo Morabito. "The internet of things: A survey." Computer networks 54, no. 15 (2010): 2787-2805. [13] Selvage, M., et al. (2006), "Achieve semantic interoperability in a SOA, Patterns and best practices", IBM Technical library, Available at: www.ibm.com/developerworks/webservices/library/ws- soaseminterop/ index.html. [14] (http://www.w3.org/2005/Incubator/ssn/XGR-ssn- 20110628) Final report of the W3C Semantic Sensor Network Incubator Group. [15]Cory Henson. W3C Semantic Sensor Networks: Ontologies, Applications, and Future Directions. Plenary Talk given at the IERC AC4 Semantic Interoperability Workshop, Venice, Italy, June 19, 2012. Co-located with IoT Week 2012. [16] Hachem, Sara, Thiago Teixeira, and Valérie Issarny. "Ontologies for the Internet of Things." In Proceedings of the 8th Middleware Doctoral Symposium, p. 3. ACM, 2011. [17] Cory Henson, Josh Pschorr,Amit Sheth, Krishnaprasad Thirunarayan, 'SemSOS: Semantic Sensor Observation Service', In Proceedings of the 2009 International Symposium on Collaborative Technologies and Systems (CTS 2009), Baltimore, MD, May 18-22, 2009. [18] (http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Suggested_ Key_Ontology_Intro_Attributes) Source attributes. [19] Onem2m press release 2012 (http://www.onem2m.org/) [20] (http://www.onem2m.org/library/index.cfm) Technical Report - oneM2M Abstraction & Semantics Capability Enablement (oneM2M Architectural Considerations for Semantics). [21] (http://www.onem2m.org/library/index.cfm) Technical Report - oneM2M Abstraction & Semantics Capability Enablement (Discussion about existing technologies for semantics from other SDOs). [22] Predictions (cisco): http://newsroom.cisco.com/feature- content?type=webcontent&articleId=1208342