G. Cassar Semantic IoT Semantic Inter-Operability Practices-Part2 presented at the IERC AC4 IoT Semantic Interoperability workshop, Guildford, UK, 15 April 2013

1. IoT Semantic Inter-Operability Event
Part 2: IoT semantic interoperability practices
Presenter: Gilbert Cassar
Centre for Communication Systems Research, University of Surrey
Contributors: Dr. Payam Barnaghi, Dr. Martin Serrano, Mr. Phillippe Cousin

2.  “People want answers, not numbers”
(Steven Glaser, UC Berkley)
Sink
node Gateway
Core network
e.g. Internet
What is the temperature at home?Freezing!

3. Turning Data into Wisdom
Data
Information
Knowledge
Wisdom
Raw sensory data
Structured data (with
semantics)
Abstraction and perceptions
Actionable intelligence

4. Components Related to Things
 Physical world objects
 e.g. A room, a car, A person;
 Feature of Interest
 e.g. Temperature of the room, Location of the car, heart-
rate of the person;
 Sensors
 e.g. Temperature sensor, GPS, pulse sensor

5. How to say what a Sensor is and
what it measures
Sink
node
Gateway

6. Semantics and IoT Data
 Creating ontologies and defining data models is not enough
 tools to create and annotate data
 data handling components
 Complex models and ontologies look good, but
 design lightweight versions for constrained environments
 think of practical issues
 make it as compatible as possible and/or link it to the other existing ontologies
 Domain knowledge and instances
 Common terms and vocabularies
 Location, unit of measurement, type, theme, …
 Link it to other resources
 Linked-data
 URIs and naming

7. 7
Semantics and Linked-data
 The principles in designing the linked data are
defined as:
 using URI’s as names for things;
 using HTTP URI’s to enable people to look up those
names;
 provide useful RDF information related to URI’s that are
looked up by machine or people;
 including RDF statements that link to other URI’s to
enable discovery of other related concepts of the Web
of Data;

8. 8
Linked Sensor data

9. 9
Myth and reality
 #1: If we create an Ontology our data is
interoperable
 Reality: there are/could be a number of ontologies for a domain
 Ontology mapping
 Reference ontologies
 Standardisation efforts
 #2: Semantic data will make my data machine-
understandable and my system will be intelligent.
 Reality: it is still meta-data, machines don’t understand it but can
interpret it. It still does need intelligent processing, reasoning mechanism
to process and interpret the data.

10. 10
Myth and reality
 #3: It’s a Hype! Ontologies and semantic data are
too much overhead; we deal with tiny devices in IoT.
 Reality: Ontologies are a way to share and agree on a common vocabulary
and knowledge; at the same time there are machine-interpretable and
represented in interoperable and re-usable forms;
 You don’t necessarily need to add semantic metadata in the source- it could be
added to the data at a later stage (e.g. in a gateway);
 Legacy applications can ignore it or to be extended to work with it.

11. The Importance of Domain Knowledge
 Created with the help of domain experts.
 Provides a common understanding of the domain for
people and machines to refer to.
 Allows machines to determine the relationship
between assertions coming from the same domain.
 What’s the relationship between ‘temperature’ and ‘weather’?
 Easier to provide suggestions to engineers building a
semantic description of their sensor.

12. Exercises 1
 Open the following ontologies in Protégé:
 Quantity and Dimensions ontologies:
 http://purl.oclc.org/NET/ssnx/qu/qu
 http://purl.oclc.org/NET/ssnx/qu/qu-rec20
 Units ontology:
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/Units.owl
 http://qudt.org/1.1/schema/dimension

13. Exercise 1
 Quantity and Dimensions ontologies:
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/SUMO.owl
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/Mid-level-ontology.owl
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/books.owl
 Qos/QoI Ontology:
 http://ict-iotest.eu/iotest/ontologies/v1.0/IoT.est-QoSQoI.owl

14. Input and Output Parameters
 A very important part of any semantically
annotated service description.
 Used by:
Discovery Engines.
Semantic Matchmakers.
Composition Engines.
Compensation Engines.

15. Importance of Service Parameters

16. Describing Service Parameters

17. Filters Used By Semantic Matchmakers
 Where A and B are parameter
types.
The Subsumes filter is less useful
than the other two because when A
is more generic than B, A cannot
interoperate with B in most cases.

18. QU-rec20 Ontology
 Ontology for Quantity Kinds and Units: units and
quantities definitions
 This ontology imports the qu ontology derived from
the work done by the SysML 1.2 QUDV working
group (see http://purl.oclc.org/NET/ssnx/qu/qu for
details).
 Defines a huge variety of dimensions and could be
used a common domain for describing the type of
data measured by a sensor.

19. QUDT Ontology
 Ontology for Quantities, Units, Dimensions and Data
Types.
 Developed by TopQuadrant and NASA.
 Another standardisation effort. Compare with the
QU-rec20 ontology.

20. QoS/QoI Ontology
 Created as part of the IoT.est Project
http://ict-iotest.eu/iotest/
 Contains various definitions for Quality of
Service and Quality of Information
attributes that could be used to describe a
service parameter.

21. Useful Domain Ontologies
 Quantity and Dimensions ontologies:
 http://purl.oclc.org/NET/ssnx/qu/qu
 http://purl.oclc.org/NET/ssnx/qu/qu-rec20
 Units ontology:
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/Units.owl
 http://qudt.org/1.1/schema/dimension

22. Useful Domain Ontologies
 Quantity and Dimensions ontologies:
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/SUMO.owl
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/Mid-level-ontology.owl
 http://localhost:8080/InteropOntologyMatchingTool/Ontos/books.owl
 Qos/QoI Ontology:
 http://ict-iotest.eu/iotest/ontologies/v1.0/IoT.est-QoSQoI.owl

23. Exercises 2: create a parameter ontology
 Considering reuse of the existing ontologies (using
‘import’ in Protégé)
 Consider the following parameter attributes:
 Data Type
 Unit of Measure
 Response Time
 Location
 More information also means more overhead.

24. Exercise 3: Comparing your parameter
model with others’
 Copy your parameter description on a usb stick.
 Transfer it to the Virtual Machine of another person sat at your
table.
 Save it in the folder:
 Home/apache/apache-tomcat-6.0.36/webapps/docs/ontology/
 The URL of your model should now be:
 http://localhost:8080/InteropOntologyCheckingTool/docs/ontology/yourontology.owl
 Use the Interoperability tool at:
 http://localhost:8080/InteropOntologyCheckingTool/
 Compare your parameter model to the other person’s model
to check how interoperable they are.

25. Exercise 3: Discussion
 How interoperable is your model with other
people’s model?
 Have you re-used existing structures (for example
from the IoT.est service model) ?

26. Thank you