Our project is an extension for the Knowledge Modeling and Management Architecture (KOMMA), an application framework for ontology based software systems. It is based on the Eclipse platform and is therefore easily extensible. As KOMMA’s support for the execution of SPARQL queries is limited to SPARQL 1.0, we have extended its functionality by introducing full SPARQL 1.1 support using Apache Jena, a general purpose ontology modeling framework.
There were two particularly important factors why we decided to build on KOMMA: Functionality and Maintenance. Upon our first inspection, KOMMA’s feature set looked refined enough in order to be able to use it in productive environments.
The second major factor (i.e. Maintenance) is KOMMA’s up to date state of development, it offers a working Eclipse marketplace version 6 that ran right out of the box on Eclipse Luna which was another requirement that had to be satisfied.
SPARQL is a query language designed to retrieve and manipulate data stored in RDF graphs. SPARQL is considered as one of the key technologies of the Semantic Web and is widely used. It was standardized by the W3C RDF Data Access Working Group (DAWG) has become a W3C Recommendation on 15 January 2008. It was later replaced by SPARQL 1.1 which has also been declared a W3C Recommendation on 21 March 2013. With SPARQL 1.1, several additions and extensions to the query language have been introduced. In addition to performing query tasks, it is now possible to output the query results in JSON, CSV and TSV formats. Also, the SPARQL query and update system can be provided as a service via HTTP as part of the SPARQL protocol.
According to KOMMA's documentation, it should already be able to parse and execute user entered SPARQL 1.0 and 1.1 queries on ontologies opened in the editor. By analyzing the source code of KOMMA, we discovered that the support of SPARQL 1.1 is limited to only two features (FILTER EXISTS, MINUS). All other SPARQL 1.1 features were not implemented. KOMMA uses its own implementation of SPARQL 1.0 and a partial implementation of SPARQL 1.1 instead of relying on an already existing library or framework. Our task was to analyze and enhance KOMMA’s ability to handle both SPARQL 1.0 and 1.1 queries.
There are a three main reasons, why we used an already existing library or framework for our implementation:
- Test Coverage:Since Jena is a project of the Apache Software Foundation it can be assumed that the implementation is of great quality and very well tested.
- Usage:The bigger the user-base the more, and also faster, potential bugs and / or features get fixed and implemented.
- Reinvention: Rewriting code for such complex specifications as SPARQL is probably a great learning experience but should not be of highest priority and has resemblance to reinventing the wheel.
For our modification we first added the Jena framework together with its needed dependencies to one of KOMMA’s submodules in order to be able to use it for our SPARQL 1.1 integration.
We used Apache Jena's QueryFactory class to parse and validate the user-entered string which gave us the opportunity to detect errors in queries and to help the user correcting them. One of the trickiest parts was to connect Jena with KOMMA's own model representation. For our specific case we used a default model and fed it KOMMA’s representation of the model as a ByteArrayInputStream which was quite tricky since KOMMA was not designed for such a use-case. The third major part of our implementation was the use of the QueryExecutionFactory which utilizes the output of the ModelFactory and QueryFactory to provide us a ResultSet to work with.
The image above shows KOMMA’s new SPARQL query interface after our modifications. The user is now able to enter any SPARQL 1.0 or 1.1 query in the input field and KOMMA will parse and execute the query over the ontology. The user also gets notified via a pop-up if the query contains any syntactic or semantic errors. If the query passes, it gets successfully applied to the ontology and the interface then displays the resulting output in the result table which is created dynamically for each individual query.