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
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)
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
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, …
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
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-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"
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, …
Reference
• IPSO Starter Pack
• https://github.com/IPSO-Alliance/StartHere
• Humidity Sensor
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
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
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
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
http://iotdb.org/social/imadeit/