Linked Data Queries as Jigsaw Puzzles: a Visual Interface ... ?· Linked Data Queries as Jigsaw Puzzles:…

  • Published on

  • View

  • Download


<p>Linked Data Queries as Jigsaw Puzzles:a Visual Interface for SPARQL Based on Blockly Library</p> <p>Paolo BottoniSapienza, University of Rome</p> <p>Roma,</p> <p>Miguel CerianiSapienza, University of Rome</p> <p>Roma,</p> <p>ABSTRACTSPARQL is a powerful query language for Semantic Webdata sources but it is quite complex to master. The jigsawpuzzle methaphor has been succesfully used in Blockly toteach programming to kids. We discuss its applicability tothe problem of building SPARQL queries, through the pre-sentation of a dedicated Blockly-based visual user interface.</p> <p>CCS ConceptsInformation systemsWorld Wide Web; Human-centered computing Empirical studies in HCI;</p> <p>Keywordsblock programming; visual query language; SPARQL;Linked Data; RDF</p> <p>1. INTRODUCTIONOver the past few years the Web has been evolving from</p> <p>an interlinked set of documents to an interlinked web of dataand services. This trend follows the long standing vision ofthe Semantic Web [3] and Linked Data [1]. The structureddata available online are increasing both in quantity anddiversity [4], thanks in part to the comprehensive data modelproposed by the World Wide Web Consortium (W3C) aspart of the Semantic Web effort: the Resource DescriptionFramework (RDF) [6].</p> <p>A key advantage of the linked data model is its support forserendipitous exploration and reuse of existing data. Poten-tially, any expert of a specific domain can create a specificview of a set of Linked Data sources. In practice, exploringand querying Linked Data is not trivial and usually requiresadvanced programming skills.</p> <p>Block programming languages, in which coding is doneby dragging and connecting fragments shaped like jigsawpuzzle pieces, have been succesfully used to introduce pro-gramming to non-experts. Recently, millions of users havebeen exposed to the basics of programming using Blockly [8]</p> <p>Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from</p> <p>CHItaly 2015, September 28 - 30, 2015, Rome, Italyc 2015 Copyright held by the owner/author(s). Publication rights licensed to ACM.</p> <p>ISBN 978-1-4503-3684-0/15/09. . . $15.00</p> <p>DOI:</p> <p>as part of code.orgs Hour of Code. The same metaphor wasused in Scratch [13] to create animations and games and inMIT App Inventor [16] to build Android Apps.</p> <p>In this paper, we propose to use the block programmingparadigm to design queries on Linked Data sources. Thelanguage mimics the (textual) syntax of SPARQL [10] lan-guage, the standard query language for RDF. Compared tothe previous uses of block programming languages this pro-posal addresses novel challenges due to two main specificproperties: 1) the heterogeneous nature of Linked Data, thatrequires the ability to explore graph datasets even withoutany previous a priori knowledge; 2) the structural differ-ence between procedural imperative languages for which thisparadigm was previously used and a functional query lan-guage as SPARQL.</p> <p>2. BACKGROUNDWe start by introducing the basics of the RDF data model,</p> <p>the SPARQL language, and the Blockly library.The Resource Description Framework (RDF) [6] is the</p> <p>data model proposed by W3C for the Semantic Web [3].In this model knowledge is represented via RDF statementsabout resources where a resource can be anything in theuniverse of discourse, e.g. documents, people, physical ob-jects, abstract concepts. An RDF statement is representedby an RDF triple, composed of subject (a resource), predi-cate (specified by a resource as well), and object (a resourceor a literal, i.e. a value from a basic type). An RDF graph istherefore a set of RDF triples. Resources are uniquely iden-tified by an internationalized resource identifier (IRI) gen-eralization of the uniform resource identifier (URI) [2] orby a local (to the RDF graph) identifier if they do not have ameaning outside of the local context (in which case they arecalled blank nodes). The resources used to specify predicatesare called properties. A resource may have one or more types,given by the predefined property rdf:type. In RDF serial-izations, prefixes can be used in place of the initial part of anIRI, which represents specific namespaces for vocabularies orsets of resources. In the initial part of the query prefix dec-larations are used to associate prefixes with namespaces. Anamespace can be associated with any prefix, but the mostcommon namespaces are often abbreviated in the same way(e.g., the namespace is almost always abbreviated as rdf:). The website prefix.cc1 holds a collectively maintained set of standardmappings between prefixes and namespaces. The mappings</p> <p>1</p> <p>86</p> <p></p> <p>can be accessed through a Web user interface, a Web APIor downloaded in several formats.</p> <p>SPARQL [10] is the standard query language for RDFdatasets. The basic building block of SPARQL is the TriplePattern, a triple in which each of the components can bereplaced by a variable. A Basic Graph Pattern is a set oftriple patterns associated with a specific input graph (the de-fault graph, a graph named by an URI or a generic namedgraph referred to via a variable). The Basic Graph Patternis matched against the input dataset and the result is a mul-tiset of tuples in which each tuple corresponds to a bindingfor each of the variables. The relations generated throughbasic graph patterns can be filtered, composed, or groupedusing relational operators. The final result of a SPARQLSELECT (one of the available query types and the one thatwill be considered in this work) query is a multiset of tuplesthat can be optionally ordered, making it a list of tuples.</p> <p>Blockly [8] is a JavaScript library maintained by Googleand based on previous work at MIT. It provides a set of basicblocks covering the structure of typical imperative programs.Most importantly, it is extensible programmatically to definenew blocks. The interface to a Blockly application presents:the workspace, the area where blocks can be dragged to andcomposed; the toolbox, the area where all the blocks availableto the user are shown organized by categories and fromwhich they can be dragged to the workspace.</p> <p>3. RELATED WORKSeveral interactive tools has been proposed to support the</p> <p>structured querying of RDF data sources, at various levelsof abstraction and using different paradigms. A basic dis-tinction can be made between: 1) tools that require writ-ing and reading SPARQL syntax and 2) tools that provideother metaphors (usually visual) aiming to lower the learn-ing curve and provide more intuitive interaction. The firstkind of UIs include advanced editors as YASGUI [14] or in-tegrated environments as Twinkle2. To design the query theuser has still to know SPARQL and the vocabularies used.</p> <p>UIs of the second kind provide interaction with anotherrepresentation of the query, that is then transformed toSPARQL to be executed. Some of the them are text based,using forms as SPARQLViz [5] or controlled constructionof natural language statements as SPARKLIS [7]. Thesesystems do not scale well when the query complexity in-creases and do not easily permit code reuse. Others arevisual tools, often using a graph based paradigm, like NITE-LIGHT [15]. Graph-based interfaces fit the model very well,but are highly inefficient in terms of space on user screenand have often interaction issues.</p> <p>A previous important proposal for using block program-ming for SPARQL queries is the SPARQL/CQELS VisualEditor designed for Super Stream Collider framework [12].In that case the blocks strictly follow the language structureand syntax and the tool requires at least basic knowledge ofSPARQL to be used. Conversely, the user interface we pro-pose is designed to provide blocks that should be mostly selfdescribing and usable without knowing the SPARQL syn-tax in advance. Finally, for most of the existing tools thevisualization of the result set is passive and often presentedin an indipendent panel/window (e.g., in many Web-basedinterfaces the result page replaces the query page). In our</p> <p>2</p> <p>proposal, on the contrary, results and query share there sameworkspace to allow for an exploratory pattern of interaction.</p> <p>4. PROPOSED USER INTERFACEWe propose a visual user interface where users can build</p> <p>SPARQL queries without having to know SPARQL syntax,but simply requiring a basic conceptual understanding ofthe RDF model as a graph-based knowledge representation.That does not include necessarily knowledge of the structureof the data against which the query(ies) are being built.</p> <p>We enumerate here a set of basic requirements based onthe kind of scenarios that we want to support: (1) usersshould not care about the syntax hence visual clues andconstraints should prevent syntax errors; (2) the need toinput text by users should be minimized; (3) there shouldbe direct ways to build commonly used structures; (4) usersshould be able to use the tool as a step to learn the SPARQL(textual) syntax hence the used blocks should follow thestructure of the language; and (5) users should be able towork even without prior knowledge of the dataset henceexploratory queries should be explicitly supported.</p> <p>Following the organization of Blockly, we use blocks oftwo different types: value-like, used for expressions, literalvalues, variables; statement-like, used for graph patterns andrelational operators.</p> <p>As this categorisation is not sufficient to distinguish legalcases of composition from forbiddden ones, the connectionsavailable on the blocks are given a more specific type torestrict the attachement only to the meaningful ones. Forexample, in graph patterns, literals cannot be used as sub-jects or predicates of a pattern, but only as objects in linewith RDF data model and SPARQL syntax.</p> <p>In Figure 1 a construction representing a query is shown.The query is represented by the purple coloured select allblock and its subblocks. The where subblock is a graph pat-tern and corresponds to the where clause of the query. In-side graph patterns and expressions different types of graphterms can be used: IRIs (represented in brown and usingthe prefixed notation), variables (using Blockly appearanceof variables for consistency), and literals (represented in dif-ferent colours according to their type, numeric, string orboolean).</p> <p>The query in Figure 1 is translated to the followingSPARQL query.</p> <p>prefix rdfs: prefix dbo: prefix dbpedia: </p> <p>select distinct *where {</p> <p>?film a dbo:Film;rdfs:label ?label;dbo:director dbpedia:Francis_Ford_Coppola.</p> <p>}order by ?labellimit 3</p> <p>Even if, by designing such query with blocks, potentialsyntax errors are avoided, it is still required some knowledgeabout the specific dataset (that there exist a resource dbpe-dia:Francis_Ford_Coppola representing the person FrancisFord Coppola) and the used vocabularies (that movies havetype dbo:Film and the property dbo:director associates amovie with its director).</p> <p>To address this issue, we designed the execution of thequeries in the tool in such a way as to allow exploratory ac-</p> <p>87</p> <p></p> <p>Figure 1: Execution of a query to get movies directed by Francis Ford Coppola.</p> <p>Figure 2: A generic query to look for specific classes.</p> <p>cess to the dataset. A specific block, the execution block, isdesigned for the execution of a query (the top block in Fig-ure 1); as soon as a query is attached to its query connectionthe SPARQL query is generated and run on the underlyingdataset; when the results are ready, they appear in a tabularformat attached to the results connection of the executionblock. Data from the table is represented as IRI blocks andliteral blocks that can be dragged and used to refine thesame query or to create a new one. The table of results canbe seen in Figure 1 as well 3.</p> <p>To effectively favour this kind of exploration, the toolboxalready contains some pre-built queries that can be used toaccess the main features of a dataset. These pre-built queriesare just a set of pre-connected blocks that can be freelyrearranged and decomposed on the workspace. Figure 2shows one of the pre-built queries, used to look for classesin the dataset.</p> <p>For example, in order to find the class used for moviesin the dataset, the user drags the query in Figure 2 to theworkspace and replaces the empty string in the provided thatblock corresponding to the filter clause in SPARQL with the word movie. The execution of the query, shownin Figure 3, returns all the classes in the dataset with alabel containing the word movie. In this case the first rowcontains the class the user was looking for: dbo:Film. Thefollowing is the corresponding SPARQL query.</p> <p>prefix rdfs: prefix owl: </p> <p>select distinct *where {</p> <p>3Here and in the following examples, the results shown arefrom the DBpedia [11] dataset.</p> <p>?type a owl:Class;rdfs:label ?label.</p> <p>filter( contains (?label , movie ) ).}order by strlen (?label)limit 5</p> <p>The dbo:Film block can be dragged from the query resultsand directly reused. Other pre-built queries allow users toretrieve and reuse the other IRI blocks for the query in Fig-ure 1. Thus, users need not use external means for exploringvocabularies and datasets before designing their queries.</p> <p>5. IMPLEMENTATIONThe presented tool is based on an extension of the Blockly</p> <p>JavaScript library, that works entirely client side. We ex-tended the library to supply the specific blocks needed forSPARQL queries and execution. We also added the neces-sary code to generate SPARQL fragments from the blocks.The SPARQL execution block listens for changes in its queryconnection; each time the query changes, the correspondingSPARQL query is generated and sent to a SPARQL end-point. The SPARQL endpoint used can be set through con-figuration of the client code, but in the future it could ratherbe chosen through the user interface. The results are usedto dynamically generate the result block and its subblocks.The standard prefix definitions from are used to addprefix declarations in the query sent to the endpoint and toconvert the IRIs in the result to the prefixed notation.</p> <p>6. EVALUATIONAn initial evaluation of the tool is derived based on the</p> <p>most relevant dimensions enumerated by Green and Petrefor the assessment of visual pro...</p>