towards constrained semantic web
TRANSCRIPT
Toward Constrained Semantic Web
Remy Rojas Lionel Médini Amélie Cordier
LIRIS lab., Université de Lyon, [email protected]
1
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
2
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
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, Storage2. Network3. Energy Efficiency 4
Motivation
Embedding minimum technologies for constrained devices to integrate the Semantic Web of Things, without undermining their original functionalities.
5
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
6
Architecture overview
7
Constrained Thing
Thing Configuration
Semantic Server
Repository
HTTP/CoAP Proxy
HTTP
SharedVocabularies
RAMService TemplateService
TemplateService Model
CoAP
HTTPreferences
describe
SensorsActuators
I/O
Processing buffers
CoAP
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
8
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
RAMe
Service Model
Processing buffers
Application ProtocolCoAP(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
Constrained Device processing workflow
Mode 1: Startup
Mode 2: Requesting
BootDevice 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
ResultsBuffer
Serializing CoAP Buffer
Blockwise Transfer
11
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
12
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
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."
},[...]
14Hosted @ https://github.com/ucbl/arduinoRdfServer/blob/master/example/arduino.jsonld
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
15
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
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
17
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
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%)
Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion
20
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