Semantic IoT Semantic Inter-Operability Practices - Part 2
Upcoming SlideShare
Loading in...5
×
 

Semantic IoT Semantic Inter-Operability Practices - Part 2

on

  • 258 views

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

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

Statistics

Views

Total Views
258
Views on SlideShare
258
Embed Views
0

Actions

Likes
3
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Semantic IoT Semantic Inter-Operability Practices - Part 2 Semantic IoT Semantic Inter-Operability Practices - Part 2 Presentation Transcript

  • 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;
  • 8Linked Sensor 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
  • 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
  • Input and Output Parameters A very important part of any semanticallyannotated service description. Used by:Discovery Engines.Semantic Matchmakers.Composition Engines.Compensation Engines.
  • Importance of Service Parameters
  • Describing Service Parameters
  • 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 Projecthttp://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
  • 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
  • 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) ?
  • Thank you