=Paper=
{{Paper
|id=Vol-1481/paper20
|storemode=property
|title=MOCAP: Towards the Semantic Web of Things
|pdfUrl=https://ceur-ws.org/Vol-1481/paper20.pdf
|volume=Vol-1481
|dblpUrl=https://dblp.org/rec/conf/i-semantics/SahlmannS15
}}
==MOCAP: Towards the Semantic Web of Things==
https://ceur-ws.org/Vol-1481/paper20.pdf
MOCAP: Towards the Semantic Web of Things
Kristina Sahlmann Thomas Schwotzer
HTW Berlin, University of Applied Sciences HTW Berlin, University of Applied Sciences
Wilhelminenhofstraße 75A, 12459 Berlin, Germany Wilhelminenhofstraße 75A, 12459 Berlin, Germany
+49 30 5019 3626 +49 30 5019 2604
kristina.sahlmann@htw-berlin.de thomas.schwotzer@htw-berlin.de
ABSTRACT That seamless user experience is also the idea developed by the
The original idea of the internet had a decentralized approach: Physical Web Project2. Every smart device has an URL. Users ask
every internet host sends data packages along to its neighbors if for devices nearby and get the list. Then they can use the URL in
they are not addressed to itself. Every host is a sender and a order to get more information. The project uses the URI Beacons
receiver at the same time. Nowadays we are moving towards schema.
Internet of Things (IoT) and again all the small devices and This paper describes the decentralized approach for data exchange
sensors get decentralized nature. They exchange data with their between small devices on the IoT using the low level M2M
environment and neighbors next to them. Data exchange requires protocols. We combine the common technologies like RDF with
a mutual understanding of exchanged data. Semantic approaches, constrained devices and their networks. The transported data is
namely a vocabulary help which leads to a Semantic Web of enriched by semantic description. We introduce the common
Things. This paper describes a proposal for the Micro-Ontology M2M protocols and apply the idea of context-aware micro-
Context-Aware Protocol (MOCAP). Sensors can use micro- ontology. M2M protocols has to follow some rules and
ontologies which are always context-aware and send this semantic restrictions.
information to other devices. The receivers gain valuable
information using the semantic description and data about micro- 2. RELATED WORK
ontology. Implementing M2M protocols on limited devices like There are several works on standardization of ontologies among
sensors is challenging. We introduce an extension to MQTT and them for sensors, too. The SSN ontology [2] by W3C describes
CoAP that exchanges data based on Micro-Ontologies. That leads high-level model for sensors, their capabilities, platform,
to semantic interoperability even on the level of sensor grids. observation etc. on behalf of OWL. But it does not address the
units of measurement or other specific domain knowledge. There
Categories and Subject Descriptors should be simple semantic definition for the sensor data exchange.
C.2.2 [Computer-Communication Networks]: Network There is a draft for SenML [6] providing the lightweight protocol
Protocols – routing protocols. describing the media type i.e. for temperature sensor in protocols
like HTTP or CoAP. They introduce several representations
General Terms JavaScript Object Notation (JSON), eXtensible Markup Language
Design, Experimentation, Standardization, Theory (XML) and Efficient XML Interchange (EXI). But the markup is
limited on sensors.
Keywords Other work in [12] proposes “a method of transforming sensor
Internet of Things, Semantic Web, Ontology, M2M Protocol, data into the RDF conforming to SSN ontology”. They introduce
MQTT, CoAP, Sensors an XML-based language for annotation of sensors.
The work presented in [11] proposes the design for lightweight
ontology, linked IoT data, distributed semantic data storage and
1. INTRODUCTION semantic service discovery and ranking. It shows some concepts
At the 12. Google I/O conference 2015 Google introduced the
to connect the sensors with the web and also use common web
new operation system named Brillo for the smart home and the
practices like linked data and web services. But it does not
Internet of Things (IoT). Google is also working on the Weave
describe a M2M protocol binding or any semantic enhancements.
API which should be used for communication in the IoT. This
API can be used cross-platform even on top of the existing stack. The researcher group developed a semantic engine for IoT [4].
The Google’s solution for the interoperability is furthermore a They address some challenges for IoT and want to provide
core set of schemas1 for data exchange. Developers can extend interoperability and integrate semantic web technologies among
this schema in terms of certified program which should guaranty others. They introduce a semantic-based M2M architectures for
that devices can exchange data seamlessly. This should improve ETSI M2M and oneM2M.
the user experience. Every Android device recognize There is another work [5] analyzed the semantic usage on the IoT.
automatically any Brillo OS or Weave API based device. Users They see the Semantic Web of Things (SWoT) as the next step
can choose a device, set it up and use it immediately. after IoT and Web of Things. The goal of SWoT is to connect the
physical and the digital world, and semantic is the key. They
analyze the protocols for the SWoT application, and see the
1 2
https://developers.google.com/brillo/ http://google.github.io/physical-web/
59
MQTT still in the telemetry market, and CoAP is more applicable The way how these devices are going to exchange context-aware
for IoT and higher level standards. data based on micro-ontology we are calling MOCAP – micro-
ontology context-aware protocol.
3. SCENARIO
The growth of the Internet of Things (IoT) has led to the spread of 4. M2M PROTOCOLS
various small devices, including wearables, beacons, sensors etc. In these scenarios we have a machine to machine (M2M)
Every device can be seen as peer. Devices usually communicate communication. There are two M2M protocols specified for the
directly – in a direct, a P2P manner. Devices don't have to be Internet of Things (IoT): the Message Queuing Telemetry
connected with Internet. Information exchange is usually Transport (MQTT) and the Constrained Application Protocol
performed between nearest devices with near-field protocols. (CoAP). They both work on level four of the Open Systems
Interconnection model (OSI Model), which makes them better
Devices can be i.e. a couple sensors and a smartphone. Sensors suitable for constrained environments than HTTP. Both protocols
are constrained devices. They have small processors and little are open standards: MQTT v. 3.1.1 is an OASIS Standard [1] and
storage. But they have an operation system and network access. CoAP is specified as Request for Comments (RFC) 7252 [9] by
And they are built and used for the certain purpose (e.g. measure Internet Engineering Task Force (IETF). The MQTT has an
temperature). That purpose is the context and the devices are extension for the sensor networks the MQTT-SN [10].
context-aware. In our scenario, sensors can measure different
environment data. The smartphone next to it should collect and These protocols have different architecture and message formats.
combine these information and present it users. This can occur as They have a mutual understanding of the M2M data exchange and
well in the push as in the pull way. Either users scan for the constrained devices as well as IoT, though. We want apply a
nearest sensor or will be notified. Sensors measure the context-aware data based on micro-ontology on M2M protocols.
temperature, the humidity and the brightness in the house and Because it’s difficult to say which protocol may win by the end,
environment etc. Users get the information on smartphone but we take a look on all three protocols and analyze advantages and
also the automatic blinds for the windows in their home get these disadvantages.
information and close or open automatically. Users can control We use the Resource Description Framework (RDF)3 as a data
the blinds with the smartphone, too. Devices need a common format for communication. This is a standard for Semantic Web.
understanding of exchanged data to work in that way. This Alternative we could use JSON-LD4 as a standard for Linked
scenario is outlined in the Figure 1. Data, but for our home scenario is seems to be oversized. RDF
use the URI for resource and properties identification. On the
other hand RDF has several data representations among them N-
Triples and Turtle. N-Triples are used i.e. by DBpedia. Turtle
format seems to be more appropriated for the small devices
because it separates the data representation into two parts: a list of
prefixes and a list of the triples as shown in the Table 1. The data
representation is more compact.
Table 1. RDF Turtle example.
@prefix rdf: .
@prefix sens: .
Figure 1. Context-aware data exchange. @prefix meas: .
sens:mysensor rdf:type temperature;
Sensors have only less context-aware information (e.g. position, meas:units “degree Celsius”;
measured values). Thus, even small devices have to describe and meas:short “°C”;
exchange their context. In our model, information are only rdf:value "20.5" .
merged if their context matches. Each information is enriched
with a micro-ontology data that describes that context. This is a
4.1 MQTT
First we take a look on MQTT. This protocol is designed for
controlled vocabulary. It can be a part of the top-level ontology.
publish and subscribe messaging. It uses TCP/IP or “other
Back to our scenario the sensor knows only the micro-ontology network protocols that provide ordered, lossless, bidirectional
for its own measurement. Let’s assume it measures the connections” [1] for the transport. The protocol relies on
temperature. The smartphone knows this temperature micro- client/server architecture paradigm.
ontology either because users added it before or the smartphone
The MQTT protocol defines fourteen types of Control Packets.
has downloaded it from Internet in order to process the
Two of them are suitable for transporting semantic information:
information. Now they can communicate.
PUBLISH and SUBSCRIBE.
In the home scenario the sensors measurement should tell what
The SUBSCRIBE Control Packet contains the client subscription
they measure and in which unit of measurement the results are.
for one or more Topics. This packet is sent from the client to the
The micro-ontology of the sensor is a subset of the environment
server. Topics have Topic Names which can be structured by topic
ontology. Thus the window blinds need to know this micro-
level separator as the forward slash (‘/’) and provide the
ontology for the measurement but also for its control. The
hierarchical structure. In our case the smartphone and the blinds
smartphone has knowledge about the environment ontology and
can process data from the other devices like temperature, humidity
or brightness sensors. And the smartphone knows the micro- 3
ontology for the blinds control as a subset of home control http://www.w3.org/standards/techs/rdf#
4
ontology. http://json-ld.org/
60
are subscriber by the temperature sensor. The sensor must 4.3 CoAP
recognize the subscription Topic for micro-ontology. The The Constrained Application Protocol (CoAP) was developed for
subscription Topics should be the namespaces of the ontology and use with constrained networks and nodes [3]. The protocol
the micro-ontology. The PUBLISH packet may contain only one “provides a request/response interaction model between
Topic. Therefore the sensor publishes the message twice: one with application endpoints” [9]. It uses UDP or other datagram-
the ontology and one with the micro-ontology namespace. Our oriented protocol like 6LoWPAN. The protocol can easily be
scenario with MQTT is shown in the Figure 2. integrated with Web over HTTP under some circumstances.
CoAP-HTTP Proxy and HTTP-CoAP Proxy must be
implemented. Service and resource discovery is supported beside
multicast clients.
The Constrained RESTful Environments (CoRE) [8] uses the
REST architecture paradigm. Clients and servers exchange data
by means of GET, PUT POST and DELETE requests. CoAP
endpoints can be both, client and server. Resources are identified
by an URI with coap-prefix, e.g. “coap://server/temperature”.
Because of the underlying datagram-oriented transport and
constrained network, the size of the request/response is limited to
the datagram and IP packet size without fragmentation. For the
UDP it results in 1024 bytes for the payload size [9]. In case of
6LoWPAN L2 the packets are limited to 127 bytes including
Figure 2. MOCAP based on MQTT protocol.
overhead.
The PUBLISH Control Packet transports an Application Message.
For our scenario the sensor have a server role, and the smartphone
This packet can be send from a client to server or from a server to
and blinds have the client role to succeed the GET request for the
a client. The Application Message contains among others a
temperature, see Figure 3.
variable header and a payload. The Topic Name is one field from
the variable header. It identifies the topic of the payload. The
payload contains the publish message. The MQTT Control Packet
can have a size up to 256 MB [1] due to variable length encoding
scheme. The payload in RDF format can contain N-Triples or
Turtle. For constrained devices and networks the message payload
should be reduced to the Turtle and consists only the triples.
Using prefixes allows sending an ontology within a single
package.
4.2 MQTT-SN
The MQTT-SN is specified by IBM. The protocol is intended for
Wireless Sensor Networks (WSNs) and constrained devices with a
limited processing and power capacity. This protocol addresses
the lower transmission rate. In case of WSN based on IEEE Figure 3. Scenario with CoAP.
802.15.4 the packet length is limited to 128 bytes [10] for the The most common request is the GET request. It retrieves
whole message. Subtracting the overhead for security, etc. there information from the current resources. On success a 2.05
will be left only the half-length for the payload. MQTT-SN (Content) response code should be presented in the response. The
doesn’t necessary need the TCP/IP layer. The protocol can work payload content has to indicate the content-format of the payload
on any network which supports “a bi-directional data transfer in order to simplify the message processing. There is a sub-
service between any node and a particular one (a gateway)” registry for the subset of Internet media types which can be used
supporting the protocol. The protocol already supports UDP and by CoAP as a numeric identifier. For an example
Zigbee. The MQTT-SN extends the MQTT protocol optimizing it “application/xml” has the identifier “41” [9]. The payload itself
for constrained devices and networks. has a very limited size for transporting RDF enriched semantic
Due to this limited capacities the Topic is replaced by a short data. As we already have seen, the Turtle could be divided into
topic id of two bytes. Clients must register their Topics with the two parts: the prefix definitions and the triples. Thus we could
gateway to get the corresponding topic id. Gateways mediate transfer only the triples assuming that clients know those prefixes.
between MQTT-SN and MQTT. Furthermore pre-defined topic There are two ways in CoAP how the endpoints get connected:
ids and short topics are introduced which don’t require either by service discovery or by multicast. In case of service
registration. The pre-defined topic is two byte long. The short discovery the client knows (or learns) the server’s address. The
topics have a fixed length of two octets. Both the pre-defined and resource discovery offered by the CoAP endpoint proceeds in
short topics are used by PUBLISH message. We propose to use machine-to-machine way. For more interoperability the endpoints
that structure to transmit prefixes of the micro-ontology should support the Constrained RESTful Environments (CoRE)
namespaces in RDF Turtle format. The publish message contains Link Format [8] of resources.
only the triples of Turtle. MQTT-SN is more suitable for sensors Using the entry point clients get the response with a payload in
and the semantic data can be reduced by using the RDF Turtle. the CoRE Link Format. It consists of resources hosted by the
server, i.e. a list of environment sensors i.e. for temperature,
humidity, etc. There are several examples described in the
61
RFC6690 [8]. They consider a server with two resources: for Summarizing we call this approach MOCAP – micro-ontology
temperature and humidity. The GET request returns a list of these context-aware protocol. The next step will be a case study with
resources, see Table 2. some use cases and different device classes. We need to evaluate
Table 2. CoAP GET request and response. the micro-ontology, its size etc. We follow the work of RDF
Stream Processing Community Group (RSP)5 and Web of Things
REQ: GET /.well-known/core (WoT)6 community groups at W3C.
RES: 2.05 Content
;ct=40;title="Sensor Index", 6. REFERENCES
;rt="temperature-c";if="sensor", [1] MQTT Version 3.1.1. Edited by Andrew Banks and Rahul
;rt="light-lux";if="sensor" Gupta. 29 October 2014. OASIS Standard.
The resource URI could be the namespace of the micro-ontology http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-
which is known by the sensor. The attribute “rt” describes the os.html. Latest version: http://docs.oasis-
resource type. In this case it is the unit measurement. The attribute open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html.
“if” describes the interface of the resource which is sensor. The [2] Semantic Sensor Network XG Final Report. Edited by
client can process this semantic data and match it to its known Laurent Lefort, Cory Henson and Kerry Taylor. W3C
ontologies. Incubator Group Report 28 June 2011.
http://www.w3.org/2005/Incubator/ssn/XGR-ssn-
In the multicast CoAP the endpoints listen on the default CoAP 20110628/. Latest version:
port in order to offer services to multicast endpoints. This process http://www.w3.org/2005/Incubator/ssn/XGR-ssn/.
is described by RFC 7390 [7]. After they have received a [3] Bormann, C., Ersue, M., and Keranen, A. 2014.
multicast request they can process the message or ignore it. The Terminology for Constrained-Node Networks. RFC 7228.
message can contain the semantic information about micro- RFC Editor, May 2014. DOI=10.17487/RFC7228.
ontology of the client. The endpoint matches these information to [4] Gyrard A., Datta S. K., Bonnet C., Boudaoud K. 2015. A
its known ontologies and process it. Every message is identified Semantic Engine for Internet of Things: Cloud, Mobile
by Message ID used to detect duplicate messages. The request Devices and Gateways. http://www.eurecom.fr/en/
may include further options and among them the client URI. publication/4555/download/cm-publi-4555_1.pdf.
The CoAP protocol is more adapted for constrained nodes and [5] Jara, A. J., Olivieri, A. C., Bocchi, Y., Jung, M., Kastner,
networks. The MOCAP protocol can be setup on top of it because W., and Skarmeta, A. F. 2014. Semantic Web of Things: an
the nodes are context-aware and have limited vocabulary. The real analysis of the application semantics for the IoT moving
challenge is to reduce the semantic data for the limited towards the IoT convergence. IJWGS 10, 2/3, 244–260.
capabilities. The micro-ontology must be still recognizable and DOI=10.1504/IJWGS.2014.060260.
the support for RDF included. [6] Jennings C., Shelby Z., Arkko J. 2015. Media Types for
Sensor Markup Language (SENML).
[7] Rahman, A. and Dijk, E. 2014. Group Communication for
5. CONCLUSION AND FUTURE WORK the Constrained Application Protocol (CoAP). RFC 7390,
This paper shows the feasibility of the concept. The constrained October 2014. DOI=10.17487/RFC7390.
devices like sensors are context-aware because they have a certain [8] Shelby, Z. 2012. Constrained RESTful Environments
purpose or task i.e. measure the temperature in degree Celsius and (CoRE) Link Format. RFC 6690, August 2012.
share it with other devices. This is their context. They only need DOI=10.17487/RFC6690.
to know their own micro-ontology and the namespace of the top- [9] Shelby, Z., Hartke, K., and Bormann, C. 2014. The
level ontology. Constrained Application Protocol (CoAP). RFC 7252, June
The micro-ontology is a subset of the top-level ontology. As there 2014. DOI=10.17487/RFC7252.
are more capable devices like smartphones participating in data [10] Stanford-Clark A., Truong H. L. 2013. MQTT For Sensor
exchange, they have knowledge about the top-level ontology and Networks (MQTT-SN). Protocol Specification, Version 1.2.
can process the data. In our scenario the top-level ontology is [11] Wang, W., De, S., Cassar, G., and Moessner, K. 2013.
about environment, and the micro-ontology is about the Knowledge Representation in the Internet of Things:
temperature. Semantic Modelling and its Applications. Automatika
Journal 54, 4, 388–400. DOI=10.7305/automatika.54-
The semantic data should be described in a standardized way i.e. 4.414.
by RDF or JSON-LD. The Turtle representation of data is more [12] Zhang X., Zhao Y., Liu W. 2015. Transforming Sensor
compact then other RDF formats. The length of a message is Data to RDF based on SSN Ontology. Advanced Science
limited. The challenge is to reduce the overhead caused by and Technology Letters 2015, 81, 95–98.
semantic description. This can be done by splitting the Turtle in DOI=10.14257/astl.2015.81.20.
prefixes definition and the triples themselves. Assuming the more
capable device knows the prefixes we transport only the triples.
We took a closer look at three M2M protocols: MQTT, MQTT-
SN and CoAP. We applied the principles above. Every protocol
follows another architecture paradigm or has a different intension
in sense of nodes or networks. Anyway we could apply our
principles to them all. 5
https://www.w3.org/community/rsp/
6
http://www.w3.org/WoT/
62