## 7 Automated Event Visualization Using Semantic Reasoning
{?widget a dashb:Widget ;  dashb:dataSource?dataSource;#Theanomalyorsensorpropertythatisvisualizedinthis!widget. dashb:visualization?visualization;#Visualizationtodisplaytheinfoaboutthegivenanomaly!orthehistoricaldataofthesensorproperty. dashb:widgetName?widgetName.#Descriptionoftheanomalyorsensorpropertytobevisualized } } _= {?widget a dashb:Widget; ;  dashb:dataSource?dataSource;  dashb:visualization?visualization;  dashb:widgetName?widgetName. }. ```

**Listing 4**. The query passed to the EYE reasoner, stating which triples are expected output for the automatic event visualization process. With the RDF input from Listings 1 and 3, the logic condition in the query is not yet fulfilled. Additional files passed to the reasoner express visualization logic and facts about available visualizations. With this additional knowledge, the semantic reasoner will continuously apply logic rules on existing facts to deduce new facts, until no new knowledge can be derived, after which the query output is returned. The visualization logic is shown in Listings 5-7. Please note that in these listings, events are referred to as \"anomalies\" instead of the more broad \"event\". This is because the original use case only foresaw anomalies as interesting, whereas it became quickly obvious that various interesting events, such as showers, cannot really be considered anomalous behavior. The logic is summarized as follows:

* create a widget that visualizes basic information about the selected event, such as the names of the sensors and observed properties for which the event was detected, and during which time interval it has been detected;
* create a similar basic information widget for _child_ events linked to an event (if any), as Section 8 will explain;
* for each sensor property linked to the selected event (e.g., CO\({}_{2}\)), create a widget that visualizes the historical observations made for the sensor property;
* similarly, create historical sensor data widgets for each sensor property linked to _child_ events (if any) of the selected event. For the first two cases, the type of visualization to be displayed in the dashboard widget is directly set to be of type dashb:AnomalyVisualization, for which one concrete, basic anomaly visualization was currently sufficient. Its RDF metadata is shown in Listing 7. It specifies that the only accepted input data is one anomaly and documents which javascript file contains the code for construction of the visualization, which the dashboarding platform will import. For the latter two cases listed above, the visualization choice is less trivial though. Sensor observations can be visualized with gauges, textual displays, bar charts, line charts, etc. Therefore, the logic rules of the latter two cases in the above list add that the sensor data originates from a time window, rather than a single timestamp. Additional visualization logic then determines that the only currently supported visualization for this case is a line chart. The additional visualization logic is published, together with all other files involved, in an online repository ([[https://github.com/idlab-predict/ddashboard-reasoning](https://github.com/idlab-predict/ddashboard-reasoning)]([https://github.com/idlab-predict/ddashboard-reasoning](https://github.com/idlab-predict/ddashboard-reasoning)),accessed on 15 October 2021), and is discussed in detail in [PERSON] et al. [5]. As a result, the line chart's RDF resource is set as a dashb:candidateVisualization for the widget. The number of candidate visualizations for all widgets on the event dashboard tab has been reduced by reasoning over all rules expressed in the visualization logic [5]. Eventually, only one candidate visualization remains, and future work will foresee additional rules at the end of the reasoning process in case of ties to select the candidate visualization that is used most frequently among all dashboard operators.