# Dynamic Linked Data: A SPARQL Event Processing Architecture
## 3 SPARQL 1.1 Secure Event Protocol and Subscribe Language  
The SPARQL 1.1 Secure Event (SE) Protocol ([[http://mml.arces.unibo.it/TR/sparql11-se-protocol.html](http://mml.arces.unibo.it/TR/sparql11-se-protocol.html)]([http://mml.arces.unibo.it/TR/sparql11-se-protocol.html](http://mml.arces.unibo.it/TR/sparql11-se-protocol.html))) wraps the SPARQL 1.1 Protocol to support subscriptions and secure communications. The SPARQL 1.1 SE Protocol aims to transparently support the HTTP methods, provided by the SPARQL 1.1 Protocol, for conveying SPARQL 1.1 Queries and Updates. As shown in Figure 2, this is obtained by complementing these two languages with a third one: the SPARQL 1.1 Subscribe Language (see Sections 3.1-3.3). For instance, according to the SPARQL 1.1 Service Description ([[https://www.w3.org/TR/sparql11-service-description/](https://www.w3.org/TR/sparql11-service-description/)]([https://www.w3.org/TR/sparql11-service-description/](https://www.w3.org/TR/sparql11-service-description/))), this could be specified by a SEPA broker through the sd:languageExtension and sd:supportedLanguage properties. Furthermore, subscriptions need a two-way asynchronous communication between subscribers (i.e., to issue subscribe and unsubscribe requests) and the SEPA broker (i.e., to provide notifications). SEPA is mainly focused on pushing notifications to agents in order to deal with high frequency changes and to provide highly reliable agents synchronization. The SEPA broker reference implementation adopts the WebSocket protocol ([[https://tools.ietf.org/html/rfc6455](https://tools.ietf.org/html/rfc6455)]([https://tools.ietf.org/html/rfc6455](https://tools.ietf.org/html/rfc6455))) for conveying subscribe/unsubscribe requests and notifications, but other protocols like MQTT ([[http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)]([http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html))) or COAP ([[https://tools.ietf.org/html/rfc7252](https://tools.ietf.org/html/rfc7252)]([https://tools.ietf.org/html/rfc7252](https://tools.ietf.org/html/rfc7252))) can be easily supported. Furthermore, according to [28], the push mechanism can be complemented by a pull mechanism (e.g., the one provided by Linked Data Notifications [26]). Figure 2: SPARQL 1.1 Secure Event Protocol. The SPARQL 1.1 Subscribe Language ([[http://mml.arces.unibo.it/TR/sparql11-subscribe.html](http://mml.arces.unibo.it/TR/sparql11-subscribe.html)]([http://mml.arces.unibo.it/TR/sparql11-subscribe.html](http://mml.arces.unibo.it/TR/sparql11-subscribe.html))) complements the SPARQL 1.1 Update and Query Languages in order to express subscribe/unsubscribe requests and notifications. The language can be used by those agents who want to subscribe to changes in the content of an RDF store (i.e., aggregators or consumers, as shown in Figure 1 and detailed in Section 5). The following requirements have been assumed:  
* The content of a subscribe request is the same as the one of a SPARQL 1.1 Query;
* At subscription time, an agent receives the complete set of query results;
* A notification includes the added and removed results since the previous notification;
* A client may activate more than one subscription at the same time;
* A notification refers to a specific subscription;
* Notifications related to the same subscription must be differentiated by an incremental index. The language presented in this paper includes the minimum set of messages required to implement the above requirements and can be extended in the future if needed. This section presents a JSON ([[https://tools.ietf.org/html/rfc7159](https://tools.ietf.org/html/rfc7159)]([https://tools.ietf.org/html/rfc7159](https://tools.ietf.org/html/rfc7159))) serialization of the SPARQL 1.1 Subscribe Language. Other type of serializations may be implemented.