Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards constrained semantic web

291 views

Published on

Our presentation of the paper at the 7th international Workshop on the Web of Things http://webofthings.org/wp-content/uploads/2016/07/WoT_2016_Paper_6_ConstrainedSemanticWoT.pdf

Published in: Internet
  • Be the first to comment

Towards constrained semantic web

  1. 1. Toward Constrained Semantic Web Remy Rojas Lionel Médini Amélie Cordier LIRIS lab., Université de Lyon, France remy.rojas@protonmail.com 1
  2. 2. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 2
  3. 3. Context: WoT assumptions ● Servient ○ Part of the Web of Things Architecture ○ Represents a Thing on the Web ○ Component-based architecture that addresses different concerns ● Avatar ○ Defined in the French ASAWoO project ○ One possible implementation of a servient ○ Defines a vocabulary that distinguishes ■ Capabilities ■ Functionalities ● Embedded WoT server ○ Standard compliant ○ Partly implement servient / avatar architecture ○ Expose RESTful capabilities 3
  4. 4. Requirements ● Be based on Web standards ○ Protocols: HTTP, CoAP ○ Communication scheme: REST ● Ensure application-level Interoperability and Discoverability ○ Provide Semantic resource descriptions ○ RDF, RDF-S, OWL ● Fit in constrained devices ○ Ease of Deployment and Scalability ○ Constraints: 1. Computing power: CPU, Memory, Storage 2. Network 3. Energy Efficiency 4
  5. 5. Motivation Embedding minimum technologies for constrained devices to integrate the Semantic Web of Things, without undermining their original functionalities. 5
  6. 6. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 6
  7. 7. Architecture overview 7 Constrained Thing Thing Configuration Semantic Server Repository HTTP/CoAP Proxy HTTP Shared Vocabularies RAM Service TemplateService TemplateService Model CoAP HTTPreferences describe Sensors Actuators I/O Processing buffers CoAP
  8. 8. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 8
  9. 9. Constrained Device software components ● Thing Configuration: A non-volatile memory space where the state of the device’s services is stored. ● Semantic Server Repository: A space where the device can store and read its Semantic descriptions. ● Service Model: In memory representation of the services currently provided by the sensors and actuators. ● Processing buffers: Handle requests and generate responses ○ CoAP headers ○ JSON payloads 9 Constrained Thing Thing Configuration Semantic Server Repository RAM e Service Model Processing buffers
  10. 10. Application Protocol CoAP(Constrained Application Protocol) - Analogous to HTTP request semantics (GET/POST/PUT…) - Binary Headers ➔ Support for REST implementations - On top of UDP (but also 6LoWPAN) - Blockwise transfer: fixed size packet exchange ➔ Suitable for constrained devices 10
  11. 11. Constrained Device processing workflow Mode 1: Startup Mode 2: Requesting Boot Device Configuration Reader Thing Config. List of Enabled Services Service Parser Sem. Server Repo. Service TemplateService TemplateService Model CoAP Request Buffer AnalyserService URI . . . Completeness Detection Sensor/Act. Sensor/Act. CoAP Response Results Buffer Serializing CoAP Buffer Blockwise Transfer 11
  12. 12. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 12
  13. 13. A Thing exposes a list of Capabilities. ● Capability Properties ○ Enabled Status ○ Command ○ Value Each device describes its API through a complete Hydra API documentation ➔ Resource Expensive ➔ Use Linked Data to reference common parts of the API → ASAWoO ontology Hosted @ http://liris.cnrs.fr/asawoo/ontology/asawoo-hydra.jsonld Semantic API documentation 13
  14. 14. Hydra-based documentation example { "@id":"vocab:temperatureSensor", "@type" : ["hydra:Resource","asawoo:Capability"], "description": "Retrieves a temperature.", "hydra:supportedOperation" : [ { "@id": "_:senseTemp", "@type": "asawoo:capability_retrieve", "returns": "vocab:Temperature" },[...] ] },[...] { "@id": "vocab:Temperature", "@type": ["http://ontology.tno.nl/saref/#Temperature","asawoo:Value"], "description": "The value returned for a Temperature reading, as specified in SAREF." },[...] 14 Hosted @ https://github.com/ucbl/arduinoRdfServer/blob/master/example/arduino.jsonld
  15. 15. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 15
  16. 16. Translation Proxy ● Goals ○ Realistic client use-cases ○ Ease of deployment (Python Script) ○ Protection from malformed CoAP ● Functions ○ Transforms TCP payloads into “blockwise-compatible” UDP packets ○ Translates HTTP headers into CoAP and vice-versa ● Tools ○ Twisted Framework powered with TxThings extension 16
  17. 17. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 17
  18. 18. Implementation: Arduino UNO ● Component repartition ○ Device Configuration → EEPROM ○ Semantic Server Repository → ProgMem ○ Service Configuration, Processing Buffers → RAM ● CoAP Blockwise Transfer → 64B payload set ● Tools ○ CoAP (partial) support: Ethernet libraries provided by Arduino ○ JSON parsing : ArduinoJSON RAM ProgMem EEPROM Processor 2KB r/w 32KB ro 1KB r/w ATmega328P @ 16MHz 18
  19. 19. Results Feasibility is achieved on a Constrained Device using the CoAP standard with a REST architecture: ● Several services can be instantiated at once. ● Embedded RDF graphs are used by both client and server to describe an API ● Configuration persists through power cuts 19 RAM Footprint Cumulative Available RAM Algorithm & Class Instantiation 968B 1080B (52%) Service Template (x3) 279B 725B (35.4%) Static JSON Buffers 200B 525B (25.63%) Package-processing variables 24B 501B (24.46%)
  20. 20. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 20
  21. 21. Conclusion ● POC about semantic interoperability in the WoT on constrained devices ● Next step: intelligent clients that can discover and use such WoT servers ● A step toward decentralized semantic WoT? ○ Aggregating such servers can result in complex applications by pushing hypermedia possibilities further 21
  22. 22. Thank you! ...Questions? 22 This work is supported by the French Agence Nationale pour la Recherche (ANR) under the grant <ANR-13-INFR-012>

×