Existing Linked Data browsing user interfaces (UIs) allow users who are not familiar with Semantic Web technologies to explore interlinked datasets by generating SPARQL queries behind the scenes. This is analogous to the well-known WYSIWYG (What You See Is What You Get) paradigm, which generates the required markup in the background based on the user interactions. Nonetheless, and contrarily to the WYSIWYG approach where users are enabled to switch between the source code and the UI, there is no alternative in Linked Data browsing UIs to generate the browsing UI based on a given SPARQL query. In this paper we propose WYSIWYQ (What You See Is What You Query), a novel approach that allows people to interactively visualize a given SPARQL query as a browsing UI, which can be further enriched or re-purposed by users. WYSIWYQ aims to provide a two-way binding between SPARQL queries and RDF-based faceted browsing environments. We showcase WYSIWYQ with a proof-of-concept prototype implemented on top of the Linked Data Reactor framework and grlc APIs for SPARQL queries.
Existing Linked Data browsing user interfaces (UIs) allow users who are not familiar with Semantic Web technologies to explore interlinked datasets by generating SPARQL queries behind the scenes. This is analogous to the well-known WYSIWYG (What You See Is What You Get) paradigm, which generates the required markup in the background based on the user interactions to hide the complexity of the underlying technology. Nonetheless, and contrarily to the WYSIWYG approach where users are enabled to switch between the source code and the UI, there is no alternative in Linked Data browsing UIs to generate the browsing UI based on a given SPARQL query. This lack of reversibility turns SPARQL queries into a passive product of the current Linked Data browsing environments. The generated queries can then only get enriched and repurposed by technical users who have the knowledge of SPARQL.
In this paper, we propose an analogous concept to the currently well-adopted WYSIWYG paradigm, called WYSIWYQ (What You See Is What You Query). WYSIWYQ allows users to switch between the query mode and visual mode in an interactive Linked Data faceted browsing environment. As depicted in Figure 1, our proposed WYSIWYQ model aims to enable a twoway binding between the Linked Data queries and their corresponding interactive browsing UIs, in a same way as WYSIWYG does for rich text authoring. We see the following features as main requirements for realizing the WYSIWYQ model: – A mechanism to componentize and customize a faceted browsing environment. In order to be able to regenerate the faceted browsing UI, the system should provide a mechanism to decompose the monolith UI to a set of reusable and customizable components. – A mechanism to identify, share and enrich SPARQL queries. In order to manage the modification of SPARQL queries in a collaborative way and to provide provenance data on changes occurred during user’s interaction, the system should provide a mechanism to identify the queries as Web URIs and allow to share and modify the queries by multiple users. – A mechanism to validate SPARQL queries against a certain pattern. Since it will be very hard to address all features of the SPARQL language when generating the browsing UI, the system should be able to first validate the given queries against the query patterns provided by the browsing UI and then decide whether it can render the query to an interactive UI or not. – A mechanism to decompose a SPARQL query into a set of sub-queries which match a certain pattern. Given a certain query pattern, the system should be able to decompose the query into a set of fine-grained sub-queries which could be mapped into UI components in a faceted browsing environment. – A mechanism to map SPARQL queries and their corresponding metadata to a set of customizable UI components. This is the core part of the system where the result of parsing a query is mapped to a set of browsing UI Components. Based on the given metadata in the query, the system should be able to customize the generated UI components. 3
In the following sections we investigate the related work and available tools to fulfill the requirements identified in Section 2 and to find the existing gaps and barriers towards realizing the WYSIWYQ model. 3.1
The amount of Linked Data available through SPARQL endpoints is
increasing1, however, search, exploration and question answering is still a tedious task
for end-users without the knowledge of SPARQL query language. There are
currently two main approaches to make information retrieval from SPARQL
endpoints more usable [
A faceted interface has several advantages over keyword search or NL queries:
it allows exploration of an unknown dataset since the system suggests restriction
values at each step; it is a visual interface, removing the need to write explicit
queries; and it prevents dead-end queries, by only offering restriction values that
do not lead to empty results [
There are already lots of works done in the area of faceted search and
navigation over Linked Data. SemFacet [
In all the above tools, SPARQL queries are treated as passive final products of the user interactions and cannot be fed back to the system as input for regenerating the faceted browsing experience. The main barrier to support this reversibility, in our opinion, is the lack of fine-grained reusable UI elements supported with a clear data-flow. Most of the current Linked Data browsers act only as a monolith Web application and thereby do not support division of UIs into a set of reusable interactive Web components to enable UI regeneration. 3.2
Component-based software engineering (CBSE) has been an active research area
since 1987 with numerous results published in the research literature [
When it comes to component-based development of Linked Data
Applications (LDAs), the works typically fall into software application frameworks that
address building scalable LDAs in a modular way. The survey conducted by [
Linked Data Reactor (LD-R) framework [
Identifying, Sharing and Collaborative Editing of SPARQL
Queries
In the Semantic Web there are a number of approaches proposing some form of
repository for SPARQL queries. Benchmark-oriented collections, like the Berlin
SPARQL Benchmark (BSBM), the DBpedia SPARQL Benchmark [
The recently proposed Shapes Constraint Language7 (SHACL) is “a language for describing and validating RDF graphs”. SHACL revolves around the so-called shapes graph, a graph that contains constraints that a certain target RDF graph must meet. Two important shortcomings of SHACL are that these constraints do not support named graphs, which are typically used in SPARQL queries retrieving Linked Data UI components; and that using SHACL for SPARQL validation adds yet another layer of parsing.
In our approach, we propose to use parametrization and metadata on top of SPARQL queries in order to check their compliance with UI components. These are two principles already used in grlc, and hence our proposal uses and extends grlc for the specific case of matching UI components. Listing 1.1 shows 5 https://www.w3.org/TR/2015/REC-ldp-20150226/ 6 https://github.com/OAI/OpenAPI-Specification 7 https://www.w3.org/TR/shacl/ 1 #+ expand : 2 #+ - v1_values 3 #+ - v2_values 4 #+ browser : 5 #+ - BarChart : v2_values 6 SELECT DISTINCT ?s ? title WHERE { 7 GRAPH <http :// grid . ac /20170522 > { 8 { 9 10 11 12 13 14 } 15 } 16 LIMIT 20 OFFSET 0 17 } 18 OPTIONAL { 19 ?s rdfs : label ? title . 20 } 21 } 22 }
SELECT DISTINCT ?s WHERE {
GRAPH <http :// grid . ac /20170522 > { ?s a ? v1 . ?s <http :// www . grid . ac / ontology / establishedYear > ? v2 .
FILTER ( iri (? v1 ) IN (? _v1_values ) && str (? v2 ) IN (? _v2_values )) Listing 1.1: Example of a SPARQL query using parameters and metadata to describe a valid UI component. an example of such a query, which uses parameters to preserve its genericity, and extends the metadata fields typically used in grlc for API generation to specify values specifically for matching and customizing UI components (e.g. to use a specific browser component to render the values of a given facet).
After a SPARQL query is validated against these patterns, tools such as SPARQL.js8 and SPIN9 can be employed to extract different components of the query and to semantically represent them. 3.5
There are already several tools available for ad-hoc and static visualization of
results for a given SPARQL query. Tools such as YASGUI [
On the other hand, there are already some generic approaches to map RDF
data to UI elements. WYSIWYM (What You See Is What You Mean) [
A proof-of-concept implementation of the WYSIWYQ model is available at https://github.com/ali1k/ld-r/tree/WYSIWYQ. We also created an screencast to showcase the concept by employing some examples: http://wysiwyq. ld-r.org. The implemented prototype is based on the LD-R10 framework, SPARQL.js library and grlc query APIs stored on Github. 5
In this paper we presented the idea of generating interactive UI components from a given SPARQL query to facilitate switching contexts between Linked Data experts and end-users with limited knowledge of SPARQL, while browsing over Linked Data. The proposed WYSIWYQ (What You See Is What You Query) model aims to create a two-way binding between the elements of a SPARQL query and existing UI components required for an interactive faceted browsing environment. We believe that providing a continuous multi-modal user experience will spread the power of existing passive SPARQL queries to end-users who can collaboratively and interactively enrich and repurpose the queries to derive more innovative insights from Linked Data.
This work was supported by a grant from the European Union’s 7th Framework Programme provided for the project RISIS (GA no. 313082). 10 http://ld-r.org