The YASGUI Family of SPARQL Clients

Tracking #: 1001-2212

Authors: 
Laurens Rietveld
Rinke Hoekstra

Responsible editor: 
Eero Hyvonen

Submission type: 
Tool/System Report
Abstract: 
The size and complexity of the Semantic Web makes it difficult to query. For this reason, accessing Linked Data requires a tool with a strong focus on usability. In this paper we present the YASGUI family of SPARQL clients, a continuation of the YASGUI library introduced more than two years ago. The YASGUI family of SPARQL clients enables publishers to improve the ease of access to their SPARQL endpoints, and provides consumers of Linked Data with a robust, feature-rich SPARQL editor. We show that the YASGUI family made a large impact on the landscape of Linked Data management: YASGUI components are integrated in state-of-the-art triple-stores and Linked Data applications, and used as front-end by a large number of Linked Data publishers. Additionally, we show that the YASGUI web service – providing access to any SPARQL endpoint – has been a popular service for Linked Data consumers.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Minor Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Osma Suominen submitted on 17/Mar/2015
Suggestion:
Minor Revision
Review Comment:

The paper describes the YASGUI, YASQE and YASR JavaScript components that can be used to enhance human access to SPARQL endpoints. Either stand-alone or in combination, these tools provide a user interface that guide users writing and executing SPARQL queries.

(1) Quality, importance, and impact of the described tool or system

The tools described are obviously high quality, which is also evidenced by the large number of adopters mentioned in the paper. Since the previous papers have been published, the uptake of the YASGUI tools has increased significantly, so a new paper is warranted.

(2) Clarity, illustration, and readability of the describing paper

The paper is well written and clear. It discusses the features and limitations of comparable systems in detail, as well as the (obviously superior) capabilities of the YASGUI tools.

However, there is not much discussion about the limitations of the tool, or potential future work. Was there something desirable in the existing tools that is not yet in YASGUI? Have users suggested particular features? Have the authors performed any usability testing that would indicate problems or pitfalls in the user interface? I have personally found that many users had problems finding the download button in an earlier version of YASGUI, but the user interface has since changed a lot, so this may not be relevant anymore.

There were a few issues with the English. I have provided suggestions for some corrections below, but proofreading before publication is suggested.

Detailed corrections or suggestions:

"its primary interface language: SPARQL". I'd rather say "primary query language". There are many interfaces to RDF, such as the APIs of various toolkits.

"All who know the RDF namespace by heart raise their hands now!". Suggest to say "namespace URI", otherwise this can be confusing (I think I know pretty well the properties and classes that are defined in the RDF namespace, but I cannot recall the exact namespace URI).

"We furthermore show that YASGUI has had considerable impact: it has been included in three important triple stores, was adapted and included in several other tools, and is used by several important data publishers, and provides a useful information source for further research." Suggest breaking up the sentence, it is too long and unwieldy.

"where users might not always know the exact namespace prefix she would like to use". Suggest changing "she" to "they".

"There are only six clients who allows" change to "six clients that allow"

"which only support query results in SPARQL-JSON format" change to "supports"

"as any major operating system contains java support" change to e.g. "as all major operating systems support Java"

"The only applications that do not support the downloading of results, are the Flint SPARQL editor and SparQLed." remove the comma

"no SPARQL interface libraries exist which increases such accessibility." change to "which would increase"

"Finally, YASQE has built-in support for executing SPARQL queries." What does this mean? I assume it means that YASQE can submit the query to a SPARQL endpoint, or something. But it is quite unclear.

"by parsing the results and wrapping it in an internal data representation" change to "wrapping them"

"have been integrated in YASR since then" change to "integrated into"

"YASGUI uses the SPARQLES [9] service by providing endpoint search functionality." change to "service to provide endpoint search functionality"

"solely from the clients side via JavaScript" change to "client side"

"4.2. Integration in Other Applications" The footnote links (28. 29 etc.) are incorrectly placed, there is extra space between the name and the number.

"allowing us to distinguish man-made queries from (routine) machine" change to "(routine) machine use"

In the Reference list, there are many examples of incorrect capitalization, e.g. "sparql", "rdf" and "gui".

