We showcase an approach to use workflows for composing applications from components with Linked Data interfaces. Our approach consists in an ontology and corresponding operational semantics. We use the ontology to describe workflow models and workflow instances in Linked Data. To execute workflows, we developed operational semantics for the ontology using ASM4LD, a rule-based language for specifying computation in the context of Read-Write Linked Data. For our interactive showcase, we use as components: (1) networked devices with sensors and actuators from the Internet of Things / Web of Things, and (2) APIs from the Web that produce and consume RDF.
The increasing distribution of information systems into decentralised
components poses new challenges for integration. Consider, e. g. the increasing amount
of devices on the Internet of Things (IoT) caused by the widespread availability
of cheap networked hardware3, the modularisation of software into microservices
caused by the need for component re-use in rapidly changing business
environments [
Besides components with interfaces made for integration, we need a way to
compose applications from the components. Workflows are a way to create
applications that is highly suitable for intergration scenarios [
how-the-new-hardware-movement-is-even-bigger-than-the-iot/
4 “Putting Data back into the Hands of Owners”, http://tcrn.ch/2i8h7gp
a corresponding workflow language with operational semantics [
The lack of event data in REST HTTP supports the CRUD operations
(create, read, update, delete), but not the subscription to events. However, works
in workflow management traditionally use events as notifications of change.
We elaborate in our paper “Specifying, Monitoring, and Executing Workflows
in Linked Data Environments” [
The contribution of this demo is a working system in the form of an interactive demo5 of WiLD, which brings workflow-based composition to Linked Databased components, e. g. on the Web of Things. In contrast to rule-based composition typically found in IoT-based home automation scenarios, workflow-based composition allows to specify compositions that require a notion of application state. While the demo scenario is fairly small and the selection of components may seem a bit made-up, we present an analogy of the demo scenario to a more serious scenario of a digitised work environment in the conclusion. 2
Unlike in other works around semantics, REST, and services, we do not study
how to derive compositions from descriptions, e. g. using a planner or proof
mechanism, but study the enactment of compositions. In other words, we study how
to execute a composition, be it generated automatically or manually, as for this
paper. For instance, in Semantic Web Services, on the Web of Things, or when
using RESTdesc [
Unlike in Web Services, which are based on a model of computation where
service calls are first-class citizens, we work with REST, where state information
is the first-class citizen. Pautasso proposes an extension to BPEL [
Ask for darkness
Wait for darkness
Ask about the weather
Wait for
answer
give bad
comment
Correct
Wrong
give good
comment
end
computation that is built for state information. Similarly, scientific workflows,
another approach to bridge semantic technologies and workflows, work on
different models of computation, e. g. pipe-and-filter, or function calls [
In a previous demo, we showed rule-based composition [
Visitors to our booth open their smartphone and find our WiFi network. They connect and are directed to our registration form where they register their name and home town. By registering, visitors create a workflow instance in a LDP container. The instance is immediately executed and guides the visitor in the following manner: At the first station, visitors are asked using a loudspeaker connected to an IoT device to make it dark by covering another IoT device’s light sensor. The request for darkness shall get the visitors closer to the devices and familiarise them with the interactive scenario. Again using the loudspeaker, the system thanks the visitor, and next asks the visitor how the weather is at home. The visitors answer by placing a RFID card on RFID sensors, that correspond to nice / not so nice ( / ), connected to another IoT device. Next, the system evaluates the answer live using a weather API from the web and gives a comment to the visitor, again using the loudspeaker. The underlying workflow that our demo system executes is sketched in Fig. 1. 4
The demo consists of multiple IoT devices, all exposing data and functionality on
a (Read-Write) Linked Data interface: RFID readers, a light sensor, and a
loudspeaker. The devices are built using off-the-shelf IoT components such as Tessel
26. In terms of Web APIs, we use interfaces to Weather Underground, a weather
data service, and a registration form. We describe the workflow model for the
system as Linked Data using WiLD7, the ontology for our workflow language,
and put the workflow model in an LDP Container. Moreover, we maintain
workflow instances in the same LDP container. To execute the workflow instances, we
deploy the operational semantics for the workflow language [
Weather Underground Wrapper Tessel 2 with Light Sensor
LDP-Server w/ WiLD Workflow models and instances
Tessel 2 with Loudspeaker
Station is the weather nice?
Tessel 2 with 2 RFID readers
Linked Data-Fu w/ WiLD operational
semantics
We presented our approach to use workflows to compose components that expose Linked Data interfaces to an integrated application. Thus, our approach allows to do composition in the context of the fundamental technologies of the Web of Things. For the composition, we use a workflow language for Linked Data with a formal grounding. The formal grounding allows to apply formal techniques for workflow analysis, e. g. for liveness and deadlock properties. While the demo looks somewhat made-up, our approach allows to build serious applications: For instance, an assistance system for workers that work in an digitised environment: Imagine the loudspeaker as virtual assistant that gives instructions to an order picker. The tracking of the progress of the picker’s work can be done using light and proximity sensors, or RFID sensors on shelf and tray.
Acknowledgements This work is partially supported by the German BMBF in AFAP (FKZ 01IS12051).