## 6 Evaluation of the USN-Platform Semantic Extension
### Performance of the Observation Storage including a Semantic Web Repository
#### 6.2.2 Accessing Information  
To test the performance of the USN-Enabler when providing applications with semantic access to the USN-Platform, we measured response times to different SPARQL queries from applications processed by Sesame, again configured with and without RDFS inference resolution. We sent each query at least ten consecutive times (leaving a timeout of 1 second between each run) and computed the average response time. Three different types of SPARQL queries were used to study how response times were affected by different parameters of the repositories and queries, including _repository size_, _query complexity_, _number of returned responses_, and whether the repository accepted RDFS _inference or not_. The first parameter evaluated was the response time as a function of the _number of responses to be returned_. To this end we measured response times for two queries (Queries 1 and 2) to SPARQL Endpoints of different sizes. Query 1 requested all observations whose feature of interest was an  
Figure 9: Response times for queries returning different amounts of results from the SPARQL Endpoint. \"Electric_vehicle\", and had to deal with a large number of results returned (approximately 99% of the observations stored in the repository). Query 2 searched for those observations whose feature of interest was a \"Recharge_Station\" (the remaining 1% of the repository), with which the number of results returned was much smaller (approximately 1%) than for Query 1. The response times obtained are presented in Figure 9 (discussion is given below). In a second test we studied the effects of _query complexity_ on response times using two queries returning a similar number of results (Queries 2 and 3). Query 2 searched for all observations whose feature of interest was \"RechargeStation\". Query 3 accessed \"Electric_Vehicle\" observations with a specific battery charge level. Figure 10 presents the response times for both queries. For any particular number of results returned we observe that response delays were significantly larger for the more complex query (Query 3), and the difference increased with the number of observations returned. As a final test we explored how _different sizes of the repository_ affect response times when the number of responses remains constant. We first stored 300 observations in the repository with the same feature of interest, observed property, location and result (value equal to 5), and then we filled it with observations similar to the previous ones but changing the observation results (result value set to 20). Once this data was available in the repository we queried it (Query 4) without RDF inference, searching for all observations with \"Electric_Vehicle\", \"ChargeLevel\", \"Madrid\" and \"5\" as feature of interest, observed property, location and result, respectively. Table 3 shows the results obtained for repository sizes of 1000, 10000, 50000 and 1 million observations. Drawing from these test results we may observe, first (Figure 9), that response times increase proportionally to the number of returned responses. Moreover, the graph for Query 2 shows differences between inference and non-inference repositories. These differences are due to the higher number of returned results when using inference. In our example this is caused by the observations in the repository with \"BrandX_RechargeStation\" as feature of interest, which are also associated with a \"RechargeStation\" feature of interest through the inference from \"v:BrandX_RechargeStation  
Figure 10: Response times for queries returning a similar number of responses but different amounts of data in the SPARQL Endpoint. rdf:subClassOf v:RechargeStation\". As discussed above, inferences are made when data is loaded in the repository. Consequently, the inference process does not affect the response time, which makes most queries faster at the cost of requiring a larger repository and longer loading times. Results in Figure 10 also show how higher query complexity entails a greater response time.