AP breakouts Montreal F2F 2016

From Web of Things Interest Group
Jump to: navigation, search


Resource Patterns:

  • Property
    • e.g. Measured Temperature, Color state
    • - suggestion: GET / PUT a resource
  • Collection
    • e.g. a group of properties, config values, GPIO pins, etc.
    • - suggestion: resource pattern like e.g. core interfaces collections
  • Action
    • e.g. dimming of a light, brewing coffee, runing a dishwasher program
    • POST to an action resource
    • - suggestion: for long running actions: sub-resource for execution tracking (GET/PUT/DELETE)
  • Event
    • e.g. doorbell, current power cosumption, it starts to rain
    • - suggestion: resource that updates the state and keeps at least the last knwon state
  • Subscription
    • e.g. subscribe to an event, the update of a value or the execution of an action
    • - suggestion: resources to manage subscriptions, e.g. like [RestHooks](http://resthooks.org/docs/)
  • Binding
    • e.g. on/off property of lightswitch and lightbulb, temperature of sensor and input of HVAC
    • - suggestion: "bind" or "connect" to interactions together on the thing level, protocol binding specifies how to synchronize the state

Abstract Messages / Schema of the thing-models:

  • Actions: calling, state
  • Lifetime: registering
  • Event Notifications
  • Subscribing
  • Binding a resource to another resource
  • Metadata as opposed to payload data model

Scripting APIs:

  • Consuming Things
    • Factories:
      • Discovery
      • Thing description
      • Proxying another thing
      • Local
    • Interaction
      • subscribing
      • calling actions
      • read/write properties
  • Exposing things
    • Factories:
      • Thing description
      • Programmatically creating a thing
      • Proxying another thing
    • Interaction
      • event handling
      • spontaneous

Error conditions:

  • abstract list of error conditions
    • can be mapped to protocols
    • can be used by APIs
  • integrity constraints
    • what expectations can we put on the interactions/messages

Architecture Model:

  • Dataflow of Plugfest demos as a base for the required messages (e.g. event description level)
  • Deployment views


AP & DI:

Deployment scenarios:

  • A) Single-Thing WoT Server on device directly controlled by WoT client in local network
  • B) in addition to (A), also discovery and control from remote (through internet)
  • C) Home hub is a servient that is a local proxy of electronic devices, and is accessed like A/B. Discovery between hub and devices is local.
  • D1) Shadow is a servient acting as a remote proxy (e.g. on the cloud), discovery of shadow is remote
  • D2) Both shadow and hub to enable local discovery for the hub and remote access and discovery via the shadow
  • D3) industry case: local servients abstract industrial protocols, accessed or proxied by local clients.
  • D4) Car gateway providing WoT server inteface to car-specific interfaces, accessed remotely
  • E) Servient-to-Servient interaction, client/server roles for interaction determined by appliation. Variation of scenarios A-D.


  • need a building block: how to create and sync virtual instances / shadows of a thing?
  • need to investigate how these servients find each other

Interactions for discovery:

  • local
    • be discoverable
    • discover
  • remote
    • be discoverable
    • discover

API primitives:

discovering is covered by current practises Registering/Advertising need to be specified

Factory functions for thing object:


  • Structure for scenarios out of the Contributions of Fujitsu and DI
  • API primitives for the "Registering/Advertising" part of the discovery
  • Define Lifecycle for Proxies / virtual shadows
  • Possible Plugfest proposal: have an example script using client/physical API, check interoperability