Review #2
Anonymous submitted on 25/Mar/2015
Suggestion:
Reject
Review Comment:

The YASGUI Family of SPARQL Clients

In this paper the authors present the set of client tools known as YASGUI. This set of tools help SPARQL endpoint users to build their queries providing syntactic features (autocompletion, syntax highlighting, etc.), and some usability features (query retention, file upload, results renderting, etc.) and other features like providing access to multiple SPARQL endpoints (local and remote). They describe all these features, they compare to other tools in the state of the art and also provide a description of the impact these tools had in the community.

Introduction section:
In this section the authors introduce the problem of querying SPARQL endpoints. Normally these endpoints only offer a text box to enter a SPARQL query and YASGUI helps in that by providing a much nicer application to write these queries. I mostly agree, but I think that another important problem that users have when querying the data is that they do not know the schema behind the data, i.e. users do not know what properties, how to link resources in a query so in the end they get useful results. What happens when a dataset does not use a usual namespace? does YASGUI et al provide some solution to this?

State of the art section:
In this section the authors describe the existing work done in clients for easing the access to SPARQL endpoints. I think the authors present a very complete summary of clients that help users in querying SPARQL endpoints. These clients are classified in three main categories (syntactic features, applicability features and usability features). I think these are a nice set of features that help quite a lot to users. However, as I noted in previous comments can syntactic features use URI autocompletion for non predicate URIs?, like http://dbpedia.org/resource/Ber autocomplete for http://dbpedia.org/resource/Berlin? I think that the most important gap for users is that they do not know the data. How feasible is that?

The YASGUI Family section:
In this section the authors describe the components of YASGUI. These components are the query editor (YASQE), the results visualiser (YASR) and the JavaScript library (YASGUI). I find this set of tools of great help for SPARQL endpoint users. I personally used them in several times and I find them very user friendly. The authors discuss in the YASR the problem with errors messages returned by endpoints. This is certainly an issue, have the authors think in generating their own error descriptions based on those they receive? that would be a step forward in normalising the error messages generated by endpoint servers.

Impact section:
In this section describe the impact that YASGUI had, including its integration within triple-stores, other applications and publishers. Such impact show that the YASGUI set of tools are important for the community.

Conclusion section:
The authors present their conclusions with which I agree. One final comment: I think the next step would be to try to show users some summary of the schema in the RDF database. In that way the users may be able to generate more exact queries.

In summary, the paper presents the need in the Introduction section, the existing tools in the State of the Art, the new features of YASGUI, it discusses its impact in the community and it provides conclusions. I think that the thing missing is to try to ease the access to the endpoint’s content by for instance allowing autocompletion of data resources URIs. Trying to present the schema of what the user wants to query would be also a great improvement for easing the access of users to RDF data.

Overall I liked the paper and I’m a user of the tool which I think it helps a lot in in formulating SPARQL queries. I also have read the other YASGUI papers [1,2,3] and many paragraphs of the current paper were already in in one of these papers. For instance, the Introduction section, paragraphs 1, 2 and 4 are just copy and paste from [1]. Section 2 State of the Art is again mostly copy and paste from [1], specially sections 2.1, 2.2 and 2.3 includes paragraphs from [2]. Table 1 is mostly the same (75%) than Table 1 in [2] which was inspired by Table 1 in [1] (table which now is one page long, before less than half a page). These are the introductory sections which are 5 pages (half the paper). Regarding the YASGUI description section, this is mostly original however if we look carefully at the YASQE description and we compare it to Section 3.1 in [2] it seems that YASQE is a modularisation of YASGUI, thus there is nothing new in YASQE. Figure 4 in the current paper is almost the same than Figure 3 in [2].
That said, I think that at the very least more than 50% of this paper was published in other venues (EKAW and ESWC) in LNCS for the EKAW paper and the CEUR proceedings for the ESWC workshop proceedings. I understand that the CEUR proceedings are not a proper editorial proceedings and from my side I consider that as preliminary work. However the intensive use of the copy and paste tool worries me. It also worries me that I think that the work presented here is just a refactoring of the initial tool (Now YASGUI provides similar functionalities but divided in 3 modules). I think that the authors should rewrite the paragraphs that were just copied and pasted from other papers and explain better why this is a novel work.

