This paper introduces a multimodal SPARQL query system that combines the capabilities of Sparklis and ViziQuer, two powerful tools for SPARQL query building and visualization. Sparklis offers a faceted user interface for constructing SPARQL queries, while ViziQuer provides a rich visual interface for constructing and visualizing SPARQL queries. By integrating the two applications, the system facilitates the automatic visualization of SPARQL queries constructed in Sparklis within the ViziQuer visual environment.
SPARQL queries can be difficult to write by non-technical users [
Each of the notations have their strengths and weaknesses, especially when it comes to the design of rich SPARQL queries (involving, e.g., aggregation and subqueries). For instance, the Sparklis notation allows for rich query composition using the natural language snippets that can be expected to be suitable for a less technical end-user, while the created query formulations may still appear difficult to understand by some end-users. On the other hand, ViziQuer may provide a structural overview and further refinement of the query.
Both Sparklis and ViziQuer provide means for rich SPARQL query definition including complex
expressions, grouping and aggregation. The ViziQuer functionality for visualizing SPARQL
queries [
This paper presents a prototype of such a multi-modal system that integrates Sparklis and
ViziQuer tools2 and allows users to visualize SPARQL queries created in Sparklis. The integrated
system combines the benefits of the two tools: users can use the faceted UI and controlled natural
language approach of Sparklis, and can visualize and refine these SPARQL queries in the ViziQuer
visual query environment. These visualizations are based on the UML-like notation implemented
in ViziQuer and ViziQuer's query visualization functionality [
The rest of the paper consists of main information about Sparklis (Section 2) and ViziQuer (Section 3), followed by a description of the integration of these tools (Section 4) and examples of SPARQL queries in both notations (Section 5). The paper is completed by a summary of related work (Section 6), and conclusions and future work (Section 7).
Sparklis3 is an open source SPARQL query builder tool that uses controlled natural language and
a faceted search user interface, and allows people to explore and query SPARQL endpoints
without knowledge of SPARQL or the vocabulary used by a particular SPARQL endpoint [
Sparklis covers a large subset of SPARQL 1.1 SELECT queries: basic graph patterns (BGP) including cycles, UNION, OPTIONAL, NOT EXISTS, FILTER, BIND, complex expressions, aggregations, GROUP BY and ORDER BY. Its configuration panel offers options to adapt to different endpoints. Sparklis also includes the YASGUI editor to let advanced users access and modify the SPARQL translation of the query. We extend the Sparklis functionality by letting users also access and modify the visual representation of the SPARQL query.
The query builder functionality lets Sparklis users incrementally build complex queries by combining elementary queries. Elementary queries can be a class (e.g. "a film"), a property (e.g. "that has a director"), an RDF node (e.g. "Tim Burton"), a reference to another node (e.g. "the film"), or an operator (e.g. "average"). Sparklis queries are verbalized in controlled natural language, hiding the SPARQL queries generated by this tool from the user. Figure 1 shows an example of a Sparklis query for films by Tim Burton that star somebody born after 1980. Additional query examples can be found on the Sparklis website4.
ViziQuer5 is an open source UML-style visual SPARQL query tool that allows users to define
SPARQL queries visually using the ViziQuer visual notation. The ViziQuer notation and
environment (cf. [
ViziQuer has been extended with a query visualization functionality that allows users to
transform SPARQL queries into their visual representation. The visualization of SPARQL SELECT
queries produces a visual extended UML-style diagram that describes the entire query contents.
For a simple query consisting of the graph patterns, the pattern subject and object variables and
resources are depicted as the query graph nodes, with important optimizations for representing
the variable/resource classes in the dedicated class name compartments and single-use SPARQL
triple objects within node attribute fields, so obtaining a compact query presentation [
The visualization of a SPARQL query could originally be achieved by copying the SPARQL query text into ViziQuer's SPARQL query pane and activating a "Visualize SPARQL" context menu item. Before doing this, users also needed to log in to the ViziQuer tool. In order to perform automatic integration of ViziQuer with external tools such as Sparklis, ViziQuer was extended in order to allow anyone to work with SPARQL queries (incl. visualizing queries) without logging in.
The integration of Sparklis and ViziQuer was realized by creating a Sparklis plugin (viziquer.js) that retrieves the SPARQL query and associated information from Sparklis and sends it to the ViziQuer API. Sparklis source code was augmented in order to add the ViziQuer tab to the Sparklis UI. The user interface allows ViziQuer to be launched either in the same Sparklis screen (button "Show here") or in a new browser tab (button "Show in a new tab"). The modified version of Sparklis and its ViziQuer plugin are available on Github7. 6 https://github.com/LUMII-Syslab/viziquer/tree/development 7 https://github.com/LUMII-Syslab/sparklis
The required ViziQuer API call can be invoked as an HTTP POST request to the API endpoint provided by the public ViziQuer service8. Alternatively, users can launch their own instances of ViziQuer. The parameters of this API call include the type of the query (SPARQL), the SPARQL endpoint URI and the SPARQL query to be visualized along with a flag that indicates if the visualization action should be started automatically (the other alternative is to just send the SPARQL query to ViziQuer and let users launch the visualization action manually). Figure 3 shows the parameters passed to ViziQuer's JSON API call.
In a similar way, the ViziQuer tool can be integrated into other querying environments, e.g., into a YASGUI based frontend of a SPARQL endpoint.
Query visualization in ViziQuer works best if ViziQuer is "aware" of the data schema of the given SPARQL endpoint but it is also possible to visualize SPARQL queries for endpoints for which ViziQuer does not have a data schema available.
Through the integration of Sparklis and Viziquer, users can visualize SPARQL queries constructed
in Sparklis. This section provides some examples of queries expressed in the controlled natural
language of Sparklis [
UML-style visual queries in ViziQuer notation consist of nodes describing variables or
resources where each node can have a possible class name and attribute specification. One of the
nodes is marked as the main node of a query (orange round rectangle). The edges that connect
the nodes correspond to links among the query variables or resources. Furthermore,
condition/filter fields, as well as aggregation and query nesting links can be used in query
construction [
ViziQuer allows users to edit and fine-tune the visual representation of SPARQL queries. We used this functionality to manually tune the presentation of visualizations shown in this section.
Figure 4 shows a simple query for information about biomolecule class instances from DBpedia in Sparklis and ViziQuer representation. The following SPARQL query is represented by Sparklis and ViziQuer notations in this example:
SELECT DISTINCT ?Biomolecule_1 ?label_103 ?name_140 WHERE { ?Biomolecule_1 a dbo:Biomolecule .
?Biomolecule_1 rdfs:label ?label_103 .
?Biomolecule_1 foaf:name ?name_140 . }
LIMIT 200 8 https://viziquer.app/api/public-diagram
We observe that the ViziQuer representation of the query matches the structure of the original Sparklis query, explicating at the same time some of the assumptions regarding property and variable names and the query limit that are left implicit in the original Sparklis notation.
Figure 5 illustrates a query that uses aggregation to calculate the number of languages spoken in Colombia.
The visual query representation distinguishes the nodes corresponding to the language and the country. The full visual appearance of the query is somewhat overburdened by the explicit variable names (Language_1 and number_of_122) introduced by the Sparklis tool in the generated SPARQL query: PREFIX dbr: <http://dbpedia.org/resource/> PREFIX dbo: <http://dbpedia.org/ontology/> SELECT DISTINCT (COUNT(DISTINCT ?Language_1) AS ?number_of_122) WHERE { ?Language_1 a dbo:Language .
?Language_1 dbo:spokenIn dbr:Colombia . } LIMIT 200
Figure 6 illustrates a more complex query that uses aggregation to calculate the number of books written by poets and returns the results ordered in decreasing order of aggregated values. It shows the original Sparklis representation and four options how the corresponding query can be represented in ViziQuer. Option (a) is auto-generated from the SPARQL query produced by Sparklis, while option (b) is a cleaned-up form of it. The options (c) and (d) were created manually by placing the Person class at the main node of the query. Option (c) uses the joined classes construction, while option (d) uses a subquery to calculate the number of books authored by a person (option (d) would translate to a different SPARQL query form).
It might be an interesting future work to understand which of the query representations (b), (c) or (d) would be the easiest-to-understand by various groups of potential end users. This ease of perception may depend on users mastering the concepts of aggregation with grouping (option (b)), instance aliases (option (c)) and subqueries (option (d)). Each of these representations provides an explicit query structure of nodes linked by properties that was not present in the initial Sparklis formulation. Given the obtained understanding, further work would be to implement an automated creation of the desired visual query form.
(a) (b) (c) (d)
The following SPARQL query corresponds to the Sparklis and ViziQuer query representation in Figure 6 (a): SELECT DISTINCT ?Person_1 (COUNT(DISTINCT ?Book_106) AS ?number_of_165) WHERE { ?Person_1 a dbo:Person .
?Person_1 dbo:occupation dbr:Poet . ?Book_106 a dbo:Book .
?Book_106 dbo:author ?Person_1 . } GROUP BY ?Person_1 ORDER BY DESC(?number_of_165) LIMIT 200
The visual presentation of information can facilitate its perception. Facet-based tools such as
PepeSearch [
Compared to these tools, the ViziQuer notation and environment (cf. [
The integration of Sparklis and ViziQuer was made possible by the extension mechanism in Sparklis and the ViziQuer visualization API. While there are other tools available for defining SPARQL queries, after exploring related work we did not find other instances of integrating SPARQL query tools in the way described in this paper.
In this paper we presented the integration of two powerful tools for defining SPARQL queries – Sparklis and ViziQuer – resulting in a multi-modal system that allows users to define SPARQL queries in Sparklis and visualize and refine them in ViziQuer. We described the implementation details of this integration and demonstrated it with SPARQL queries in their Sparklis and ViziQuer representation. The obtained results show that the visual query representation that is autogenerated from the technical SPARQL query requires some cleaning up to improve its usefulness for the potential end-users. Implementation of such cleaning is left to future work. It may also be worthwhile to consider making use of higher-level Sparklis concepts in the visual query generation. While it is essential for the ViziQuer tool to maintain the principle of generating the visual queries from their SPARQL encoding, incorporating some form of annotations into this encoding could let us preserve the principal query generation architecture and still reach the necessary effects of user-friendliness.
The core of the Sparklis and ViziQuer integration described in this paper is the ability of the ViziQuer tool to create a visual representation of a given SPARQL query. This feature also allows integrating the SPARQL query visualization functionality in other contexts where SPARQL queries are available. The technical solution of invoking ViziQuer without logging in, described in Section 3, can be used to support such visualizations. It could also be useful in simpler use cases where a visual query environment can be seamlessly offered to the users for visually composing queries over a given SPARQL endpoint.
Other potential areas for future exploration are the integration of ViziQuer and Sparklis in the opposite direction (from ViziQuer visual notation to Sparklis queries), which would require a method for reverse translation of SPARQL queries into their Sparklis representation, as well as the integration of the ViziQuer SPARQL visualization functionality with other Semantic Web tools. This work has been partially supported by a Latvian Science Council Grant lzp-2021/1-0389 “Visual Queries in Distributed Knowledge Graphs”.