Semantic Tuple Spaces for Constrained Devices: A Web-compliant Vision

Presentation of my PhD thesis.

Transcript

1. Semantic Tuple Spaces for Constrained Devices: A Web-compliant Vision Aitor Gómez Goiri gomezgoiri.net June 16, 2014
2. Outline 1. Introduction 2. Hypothesis 3. Space model 4. Search architecture 5. Actuation 6. Conclusions
3. Introduction
4. Background Introduction
5. Background Introduction
6. Background Introduction
7. Background Introduction
8. Background Introduction
9. Background: UbiComp Introduction
10. Background: UbiComp Introduction
11. UbiComp, challenge 1: dynamism Introduction
12. UbiComp, challenge 1: dynamism Introduction
13. UbiComp, challenge 1: dynamism Introduction
14. UbiComp, challenge 1: dynamism Introduction
15. UbiComp, challenge 1: proposed solution Introduction
16. UbiComp, challenge 2: heterogeneity Introduction
17. UbiComp, challenge 2: heterogeneity Introduction The IEEE defines interoperability as The ability of two or more systems or components to exchange information and to use the information that has been exchanged.
18. UbiComp, challenge 2: heterogeneity Introduction The IEEE defines interoperability as The ability of two or more systems or components to exchange information and to use the information that has been exchanged.
19. UbiComp, challenge 2a: use info Introduction
20. UbiComp, challenge 2a: proposed solution Introduction
21. UbiComp, challenge 2b: exchange info Introduction The IEEE defines interoperability as The ability of two or more systems or components to exchange information and to use the information that has been exchanged.
23. Why the Web? Introduction > UbiComp, challenge 2b: exchange info
24. Why the Web? Introduction > UbiComp, challenge 2b: exchange info
25. UbiComp, challenge 2b: exchange info Introduction
26. Summary: Solutions for UbiComp challenges Introduction
27. State-of-the-art Motivation
28. Common design: delegate semantic provision Motivation
29. Common design: delegate semantic provision Motivation
30. Common design: delegate semantic provision Motivation
31. "Short" or "limited" are relative adjectives Motivation
32. Delegation of semantic provision: Problem 1 Motivation
33. Delegation of semantic provision: Problem 1 Motivation
34. Delegation of semantic provision: Problem 1 Motivation
35. Delegation of semantic provision: Problem 1 Motivation
36. Delegation of semantic provision: Problem 1 Motivation
37. Delegation of semantic provision: Problem 1 Motivation
38. Delegation of semantic provision: Problem 2 Motivation
39. Delegation of semantic provision: Problem 2 Motivation
40. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
41. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
42. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
43. Goals 1. Space model 2. Search architecture 3. Actuation mechanism
44. Outline 1- Introduction 2- Hypothesis 3 - Space model 4- Search architecture 5- Actuation 6- Conclusions
45. Space model [CHB2014] Lightweight semantic framework for interoperable ambient intelligence applications [WoT2012] RESTful Triple Spaces of Things [IEEESensors2011] Collaboration of Sensors and Actuators through Triple Spaces. [WoT2011] On the complementarity of Triple Spaces and the Web of Things.
46. Space model s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . TSC HTTP API s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . asteroid 1 s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . asteroid N OSAPI Outer space Coordination space OSAPI ... coordinator Analysis: Networking properties Coordination properties Is it for limited devices?
47. Networking properties Space model
48. Networking properties Space model
49. Networking properties Space model
50. Networking properties Space model
51. Networking properties Space model
52. Networking properties Space model REST-like APIs Scalability Simplicity User perceived performance Efficiency Evolvability
53. Time uncoupling Coordination properties Space model Space uncoupling
54. Time uncoupling Coordination space ✔ ✔ Coordination properties Space model Space uncoupling
55. Time uncoupling Coordination space ✔ ✔ Outer space ✔ Coordination properties Space model Space uncoupling
56. Time uncoupling Coordination space ✔ ✔ Outer space ✔ X Coordination properties Space model Space uncoupling
57. Properties for UbiComp Space model
58. Properties for UbiComp Space model
59. Outline 1- Introduction 2- Hypothesis 3 - Space model 4- Search architecture 5- Actuation 6- Conclusions
60. Energy-aware search architecture [IJWGS2014] Energy-aware architecture for information search in the semantic web of things. [IMIS2012] Assessing data dissemination strategies within triple spaces on the web of things.
61. Problem: in the context of this PhD Energy-aware search architecture How to search in the outer space? s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . TSC HTTP API s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . asteroid 1 s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . s1 p1 o1 . s2 p2 o2 . s3 p3 o3 . asteroid N OSAPI Outer space Coordination space OSAPI ... coordinator
62. Problem: a generalization Energy-aware search architecture
63. Problem: a generalization Energy-aware search architecture
64. Energy consumption: an example Energy-aware search architecture Platform FoxG20 RAM Memory 64 MB CPU 400 MHz Atmel ARM9
65. Energy consumption: an example Energy-aware search architecture
66. Roles Energy-aware search architecture
67. Roles Energy-aware search architecture
68. Roles Energy-aware search architecture
69. Roles Energy-aware search architecture
70. Roles Energy-aware search architecture
71. Roles Energy-aware search architecture
72. Clues Energy-aware search architecture
73. Clues Energy-aware search architecture
74. Clues Energy-aware search architecture
75. Clues Energy-aware search architecture
76. Clues Energy-aware search architecture
77. Clues Energy-aware search architecture
78. Clues Energy-aware search architecture
79. Clues Energy-aware search architecture
80. Clue content Energy-aware search architecture
81. Clue content Energy-aware search architecture
82. Clue content Energy-aware search architecture
83. Clue content Energy-aware search architecture
84. Clue content Energy-aware search architecture
85. Discovery Energy-aware search architecture Using a discovery mechanism each node shares: 1. the Spaces it belongs to, 2. whether it is White Page (+ its setup version) 3. information for the White Page selection process
86. White page selection Energy-aware search architecture
87. White page selection Energy-aware search architecture
88. White page selection Energy-aware search architecture
89. White page selection Energy-aware search architecture
90. White page selection Energy-aware search architecture
91. White page selection Energy-aware search architecture
92. White page selection Energy-aware search architecture
93. Experimental environment: simulation inputs Energy-aware search architecture
94. Experimental environment: simulation inputs Energy-aware search architecture AEMET metereological dataset University of Luebeck Wisebed Sensor Readings Kno.e.sis Linked Sensor Data Bizkaisense
95. Compared strategies Energy-aware search architecture
96. Evaluation: Network activity Energy-aware search architecture
97. Evaluation: Network activity (by device type) Energy-aware search architecture seconds seconds
98. Evaluation: Network activity (high dynamism) Energy-aware search architecture
99. Summary Energy-aware search architecture The presented search architecture cares about computation (C) and energy (E), because: Management tasks are delegated to the most powerful devices in the space (C+E) The search is improved avoiding many unnecessary requests (C+E) If the Provider cannot process the aggregated clue, it can delegate it on the WP (C) The WP selection process prioritizes cases where less providers are forced to resend their last clue version (E).
100. Summary Energy-aware search architecture
101. Outline 1- Introduction 2- Hypothesis 3 - Space model 4- Search architecture 5- Actuation 6- Conclusions
102. Actuation [esIoT2014] Reusing web-enabled actuators from a semantic space-based perspective.
103. Patterns for Tuple Spaces Actuation
104. Patterns for Tuple Spaces Actuation
105. Patterns for Tuple Spaces Actuation
106. Patterns for Tuple Spaces Actuation
107. Patterns for Tuple Spaces Actuation
108. Patterns for Tuple Spaces Actuation
109. Patterns for Tuple Spaces Actuation
110. Patterns for Tuple Spaces Actuation
111. Patterns for Tuple Spaces Actuation
112. Patterns for Tuple Spaces Actuation
113. Patterns for Tuple Spaces in UbiComp Actuation
114. Patterns for Tuple Spaces in UbiComp Actuation
115. Patterns for Tuple Spaces in UbiComp Actuation
116. Patterns for Tuple Spaces in UbiComp Actuation
117. HTTP API Actuation P O S T / b l a d e s H T T P / 1 . 1 H o s t : s m a r t f a n . e u t r u e
118. HTTP API Actuation
119. HTTP API Actuation
120. RESTdesc Actuation
121. RESTdesc Actuation
122. RESTdesc Actuation
123. RESTdesc Actuation
124. RESTdesc Actuation O P T I O N S / d e u s t o t e c h / l i g h t s H T T P / 1 . 1 H o s t : d e u s t o . e u H T T P / 1 . 0 2 0 0 O K D a t e : S a t , 1 4 J u n 2 0 1 4 2 1 : 2 2 : 0 1 G M T C o n t e n t - t y p e : t e x t / n 3 ; c h a r s e t = U T F - 8 C o n t e n t - L e n g t h : 5 1 2 { a c t u a t o r s : l i g h t s s n : m a d e O b s e r v a t i o n ? l i g h t _ o b s . } = > { _ : r e q u e s t h t t p : m e t h o d N a m e " G E T " ; h t t p : r e q u e s t U R I ? l i g h t _ o b s ; h t t p : r e s p [ h t t p : b o d y ? l i g h t _ o b s ] . ? l i g h t _ o b s a s s n : O b s e r v a t i o n ; s s n : o b s e r v e d P r o p e r t y s w e e t : L i g h t ; . . .
125. RESTdesc Actuation
126. RESTdesc Actuation
127. RESTdesc Actuation
128. RESTdesc Actuation
129. RESTdesc Actuation
130. Motivation Actuation
131. Comparison Actuation Actuation Communication style Benefits Required features Space-based Indirect Decoupling Subscriptions REST-based Direct Reuse Rule-based reasoning
132. Comparison Actuation Actuation Communication style Benefits Required features Space-based Indirect Decoupling Subscriptions REST-based Direct Reuse Rule-based reasoning
133. Comparison Actuation Actuation Communication style Benefits Required features Space-based Indirect Decoupling Subscriptions REST-based Direct Reuse Rule-based reasoning
134. Driving scenario Actuation
135. Comparison Actuation
136. Comparison Actuation Platform Raspberry Pi (model B) RAM Memory 512 MB CPU 700 MHz Low Power ARM1176JZ-F Applications Processor
137. Comparison Actuation seconds
138. Comparison Actuation 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
139. Comparison Actuation 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
140. Comparison Actuation 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
141. Interoperation Actuation
142. Interoperation Actuation
143. Interoperation Actuation
144. Interoperation: how? Actuation
145. Interoperation: how? Actuation
146. Interoperation: how? Actuation
147. Discussion Actuation 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?
148. Outline 1- Introduction 2- Hypothesis 3 - Space model 4- Search architecture 5- Actuation 6- Conclusions
149. Conclusion
150. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
151. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
152. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
153. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
154. Hypothesis The alignment of the TSC paradigm with the web's principles together with the consideration of its energy and computational impact, leads to UbiComp environments where heterogeneous devices communicate autonomously in an uncoupled and interoperable fashion.
155. Scientific contributions: space model [CHB2014] Lightweight semantic framework for interoperable ambient intelligence applications [WoT2012] RESTful Triple Spaces of Things [IEEESensors2011] Collaboration of Sensors and Actuators through Triple Spaces. [WoT2011] On the complementarity of Triple Spaces and the Web of Things.
156. Scientific contributions: search architecture [IJWGS2014] Energy-aware architecture for information search in the semantic web of things. [IMIS2012] Assessing data dissemination strategies within triple spaces on the web of things.
157. Scientific contributions: actuation [esIoT2014] Reusing web-enabled actuators from a semantic space- based perspective.
158. Scientific contributions: related Lightweight user access control for limited devices. [JUCS2013] Enabling user access control in energy-constrained wireless smart environments. [CISIS2013] Extending a user access control proposal for wireless network services with hierarchical user credentials. [UCAmI2012] Lightweight user access control in energy- constrained wireless network services.
159. Scientific contributions: related Use of TSC middleware in a number of different domains: [IWAAL2011] Easing the mobility of disabled people in supermarkets using a distributed solution. In Ambient Assisted Living, n. 6693 in LNCS, pp. 41–48, January 2011. [Robot2011] Distributed semantic middleware for social robotic services [IWAAL2011] Distributed tracking system for patients with cognitive impairments.
160. Technical contributions As a result of my PhD, I have open-sourced the following software: A parametrizable simulation environment https://github.com/gomezgoiri/Semantic-WoT-Environment-Simulation The three different implementations of the same basic actuation scenario presented before https://github.com/gomezgoiri/reusingWebActuatorsFromSemanticSpace A TSC-based middleware: Otsopack https://github.com/gomezgoiri/otsopack
161. Technical contributions Otsopack has been used in the following research projects: THOFU (CEN-20101019), funded by the Spanish Centro para el Desarrollo Tecnológico Industrial (CDTI) and supported by the the Spanish Ministry of Science and Innovation. ACROSS (TSI-020301-2009-27), funded by the Spanish Ministerio de Industria, Turismo y Comercio. TALIS+ENGINE (TIN2010-20510-C04-03), funded by the Spanish Ministry of Science and Innovation. ISMED (PC2008-28), funded by the Department of Education, Universities and Research of the Basque Government for the period 2008-10.
162. Technical contributions These projects used it in different domains... Residences Hospitals Supermarkets Hotels and homes environments.
163. Future work Are limited devices just dumb devices unable to manage semantic annotations? Do we really need the Semantic Web? Will true-REST-architectures ever prevail?
164. Questions? Aitor Gómez Goiri aitor.gomez (at) deusto (dot) es
165. 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 license. * leogg, rduris, williamtheaker and cibo00.