Using Google Visualizations to display SPARQL results

By William - Posted on 21 September 2010

Google's Visualization API is a great, flexible tool for displaying data. However, it takes some technical savvy to use Google Visualizations to display SPARQL results. If the user handles SPARQL results with a tool like SPARQLproxy, then setting up a visualization requires knowledge of Javascript and SPARQL.

1. What is the Visualization API?

From Google: "The Google Visualization API lets you access multiple sources of structured data that you can display, choosing from a large selection of visualizations. Google Visualization API enables you to expose your own data, stored on any data-store that is connected to the web, as a Visualization compliant datasource. Thus you can create reports and dashboards as well as analyze and display your data through the wealth of available visualization applications. The Google Visualization API also provides a platform that can be used to create, share and reuse visualizations written by the developer community at large."

2. What sorts of visualizations can you make?

See the Interactive Code Samples: there are time lines, area charts, bar charts, speedometers, pie charts, intensity maps, tables, organization charts, and more... each chart can be customized in many ways, and charts can be made to interact with other charts. Of course, the more complex a chart needs to be, the more knowledge of Javascript it takes to get it to work.

3. How do charts access data?

Charts can load data directly from Google Spreadsheets, and we can populate Google Spreadsheets with SPARQL results easily enough. However, this means that if the spreadsheet has not been refreshed recently, the visualization may not be up-to-date. It would be better to load the data "live" whenever a visualization is created.

It's possible to use Java Server Pages (JSP) to execute a SPARQL query, have the server process the results using custom Java code, and pass the results to the web page. It takes a long time to set up this process, and on several occasions the final result hasn't worked because of a quirk somewhere in the Google Appspot server we've been using. So this method is also less than ideal.

The folks at the Data-gov Wiki solve this problem with their SPARQLproxy web service. This web service generates a URL that can be pasted into the javascript code for a Google Visualization; when the Visualization calls on that URL, it gets live SPARQL results in a form that works for the visualization. SPARQLproxy uses XSLT to convert the standard SPARQL/XML result format to JSON. XSLT, as I understand it, uses instructions in an XSL file to transform an XML document into a document in some other format. I think this is much more direct than the JSP method described above: it takes one step to transform the SPARQL results to something Google Visualizations can use rather than four. SPARQLproxy's creators have exposed the XSL file that governs the transformation. (This video from the data-gov wiki shows how SPARQLproxy is used with Javascript, especially right around 6:25.)

4. Can Google Visualizations handle data from multiple SPARQL endpoints or data sources?

The Google Visualization API has built-in functions for joining data objects (tables), so the short answer is yes. We could join the results of a SPARQL query to the data pulled from a Google spreadsheet, or we could combine the results of SPARQL queries from different endpoints. However, in practice we've run into the problem that names for elements in different data sources (country names, for example) don't match up exactly, and so some elements may get left out. Matching data from different sources will be one of the major challenges of using open data from the Semantic Web.

5. Can Google Visualizations handle aggregation?

Yes. Until SPARQL 1.1 gives us the ability to use SUM and COUNT in our queries, we can easily run basic aggregations usingGoogle's aggregation functions.

6. Can Google Visualizations be gadgetized?

Yes. Right now we're running visualizations as Javascript code in the web pages' HTML files, but it looks like we could hide some of our code (and make our code more modular) with Google's Gadgets API. This may be worthwhile as a future project.