1. 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

2. People want answers, not numbers(Steven Glaser, UC Berkley)Sinknode GatewayCore networke.g. InternetWhat is the temperature at home?Freezing!

3. Turning Data into WisdomDataInformationKnowledgeWisdomRaw sensory dataStructured data (withsemantics)Abstraction and perceptionsActionable 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 andwhat it measuresSinknodeGateway

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. 7Semantics and Linked-data The principles in designing the linked data aredefined as: using URIs as names for things; using HTTP URIs to enable people to look up thosenames; provide useful RDF information related to URIs that arelooked up by machine or people; including RDF statements that link to other URIs toenable discovery of other related concepts of the Webof Data;

8. 8Linked Sensor data

9. 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 dont understand it but caninterpret it. It still does need intelligent processing, reasoning mechanismto process and interpret the data.

10. 10Myth and reality #3: Its 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 dont 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.

11. 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. Whats the relationship between temperature and weather? Easier to provide suggestions to engineers building asemantic description of their sensor.

12. Exercises 1 Open the following ontologies in Protg: 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 semanticallyannotated 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 parametertypes.The Subsumes filter is less usefulthan the other two because when Ais more generic than B, A cannotinteroperate with B in most cases.

18. 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.

19. QUDT Ontology Ontology for Quantities, Units, Dimensions and DataTypes. Developed by TopQuadrant and NASA. Another standardisation effort. Compare with theQU-rec20 ontology.

20. 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.

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 (usingimport in Protg) Consider the following parameter attributes: Data Type Unit of Measure Response Time Location More information also means more overhead.

24. 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 persons modelto check how interoperable they are.

25. Exercise 3: Discussion How interoperable is your model with otherpeoples model? Have you re-used existing structures (for examplefrom the IoT.est service model) ?

26. Thank you