## 6 Evaluation of the USN-Platform Semantic Extension
### Discussion  
The results reported in this section show that publishing times are lower than 50 ms for the majority of messages, with the exception of some configurations with inference (Message C), for which the publishing times reach 100 ms. It is worth noting that these response times are well below recommended minimum separation time of 1.8 s, from leading vehicle to following vehicle, to avoid crashes caused by sudden braking [40]. The query response times obtained are less than 3% of this figure. Therefore, the publishing times in our test scenario can be considered appropriate for the delivery of emergency warning messages to motor vehicles and/or their drivers. In this section we have also shown that the Observation Storage extended with a Sesame SPARQL endpoint can handle repository sizes of 1 million observations (around 10 million triples). This means that we can collect at least 1 million observations of electric vehicle charge levels, and make them available to a Smart Grid planning application. In addition to our evaluation results, we can also rely on other studies that have shown it is possible to add around 70 million RDF triples to a Sesame repository in 3.5 h [41]. We note that in our tests all publications and all queries were done sequentially. However, SESAME has features to facilitate scalability, such as allowing the queuing and parallel processing of incoming messages. It would be worthwhile to explore the possibility of scaling to larger amounts of data, resorting to other repository systems such as YARS2 [42], Jena TDB ([[http://jena.apache.org/documentation/tdb/index.html](http://jena.apache.org/documentation/tdb/index.html)]([http://jena.apache.org/documentation/tdb/index.html](http://jena.apache.org/documentation/tdb/index.html))), Mularara ([[http://www.mulgara.org/](http://www.mulgara.org/)]([http://www.mulgara.org/](http://www.mulgara.org/))), Kowari ([[http://kowari.sourceforge.net/](http://kowari.sourceforge.net/)]([http://kowari.sourceforge.net/](http://kowari.sourceforge.net/))) or Oracle ([[http://www.oracle.com/technetwork/database/options/semantic-tech/index.html](http://www.oracle.com/technetwork/database/options/semantic-tech/index.html)]([http://www.oracle.com/technetwork/database/options/semantic-tech/index.html](http://www.oracle.com/technetwork/database/options/semantic-tech/index.html))). The above results allow drawing different conclusions depending on the type of application that is requesting the information. First, some queries (Queries 2 and 3) have response times of under 100 ms when the repository size has fewer than 10,000 observations (100,000 triples). In Human Machine Interaction this magnitude of response time is considered \"the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display de result\" [42]. Query 4 has a constant response time of around 150 ms. This response time lies within the \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{4}{c}{**Number of Observations**} \\ \cline{2-5}  & 1000 & 10,000 & 50,000 & 1,000,000 \\ \hline
**Time (ms)** & 152 & 151 & 147 & 152 \\
**No. Answers** & 300 & 300 & 300 & 300 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Response times for SPARQL queries returning the same number of results from repositories of different sizes. interval of 0.1-1 s that [PERSON] [43] considers \"the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay\". Query 2 has response times under 1 s for all of the repository sizes tested, and Query 3 for repositories with less than 500,000 observations (5 million triples). These delays could be acceptable in application contexts such as electric vehicles trying to locate nearby recharging stations (Query 2), or Smart Grid applications locating in an area electric vehicles with a certain level of battery charge (Queries 3 and 4).