With the adoption of Nepomuk as an organic part of KDE the semantic desktop became a reality to a great number of users and is employed by a growing number of applications. Thus, the amount of semantic data is constantly growing on the desktop. Therefore users need a way to access this data outside of the limiting use cases of the applications employing Nepomuk-KDE. We aim to assist users in building queries and running them to make use of RDF data that would otherwise be partially or completely hidden. In this paper, as an initial iteration of our efforts, we present four approaches to building SPARQL queries visually, based on two different categorizations: schema-based vs. instance-based and SELECT vs. CONSTRUCT queries. We present the used interfaces, visual languages and query generation methods associated to each of approaches as well as the autocompletion techniques for the instancebased query builders.
INTRODUCTION
The Social Semantic Desktop [
Konduit [
We want to provide a way for users to build these queries
in an intuitive way, with having no or little knowledge about
the querying language (i.e., SPARQL [
Nevertheless, several of the tools only support querying based on a single ontology, some of them do not support RDF and SPARQL. Some of them require extensive manual editing of the queries, or do not feature clear relationships between query parts. Moreover, excepting SPARQLViz, all query builders are web-based (or only usable within their own system), not allowing for the integration of desktop data. Our two schema-based interfaces are mostly built on the intuition of MashQL and GRQL, in exposing schema structures and possible restrictions branching from an initial class. The instance-based query builders resemble SPARQLViz in providing forms for the user to complete, but feature a single, less confusing and simple interface, with clear connections between the query parts.
RUNNING EXAMPLE Suppose we are searching for a contact from the local repository whose name contains the letter ‘K’ and has written a publication on the semantic desktop.
QUERY BUILDING The interface of the query builder application features a central part for the visual query builder and previewers for the query and its results, as well as menu actions and a status bar. The central query builder has four incarnations as presented in the following sections, employing different approaches to building SPARQL queries.
The most common searching interface, a search box for simple keyword searches to retrieve semantic information is highly ambiguous and needs extensive research, so abstracting completely from the structure of semantic data is not yet our intention. Also, we can’t yet provide a fully-featured mature semantic querying application, as we aim to explore the most appropriate ways to do it and research the possibilities and limitations in accomplishing this task.
The two schema-based approaches use schema information from the ontologies in the Nepomuk system, allowing users to compose tree-based queries in restricting the properties of the resulting objects. This allows users to explore the local schema structures. These approaches feature a simplification of SPARQL, in allowing only to restrict the initial selection descending in a tree-like fashion.
The instance-based approaches are based on constructing triples without necessarily knowing RDF or SPARQL (similarly to the Wikipedia Visual Query Builder2. They use schema information as well as instance information in suggesting users possibilities in completing the subjects, predicates and objects of the constraining triples of the SPARQL query. This autocompletion allows for users to explore the data stored on the local RDF repository. The instance-based query builders also allow for the construction of triples that 2http://dl-learner.org/Projects/dbpedia don’t exist in the repository, adding properties that have not been defined or converting an instance from one ontology to another, e.g., transforming ?v foaf:name ‘‘Smith’’ to ?v nco:fullName ‘‘Smith’’.
SCHEMA-BASED SELECT QUERIES The schema-based SELECT query builder (Figure 1) is the most user-friendly approach to building SPARQL queries, aimed at users having the least knowledge of semantic technologies. We have devised a simplification of the SPARQL language, which allows for this particular kind of builder. It allows for selecting a class (which will be the type of the queried variable) and restricting it in a tree-like manner through its properties.
Queries are built using schema information from Nepomuk. The possible classes and predicates to be chosen are queried and presented to the user.
We start from the assumption that users most often want to find certain information belonging to an entity of certain classification and/or having a number of known restricting characteristics. For example, one would want to search for a contact person (entity) with a given name (restricting characteristic), similarly to doing a free text search.
The interface therefore provides a way to build queries as trees, starting with the type of entity the user inquires for and progressing with restrictions on the branches of the tree. The Visual Language The visual language covers a subset of SPARQL. Listing 1 provides a formal description of the queries built through the visual facilities of the interface. Note that the missing terminal definitions ClassN ame and P redicate are IRI references, LiteralV alue is a string literal and V ariableN ame is a SPARQL variable (such as ?v or $x). Relation denotes a relation such as contains, equals, etc.
Query : : = O u t p u t s C o n d i t i o n s O u t p u t s : : = RootNode j L i t e r a l N o d e C o n d i t i o n s : : = G r a p h P a t t e r n G r a p h P a t t e r n : : = QueryTree + QueryTree : : = RootNode TreeNumber RootNode : : = ClassName VariableName R e s t r i c t i o n s R e s t r i c t i o n s : : = QueryNode QueryNode : : = C l a s s R e s t r i c t i o n j L i t e r a l R e s t r i c t i o n C l a s s R e s t r i c t i o n : : = P r e d i c a t e RootNode L i t e r a l R e s t r i c t i o n : : = P r e d i c a t e R e l a t i o n L i t e r a l N o d e L i t e r a l N o d e : : = VariableName L i t e r a l V a l u e
Listing 1. EBNF description of the visual language (non-terminals) Query Generation Queries are generated based on the visual description according to the defined language. The SELECT part of the queries will be a set of variables extracted from the components (class combo boxes or literal text boxes) selected as Outputs. It is made up of the variable names in the RootN odes and LiteralN odes, for class combo boxes or literal text boxes, respectively. This happens in a transparent way, as variables are extracted automatically from the selected components.
The WHERE clause is a set of RDF triples generated from the query tree structures present in the query form. We have the following three cases: (1) For the root RootN ode the generated triple is VariableName a ClassName and for every restriction a triple is generated starting with VariableName and continuing as presented in the following points (e.g. ?v41 a foaf:Person generated for the root node in Figure 1). (2) A ClassRestriction completes the parent’s triple with Predicate VariableName (where VariableName is the variable of the RootN ode belonging to the new restriction) (e.g. ?v41 foaf: publications ?v77 generated for the publication restriction in Figure 1). (3) A LiteralN ode completes the triple with Predicate VariableName adding a regular expression filter string according to the chosen Relation and LiteralV alue (e.g. FILTER regex(?v59, ’K’, ’i’) generated for the first restriction shown in Figure 1). User Interface The query builder form (Figure 1) allows for adding several query trees (staring from different classes), and restricting them by their properties. If a property has a literal range, the user can enter a value and restrict it on a relation, such as equals or contains. If its range is not a literal, they can add restrictions.
Outputs are selected by right clicking on a combo box representing a class or a value. The corresponding variable will be added to the output, and the combo box will be highlighted. SCHEMA-BASED CONSTRUCT QUERIES The approach to building schema-based CONSTRUCT queries is very similar to the one shown in the previous section. The difference lies in the way in which the outputs are selected.
Visual Language Extension The visual language is extended, as the output part of the queries is built using graph patterns constructed from triples. O u t p u t s : : = G r a p h P a t t e r n G r a p h P a t t e r n : : = T r i p l e + T r i p l e : : = S u b j e c t P r e d i c a t e O b j e c t S u b j e c t : : = VariableName P r e d i c a t e : : = PredicateName j VariableName j ClassName O b j e c t : : = PredicateName j VariableName j ClassName j L i t e r a l V a l u e
Listing 2. EBNF description of the output part (non-terminals) Query Generation Extension The way outputs are generated has been changed for this query builder: in this case outputs are triples and consist of the triples described in the graph pattern.
User Interface Extension The user interface is extended with a component for composing output triples, as shown in Figure 2. It lists all variables for the subject field, all variables, predicates and classes for the predicate field and all variables, predicates, classes and literal values for the object field. Users can select desired triples and add them to the output list.
INSTANCE-BASED SELECT QUERIES Building queries with the instance-based SELECT builder relies on schema and instance information from the underlying RDF repository.
The Visual Language
Variable, class and predicate names are IRIs describing the
corresponding entities, as described for the previous builders,
where the meaning of Relation is also explained. Instance
IRIs are taken from the repository as autocompletion
popups based on user input. The LiteralV alue represents valid
SPARQL literals, such as strings or integers (e.g.
"Example" ). See Listing 3 for the formal EBNF description.
Listing 3. Visual language of the instance-based SELECT query
builder
Query Generation
Queries are constructed by enumerating the variable names
for the SELECT part and taking the list of triples for the
WHERE part. Filter expressions are built by adding a
regular expression filter string according to the chosen relation.
Autocompletion
The interface features an incremental autocompletion for the
WHERE part based on user input described in [
User Interface The user interface features a component for building conditional (WHERE) triples, as shown in Figure 3. The text fields provide autocompletion popups for user input, based on what the repository contains, against the triples that have already been added to the output list. The user can select a filter option using the desired relation or can specify the type of the object, the latter defining the way it will be formatted and/or suffixed in the output.
Outputs are selected from an output list that is populated with all the variables occurring in the conditional triples. INSTANCE-BASED CONSTRUCT QUERIES Visual Language Extension The visual language is extended with triple patterns for the output part as well. They are identical to the GraphP attern nonterminal defined for instance-based SELECT queries. There is one exception, namely the lack of F ilterExpressions, since such expressions do not exist in the output part of SPARQL queries for obvious reasons. Query Generation Extension The query generation is extended by taking the triples from the Output graph pattern and enclosing them in the CONSTRUCT part of the query.
Autocompletion Extension This interface also supports autocompletion for the output part of the query, similarly to its sibling interface. There is a slight modification, however, since the output triplesv´alues do not need to satisfy any conditions, only being present in forming the output triples. Thus, it is not required to comply with the rest of the graph pattern, so all existing entities are suggested to the user, that match the given input.
User Interface Extension The user interface is extended with an output construction part, shown in Fig. 4, having an almost identical structure to the triple building component for the conditional (WHERE) part, excluding the filtering option.
DISCUSSION The schema-based SELECT query builder allows for simple querying and restricting the desired properties with userdefined input. The advantage is that it is simple, intuitive and satisfies the large number of occasions when the user wants to search for something based on certain properties. Selecting the outputs is also straightforward and clear. The disadvantage is that it is limiting and inflexible, only allowing querying as trees, thus being unsuitable for some cases a proficient user would meet.
The schema-based CONSTRUCT query builder allows to construct triples, this being required in many cases (in Konduit, all data are RDF triples). The advantages/disadvantages are similar to its sibling approach, adding the complication of selecting the correct variables and classes for the output triples, but adding the flexibility of formatting the output. For the instance-based SELECT query builder we have the advantages of conditioning the results in a flexible, datadriven manner (with autocompletion based on the data in the repository), using user-defined variables and types, and reusing variables. The disadvantage is that it features a direct correspondence of the underlying RDF structure, making it more complicated than the schema-based interfaces. The instance-based CONSTRUCT query builder is the most flexible, triple-based query assistant, making it possible to compose advanced queries, with the obvious disadvantage of being the least accessible to na¨ıve users.
CONCLUSIONS We have presented four techniques to assist users in building SPARQL queries to retrieve information from the evergrowing collection of semantic data. Aimed at beginners and proficient users as well, the interfaces feature a range of approaches that ease the composition of queries. The query builders are based on the local (or possibly, remote) repository, facilitating the discovery of the RDF store.
The first two approaches relied solely on schema information, helping the users to query for instances of existing classes and restricting them with the available properties. One of these is intended for writing SELECT queries by selecting a set of outputs, the other one is for CONSTRUCT queries presenting the used variables, predicates and classes in three lists for selecting the subject, predicate and object. The other two approaches use instance information as well in providing autocompletion popups based on user input to suggest possible options, taking into consideration the triples previously added. The SELECT query builder simply allows for selecting the variables used in the query for output, and the CONSTRUCT query builder allows for composing triples from the variables used and all existing entities in the repository.
We plan to perform a usability evaluation in determining the most appropriate tool from the ones presented for building SPARQL queries within Konduit and Nepomuk-KDE. We will present it to users with no RDF/SPARQL background as well as users with deep knowledge in semantic technologies to decide on the future direction in what approach and features best suits a SPARQL query builder aimed at a fairly wide variety of users.
Acknowledgments The work presented in this paper has been funded (in part) by Science Foundation Ireland under Grant No. SFI/08/CE/I1380 (L´ıon-2) and (in part) by