IoT as a poor man's version of the semantic web by Antonio Almeida

Transcript

1. IoT as a poor man’s version of the semantic web Riga Dev Day 2016 Antonio Almeida developer & product evangelist at relayr antonio@relayr.io March 3, 2016
2. ounce upon a time there was the Semantic Web - circa 2005 the dream was to make machines understand context: a thing we humans are pretty good at infering the promise of Machine to Machine (M2M) communication with semantics machines would be able to reason about the messages being exchanged and ideally act on them
3. the vision The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. Tim Berners-Lee
4. making the dream come true I define ontologies based on frame modeling of the world - AI concept from the 1970s (Marvin Minsky, 1974) A frame is an artificial intelligence data structure used to divide knowledge into substructures by representing stereotyped situations. marking up each web page with a description language that conceptualizes everything as frames
5. making the dream come true II use ontologies that define the domain in terms of frames ontologies are like class hierarchies in OOP
6. making the dream come true III
7. making the dream come true IV if you markup an existing page with RDF/XML - Resource Description Framework and you setup Content Negotiation in your server so that it can deliver multiple resources depending on the Accept header of the client smart machines would request the RDF version always
8. making the dream come true V
9. the dream was never realized I too complicated, too academic, too much of an hassle ontologies aren’t reliable - people lie easy to trick the system - metadata as a spammer wet dream and I haven’t talked yet about things like SPARQL Protocol and RDF Query Language (SPARQL) SQL inspired query language to question resources (e.g., pages) and make inferences from it
10. the dream failed miserably
11. meanwhile in a parallel universe the smartphone revolution started happening - circa 2007 each phone comes with a lot of sensors gyroscope accelerometer GPS WiFi location - using geoIP sensors became cheap and abundant what if …
12. the dream rises I
13. the dream rises II sensors are for machines sensing the world around them so if sensors are internal to machines then we just need to markup each of them also sensors are coming online now no need to retrofit existing resources
14. the dream rises III
15. intermission to be continued …
16. commercials I relayr is a company that focuses on the great chain of APIs as the IoT enabler: we’re basically a software company we approach IoT end-to-end: from sensors to data analysis
17. commercials II from the sensors ...
18. commercials III ... to the data analysis
19. commercials IV many protocols are used: MQTT, CoAP, HTTP, WebSockets, &c the modern protocols are open and fully standardized — APIs are built upon them that’s where the value comes from: munging the data streamed via those APIs currently we support MQTT, HTTP and WebSockets - CoAP is coming later this year
20. commercials V IoT usually lingers almost to the exclusion of everything else in hardware on the other hand hardware is becoming a commodity hardware is but a tool: it’s what you craft with this tool that matters
21. commercials VI our SaaS offering is so new that we don’t have any pricing yet defined but relax: there will always be a free tier so start prototyping right now we focus on making it easy for you to get up and running your prototype ASAP we have security in mind also: WSS, HTTPS and MQTT over TLS
22. demo time I your smartphone as an IoT device
23. back to the main programme picking up the thread where we left it before the intermission
24. metadata for sensors I: readings when we sense a physical phenomenon we can define meanings for that data stream e.g., meaning temperature, meaning humidity, meaning acceleration, etc and we can distinguish multiple sensors with the same meaning by using an additional metadata field
25. metadata for sensors II
26. metadata for sensors III: readings example { "path" : "" , "meaning" : "temperature" , "valueSchema" : { "type" : "number" , "unit" : "celsius" , "maximum" : 100, "minimum" : −100 } , "template" : "temperature" } we’re reading a temperature
27. metadata for sensors IV: explanation our ontology (kind of) uses http://json-schema.org/JSON Schema like XML schemas but with JSON JSON means data == code: always nice to have web friendly format also
28. metadata for sensors V: commands although MQTT is pub-sub, hence no request-response we can fake it CoAP is a better protocol IMHO, it has both request-response and pub-sub - but is very recent IETF standard last year only how to mock request-response, i.e., commands in MQTT with JSON Schema
29. metadata for sensors VI: commands example "commands" : [ { "name" : "cmd" , "path" : "led" , "valueSchema" : { "type" : "integer" , "maximum" : 1 , "minimum" : 0 } } , ] we turn on/off a led
30. metadata for sensors VII: configurations we can even add configurations, e.g., the sampling frequency of a given physical unit let’s see how that works with our JSON Schema
31. metadata for sensors VIII: configurations example "configurations" : [ { "name" : "frequency" , "path" : "/" , "valueSchema" : { "type" : "integer" , "unit" : "milliseconds" , "minimum" : 200 } } ] we do 5 readings per minute
32. demo time II your smartphone as an IoT device with everything - readings, commands and configurations (not)
33. conclusion using metadata judiciously you can make your IoT (M2M) setup smart. i.e., context aware this is very cool and useful so in conclusion: IoT delivers a poor man’s version of the semantic web
34. I rest my case
35. resources come and test our IoT platform help us make it better while realizing your IoT projects relayr cloud: http://dev.relayr.io me: @perusio myself: antonio@relayr.io
36. thank you