class: center, frontpage .frontcontent[ # Reusing Web-enabled Actuators from a Semantic Space-based Perspective ##
Aitor Gómez Goiri
, Iñigo Goiri, Diego López-de-Ipiña .date[July 2, 2014] ] ??? Hello to everyone. My name is... I come from the univ... to present the paper I made together with Iñigo and Diego entitled... --- # Outline 1 - Introduction 2 - Baseline actuation techniques 3 - Comparison 4 - Hybrid actuation 5 - Conclusions --- class: center, middle # Introduction --- # Background .subtitle[ ## Introduction ]
??? So let's start from the beginning. At the beginning, there were few computers in the Internet. Maybe too beginning. --- # Background .subtitle[ ## Introduction ]
??? Then, the __popularity__ of the Internet increased and connecting computers became __easier and cheaper__. Consequently, __more and more__ computers got connected. --- # Background .subtitle[ ## Introduction ]
??? Thanks to __wireless__ technologies, devices started accessing to the Internet without having to be physically connected to a network. --- # Background .subtitle[ ## Introduction ]
??? So the __mobile computing__ appeared. --- # Background .subtitle[ ## Introduction ]
??? Nowadays, __not only__ a wider range of smartphones, but also everyday objects like cars or washing machines connect to the Internet to exchange information. This is what __is know as__ the Internet of Things (IoT). Both IoT and the mobile computing have contributed to the __Ubicomp__ idea. --- # Heterogeneity challenge .subtitle[ ## Introduction ]
??? So, as we saw in the previous slide, nowadays, we have __heterogeneous__ devices running on top of heterogeneous applications. This means that the __interoperability__ is a key property for these environments. --- # Interoperability .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines __interoperability__ as > The ability of two or more systems or components to __exchange__ information > and to __use__ the information that has been exchanged. ??? The [AI] triple [I] defines... --- # Interoperability .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines __interoperability__ as > .weak[The ability of two or more systems or components to _exchange_ information > and to __use__ the information that has been exchanged.] ??? So, let's first talk about the second problem: how to use (or reuse) information. --- # Interoperability: use info .subtitle[ ## Introduction > Heterogeneity ]
??? We can identify two levels to allow this __use__: 1. The __syntactic__ level, which cares about the format of the data (i.e. its syntax and encoding) * For instance, if the robot does not undestand chinese characters, the information the mobile phone provides will be useless. 1. The __semantic__ level gives a precise meaning to the information... * _"understandable by any other application that was not initially developed for this purpose"_ * Following the example, this character may mean different things depending on the context. --- # Interoperability: use info (solution) .subtitle[ ## Introduction > Heterogeneity ]
??? To achieve both levels, we propose to use __Semantic Web__ standards and tools. The vision of the Semantic Web is to __extend__ principles of the __Web from documents to data__. It __relates terms__to one another, so they can be shared and reused across applications. This terms can be __processed automatically__ revealing __new relationships__ among the data. > .weak[The __vision__ of the Semantic Web is to extend principles of the Web from documents to data. > Data should be accessed using the general Web architecture using, e.g., URI-s; > data should be __related to one another__ just as documents (or portions of documents) are already. > This also means creation of a common framework that allows data > to be __shared and reused__ across application, enterprise, and community boundaries, > to be __processed automatically__ by tools as well as manually, > including revealing possible __new relationships__ among pieces of data.] --- # Interoperability: exchange info .subtitle[ ## Introduction > Heterogeneity ] The [IEEE](http://ieeexplore.ieee.org/servlet/opac?punumber=2238) defines _interoperability_ as > .weak[The ability of two or more systems or components to __exchange__ information > and to _use_ the information that has been exchanged.] ??? The other aspect which affects the interoperability is __how to exchange information__. Rather than focusing on __low-level__ communication protocols, this paper analyses __more general__ communication strategies. --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? The first way is the web. The web is massively accepted * By humans * But also, by machines: a lot of applications expose their capabilities using HTTP APIs __REST__ architectural style comprises the design principles of _the modern web_ --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? It achieves the following properties (see Fielding's thesis) * Scalability * Simplicity * Portability * etc. Note that most of these properties are particularly useful for limited devices. --- # Exchange info 1: the Web .subtitle[ ## Introduction > Heterogeneity ]
??? As a consequence, the web has been widely applied to IoT, bringing what people has called the __Web of Things__ (WoT). In the WoT, everyday things expose their capabilities through web standards. This way, they are first-class web citizens and can seamlessly work with other web apps. --- # Exchange info 2: Tuple Spaces .subtitle[ ## Introduction > Heterogeneity ]
??? A second way to exchange info is space-based computing (or Tuple Spaces). Tuple Spaces is a paradigm where nodes coordinate with each other by writing and reading structured pieces of information (i.e., tuples) in a shared space. --- # Exchange info 2: Tuple Spaces .subtitle[ ## Introduction > Heterogeneity ]
??? This paradigm can be uncoupled in space and in time. * _Space uncoupling_ is achieved because the nodes __don't need to know each other beforehand to communicate__. * _Time uncoupling_ is achieved because two nodes communicating with each other __do not need to coexist at the same time__. --- class: center, middle # Baseline actuation techniques ## How to make a change in the environment? ### (2/5) --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? To solve this question I first examined the common Tuple Spaces' usage patterns. For sake of brevity, I will present just two of them. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? The first one is the __replicated-worker pattern__. In this pattern, there is a master process and many worker processes able to compute the same task. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? First, the master takes a problem, divides it into smaller tasks, and --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? writes these tasks into the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? Then, any available worker takes a task, --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? processes it, --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? and writes the result back into the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? As the workers write their results, the master takes these results from the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? When the master has collected all the results, it combines them into a meaningful merged solution. This pattern is scalable and naturally balances the load on the space. --- # Patterns for Tuple Spaces .subtitle[ ## Baseline actuation techniques ]
??? The second pattern in the __specialist pattern__. It can be seen as a variation of the previous one. The difference is that in this pattern each __worker is specialized__ and knows how to make a particular task. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? We can __translate__ the previous patterns to our domain. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? For instance, a smartphone may write the "__turn the fan on__" __task__ into the space. --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? A smart-fan which belongs to the same space, will then take the task, --- # Patterns for Tuple Spaces in UbiComp .subtitle[ ## Baseline actuation techniques ]
??? process it and as a result __activate the blades__. Then, it may __write a result__ in the space that the "activator node" will read. For example, with information about when it was turned on. .weak[This approach has been widely applied in the literature. In the past, this idea evolved into service-oriented engines. The task-types where described through services and task through _service invocations_.] --- # HTTP API .subtitle[ ## Baseline actuation techniques ]
```http POST /blades HTTP/1.1 Host: smartfan.eu true ``` ??? However, the more I read about __WoT__, the more I liked its simplicity. For example, for the fan, we could simply make a HTTP POST request to the smart-fan. Unfortunately, like most of the resource-oriented API, this per-se would __not__ be __REST-compliant__. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? To make the API hypermedia-driven, the application has to describe * the current state and * the transitions to the next ones. This way, the client can __select__ the __next state__ of the application through __hypermedia__. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? When the __client is a human__, it's easy for him to interpret the HTML content and decide __which link__ to follow or which __button__ to press. --- # REST/Hypermedia-driven HTTP API .subtitle[ ## Baseline actuation techniques ]
??? However, doing this automatically (__without human intervention__) is currently a __hot research topic__. Some solutions propose to use the __semantic__ web to __describe__ these __applications and__ state __transitions__. In this paper, we used a solution called __RESTdesc__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? RESTdesc describes HTTP methods using __rules expressed in the Notation 3__ language (or N3). In the figure, we can see a description for a HTTP __GET__ method. It explains __how to obtain a light measure__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? A rule’s __premise__ expresses the __requirements__ to make an state __transition__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? A rule’s __conclusion__ expresses both * the HTTP call that needs to be made and... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? ...the description of what we can __expect as a result__ of the request. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ] ```http OPTIONS /deustotech/lights HTTP/1.1 Host: deusto.eu ``` ```http HTTP/1.0 200 OK Date: Sat, 14 Jun 2014 21:22:01 GMT Content-type: text/n3; charset=UTF-8 Content-Length: 512 { actuators:light ssn:madeObservation ?light_obs . } => { _:request http:methodName "GET" ; http:requestURI ?light_obs ; http:resp [ http:body ?light_obs ]. ?light_obs a ssn:Observation ; ssn:observedProperty sweet:Light ; ... ``` ??? These descriptions can be obtained through different mechanisms. We will assume that they are provided in the same resources which it describes. To this end, we can use the __HTTP OPTIONS verb__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? So, when a client has __crawled an API__ collecting several of these descriptions, __what can we do__ with them? IF we also have... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? ... background knowledge expressed with semantics, and... --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? __a goal__, which is an __special rule__ which expresses the __ending state__ we want to reach; --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? THEN we can use a reasoner to make an __execution plan__. Personally, I have used the __EYE reasoner__. --- # RESTdesc .subtitle[ ## Baseline actuation techniques ]
??? This plan indicates different paths to __reach the desired goal__ (or final state). Let's assume that there is only one path (or no path). This path will contain different steps composed by the rules which need to be invoked to obtain a plan. And since these rules are composed by the HTTP requests, we just have to check if we can invoke them. --- # Motivation .subtitle[ ## Baseline actuation techniques ]
??? In short, machines can learn __how to use__ an API __autonomously__ using RESTdesc. That is, RESTdesc becomes APIs hypermedia-driven. The main advantage of an hypermedia-driven __API__ is that it __can change its shape over the time__ and the applications automatically consuming it will not need to be reconfigured or redeveloped. Translating it to the WoT field, it will allow to act __using actuators not known__ at the design or implementation phases. --- class: center, middle # Comparison ### (3/5) --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? The two actuation techniques presented are quite distinct in nature. --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? One promotes the direct communication style, while the other promotes an indirect uncoupled style. .weak[ * Decoupled communication * Reuse of third-party WoT apps ] --- # General properties and requirements .subtitle[ ## Comparison ]
Actuation
Communication style
Benefits
Required features
Space-based
Indirect
Decoupling
Subscriptions
REST-based
Direct
Reuse
Rule-based reasoning
??? We can also see in the table how each of them require additional features: * A subscription mechanism in the case of space-based computing. This mechanism helps nodes __to be aware__ of what is written into the space without constantly polling it. * A reasoner to create a execution plan, --- # Driving scenario .subtitle[ ## Comparison ]
??? To __deepen__ in the comparison, I planned a baseline scenario and __implemented it using both__ mechanisms. The scenario is the "helloworld" of the scenarios: turning on and off a light. However, it __helps to understand__ both actuation mechanisms and test the interoperation ideas. --- # Networking activity .subtitle[ ## Comparison ]
??? After implementing both scenarios, I calculated how the variation in the number of providers (e.g., actuators) could affect these techniques. First, we can see that as the amount of actuators increases, both techniques generate more requests. The __slope__ will __vary depending on the design__ (and implementation) of each solution. In any case, the figure shows that __none__ of the techniques behave in a __scalable__ manner. In the case of space-based actuation, the variation corresponds to the subscription request of each actuator and two additional writings it does. In the case of REST-based actuation the crawler needs to obtain 5 different rules for each actuator. --- # Experimental environment .subtitle[ ## Comparison ]
Platform
Raspberry Pi (model B)
RAM Memory
512 MB
CPU
700 MHz Low Power ARM1176JZ-F Applications Processor
??? To check how much computing resources each techniques requires, I tested them in a Raspberry Pi. Again, the scenario was tested __with 1 to a thousand actuators__. --- # Computing activity .subtitle[ ## Comparison ]
??? In the chart, we see that the amount of actuators affects more severely to __REST__-based actuation. This is due to the to the __reasoning process__ which takes place in the node which generates the plan. In __space__-based actuation, most of the time is spent __checking subscriptions__ at each write. Note that even if the subscription mechanism was unoptimized due to its __prototyping nature__, it made space-based actuation scale much better. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive, limited
Limited
Space
Reactive, high
Varies
REST-based
Provider
Reactive, limited
Limited
Consumer
Proactive, high
Demanding
??? Considering these results and after analysing the characteristics of both techniques, we came out to the following table. It summarizes the strengths and weaknesses of both techniques. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive,
limited
Limited
Space
Reactive, high
Varies
REST-based
Provider
Reactive,limited
Limited
Consumer
Proactive,
high
Demanding
??? From the consumer point of view, the previous charts have already shown its __higher activity__ compared to space-based actuation. --- # Summary .subtitle[ ## Comparison ]
Actuation
Perspective
Activity
Networking
Computation
Space-based
Provider
Proactive, limited
Limited
Consumer
Proactive, limited
Limited
Space
Reactive, high
Varies
REST
-based
Provider
Reactive,
limited
Limited
Consumer
Proactive, high
Demanding
??? The table shows how the __providers in the second__ actuation mechanism are more __lightweight__. That is, they just attend to the request received using HTTP. Probably as a consequence of these few requirements, exposing the actuation capabilities of the limited devices with HTTP is a __consolidated trend__. .weak[This tendency is backed by the WoT initiative.] REST-desc only requires devices to additionally provide their API's resources' descriptions. This can be done before deploying them and does not affect to their usual operation. --- class: center, middle # Hybrid actuation ## Could we seamlessly reuse web actuators from space-based perspective? ### (4/5) ??? So, seeing_these properties, the question I wanted to explore in this paper was: * could __space-based computing take advantage__ of these existing __REST-based actuators__? Reuse lightweight providers and consumers. Furthermore, could this reuse be made in a __seamless way for nodes already following each of these techniques__? --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? With these considerations in mind, I propose a solution which __completely reuses__ the nodes implemented for the previous actuation techniques. In the left hand side, we see a master node from Space-based actuation which writes the "turn light on" task. --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? In the right hand side, we see a smart-bulb light which exposes their actuation capabilities through an HTTP API. --- # Interoperation .subtitle[ ## Hybrid actuation ]
??? This API is __described__ using RESTdesc. In this paper, I propose __not to alter__ the existing nodes. Therefore, the space needs to be extended to make their interoperability possible. --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? And... how is it extended? The __space__ will be responsible of: * Translating a _subscription to a task result_ into a reasoning goal. Considering the how I implemented the subscriptions .weak[(based on SPARQL using RDFLib)], this is a straightforward __syntactic translation__ .weak[(from SPARQL to N3QL for EYE)]. --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? Apart from this, it will be in charge of two tasks performed by the client in REST-based actuation: * __crawl__ APIs to obtain RESTdesc rules and --- # Proposed solution .subtitle[ ## Hybrid actuation ]
??? * __create__ a plan. Note one beneficial aspect: as the process resides in the same machine as the space, it can __locally read__ all the content written into the space. This content is provided as additional knowledge to the reasoning process. This way, we __avoid__ additional costly __networking__ operations (both in bandwidth and in time) to obtain this knowledge. --- # Discussion .subtitle[ ## Hybrid actuation ] 1. Obtaining background knowledge 1. Triggering REST actuation 1. From a _subscription to result_ to goal * More general from task to result. ??? --- class: center, middle # Conclusions --- # Conclusions and Future Work Seamless reuse in simple scenario *
[github.com/gomezgoiri /reusingWebActuatorsFromSemanticSpace](https://github.com/gomezgoiri/reusingWebActuatorsFromSemanticSpace)
Further investigation with more complex scenarios is needed * Is the __translation__ between the subscriptions and the goal always possible? * If the plan has __2 or more paths__ to achieve a goal, which one should we chose? * What if __two different actuators__ from space-based and rest-based actuation can be activated? ??? We presented a solution to... However, the hybrid-actuation technique presented needs further investigation to __ensure its universality__. For example, * Would the translation between the subscriptions and the goal always be possible? .weak[What if the node initiating the change does not subscribe to any result?] * If there are two or more paths to reach a goal, how can we discern which one to follow? .weak[This problem is specific to the REST actuation using REST-desc.] * How does the middleware deal with the coexistence of both mechanisms? When both methods can be applied, which one is triggered? .weak[Which one prevails over the other?] In any case, I analysed actuation in space-based computing from a novel-point of view. From the space-based consumer perspective, I proposed to seamlessly reuse actuators from the WoT. Additionally, what about reusing space-based actuation capabilities from the web? --- class: middle, questionslide # Questions? Aitor Gómez Goiri .breakline[ aitor.gomez (at) [deusto (dot) es](http://www.deusto.es)] ??? With this I conclude my presentation and I am ready to answer the questions and comments you make regarding this dissertation. Thank you very much for listening. --- class: center, middle All rights of images are reserved by the
__original owners__*, the rest of the content is licensed
under a __[Creative Commons by-sa 3.0](http://creativecommons.org/licenses/by-sa/3.0/)__ license.
![Creative commons by-sa 3.0 license logo](img/CC-logo.svg)
\* [leogg](http://openclipart.org/detail/89209/), [rduris](http://openclipart.org/detail/167948/), [williamtheaker](http://openclipart.org/detail/178310/) and [cibo00](http://openclipart.org/detail/14056/). --- class: center, middle # Backup slides --- # Space uncoupling .subtitle[ ## Tuple Spaces ]
??? __Space uncoupling__ is achieved because the nodes don't need to know each other beforehand to communicate. That is, TS' primitives do not care about addresses and references, they just care about the content which is being shared. When the computer writes the circle does not know which one node use this piece of info. --- # Space uncoupling .subtitle[ ## Tuple Spaces ]
??? Similarly, if the umbrella reads a circle, it does not know which one generated this concrete blue circle. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? __Time uncoupling__ is achieved because two nodes communicating with each other do not need to coexist at the same time. For instance, after writing the pentagon... --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? ...the laptop might left the space. For instance, because it run out of battery of it phisically left the room. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? Then, an umbrella might join the space. --- # Time uncoupling .subtitle[ ## Tuple Spaces ]
??? If it ask for a pentagon, it will get the one written by the laptop even if it is not present. Thanks to these uncoupling levels, TS faces dynamism successfully both in the short and in the long term. --- # "Short" or "limited" are relative adjectives .subtitle[ ## Motivation ]
??? The player in the center is Nate Robinson who, compared to any of the remaining NBA players will be considered small. However, he is about 4 cm taller than me, so I wouldn't consider him small. The same thing happens when we speak about _limited devices_. In the context of my dissertation, _limited devices_ are mobile or embedded devices able to manage semantic annotations. --- # The Semantic Web and limited devices * semantic reasoners for this type of environments (mencionar al tio que hizo un razonador adaptado) * lightweight semantic formats * lightweight web protocols * mobile and embedded devices' the processing capability * [autonomy of the batteries](http://energi.us/liberacion-patentes-tesla/) or * energy harvesting * large etc. ??? Some of our attempts with several platforms (e.g., Arduino) where unsuccessful. However, with current advances in: [leer] More and more devices will be able to manage semantics.