Semantics and the Internet of Things

David Janes@dpjanes

davidjanes@iotdb.orghttp://iotdb.org/social/imadeit/

January 2016

Introduction

Why Semantics?

• Inter-stack Interoperability

• In use today

• …but can be improved

• Can be used for control

• Fits with REST (and HATEOAS) Model

Actuators

• How do I tell something “turn on”

• I don’t care how it does it, just that that it does it

• the concept of "turn on" is basically universal / standard independent

Sensors

• What does { t: 24.0 } mean?

Learning from the Web

• The Web works

• Use URIs

• Use REST

• Use JSON (-like data)

Classes v Composition

• Composition is better!

• Things do what they say they do

• Things are what they say they are

Goals

• Simplicity!

• Understandability!

• Orthogonality!

Semantics Today

CoAP / LWM2M

• RFC 6690 rt

• e.g. temperature could be http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature

Shortcomings

• We want to be able to easily create specify more powerful semantics

• e.g. max temperature, what is being measured, etc.

• We want to use semantics for control too

Proposed Model

N.B.

• We are leaving out some details to keep this high level

Key concept: Bands

• Bands are JSON-like dictionaries

• Bands have a URI

• Bands fully elucidate Things:

• A Thing has multiple bands: model, istate, ostate, meta, …

• think as: a Thing is a collection of bands

• each band can be manipulated RESTfully

• orthogonal

Assertion

• Everything we need to create Interoperability can be done well with this model

• Based on URIs / API / REST / JSON - i.e. how we program the Internet today

Bands

• JSON-like dictionaries

• Referenced by URIs

• Manipulate in a “web standard” way

• URI (from id and band)

• PUT / PATCH / GET

band: istate

• The “input” (toward me) state

• The actual state of the Thing

• e.g. "the light is on", "the light is off"

band: ostate

• The “output” state (toward the Thing)

• What we want the state to become

• e.g. "turn the light on", "turn the light off"

band: model

• describes terms used in istate and ostate

• "secret sauce" / HATEOAS terms

• JSON-LD

• composition not classes

Light Thing

A brief interruption

• we follow with a simple example

• we use a "little language" called IoTQL to write models

• it compiles to JSON-LD, which is what is actually in the model band

• used for brevity!

Light example

• A simple light which can be turned on / off

• it's currently on

• we're currently not changing anything

• note "o", the dictionary key used

Live Example

• http://homestar.io:20000/api/things

• coap://184.107.137.234:22001/ts

• mqtt://184.107.137.235:20001

Semantics

• e.g. the concept of "turning on / off" is: iot-purpose:on

• https://iotdb.org/pub/iot-purpose#on

• unconstrained "infinite" vocabulary

IoTQL model

CREATE MODEL Light WITH schema:name = "Light", iot:facet = iot-facet:lighting ATTRIBUTE "o" WITH schema:name = "on", iot:purpose = iot-purpose:on, iot:type = iot:type.boolean ;

JSON-LD model{ "@type": "iot:Model", "schema:name": "Light", "iot:facet": [ "iot-facet:lighting" ], "iot:attribute": [ { "@type": "iot:Attribute", "@id": "#o", "schema:name": "on", "iot:purpose": "iot-purpose:on", "iot:type": "iot:type.boolean", "iot:read": true, "iot:write": true, "iot:sensor": true, "iot:actuator": true } ] }

JSON istate

{ "o": true }

JSON ostate

{ "o": null }

How it works

Step 1

• the user "says" turn on the light

• as code, e.g: { "iot-purpose:on": true }

Step II

• Look in the model for

• an iot:Attribute

• with iot:purpose = iot-purpose:on

JSON-LD model{ "@type": "iot:Model", "schema:name": "Light", "iot:facet": [ "iot-facet:lighting" ], "iot:attribute": [ { "@type": "iot:Attribute", "@id": "#o", "schema:name": "on", "iot:purpose": "iot-purpose:on", "iot:type": "iot:type.boolean", "iot:read": true, "iot:write": true, "iot:sensor": true, "iot:actuator": true } ] }

Step III

• Look in the iot:Attribute found

• look at the "@id"

• this will tell us what to manipulate

• in this case "o"

JSON ostate

{ "o": null }

Step IV

• Change the ostate band in the usual RESTful way

• e.g. PATCH { "o": true }

Step V

• Actually turn on the light

• It's an implementation detail

• we don't care if it's a WeMo, a Hue, a LIFX, a homemade Arduino Light, …

Additional Notes

why istate / ostate?

• we need to know when things are transitioning - the interstitial state.

• we often want to use the same terms, e.g. "o" to describe both reading and writing

• it's a modelling concept, Things can "actually" do their own whatever

why complicated attributes?

• consider measuring temperature

• we may also need to describe:

• the units (celsius, fahrenheit), what is being measured, the accuracy, the minimum, the maximum, &c

Reference Implementation

Semantics

• https://iotdb.org/pub

• iot: core definitions

• iot-purpose: sensor and actuators

• iot-unit: units of measure

• iot-facet: facets (what does it do)

• https://github.com/dpjanes/iotdb-vocabulary

IOTDB

• https://homestar.io/about

• https://github.com/dpjanes/iotdb-homestar

• complete reference implementation

• https://github.com/dpjanes/homestar-coap/tree/master/docs/plugfest

Code

• https://github.com/dpjanes/node-iotdb

• https://github.com/dpjanes/iotdb-iotql

• (and many more)

Get in touch! David Janes

@dpjanesdavidjanes@iotdb.org

http://iotdb.org/social/imadeit/