[1] Laurens Rietveld, Rinke Hoekstra. YASGUI: Not Just Another SPARQL Client. SALAD@ESWC 2013: 1-9
[2] Laurens Rietveld, Rinke Hoekstra: YASGUI: Feeling the Pulse of Linked Data. EKAW 2014: 441-452
[3] Rietveld, L. & Hoekstra, R.: Man vs. Machine: Differences in SPARQL Queries. Proceedings of the ESWC2014 workshop on Usage Analysis and the Web of Data (USEWOD 2014)

Review #3
By Sébastien Ferré submitted on 17/Jun/2015
Suggestion:
Minor Revision
Review Comment:

The paper presents YASGUI (Yet Another SPARQL GUI), a SPARQL query
editor that is enhanced with features now commonly found in
developement IDEs: syntax highlighting, syntax validation,
auto-completion. The authors talk about the "YASGUI family" because it
comes as several independent components that can be reused as
libraries: YASQE for the edition of queries, and YASR for the
presentation of query results.

-- Strengths --

* YASGUI is a clear improvement for users over basic query editors
(bare text fields), and has more features than its competitors (at
least according to the detailed comparison provided by the paper, I
do not have a good knowledge of other tools). The syntactic features
are not new per se but they are a must-have, and not generally
available in SPARQL GUIs.

* YASGUI is a lightweight SPARQL client that can target arbitrary
SPARQL endpoints, and runs on any platform by using Web client-side
technologies (HTML5, Javascript). Moreover, it can be reused and
customized as a library. I think that this is what distinguishes
YASGUI the most to other SPARQL GUIs.

* YASGUI has been integrated to several triple stores and other
applications, and has been adopted by a number of publishers as a
web interface to their data. As a "Tools and systems" submission,
this is probably the strongest point for this paper. I tried
different instances of YASGUI, and I found them working well. The
paper has interesting sections 4.4 and 4.5 on usage statistics over
2 years (e.g., 90,000 queries on around 600 endpoints), and on its
potential impact to research.

-- Weaknesses --

* In my opinion, YASGUI is useful to knowledgeable Semantic Web
developpers, but not much beyond. Using YASGUI still requires to
have a good understanding of SPARQL as well as of
vocabularies. YASGUI is useful to detect errors earlier, and to
abstract over the SPARQL HTTP protocol. YASGUI autocompletion does
not prevent to query for, say "the elevation of films", which is
inconsistent with the schema, and would therefore produce empty
results without any apparent error. Autocompletion is limited to
classes and properties, so that asking for "the films directed by
Tim Burton" requires to know the URI of Tim Burton. Therefore, the
introduction should lower somewhat its claims, and it should also
refer to alternative approaches combining SPARQL queries with either
Faceted Search (FS) or Natural Language (NL). FS-bases approaches
provides more fine-grained guidance to avoid empty results
altogether. NL-based approaches avoids to expose users with SPARQL
queries.

* Chart visualizations of query results is a very interesting feature
that seems absent from other tools. However, I did not manage to
produce any chart, such as "the average elevation of mountains per
country" in DBpedia, although I got the relevant results. I think it
is a very complex feature, but it is presented very shortly in the
paper without any example. This does not make me confident about the
effectiveness of the feature.

* It is said that YASGUI increases the findability of
endpoints. However, from what I have understood, YASGUI has simply a
pre-defined list of endpoints that is made searchable in the
GUI. So, it is not finding endpoints over the Web, as I expected
first. Still, a good feature to have.

-- Presentation --

The paper is well written and organized. I found it pleasant to read,
with a good balance of facts, figures/tables, and discussions. I did
not find typos to report. The screenshots should be improved because
they are hardly readable.

-- Recommendation --

I recommend to accept this paper with minor revision. I see it as a
rather incremental contribution to the problem of querying SPARQL
endpoints, but it exhibits a nice combination of features, and it has
demonstrated its impact and reusability. In my opinion, it has
therefore its place in the list of Semantic Web tools and systems.


Comments