This paper introduces YASGUI, a user-friendly SPARQL client. We compare YASGUI with other SPARQL clients, and show the added value and ease of integrating Web APIs, services, and new technologies such as HTML5. Finally, we discuss some of the challenges we encountered in using these technologies for a building robust and feature rich web application.
goes far beyond a simple HTML form. These implementations convey a rather narrow interpretation of what a SPARQL client interface should do: POST (or GET) a SPARQL query string to an endpoint URL. As a result, they currently o er only a selection of the features that we, as a community, could o er to both ourselves as well as new users of Semantic Web technology.
YASGUI is a web-based SPARQL client that functions a a wrapper for both remote and local endpoints. It integrates linked data services and web APIs to o er features such as autocompletion and endpoint lookup. It supports query retention { query texts persist across sessions { and query permalinks, as well as syntax checking and highlighting. YASGUI is easy to deploy locally, and it is robust. Because of its dependency on third party services, we have paid extra attention to graceful degradation when these services are inaccessible or produce unintelligible results
The following sections give a brief overview of the featureset of the current state of the art features of SPARQL clients, followed by a more detailed description of YASGUI. 2
Most modern applications containing textual input support autocompletion. Examples are the Google website which shows an autocompletion list for your search query, or your browser which (based on forms you previously lled in) shows autocomplete lists for text inputs. One advantage of autocompletion is that it saves you from writing the complete text. Another advantages is the increase in transparency, as the autocompletion suggestions may contain information the user was not aware of. The latter is especially interesting for SPARQL, where users might not always know the exact pre x he/she would like to use, or where the user might not know all available properties in a triplestore. The only SPARQL interface that currently makes use of this functionality is the FLINT SPARQL Editor5, which uses autocompletion to suggest classes and properties.
Syntax highlighting is a common functionality for programming language editors. It allows user to distinguish between di erent properties, variables, strings, etc. The same advantage holds for query languages such as SPARQL, where you would like to distinguish between literals, URIs, query variables, function calls, etc. The only SPARQL editor currently supporting syntax highlighting is
the FLINT SPARQL Editor, which uses the CodeMirror JavaScript library6 to bring color to SPARQL queries.
Most Integrated Development Environments (IDEs) provide feedback when code contains syntax errors (i.e. syntax checking). Feedback is immediate, which means the user can spot syntax errors in the code without having to execute it. Again, such functionality is useful for SPARQL editing as well. Immediate feedback on a SPARQL syntax means the user can spot invalid queries without having to execute it on a SPARQL endpoint. The FLINT SPARQL editor supports syntax checking by means a JavaScript SPARQL grammar and parser. 2.2
There are only few clients who allows access to multiple endpoints. Most
triplestores provide a client interface, linking to that speci c endpoint. They are
endpoint dependent. Examples are 4Store [
Platform (In)dependence increases the accessibility of a SPARQL client. The user can access the client on any operating system. Web interfaces are a good example: a site should work on any major browser (Internet Explorer/Firefox/Chrome), and at least one of these browsers is available for any type of common operating system. Examples are Virtuoso, 4Store and the Flint SPARQL Editor. Another example of multi-platform support is the use of a .jar le (e.g. Twinkle), as any major operating system supports Java and executing Java archives. Examples of single-platform applications are Sesame2 Windows Client and SparqlGUI: they require Windows. 2.3
Query retention allows for easy re-use of important or often used queries. This allows the user to close the application, and resume working on the query later. An example is the `Query Book' functionality of the Sesame Windows Client.
Quick evaluation or testing of a graph generated by the user should not require the hassle of installing a local triplestore. Ideally, this functionality would
7 See http://www.sparql.org/ 8 See https://github.com/MikeJ1971/Glint 9 See http://www.ldodds.com/projects/twinkle/ 10 See http://www.dotnetrdf.org/content.asp?pageID=SparqlGUI 11 See https://gitSNORQLhub.com/kurtjx/SNORQL be embedded in the SPARQL client application itself. Most applications requiring a local installation on the users computer support this feature, such as Twinkle. The Sesame Windows Client supports le uploads as well, though it requires a local triplestore which implements the OpenRDF SAIL API.
Query results (such as JSON or XML) for SELECT queries are often relatively di cult to read and interpret, especially for a novice. A rendering method which is easy to interpret and understand is a table. All applications except 4Store support the rendering of query results into a table. Because of the use of persistent URIs, we would expect navigatable results for resources, e.g. in the form of drawing the URIs as hyperlinks. This feature is not supported by some applications, such as Virtuoso, Twinkle or SparqlGUI. SNORQL is an application with an elaborate way of visualizing the query results. Besides allowing the user to navigate to the page of the URI, the user can click on a link to browse the current endpoint for resources relevant to that URI.
Downloading the results as a le allows for better re-use of these results. A user might want to avoid running the same heavy query more than once, and use the results stored as a le instead. Additionally, the results of CONSTRUCT queries are often used in other applications or triplestores. Saving the user from needing to copy & paste query results clearly improves user experience as well. The only application that does not support the downloading of results, is the FLINT SPARQL editor.
Most of the clients described above are restricted to one simple task: accessing information behind a SPARQL endpoint. However, equally important to this task is assisting the user in doing so. This is something where all but one applications fail. Regrettably, the one interface with a user-friendly interface (FLINT SPARQL editor) falls short in the important feature of accessing all endpoints. We conclude that currently no single endpoint independent, accessible, userfriendly SPARQL client exists. 3
In this rest of this section we discuss the architecture, features and design considerations of YASGUI (Figure 1) and compare them to other clients. 3.1
YASGUI is built using SmartGWT toolkit12, jQuery13, and uses new HTML5 functionalities such as local storage and client-side generation of les. Some of the newest HTML5 functionalities are not supported by outdated browsers and Internet Explorer. This degradation is handled gracefully: access via an incompatible browser results in a noti cation to the user and disabled features (such as downloading of les, or client-side caching of large objects). The decision to use HTML5 is motivated by the increasing support of the standard by major 12 See http://www.smartclient.com/product/smartgwt.jsp 13 See http://jquery.com/ Feature Autocompletion Syntax Highlighting Syntax Checking Multiple Endpoints Query retention File upload Platform independent + Results rendering Results download + a Autocompletion of properties and classes available in the triple store b Autocompletion of pre xes/namespaces, support for properties and classes is a planned feature. c Can deal with a limited number of endpoints, e.g. only CORS enabled ones. d File upload requires a local triple store that implements the OpenRDF SAIL API, e.g. OpenRDF
Sesame or OpenLink Virtuoso.
e File upload is a planned feature, using the rdfstore-js client side triple store.
f The rendering does not use hyperlinks for URI resources.
browsers. The server-side part of YASGUI is responsible for some of the
communication with external services and endpoints. Communication with SPARQL
endpoints is done using the Jena library [
Two existing libraries provide support for syntax highlighting and checking in YASGUI: The CodeMirror JavaScript library, which is an extensive JavaScript library for highlighting code, and a JavaScript SPARQL grammar of the FLINT SPARQL Editor. Given this grammar, CodeMirror applies the highlighting to the SPARQL query. Additionally, CodeMirror provides a well documented API to parse and dissect the SPARQL query, useful for other YASGUI features such as pre x autocompletion. Both libraries are well documented, well maintained, extendible and easy to use. The existence of both libraries illustrate the avail14 See http://semantic.ckan.net/sparql 15 See http://labs.mondeca.com/endpoint/ends 16 See http://prefix.cc/ 17 See http://bitly.com
Another issue with CKAN (and to a lesser extent Mondeca) is the reward model for adding and maintaining the catalogue: there is little incentive for owners of a dataset to add it to CKAN, and even less incentive keep the information up to date (e.g. when the endpoint is down or moved). As a result, CKAN is cluttered with outdated information, and some endpoints are missing. This is partly compensated by Mondeca, which allows ltering by endpoints which are up, though incorrect or missing information still persists. The reward model employed by Pre x.cc is the opposite: the content is crowd-sourced (anybody can add pre xes), and voting is used to to deal with con icting pre x de nitions. Users of pre x.cc have an incentive to keep the information up to date and as correct as possible. As a result, the information retrieved from pre x.cc is more reliable and usable than information from CKAN and Mondeca. 3.3
As mentioned in section 2, client-side web applications such as the FLINT SPARQL Editor are endpoint independent, but only work on CORS-enabled endpoints. To overcome this limitation, YASGUI includes a server-side proxy for accessing endpoints that do not support CORS. For endpoints which do support cross domain JavaScript, YASGUI executes the queries solely from the clients side via JavaScript. The only scenario where YASGUI fails to connect to an endpoint is where a locally installed endpoint is unreachable from the web, operating on a di erent port than YASGUI, and CORS-disabled. Here, the YASGUI proxy is not able to access the client. Because of the CORS restriction, YASGUI is not able to access the endpoint via JavaScript as well, as it is operating on a di erent port. We consider this issue to be minor: because the endpoint is installed locally, the user will have access to change its CORS settings, or even run the endpoint via a di erent port.
Other than dealing with the accessibility issues of CORS disabled sites, endpoint independent clients should support con gurable requests. For instance, some endpoints may only support the XML results format, or allow the use of additional request parameters, such as the `soft-limit' of 4Store. Such endpoints can only be used to their full potential if users are able to specify these additional arguments manually. Therefore, YASGUI supports the speci cation of an arbitrary number of request parameters for every endpoint.
Finally, we had to add quite some code to deal with possible errors returned by endpoints. The SPARQL protocol speci es what the endpoint request and response should look like, but leaves error handling unspeci ed: what HTTP error code should be sent by an endpoint, and how should error messages be communicated. As a result, triple stores come with various ways of conveying errors. Some endpoints return the error as part of an HTML page (with the regular 200 HTTP code), or as a SPARQL query result. Others only return an HTTP error code, where only some include a reason phrase together with the error code. The latter is a best practice for RESTful services. The absence of a standard, and the failure to adhere to best practices, makes a generic robust error handling solution messy and di cult to implement. Developing such a solution requires coding and testing by trial and error, and test queries on as many di erent endpoints as possible. 3.4 As Table 1 shows, most SPARQL clients support both rendering and downloading of query results to some extent. YASGUI does both as well. Users can render results either as a lightweight HTML table (for large numbers results), an elaborate sortable/groupable table, or show the raw query results with syntax highlighting. Tables can be downloaded as CSV, where raw query results are available for download `as is'.
YASGUI stores the application state, making this application state persistent between browser/user sessions: a returning user will see the screen as it was when she last closed the YASGUI browser page. We elaborate on this feature by providing query permalink functionality. For a given query and endpoint combination, YASGUI creates a link. Opening the link in a browser will open YASGUI with the speci ed query, endpoint and request arguments lled in. We believe this is a welcome feature for people working together with a need to exchange queries. Other than regular query permalinks, YASGUI supports the generation of shortlinks as well using the Bitly URL shortener service. Using an external service such as bitly poses some limitations: their is a fair use policy, limiting the scalability of this solution. Additionally, there is a danger of link-rot as well. An alternative to an external URL shortener service is implementation of such a service as part of YASGUI. This deals with both the issues of scalability as well as link-rot. We opted for the external bitly service, as the danger of linkrot is low with a popular service such as bitly. Whenever scalability becomes an issue, the alternative of implementing our own service would still be a viable option. 4
In the preceding sections we described YASGUI and compared it to other clients. YASGUI shows how straightforward it is combining Web APIs, libraries and new Web technologies. Compared to other clients, YASGUI is the rst client that really leverages the tools and services we as a community have developed for ourselves.
In the process, we encountered 4 challenges in using WEB APIs and Linked Data together. First, maintenance of Web 2.0 content is a challenge. External services such as CKAN contain outdated, incorrect or incomplete information (section 3.2). The main challenge here is how to manage this information, e.g. using a reward model where users have an incentive to update the information, or active curation by the service manager. Secondly, standard adherence (or lack of standards) is a challenge (section 3.3), such as the di erent error handling approaches implemented by endpoints. Additionally, graceful degradation (section 3.2) is an issue. The before-mentioned challenges, as well as issues such as external services breaking down, should not break the application. In the worst case, it should only break application features. Finally, it is worth considering whether or not to use online web services. Use of online web services such as url-shorteners or endpoint catalogues create external dependencies. For some services such as CKAN, graceful degradation is possible. However, for other services such as url-shorteners, this is not the case. This is a trade-o . Instead of using online web services, an application speci c implementation may be preferable and more robust.
In general, our experience is that there is an abundance of libraries, new Web technologies, services, and APIs. The use of these tools increases the feature set of your application, and decreases the number of lines you have to write.