SPARQL is a powerful query language for Semantic Web data sources but one which is quite complex to master. As the block programming paradigm has been succesfully used to teach programming skills, we propose a tool that allows users to build and run SPARQL queries on an endpoint without previous knowledge of the syntax of SPARQL and the model of the data in the endpoint (vocabularies and semantics). This user interface attempts to close the gap between tools for the lay user that do not allow to express complex queries and overtly complex technical tools.
While the available Linked Data sources are increasing in quantity and diversity, their usage is still limited. One of the barriers for the adoption of Semantic Web standards, even by technology-savvy users, is their perceived complexity.
Whether someone wants to explore an RDF dataset or in general the Linked Data
cloud, the options are usually either to use a Linked Data browser for a purely
resourcecentric view or to switch to writing queries using the SPARQL language [
Block programming languages, in which coding is done by dragging and connecting
fragments shaped like jigsaw puzzle pieces, have been successfully used to introduce
programming to non-experts. Recently, tens of milions of users have been exposed to
the basics of programming using Blockly [
In [
structure of the syntax of SPARQL, while at the same time trying to avoid excessive verbosity that would lead to cognitive overload for the user. Compared to previous uses of block programming languages, this proposal addresses novel challenges due to two main specific properties: 1) the heterogeneous nature of Linked Data, that requires the ability to explore graph datasets even without any a priori knowledge; 2) the structural difference between procedural imperative languages for which this paradigm was previously used and a functional query language like SPARQL. To deal with these challenges we proposed a novel paradigm, favouring direct reuse of query results through the integration of the visual space used for query design and results visualization.
In the present paper we present a live demo of the tool. Through this online demo we want to promote discussion on the topic of visual interfaces for SPARQL and specifically evaluate the usability and reception of our proposal. Moreover, the user interface has been enhanced to permit the execution of queries on multiple SPARQL endpoints.
In the rest of the paper, Section 2 reports on related work while Section 3 presents the tool. Section 4 gives details on the implementation and the presented demo and Section 5 summarizes the proposal and draws some conclusions. 2
Several interactive tools have been proposed to support the structured querying of RDF
data sources, at various levels of abstraction and using different paradigms. A basic
distinction can be made between: 1) tools that require writing and reading SPARQL
syntax and 2) tools that provide other metaphors (usually visual) aimed at lowering the
learning curve and providing more intuitive interaction. The first kind of UIs include
advanced editors as YASGUI [
UIs of the second kind provide interaction with another representation of the query
–textual or visual– that is then transformed to SPARQL to be executed. The text based
UIs use forms –such as SPARQLViz [
A previous important proposal for using block programming for SPARQL queries
is the SPARQL/CQELS Visual Editor designed for the Super Stream Collider
framework [
the existing tools the visualization of the result set is passive and often presented in an indipendent panel/window (e.g., in many Web-based interfaces the result page replaces the query page). In our proposal, on the contrary, results and query share there same workspace to allow for an exploratory pattern of interaction. 3
The following were the basic requirements around which the user interface was defined: 1. users should not care about the syntax – hence visual clues and constraints should prevent syntax errors; 2. the need to input text by users should be minimized; 3. there should be direct ways to build commonly used structures; 4. users should be able to use the tool as a step to learn the SPARQL (textual) syntax – hence the used blocks should follow the structure of the language; 5. users should be able to work even without prior knowledge of the dataset – hence exploratory queries should be explicitly supported.
The queries are designed composing the set of available blocks. For example,
Figure 1 represents a select query –against LinkedGeoData data set [
FILTER(LANGMATCHES(LANG(?subareaName), ’en’)) } ORDER BY (?subareaName) LIMIT 5
However, in order to design such a query some knowledge about the specific dataset (that there exists a resource lgdt:relation365331 representing Italy) and the used vocabularies (that the property lgdo:members associates an area with a container of items, of which the ones with gdo:role equal to “subarea” are administrative subdivisions of the area) is still required.
If the dataset is unknown this information is usually gathered through preliminary, explorative queries. We thus designed the user interface especially to favour the reuse of query results in the same or new queries. The execution block is used to execute a query and to show the result set as soon as it is available. The produced result set is shown again in the form of blocks, which can be dragged to other parts of the workspace and connected to other blocks. Results from a query can thus easily be used as parts of another query. For the previous query the tabular results can be seen in Figure 1 as well. The execution block provides also a field to set the remote SPARQL endpoint to which the query is sent –in this case the public SPARQL endpoint for LinkedGeoData3. There is no formal limit to the number of execution blocks that can be used, new queries may thus be built while keeping aside previously built queries and their results.
Ideally, the results of execution would arrive within a small time. While this may be true for not-too-complex queries against SPARQL endpoints that perform well, it cannot be guaranteed for the general case. For that reason query executions are nonblocking, i.e. the user interface stays reactive while waiting for a result from the server. The user is thus able to keep working at the same query or other queries while the query is being executed. If a query is modified during execution, the execution is aborted and restarted with the updated query.
When exploring a new dataset, knowing the used vocabularies and looking for specific resources are a common need. For this reason the toolbox already contains some pre-built queries that can be used to look for resources, classes and properties used in the dataset. These pre-built queries are just sets of pre-connected blocks that can be freely rearranged and decomposed on the workspace. Figure 2 shows the query prepared to look for specific resources of a certain type, modified to look for a resource labelled “Italy” and of type lgdm:Relation (that is the class used in LinkedGeoData for geographical composite elements). The result of the query, together with the result of similar explorative queries, can be reused to write a query as the one in Figure 1.
The tool is based on an extension of the Blockly JavaScript library, working entirely on the client side. We extended the library to supply the specific blocks needed for SPARQL queries and execution. We also added the necessary code to generate SPARQL fragments from the blocks. The SPARQL execution block listens for changes in its query connection; each time the query changes, the corresponding SPARQL query is generated and sent to a SPARQL endpoint. The SPARQL endpoint used is set as a field of the execution block. The results are used to dynamically generate the result block and its sub-blocks. The standard prefix definitions fromprefix.cc 4 are used to add prefix declarations in the query sent to the endpoint and to convert the IRIs in the result to the prefixed notation.
The online demo5 is an instance of the tool provided to everyone willing to
experiment with this new user interface. By default the queries are executed against the
SPARQL endpoint of DBPedia6 [
7 As the tool runs on the browser, the endpoints have to be CORS-enabled; non CORS-enabled
endpoints may be reached through a proxy.
be exported in JSON format[
We developed a new visual user interface to allow non-experts to build SPARQL queries. The tool does not require prior knowledge of the used dataset and vocabularies, favouring an exploratory and constructive way of building queries. An online demo –from which any public SPARQL endpoint can be queried– has been setup to showcase the user interface to the communities of Semantic Web developers and reasearchers, in order to have feedback from a wider audience and foster discussion in this field.