A Visual Dashboard for Linked Data - Semantic Web Journal

S. Mazumdar, D. Petrelli and F.Ciravegna / A Visual Dashboard for Linked Data: An Exploration of User and System Requirements 13write the recent results. For our implementation, timeoutsof 200ms from the frontend were introduced sothat it would prevent delayed results from previousqueries over-writing recent results. Another suggestionwould be to add user interventions before sendingqueries to the backend e.g. pressing enter to retrieveinstance counts.8.2. Dynamic QueryingReal-time querying via generic filters (e.g. draggingsliders to update visualizations dynamically) couldcause the system severe delays as queries are continuouslyfired creating a backing of unresolved requests.To overcome this problem three solutions are possible:provide user interventions before passing queriesto the backend; prevent continuous dynamic queryingby providing only discreet interface items; cache theresult of a query and use the dynamic filtering on theretrieved set, but in this case only restrictions of theset will be possible. Our implementation focussed onthe first solution mainly due to the fact that it does notpose any restrictions on the interactivity of the queryinginterface.8.3. Automatic SuggestionsAutomatic suggestions were disabled, as responsesfrom the backend were often late and could overwritemore recent suggestions, as explained in a previouspoint. As the backend processing was time-exhaustive,we decided to disable searching using regular expressions.Instead, queries are presently performed usingURIs. Doing so does not put any demands on the endpointto process regular expressions, thereby makingthe backend respond quickly.8.4. Aggregate QueriesWhen large result sets were returned from the backend,there was a significant delay in loading up aggregatevisualizations pie chart, bar chart and tag clouds.We perceive two solutions to this limit the response todisplay the top few results or provide the results progressively.We decided to take the first approach as itprovides a comparatively lesser amount of data (oftenthe most important bit) to process. In our implementation,the users however have the option of the entireresult set, if they choose to do so. Doing so improvedthe performance significantly to an average of30.5 ms from 1059.6 ms. However, the inconsistencyof the SPARQL endpoints still remain. Apart from reducingthe time taken to process the queries (and results),this helped in providing a more readable visualization.Figure 11 shows the improvement in the barchart widget when this was done. The figure on the leftshows the aggregate results before any limits applied.The figure on the right shows the improved readabilityachieved by applying limits.8.5. Textual ResultsAs can be seen from Figure 9, the query executiontime for the text result widget was high. Further on,higher instance matches result in further delays sinceit takes more time to process large data objects. Textualresult can then be presented on request in a separateoverlapping layer i.e by providing only a window(as a page) of the entire result set (Figure 12). This solutionreduces time and improves readability. Thereby,instead of sending one highly time consuming query,we modified the system to send several short querieswhen required.The above mentioned guidelines are often adoptedby software developers in order to cope with unreliableor slow databases. Several other software engineeringapproaches can be adopted for improving the systemperformance like caching results, interacting with localdatasets, engineering SPARQL queries to providequicker responses etc. However, our intention of evaluatingthe system limitations is to understand how goodpractices in visualization can be harmonically alignedwith the current system infrastructure, keeping the userexpectations in mind. We have realized that the unreliabilityof the linked data endpoints may create issues(like delays, timeouts etc) in user interfaces as well asdeactivation of essential functionalities, which can adverselyaffect the user experience. In order to adhere tospecific guidelines established by the information visualizationcommunity, the backend infrastructure needsto provide a consistent performance. Our efforts arein understanding what are the existing infrastructureproblems faced by interface developers, and to benchmarksuch systems against the performance of traditionaldatastores, from a developer/consumer’s point ofview.Our focus group sessions have been instrumentalin identifying how we can generalize user needs andexpectations for exploring unknown datasets and domains- transforming an intuition into a concrete approach.The discussions with domain experts, computerscience professionals and students have indi-