This document proposes a semantic model for the Internet of Things (IoT) using bands, which are JSON-like dictionaries referenced by URIs. A Thing is represented as a collection of bands like istate (input state), ostate (output state), and model. The model band describes terms used in istate and ostate. This semantic model allows for interoperability and control of Things using RESTful manipulation of bands. An example is given of a simple light that can be turned on or off by changing the value of the "o" attribute in the ostate band as specified by its model.

1. Semantics and the
Internet of Things

2. David Janes
@dpjanes
davidjanes@iotdb.org
http://iotdb.org/social/imadeit/
January 2016

3. Introduction

4. Why Semantics?
• Inter-stack Interoperability
• In use today
• …but can be improved
• Can be used for control
• Fits with REST (and HATEOAS) Model

5. 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

6. Sensors
• What does { t: 24.0 } mean?

7. Learning from the Web
• The Web works
• Use URIs
• Use REST
• Use JSON (-like data)

8. Classes v Composition
• Composition is better!
• Things do what they say they do
• Things are what they say they are

9. Goals
• Simplicity!
• Understandability!
• Orthogonality!

10. Semantics Today

11. CoAP / LWM2M
• RFC 6690 rt
• e.g. temperature could be
http://sweet.jpl.nasa.gov/2.0/
phys.owl#Temperature

12. 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

13. Proposed Model

14. N.B.
• We are leaving out some details to keep
this high level

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

17. • think as: a Thing is a collection of bands
• each band can be manipulated RESTfully
• orthogonal

18. 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

19. Bands
• JSON-like dictionaries
• Referenced by URIs
• Manipulate in a “web standard” way
• URI (from id and band)
• PUT / PATCH / GET

20. band: istate
• The “input” (toward me) state
• The actual state of the Thing
• e.g. "the light is on", "the light is off"

21. 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"

22. band: model
• describes terms used in istate and ostate
• "secret sauce" / HATEOAS terms
• JSON-LD
• composition not classes

23. Light Thing

24. 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!

25. 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

26. Live Example
• http://homestar.io:20000/api/things
• coap://184.107.137.234:22001/ts
• mqtt://184.107.137.235:20001

27. Semantics
• e.g. the concept of "turning on / off" is:
iot-purpose:on
• https://iotdb.org/pub/iot-purpose#on
• unconstrained "infinite" vocabulary

28. 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
;

29. 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
}
]
}

30. JSON istate
{
"o": true
}

31. JSON ostate
{
"o": null
}

32. How it works

33. Step 1
• the user "says" turn on the light
• as code, e.g:
{
"iot-purpose:on": true
}

34. Step II
• Look in the model for
• an iot:Attribute
• with iot:purpose = iot-purpose:on

35. 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
}
]
}

36. Step III
• Look in the iot:Attribute found
• look at the "@id"
• this will tell us what to manipulate
• in this case "o"

37. JSON ostate
{
"o": null
}

38. Step IV
• Change the ostate band in the usual
RESTful way
• e.g. PATCH { "o": true }

39. StepV
• 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, …

40. Additional Notes

41. 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

42. 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

43. Reference
Implementation

44. 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

45. IOTDB
• https://homestar.io/about
• https://github.com/dpjanes/iotdb-homestar
• complete reference implementation
• https://github.com/dpjanes/homestar-coap/tree/
master/docs/plugfest

46. Code
• https://github.com/dpjanes/node-iotdb
• https://github.com/dpjanes/iotdb-iotql
• (and many more)

47. Get in touch!
David Janes
@dpjanes
davidjanes@iotdb.org
http://iotdb.org/social/imadeit/