Application developer guest post -

Welcome to the second of our series of guest blog posts written by community members who have developed applications using data available on This week, Martynas Jusevicius writes about the Semantic Reports application.

I have been developing as a spare-time project for nearly 2 years now. I call it "generic SPARQL results visualizer and report datastore".

The app was also mostly driven by technical challenge and my wish to see (and show) the semantic data visualized in a more accessible way. Linked Data is getting out there, we need new semantic tools to make sense out of it, and I wanted to take part in developing them. Government data, scientific, statistical data, transport, real-estate, social network data – all of it will have be analyzed and presented in a user-friendly way. Bare SPARQL endpoint or RDF output is just not good enough. One of the best ways to present it is visualizations, and I saw them and SPARQL as a perfect match. I think people like to see data in the ways they're used to, such as tables and charts, not some funky graphs of nodes.

Semantic Reports is able to visualize results of an arbitrary SPARQL query from an arbitrary endpoint. The query, the result, the visualizations and their options, and other metadata form what I call a "report". A report (given the query returns results) contains at least a table, and, if there is a sufficient number of result columns with necessary datatypes, it can include standard visualizations such as line chart, pie chart, scatter chart, map etc. Chart axis can be dynamically bound to different result variables. Reports can be saved, edited, and show up on the report list.

The app can also be seen as an endpoint proxy. It accepts endpoint and querystring parameters and opens a report in edit-mode right away, based on the results of the query. Semantic Reports can be used as software-as-a-service – the providers of semantic data can concentrate on its quality and outsource the reporting part, both for internal and public use. Imagine the possibilities with federated queries, which combine several endpoints in real-time.

I think one of the most exciting features of semantic applications like this is that they can be made generic. Semantic Reports doesn't care what queries users run on what data, but all users are still using the same single interface. Even the visualisations and their parameters are not hardcoded in the source code but rather encoded in an ontology, which I can update with new visualisation types using a WYSIWYG editor.

Technically, Semantic Reports is a Java webapp (servlet), based on a web framework that I have been developing even longer. I wasn't satisfied by existing frameworks such as Struts, Spring, Zend, or Symfony, I felt that new REST-based and semantic apps require a new approach.

The framework (which I sometimes call "DIY framework") blends the object-oriented MVC and filesystem-like tree view with HTTP methods and XML-based serialization. It treats URI-centric resources as first-class concepts which build a hierarchy, and executes HTTP methods on them. I have nearly identical object-oriented versions of the framework both in Java and PHP, it leaves a nice option for migration from one platform to another, if there would be a need. The report (meta)data is of course stored in a triple store (I use SDB), and XSLT does all the job of generating the user interface by joining multiple SPARQL results. The client-side visualisations are handled by complex Javascript. The whole application is compliant with established web standards.

It was also exciting to observe how the generic nature of the app affects the source code, something I never experienced before. First you implement a case per each content type, then you slowly morph that code into the same pattern. In the end it simplifies beautifully, but also becomes more complex as it goes into another layer of abstraction.

For the future development I have in mind user accounts, private/group/public access rights, social widgets, embeddable visualizations, interactive SPARQL editor and several more advanced features. I would like to spend more time on this project, so I'm open for all kinds of collaboration and/or integration. I'm also always looking for good examples of SPARQL queries and/or endpoints. And of course – give the app a try! Any feedback is welcome.

Martynas Jusevicius