# Dynamic Linked Data: A SPARQL Event Processing Architecture
## 5 Application Design Pattern
### The JSON SPARQL Application Profile  
SEPA introduces the JSON SPARQL Application Profile (JSAP) ([[http://mml.arces.unibo.it/TR/jsap.html](http://mml.arces.unibo.it/TR/jsap.html)]([http://mml.arces.unibo.it/TR/jsap.html](http://mml.arces.unibo.it/TR/jsap.html))) as a means to describe an application. JSAP is a JSON file, whose root structure is shown in Listing 12. JSAP allows describing a SEPA application by including the parameters needed to interact with one (or more) SEPA broker instance(s), along with all the SPARQL 1.1 Updates and Queries used by the application. Queries and updates can be written in a compact format thanks to the prefixed names for IRIs ([[https://tools.ietf.org/html/rfc3987](https://tools.ietf.org/html/rfc3987)]([https://tools.ietf.org/html/rfc3987](https://tools.ietf.org/html/rfc3987))). Prefixes are specified within the namespaces member (see Listing 12), and the PREFIX keywords are automatically appended by the API to the SPARQL issued to the broker. The graphs member includes the optional HTTP query string parameters as defined by the SPARQL 1.1 Protocol for queries (i.e., default-graph-uri and named-graph-uri) and  
Figure 7: SEPA framework.  
updates (using-graph-uri and using-named-graph-uri). The host member (see Listing 12) specifies the IP address of the broker (i.e., it can be overwritten by nested host members).  
The sparql11 protocol member (see Listing 13) and the sparql11 seprotocol member (see Listing 14) allow one to configure the protocol (i.e., the former for updates and queries, while the latter for subscribes). The sparql11 seprotocol member has two mandatory members: protocol and availableProtocols. The former specifies the protocol gate to be used (see Section 4.1). Such a protocol must be present as a JSON object within the availableProtocols member (i.e., the latter contains all the identifiers of the available protocol gates that can be used for subscriptions). The content of each member of \"availableProtocols\" is protocol specific. If present, the security member contains the parameters to connect to the OAuth service provided by the SEPA.  
One of the main benefits of JSAP consists of the ability to create a template for an application, which can be fetched and modified at run-time to fit the application needs. This template acts as an identity card of an application. For example, a producer that updates the value of a temperature sensor will only need to fill a field in the template (i.e., the current value). Here is where the definition of forced bindings comes to help. A forced binding enables the developer to substitute at run-time a variable in a template with a custom value. To define forced bindings, the key forcedBindings must be used. The value is a JSON object. The variable of a forced binding is a key in that JSON object. Its value is again a JSON object containing the keys type and value. The type key is mandatory and must be one of uri, bnode or literal. The value key is optional and should be used to specify a default value for that variable.  
All the SPARQL Updates and SPARQL Queries used by the application, along with their forced bindings, are respectively enumerated within the updates and queries members of the JSAP (see Listing 12), according to the structure shown in Listing 15. The scope of an update (or subscribe) can also be redefined with reference to the default protocol parameters (e.g., the host or the port). This can be achieved by overwriting one or more fields of the sparql11 protocol member (for update and queries) or the sparql11 seprotocol member (for subscribes). In this way, an application can interact with multiple SEPA brokers and/or SPARQL endpoints at the same time. For example, an aggregator can subscribe to a SEPA broker instance and publish on a SPARQL endpoint (i.e., storing events for later analysis).