Top Banner
Toward Constrained Semantic Web Remy Rojas Lionel Médini Amélie Cordier LIRIS lab., Université de Lyon, France [email protected] 1
22

Towards constrained semantic web

Jan 26, 2017

Download

Internet

Remy Rojas
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Towards constrained semantic web

Toward Constrained Semantic Web

Remy Rojas Lionel Médini Amélie Cordier

LIRIS lab., Université de Lyon, [email protected]

1

Page 2: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

2

Page 3: Towards constrained semantic web

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

Page 4: Towards constrained semantic web

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

Page 5: Towards constrained semantic web

Motivation

Embedding minimum technologies for constrained devices to integrate the Semantic Web of Things, without undermining their original functionalities.

5

Page 6: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

6

Page 7: Towards constrained semantic web

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

Page 8: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

8

Page 9: Towards constrained semantic web

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

Page 10: Towards constrained semantic web

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

Page 11: Towards constrained semantic web

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

Page 12: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

12

Page 13: Towards constrained semantic web

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

Page 14: Towards constrained semantic web

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

Page 15: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

15

Page 16: Towards constrained semantic web

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

Page 17: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

17

Page 18: Towards constrained semantic web

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

Page 19: Towards constrained semantic web

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%)

Page 20: Towards constrained semantic web

Overview● Introduction ● Global architecture● Constrained device● Semantic aspects● Translation proxy● Evaluation● Conclusion

20

Page 21: Towards constrained semantic web

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

Page 22: Towards constrained semantic web

Thank you!

...Questions?

22

This work is supported by the French Agence Nationale pour la Recherche (ANR) under the grant <ANR-13-INFR-012>