IOTDB,Semantics and the Internet of Things

David Janes@dpjanes

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

May 2016

Introduction

Core Ideas of IOTDB

• Semantic

• Descriptive v Prescriptive

• Atoms / Composition

• Data "Band" Oriented

• Learn from the web

Semantics

• Focus on the "what" rather than "how"

• e.g. "turn on", not "write 0xFF to 0x3200"

• Use Linked Data (URLs!)

e.g. Actuation

• 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

e.g. Sensors

• What does { t:24.0, h:73 } mean?

Descriptive v Prescriptive

• Not a "standard" but "metastandard"

• Describe how standards work!

• Not "you must do this" but "this is what they did"

Atoms

• Concepts that cannot be meaningfully subdivided

• "sensor" / "actuator"

• "min" / "max" value

• "precision"

• "temperature"

Composition

• Describe by composing Atoms

• e.g. a "temperature sensor" might be composed from:

• "sensor", "temperature", "min", "max", "in celsius", "2 decimal places of precision"

Classes v Composition

• Composition is better!

• Things do what they say they do

• Things are what they say they are

Bands

• Model interactions as manipulating and observing JSON (-like) dictionaries

• Bands capture the role data plays

• istate, ostate (input and output)

• model (semantics)

• meta (slow moving data)

Learning from the Web

• The Web works

• Use URIs

• Use REST

• Use JSON (-like data)

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

Learning from the Web

• The Web works

• Use URIs

• Use REST

• Use JSON (-like data)

Goals

• Simplicity!

• Understandability!

• Orthogonality!

• Expandability!

The IOTDB Way

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, …

IPSO / IOTDBComparison

Reference

• IPSO Starter Pack

• https://github.com/IPSO-Alliance/StartHere

• Humidity Sensor

istate

model

ostate

Potential Serialization?

{ "urn:oma:lwm2m:ext:5700": 20, "urn:oma:lwm2m:ext:5701": "CEL" "urn:oma:lwm2m:ext:5601": 18, "urn:oma:lwm2m:ext:5602": 22, "urn:oma:lwm2m:ext:5603": 0, "urn:oma:lwm2m:ext:5604": 45 }

IOTDB istate

{ "temp": 20, "min": 18, "max": 22, }

Note temp, min, max are not "magic" - defined in model

IOTDB model

CREATE MODEL tsensor WITH ATTRIBUTE temp iot:purpose = iot-purpose:temperature iot:unit = iot-unit:temperature.si.celsius iot:minimum = 0 iot:maximum = 45 WITH ATTRIBUTE min iot:purpose = iot-purpose:temperature.minimum iot:unit = iot-unit:temperature.si.celsius WITH ATTRIBUTE max iot:purpose = iot-purpose:temperature.maximum iot:unit = iot-unit:temperature.si.celsius

IPSO Recommendations /

Take-Aways

Use URLs / Names

• Linked Data could be added to IPSO

• Self Documenting!

• Allows for Mix & Match

• e.g. add QUDT, SAREF, …

• e.g. this "urn:oma:lwm2m:ext:5700" becomes "lwm2m:ext/sensor-value"

lwm2m:ext/sensor-value

• Expands to (some URL)

• Returns a document that explains what this is, including that the magic number "5700" should be used for retrieving this resource

• First Normal Form (avoid duplicated definitions, e.g. in here https://github.com/IPSO-Alliance/StartHere)

Use Semantic Values

• "CEL" is awful

• Suggestions

• iot-unit:temperature.si.celsius

• meteo:celsius

• wikipedia:Celsius

Break out "model"

• Things shouldn't have to "know" what (e.g.) their min / max values are

• Hard to assign a number to everything we might want to know about (e.g. SAREF)

• Instead: "this is my model" attribute

Break out "meta"

• What room is it in?

• What does it do? Is it a heater? A light?

• What's is its name?

• Who made it?

• What is it's model number?

• Add: "this is my meta" attribute

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/