![Protocol Stack of CoAP [6]](https://www.researchgate.net/profile/Erdogan-Dogdu/publication/308850426/figure/fig1/AS:417203728994305@1476480528404/Protocol-Stack-of-CoAP-6_Q320.jpg)
Content uploaded by Erdogan Dogdu
Author content
All content in this area was uploaded by Erdogan Dogdu on Oct 14, 2016
Content may be subject to copyright.
Development of a Smart Home Ontology and
The Implementation of A Semantic Sensor Network
Simulator: An Internet of Things Approach
Omer Berat Sezer, Serdar Zafer Can and Erdogan Dogdu
Department of Computer Engineering
TOBB University of Economics and Technology
Ankara, Turkey
{oberatsezer,szcan,edogdu}@etu.edu.tr
Abstract—Internet of Things (IoT) is a network that consists
of embedded objects communicating with each other, sense their
environment and interact with it. The number of connected
devices is increasing day by day and it is expected to reach
26 billion by 2020. There is a huge potential for the development
of many applications in IoT. Up to now, the communication of
agents in IoT is solved in different ways: non-IP solutions, IP-
based solutions and recently by high level, middleware solutions.
The diversity of sensors and the complexity of data heterogeneity
are solved by use of ontologies in recent works. In this paper,
we present a smart home sensor ontology we developed that is
a specialized ontology based on the Semantic Sensor Networks
(SSN) ontology. We also present a simulation environment we
developed for a smart home case using our ontology and present
early performance results.
Keywords—Internet of Things; semantic web; sensor network
I. INTRODUCTION
With the development of the technology, smart electronic
devices with Internet connection have been developed. These
smart devices can create networks among themselves to com-
municate with each other. Sensor networks is one example
of these networks. Sensors send real-time or non-real time
data to the other nodes in the network. Internet of Things
(IoT) is a broader term for these sensor networks. It is not a
closed circuit sensor networks. All things are connected via
Internet and they use Internet infrastructure. This fact expands
the scope of the usage and reachability of these devices and
networks.
IoT is used in many areas and scenarios. Environmental
monitoring (monitoring air, water quality, atmospheric, soil
conditions, earthquake, wildlife etc.), infrastructure manage-
ment (monitoring and controlling operations of rural and
urban infrastructure), industrial applications (managing and
controlling of the manufacturing equipment, asset etc.), en-
ergy management, medical and healthcare systems (remote
health monitoring like blood pressure, heart rate), building
and home automation (monitoring and controlling lighting,
heating, appliances, security and communication systems etc.),
transport systems (interaction of the transport systems, vehic-
ular communication, smart traffic control, parking and safety,
road assistance etc.) and large scale deployments are some of
the example areas where IoT is used [1].
IoT has different solutions and applications. Web of Things
(WoT) is an evolution and different solution of IoT. It uses
standard Web protocols and solutions such as URI, REST,
HTTP, HTML5, SOAP, Web feeds etc. It exposes synchronous
functionality of the smart objects using standard Web inter-
faces such as REST and exposes asynchronous functionality
of the smart objects through Web syndication standards such
as ATOM.
Due to the increasing number of sensors in networks, data
they generated is also increasing, alongside heterogeneity of
these devices, their data formats, and measurement procedures.
Managing the data and interoperability issues is a great chal-
lenge for sensor networks. Semantic Web technologies have
been offered to overcome this challenge for the ever growing
sensor systems [2].
Semantic technologies can provide many capabilities like
managing, querying, and combining sensors and observation
data. Ontologies and the related semantic technologies can
improve interoperability and integration, as well as facilitate
reasoning, classification and other types of assurance and
automation. A semantic sensor network will allow the network,
its sensors and the resulting data to be organized, installed and
managed, queried, understood and controlled through high-
level specifications.
In this paper, we focused on defining a semantic sensor
network ontology for smart homes and the implementation of
a semantic sensor network simulator for home automation. To
our knowledge, there is not any tool to simulate a semantic
sensor network and its performance. Our prime motivation
in this work is to be able to analyse performance of our
ontology. There are different solutions for semantic sensor
network ontologies. World Wide Web Consortium (W3C) Se-
mantic Sensor Network (SSN) incubator group has a solution
which describes sensors and observations. It is independent
of domain concepts, time and locations. We created a smart
home ontology based on the SSN and simulated the use of
our ontology in the application program we developed using
Java, ActiveMQ [3], RDF [4] and Sesame Framework [5].
In the rest of paper, section II presents the related work
about this topic and recent approaches. In section III the
proposed ontology is described in detail. Section IV gives
details about the simulation application and the experimental
results. In section V we conclude and point to future work.
II. RELATED WORK
A. IoT Solutions
There are different types of solutions for IoT communi-
cation: Non-IP solution, IP-based solutions, and high-level
middleware solutions.
1) Non-IP Solutions: These solutions were proposed and
implemented by several companies and alliances. These solu-
tions are: Zigbee, Z-Wave, Insteon, Wavenis.
Zigbee1, which is wireless networking technology for low
data rate smart devices, is developed by Zigbee Alliance. It
consists of four layers: Physical, Mac, Network, and Appli-
cation layers. Physical and Mac layer of the protocol are the
defined by IEEE 802.15.4 standard. Rest of the layers speci-
fication are designed by Zigbee. It operates in the 915 MHz
(North America), 868 MHz (Europe) and 2.4 GHz (worldwide)
bands. Data rates are 20 kb/s, 40 kb/s and 250 kb/s. Tree and
mesh topologies are used widely in the system implementation.
This solution is used mostly in home automation (lighting,
HVAC, security etc.) and smart energy applications.
Z-Wave2is wireless protocol architecture for automation
of systems which is developed by Zensys. It has 5 layers
such as Physical, Mac, Transfer, Routing and Application. Its
operating frequency bands are 908 MHz (North America), 868
MHz (Europe) and 2.4 GHz (worldwide). Data rates are 9.6
kb/s, 40 kb/s and 200 kb/s. There are two types of devices in
the system implementation: Controller and Slaves. Controllers
poll and send commands. Slaves reply controllers and execute
its commands.
Insteon3is wireless technology which is developed by Smart
Labs and promoted by Insteon Alliance. Devices operates at
the 904 MHz center frequency. Nominal data rate is 38.4 kb/s.
Mesh topology is used and nodes communicate each other by
using RF and power links.
Wavenis4is wireless protocol for monitoring and controlling
applications which is developed by Coronis Systems. It con-
sists of three layers: Physical, Link and Network. It operates
in the 433 MHz, 868 MHz, 915 MHz and 2.4 GHz bands.
1http://zigbee.org
2http://www.z-wave.com
3http://www.insteon.com
4http://www.elstermetering.com/en/wavenis-technology
TABLE I
STACK COMPARISON [7]
Zigbee Zensys 6LoWPAN
Code Size with Mesh 32K to 64K+ 32 K 22K
Code Size without Mesh Not Possible Not Possible 12K
RAM Requirements 8K <2K 4K
Header Overhead 8 to 16 bytes Proprietary to 11 bytes
Network Size ∼65K 232 264
RF Radio Support 802.15.4 Proprietary 802.15.4++
Transport Layer None Proprietary UDP/TCP
Mesh Network Support Zigbee Zensys Many
Internet Connectivity Zigbee Gateway Zensys Gateway Bridge/Router
Figure 1. Protocol Stack of 6LoWPAN [6]
Data rate are 4.8 kb/s (minimum), 100 kb/s (maximum) and
19.2 kb/s (typically) [6].
2) IP-Based Solutions: 6LoWPAN (IPv6over Low power
Wireless Personal Area Networks) is an IP-based solution
which is developed by 6LoWPAN IETF Working group. It
is working between IPv6 and IEEE 802.15.4 and it has
adaptation layer between two layers that performs header
compression, fragmentation, address auto configuration. IPv4
does not fit for this problem solution. Because its address space
is 32-bit which is limited address space for connecting 50
billion devices. On the other hand, IPv6 solves this limited
address space with 128-bit addresses. Smart devices connect
other IP-based networks without using translation gateway and
proxies [6]. Figure 1 shows the protocol stack of 6LoWPAN.
Also in Table I, the differences between the Non-IP Solutions
and IP-Based Solutions are presented.
3) High Level and Middleware Solutions: There are two
high level and middleware solutions: CoAP (Constrained Ap-
plication Protocol), GSN (Global Sensor Network). CoAP is a
protocol that supports the communication of the smart devices
which have constraints such as limited energy resources,
limited hardware capabilities and high packet loss rates. It
is proposed by IETF (Internet Engineering Task Force). It
also consists of a subset of the HTTP (Hypertext Transport
Protocol) functionalities. In addition, it is built on the top
of the UDP (User Datagram Protocol) and it has two sub-
layer: Request /Response and Transaction. Figure 2 shows the
protocol stack of the CoAP.
CoAP also supports payload-encoding standards in terms of
XML (Extensible Markup Language). In literature, 2 operating
systems, Contiki and TinyOs, run over CoAP. Contiki is an
operating system that supports standard IPv6 and IPv4 for low-
power, short range smart devices. TinyOs is an open source,
BSD-licensed operating system for low-power wireless device.
Figure 2. Protocol Stack of CoAP [6]
GSN is an open source framework that is developed using
Java. The main development in GSN is done using a virtual
sensor abstraction. A virtual sensor consists of 3 parts, in-
cluding a wrapper (the class containing functional logic), one
or more processing classes (containing post-functional logic),
and a descriptor file (XML file for configuring sensor). SQL-
based queries are used in GSN to send data streams from
sensors to the data users. Sensor discovery protocol, which is
composed of query, subscription and registration process, is
used to manage the sensor network system [6].
4) Other Solutions: Intel’s solution to IoT is by developing
custom design gateways. In gateway design, Intel processors,
Wind River5operating system is used. Figure 3 shows the
solution stack.
Figure 3. Intel Solution Stack
Internet Protocol for Smart Objects (IPSO) Alliance has
offered an application framework [8] that defines a RESTful
design to use in IPSO systems like Home/Building Automa-
tion and other machine-to-machine (M2M) applications. Their
solution does not include any semantic structures like RDF.
Advanced Metering Infrastructure (AMI) is an integrated
metering structure that can be used for smart meters and
communication networks. Sensus supports and develops these
FlexNet AMI devices to measure electricity, gas and water
consumption in North America. Our proposed solution can
5http://www.windriver.com
be adapted by using middleware that connects to device
and software. Thus, AMI devices can be simulated with our
simulation solution.
B. Sensor Ontology Solutions
Ontologies have been used successfully to model the knowl-
edge of a vast number of domains, including sensors and
observations [9]. Several sensor ontologies have been proposed
in the past, some of them focused on sensor descriptions, and
others in observations (data). Most of these proposals are,
however, often specific to a project, or discontinued, and do
not cover many important areas of sensors and observation
domains. Moreover many of these ontologies did not follow a
solid modelling process or did not reuse existing standards. In
order to overcome these issues, the W3C SSN XG group [10]
introduced a generic and domain independent model, called
Semantic Sensor Networks (SSN) ontology.
The SSN ontology can describe sensors in terms of capabil-
ities, measurement processes, observations and deployments.
However, it does not include metric terms about qualities
(temperature, location, distance etc.). For this reason, the
SSN is used with other ontologies like Spitfire [11], Swiss
Experiment [12], SWEET [13] or context specific custom
ontologies.
There are many works about customizing ontologies to add
history, prediction models, and states for sensors [14]. Re-
searchers try to find scalable ways to add these modifications
to their ontologies.
III. PROPOSED ONTOLOGY
In our solution, we propose creating a sensor network
ontology for smart home automation based on the SSN and
show that it works by using a simulation application program
we developed. The ontology is called ”smart home ontology”
(SHO). In the simulation application, systems used at home
such as computers, home appliances, security, lighting and
heating devices are modelled separately. Master/slave model
is used to implement the simulation. All modelled devices
communicate with each other via using a message queue.
The main computer system controls the whole system as a
master node where the other systems behave like slaves and
get commands from the master and execute.
A typical execution scenario in the simulation is defined as
follows:
•The main computer reads the sensor ontology (RDF/XML
file) to control the state of sensors.
•Other systems (sensors) initialize to their starting states
and show the status on their screens.
•The main computer gets all sensor reads every 0.5 sec-
onds periodically and shows the values on its screen.
•If sensors in the system get out of scope values, the main
computer responds with commands to fix the readings.
•All system devices receive the commands from the main
computer and respond when needed.
Our key principle was simplicity while constructing our
ontology. We wanted to cover all of the functionalities in the
system with the minimum number of classes and properties.
Details about our ontology (classes with their individuals and
properties) are described in this section. Class diagram of our
ontology is given in Figure 4. Prefixes that are used in the
ontology are given in Table II. Prot´
eg´
e 5.0 [15] is used to
create the ontology. The ontology can be downloaded from
the project Web site at http://wis.etu.edu.tr/iot.
TABLE II
PRE FIX ES U SE D IN T HE P ROP OS ED O NT OL OG Y.
owl http://www.w3.org/2002/07/owl#
xsd http://www.w3.org/2001/XMLSchema#
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http://www.w3.org/2000/01/rdf-schema#
dul http://www.loa-cnr.it/ontologies/DUL.owl#
ssn http://purl.oclc.org/NET/ssnx/ssn#
sho http://www.smarthome.com/ontology#
Figure 4. Smart Home Ontology (SHO) class hierarchy.
Below we describe the classes and properties in SHO
ontology.
A. Classes
dul:PhysicalObject: A generic class for any physical
item. It has two subclasses in our ontology: Platform and
System.
ssn:Platform: An entity to which other entities can be
attached - mostly Sensors. There are 16 platforms: bath-
room, computer, dishwasher, hall, kitchen, oven, refrig-
erator, TV, washing machine, rooms 1-4, electricity, gas,
and water.
ssn:System: System is an entity of abstraction for pieces
of infrastructure for sensing. A system may have subsys-
tems, which are also systems. It has four individuals in
our system: Home Appliances System, Heating System,
Lighting System, and Security System.
ssn:Sensor: Represents sensors, a subclass of System, and
has 79 members in our ontology. In Figure 5, a sample
sensor description is given in Turtle format.
ssn:Observation: Each output of a sensor is a member of
Observation class in our ontology. In Figure 5, a sample
observation description is provided.
ssn:Property: There are five individuals in this class:
illuminance, mode, power, status and temperature.
sho:Unit: Class for the types of measurement unit. We
have three unit types: Celsius for temperature, Lux for
illuminance and Watt for power.
sho: Command: This is the class that describes commands
from the main computer to platforms and systems. It has
three subclasses: System Command, Platform Command,
and Mode Command.
Figure 5. A sample sensor description and its observation.
B. Properties
Object properties (op) and data properties (dp) are described
below. {Domain} → {Range}notation is used to describe
the source and target classes of each property after a short
description.
◦ssn:attachedSystem (op): Shows the relation between a
Platform and a System (e.g., Sensors) that are attached
to the Platform.
{P latf orm}→{System}
◦ssn:featureOfInterest (op): Shows the relation between an
observation and the entity whose quality was observed.
As an example, when a sensor observes a room’s temper-
ature, the feature of interest is the room and temperature
is the quality.
{Observation}→{P latf orm}
◦ssn:hasSubSystem (op): Describes the relation between a
system and its subsystems.
{System}→{Sensor, System}
◦ssn:isPropertyOf (op): Shows the relation between a
platform and its observable quality by a sensor.
{P roperty }→{P latfor m}
◦ssn:observedBy (op): Shows relation between an Obser-
vation and a Sensor.
{Observation}→{Sensor}
◦ssn:observedProperty (op): Shows which property is ob-
served at that observation.
{Observation}→{P roperty }
◦ssn:observes (op): Relation between a Sensor and a
Property that the sensor observes.
{Sensor}→{P roperty }
◦sho:observationValue (dp): Shows the value that the
observer sensor generated.
{Observation}→{xsd :string, xsd :int}
◦sho:safeMin/safeMax (dp): These properties describe the
minimum and maximum limits of the expected value
range for a Sensor.
{Sensor}→{xsd :int}
◦sho:time (dp): Shows the time of a command or observa-
tion. Format is: YYYY-MM-DDTHH:MM:SS. ‘T’ in the
middle separates date and time.
{Observation, Command}→{xsd :dateT ime}
◦ssn:onPlatform (op): Relation between a System (e.g., a
Sensor) and a Platform that includes the system.
{Sensor}→{P latf orm}
◦sho:hasUnit (op): Shows a Property’s Unit.
{P roperty }→{Unit}
◦sho:hasSymbol (dp): Describes a Unit’s preferred symbol.
{Unit}→{xsd :string}
◦sho:commandToSystem (op): Describes a Command’s re-
lated System.
{M odeCommand, P l atfor mCommand} →
{System}
◦sho:sc start/sc stop (op): Start and stop commands to a
System.
{SystemCommand}→{System}
◦sho:sc alarmOn/sc alarmOff (op): Start and stop com-
mands to a Platform’s alarm system.
{SystemCommand}→{P latf orm}
◦sho:mc setMode (op): Describes the command of chang-
ing a Platform’s operating mode.
{ModeCommand}→{P latf orm}
◦sho:mode (dp): Shows which mode is applied to the
Platform.
{ModeCommand}→{xsd :string}
◦sho:pc start/pc stop (op): Start and stop commands to a
Platform.
{P latf ormC ommand}→{Pl atfor m}
IV. APPLICATION AND EXPERIMENTS
We used Sesame Framework’s Rio library (version 2.7.14)
to parse the ontology file in RDF/XML format. Java is used
as a programming language and SWT (Standard Widget Tool)
library is used for graphical user interface implementation.
Apache Active Message Queue (version 5.10.0) is used for
communication of all system model applications. All sensors
in the system use their own queues and sessions to trans-
fer their information. All system application programs were
modelled as state machines. The main computer application
program uses threads to get all messages from other system
sensors and process them. In Figure 6, flow diagram of the
simulator is given. Message Process Unit (MPU) has a thread
for each system. Each of them reads and processes data, then
writes the results to the triplestore. MPU checks the values
whether they exceed the limits which are described in the
ontology by sho:safeMin/safeMax properties for the related
sensor. If any sensor reads a value that passes the safe range,
MPU sends a command to the system or platform includes the
sensor to get back the values to the safe range. In Table III,
our test environment’s specifications are also given.
Figure 6. Flow Diagram of the Simulator
TABLE III
TES T ENVIRONMENT
CPU Intel Core i7-3770 3.4GHz
Memory 16 GB RAM
OS Windows 7 Professional
The main computer application has four tabs, as shown in
Figure 7. We tested the system as such that the main computer
monitors and collects information from different sensors in a
smart home environment. The system consists of 24 sensors
from home appliances, 14 sensors from lighting system, 21
sensors from heating system, and 20 sensors from security
system.
There are six appliances in Home Appliances System,
whose user interface is given in Figure 8, such as refrigerator,
washing machine, dish washer, television, oven, computer.
All appliances have four sensors each: temperature, mode,
status, electric consumption. Temperature sensor measures
temperature in Celsius, mode sensor sets the appliance mode
in one of three modes (safe, economic, advanced), status
sensor shows the status of the equipment (on/off), electric
consumption sensor measures the consumption of electric in
kWh.
There are seven rooms in the house. All rooms have
two sensors connected to the lightning system: status and
Figure 7. Main Computer Application Program
Figure 8. Home Appliances Application Program
illuminance. Illuminance sensors measure the light intensity in
Lux, status sensors show the status of the equipment (on/off).
For the heating system, all rooms have 3 sensors: temperature,
mode and status. Finally, in the security system, all rooms have
two sensors: status and mode. Mode sensor in this case sets
the mode in two forms (safe/alarm), status sensor shows the
status of the equipment (on/motion/off).
Sensors are grouped as a system in the house. Each sensor
has a dedicated queue which is used for sending messages to
the main computer. Main computer has also a dedicated queue
which is used for sending acknowledgement and commands
(telecommand) to the system in the house such as lighting,
heating, etc. Telecommand from the main computer to the
sensors, contains 3 sub-parameters: Module, Command and
Parameter. In the execution scenario, the main computer sends
a telecommand to the temperature sensor in the refrigerator.
Module is the ”refrigerator temperature sensor”, command is
the ”mode” which is related to the change mode command of
the refrigerator, and the parameter is ”safe” that is one of the
parameters for the mode.
We performed several experiments on our simulator to
analyse its performance. First of all, we measured the aver-
age In-Queue Time (IQT) of packages, which is sent from
sensors, for each system. In Table IV, measured average IQT,
maximum IQT, processing time of all systems are given. In
lighting system, the number of the sensors per thread are more
than other systems. Therefore, IQT for the lighting system is
the highest one. If the number of the sensors per thread is
decreased, IQT will be smaller.
TABLE IV
AVERA GE IQT, MAXIMUM IQ T, AN D PRO CE SS IN G TI ME F OR A LL
SYSTEMS WITH 10MS D EL AY BET WE EN M ES SAG ES
System Avg.IQT (ms) Max.IQT (ms) Processing Time (ms)
Lighting 38.48 121 15
Home Appliances 12.05 32 16
Heating 11.17 19 14
Security 11.08 17 16
We also analysed the timings when sensors send data with
different frequencies. Figure 9 illustrates the graph which
indicates average IQT vs time difference between packages
for Home Appliances System. When time difference between
packages equals to 1 ms, average IQT is observed as 83
ms. Enqueued packages are much more than the processed
packages when they are sent with higher frequencies as
expected. If time difference between packages increases, then
average IQT decreases exponentially.
Figure 9. Average IQT (ms) for increasing delay between messages
Finally, we studied on the timings of different active sensor
counts. In Table V, average IQT values are presented with al-
ternative loads at the same data send frequency(1 ms difference
between packages). It can be seen that increasing the number
of active sensors results in higher IQT’s for packages. The
exponential growth at average IQT can be seen in Figure 10.
TABLE V
TOTAL NU MB ER O F ME SS AG ES I N QU EU ES ,AVER AGE IQT ( MS ),
MAXIMUM IQT (M S)F OR VARYI NG N UM BE RS O F SE NS OR S
Number of Sensors Total Packets in Queue Avg.IQT (ms) Max.IQT (ms)
4 1642 2.55 51
8 931 4.90 107
12 1359 5.88 88
16 1052 15.98 333
18 1012 37.55 206
24 1024 114.14 423
Figure 10. Average IQT (ms) for increasing number of sensors
V. CONCLUSION AND FUTURE WORKS
In this paper, we presented the smart home ontology (SHO)
we developed and a simulator software for a smart home using
SHO. We constructed our ontology based on the well-known
SSN ontolgy. Basic concepts were covered in our case to keep
the ontology simple. Experiments are performed to test the
simulation system. We applied several scenarios to measure
the performance of the applications and ontology. The results
are not hardware and platform independent. They may vary
between on different computer configurations and operating
systems.
This work is our first step to build a hardware and platform
independent, fully configurable semantic sensor network on-
tology simulator. We are planning to analyse performance of
different ontologies with different communication topologies.
Our future simulator is going to be capable of adding/dropping
sensors at runtime and scaling with the active sensor load.
REFERENCES
[1] D. Bandyopadhyay and J. Sen, “Internet of things: Applications and
challenges in technology and standardization,” Wireless Personal Com-
munications, vol. 58, no. 1, pp. 49–69, May 2011.
[2] C. Perera, A. Zaslavsky, P. Christen, and D. Georgakopoulos, “Context
aware computing for the internet of things: A survey,” Communications
Surveys & Tutorials, IEEE, vol. 16, no. 1, pp. 414–454, 2014.
[3] Apache ActiveMQ, “Open source messaging and integration patterns
server,” http://activemq.apache.org/, [Online; accessed 16-February-
2015].
[4] W3C Recommendation, “Rdf vocabulary description language 1.0:
Rdf schema,” http://www.w3.org/TR/rdf-schema/, [Online; accessed 16-
February-2015].
[5] Sesame, “Framework for processing rdf data,” http://rdf4j.org/, [Online;
accessed 16-February-2015].
[6] L. Mainetti, L. Patrono, and A. Vilei, “Evolution of wireless sensor
networks towards of things: A survey,” in International Conference
on Software, Telecommunications and Computer Networks. IEEE,
September 2011, pp. 1–6.
[7] G. Mulligan, “The 6lowpan architecture,” in Proceedings of the 4th
Workshop on Embedded Networked Sensors. ACM, June 2007, pp.
78–82.
[8] Z. Shelby and C. Chauvenet, “The IPSO application framework,” IPSO
Alliance, http://www.ipso-alliance.org/, Tech. Rep., 8 2012.
[9] M. Compton, C. Henson, L. Lefort, H. Neuhaus, and A. Sheth, “A
survey of the semantic specification of sensors,” in Proceedings of the
8th International Semantic Web Conference. International Workshop
on Semantic Sensor Networks, October 2009, pp. 17–32.
[10] M. Compton et al., “The ssn ontology of the w3c semantic sensor
network incubator group,” Web Semantics: Science, Services and Agents
on the World Wide Web, vol. 17, pp. 25–32, December 2012.
[11] D. Pfisterer et al., “Spitfire: Toward a semantic web of things,” IEEE
Communications Magazine, vol. 49, no. 11, pp. 40 – 48, November
2011.
[12] S. R. Institutes, “Swiss experiment,” http://www.swiss-experiment.ch/
start/index.html, [Online; accessed 16-February-2015].
[13] R. G. Raskin and M. J. Pan, “Knowledge representation in the semantic
web for earth and environmental terminology (sweet),” Computers &
Geosciences, vol. 31, no. 9, pp. 1119–1125, November 2005.
[14] R. Mietz, S. Groppe, K. Romer, and D. Pfisterer, “Semantic models for
scalable search in the internet of things,” Journal of Sensor and Actuator
Networks, vol. 2, no. 2, pp. 172–195, March 2013.
[15] Prot´
eg´
e, “Ontology editor and knowledge acquisition system,” http://
protege.stanford.edu, [Online; accessed 16-February-2015].
