Semantic IoT Semantic Inter-Operability Practices - Part 2
IoT Semantic Inter-Operability EventPart 2: IoT semantic interoperability practicesPresenter: Gilbert CassarCentre for Communication Systems Research, University of SurreyContributors: Dr. Payam Barnaghi, Dr. Martin Serrano, Mr. Phillippe Cousin
“People want answers, not numbers”(Steven Glaser, UC Berkley)Sinknode GatewayCore networke.g. InternetWhat is the temperature at home?Freezing!
Turning Data into WisdomDataInformationKnowledgeWisdomRaw sensory dataStructured data (withsemantics)Abstraction and perceptionsActionable intelligence
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
How to say what a Sensor is andwhat it measuresSinknodeGateway
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
7Semantics and Linked-data The principles in designing the linked data aredefined as: using URI’s as names for things; using HTTP URI’s to enable people to look up thosenames; provide useful RDF information related to URI’s that arelooked up by machine or people; including RDF statements that link to other URI’s toenable discovery of other related concepts of the Webof Data;
9Myth and reality #1: If we create an Ontology our data isinteroperable 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 caninterpret it. It still does need intelligent processing, reasoning mechanismto process and interpret the data.
10Myth and reality #3: It’s a Hype! Ontologies and semantic data aretoo much overhead; we deal with tiny devices in IoT. Reality: Ontologies are a way to share and agree on a common vocabularyand knowledge; at the same time there are machine-interpretable andrepresented in interoperable and re-usable forms; You don’t necessarily need to add semantic metadata in the source- it could beadded 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.
The Importance of Domain Knowledge Created with the help of domain experts. Provides a common understanding of the domain forpeople and machines to refer to. Allows machines to determine the relationshipbetween assertions coming from the same domain. What’s the relationship between ‘temperature’ and ‘weather’? Easier to provide suggestions to engineers building asemantic description of their sensor.
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
Filters Used By Semantic Matchmakers Where A and B are parametertypes.The Subsumes filter is less usefulthan the other two because when Ais more generic than B, A cannotinteroperate with B in most cases.
QU-rec20 Ontology Ontology for Quantity Kinds and Units: units andquantities definitions This ontology imports the qu ontology derived fromthe work done by the SysML 1.2 QUDV workinggroup (see http://purl.oclc.org/NET/ssnx/qu/qu fordetails). Defines a huge variety of dimensions and could beused a common domain for describing the type ofdata measured by a sensor.
QUDT Ontology Ontology for Quantities, Units, Dimensions and DataTypes. Developed by TopQuadrant and NASA. Another standardisation effort. Compare with theQU-rec20 ontology.
QoS/QoI Ontology Created as part of the IoT.est Projecthttp://ict-iotest.eu/iotest/ Contains various definitions for Quality ofService and Quality of Informationattributes that could be used to describe aservice parameter.
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
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.
Exercise 3: Comparing your parametermodel with others’ Copy your parameter description on a usb stick. Transfer it to the Virtual Machine of another person sat at yourtable. 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 modelto check how interoperable they are.
Exercise 3: Discussion How interoperable is your model with otherpeople’s model? Have you re-used existing structures (for examplefrom the IoT.est service model) ?