![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](https://image.slidesharecdn.com/towardsconstrainedsemanticweb1-161108153633/85/Towards-constrained-semantic-web-14-320.jpg)
Towards constrained semantic web
- 1. Toward Constrained Semantic Web Remy Rojas Lionel Médini Amélie Cordier LIRIS lab., Université de Lyon, France [email protected] 1
- 2. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 2
- 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. 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. Motivation Embedding minimum technologies for constrained devices to integrate the Semantic Web of Things, without undermining their original functionalities. 5
- 6. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 6
- 8. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 8
- 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. 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. 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. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 12
- 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. 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. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 15
- 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. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 17
- 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. 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. Overview ● Introduction ● Global architecture ● Constrained device ● Semantic aspects ● Translation proxy ● Evaluation ● Conclusion 20
- 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. Thank you! ...Questions? 22 This work is supported by the French Agence Nationale pour la Recherche (ANR) under the grant <ANR-13-INFR-012>