# Dynamic Linked Data: A SPARQL Event Processing Architecture
## 5 Application Design Pattern
### Examples of the Design of a SEPA Application
The application is an example of how raw data (i.e., the topic-value pairs provided by an MQTT broker) can be mapped into RDF triples. At the same time, it provides an overview of how to store temporal data for later analysis (i.e., based on SPARQL and semantic reasoning techniques [72]). Information level interoperability is achieved through the use of the following ontologies:  
* W3C Sensor Network Ontology ([[https://www.w3.org/TR/vocab-ssn/](https://www.w3.org/TR/vocab-ssn/)]([https://www.w3.org/TR/vocab-ssn/](https://www.w3.org/TR/vocab-ssn/)))
* W3C Time Ontology in OWL ([[https://www.w3.org/TR/owl-time/](https://www.w3.org/TR/owl-time/)]([https://www.w3.org/TR/owl-time/](https://www.w3.org/TR/owl-time/)))
* Quantities, Units, Dimensions and Data Types (QUDT) Ontology ([[http://www.linkedmodel.org/doc/qudt/1.1/index.html](http://www.linkedmodel.org/doc/qudt/1.1/index.html)]([http://www.linkedmodel.org/doc/qudt/1.1/index.html](http://www.linkedmodel.org/doc/qudt/1.1/index.html)))  
According to the core ontology SOSA (Sensor, Observation, Sample, and Actuator), the application maps each topic into an observation, providing the data value as the numeric value (i.e., qudt-1-1:numericValue) of a quantity (i.e., qudt-1-1:QuantityValue). The ontology has been extended with the arces-monitor:hasMqttTopic property that allows one to link an observation URI with a MQTT topic (see the \"ADD_OBSERVATION\" update in Listing 18 for details on how this mapping is performed). Mappings are dynamically added by the Topics Manager agent. A set of initial mappings can also be specified within the extended member of the JSAP (see Listing 12). An example of the content of an entry used to map the topic prepoli/6 lowpan/network/NODO1/Temperature with the arces-monitor:Pepoli-6 lowpan-Nodo1-Temperature observation URI is shown in Listing 17. Data values are updated by the MQTT Adapter agent. On the one hand, the agent is subscribed to the MQTT broker (i.e., to all the topics using the \"#\" wildcard); on the other hand, it is subscribed,  
Figure 9: An MQTT sensors’ monitoring application. through the \"TOPICS\" query, to the mappings created by the Topics Manager. On every notification coming from the MQTT broker (i.e., topic-value), the MQTT Adapter agent finds the observation URI that matches with the topic and extracts the numeric value of the observed quantity from the value (i.e., using regular expressions). This is where the lack of information level interoperability comes out: the value has no a predefined format, and its meaning is unknown. Moreover, in some cases, the data identifier is embedded within the topic, while in other cases, it is included within the value: an agreement with the MQTT broker provider is required in order to parse and understand the content of each topic-value pair. On the contrary, semantic information is all described in RDF, identified by URIs and their meaning represented through ontologies. The events generated by the MQTT Adapter agent are consumed by two different agents (see \"OBSERVATIONS_VALUES\" in Figure 9): the Web Application and the Big Data Storing Service. The former, based on the Java Script APIs, visualizes the data in a Web browser as shown in Figure 13. The latter, through the \"STORE_OBSERVATION\" update, stores the events in a Big Data RDF store to be later analyzed. Events are time stamped according to the W3C Time Ontology in OWL. The discussion of the big data analysis techniques that could be used to extract meaningful information is out of the scope of this paper.