=Paper=
{{Paper
|id=Vol-1556/paper6
|storemode=property
|title=Visual Querying of Linked Data with QueryVOWL
|pdfUrl=https://ceur-ws.org/Vol-1556/paper6.pdf
|volume=Vol-1556
|authors=Florian Haag,Steffen Lohmann,Stephan Siek,Thomas Ertl
|dblpUrl=https://dblp.org/rec/conf/esws/HaagLSE15b
}}
==Visual Querying of Linked Data with QueryVOWL==
https://ceur-ws.org/Vol-1556/paper6.pdf
Visual Querying of Linked Data with QueryVOWL
Florian Haag, Steffen Lohmann, Stephan Siek, and Thomas Ertl
Institute for Visualization and Interactive Systems, University of Stuttgart,
Universitätsstraße 38, 70569 Stuttgart, Germany
{florian.haag,steffen.lohmann,thomas.ertl}@vis.uni-stuttgart.de
Abstract. In order to enable users without any knowledge of RDF and SPARQL
to query Linked Data, visual approaches can be helpful by providing graphical
support for query building. We present QueryVOWL, a visual query language
that is based upon the ontology visualization VOWL and defines mappings to
SPARQL. We aim for a language that is intuitive and easy to use, while remaining
flexible and preserving most of the expressiveness of SPARQL. In contrast to
related work, the queries can be created entirely with visual elements, taking into
account RDFS and OWL concepts often used to structure Linked Data. This paper
introduces the QueryVOWL notation and illustrates the approach with example
queries. The queries have been created with two prototypical implementations
that demonstrate the general applicability of the approach. The comprehensibility
and usability of the approach have been evaluated in a qualitative user study,
indicating that lay users are able to construct and interpret QueryVOWL graphs.
1 Introduction
An increasing amount of Linked Data is being published and ready for consump-
tion [4,12]. The data is not only of interest to the Semantic Web community but first and
foremost to lay users and domain experts from different areas [17]. A large portion of
Linked Data is available in RDF format and can be queried using the standardized query
language SPARQL [6,12]. However, writing SPARQL queries is not an easy task and
requires technical knowledge on RDF, HTTP, and IRIs, among others. Since lay users
cannot be expected to have this knowledge, visual interfaces are needed that provide
graphical support for querying Linked Data.
Experience from relational databases and SQL querying can only partly be reused,
as the data is organized in fixed table structures in those databases. Linked Data, by
contrast, is often represented as an RDF graph, more related to the representations in
graph databases, and SPARQL is designed to retrieve information from this graph-based
data. Appropriate solutions must therefore address the unique specifics of SPARQL and
Linked Data, such as the schema-independent description of resources and the use of
IRIs for global identification.
In this paper, we introduce QueryVOWL, a novel approach for visual querying that
reuses graphical elements from the Visual Notation for OWL Ontologies (VOWL) [26]
and defines SPARQL mappings for them. The ultimate goal is a visual query language
that is intuitive and easy to use, while remaining flexible and preserving most of the
expressiveness of SPARQL. In contrast to related work, users do not need to provide
structured text input but can create queries entirely with graphical elements.
2 Related Work
Several approaches to support the querying of Linked Data have been proposed in the
last couple of years. A popular paradigm is form-based querying, where the queries
are composed using form elements. Examples of this approach are SPARQLViz [14],
Konduit VQB [7], or the Graph Pattern Builder of the DBpedia project [8]. Users create
queries step by step in these tools, by entering variables, identifiers, filters, and restric-
tions in distinct forms. While form-based querying can be very usable, it offers a rather
linear way of query building that is less flexible than other querying paradigms. Further-
more, the available approaches are not designed for lay users but for people who have
some knowledge of RDF and SPARQL and are familiar with the triple representation.
Graph-based querying usually provides more flexibility than the form-based para-
digm, by using node-link diagrams to create arbitrary SPARQL query patterns. Exam-
ples for such approaches include NITELIGHT [29], iSPARQL [5], RDF-GL [23], and
LUPOSDATE [18]. However, the visual query languages used in these tools are still
very close to the RDF and SPARQL syntax: Although the triples are visually combined
to node-link diagrams, they strictly follow the subject-predicate-object notation of RDF
instead of providing a higher degree of abstraction. While this is fine for expert users,
lay users are known to have problems with the low-level semantics of RDF graphs [17].
The same holds true for many works that use a slightly higher degree of abstraction
in the query visualization. One such approach is to support the composition of SPARQL
queries with UML-based diagrams [9]. While these types of diagrams can further re-
duce the challenges of querying Linked Data, they are still comparatively difficult to
use for lay users [27].
There are also approaches that completely abstract from the SPARQL syntax. For
instance, SparqlFilterFlow [19] supports the visual composition of SPARQL queries
by letting users create filters connected by flows. However, edges in SparqlFilterFlow
represent logical connections between filter criteria rather than property links between
classes or individuals. Thus, the focus is on the logical combination of filter criteria,
whereas object relations made explicit in QueryVOWL are not directly displayed.
Also related are visual interfaces that query Linked Data as part of the browsing pro-
cess, for instance, by generating and sending SPARQL queries in the background. Ex-
amples of such Linked Data browsers include Tabulator [11], Disco [2], and gFacet [22]
(more browsers are surveyed in [17]). These browsers are comparatively easy to use, but
have been designed with particular types of queries in mind and are therefore limited
in their flexibility and expressiveness. Similar constraints apply for visual approaches
that query Linked Data for specific purposes, such as relationship discovery [21] or to
explore context information about locations [10].
Finally, QueryVOWL is related to the more general topic of visual querying on
graph databases. Examples in this area are the visual query language qGraph [13] or
a visual graph-based system for genomics data [16]. In contrast to those attempts,
QueryVOWL specifically addresses RDF and SPARQL that Linked Data is usually
based on, and defines reusable mappings for the visual language. It is therefore re-
lated to open web standards and the clearly specified VOWL notation. This is different
from visual querying approaches in the context of graph databases, which often use un-
derspecified or even proprietary languages that work only on specific graph databases.
3 QueryVOWL
We decided to base the visual query language on the VOWL notation, which has proven
to be comparatively intuitive and understandable, also and especially to lay users [26,27].
Furthermore, it provides the degree of abstraction we consider helpful to ease the query
building, as VOWL has been designed for RDFS and OWL, and concepts from these
vocabularies are often used to structure Linked Data.
3.1 VOWL
VOWL defines mappings of OWL language constructs to graphical elements that are
combined to node-link diagrams. Figure 1 shows the VOWL visualization of a small on-
tology created with WebVOWL 0.3 [25]. Classes are represented by circles that contain
the class name, whereas datatypes are displayed as rectangles with a border. Property
names are shown inside borderless rectangles that are complemented by arrow lines
indicating the direction of the properties. Some language constructs are expressed in a
different way, such as subclass relations or special OWL classes.
In addition, VOWL comes with a set of colors that are defined in an abstract way
according to their function in order to allow for custom color schemes. Shapes and
textual labels in VOWL have, however, been chosen in a way so no essential information
is lost if the colors are absent [26]. All elements and visual attributes of VOWL are
precisely defined in a specification document [28].
Literal
UserAccount Item Concept
(external) (external) (external)
tagClabel
(functional)
creatorCof Thing
SubclassCof SubclassCof
automaticC...
taggedCres... hasCcreator
(functional) (functional)
Thing taggedCwith tagCmeaning
hasCtag meaningCof
hasCaccess Tag
Tagging tagCof
(functional)
grantCaccess previousCtag
(functional)
SubclassCof SubclassCof nextCtag
(functional)
tagCcreated
taggingCcre...
taggingCmod... (functional)
(functional)
PrivateCTagging
AutomaticCTag
dateTime dateTime dateTime
Fig. 1: Small ontology (MUTO [24]) visualized with WebVOWL 0.3 [25].
3.2 Visual Elements
In contrast to VOWL, which has been designed to visualize complete ontologies, the
purpose of QueryVOWL is to express user-defined filter criteria for searching specific
1 PREFIX foaf:
politica.. 2 PREFIX dbpp:
2 3 PREFIX dbpr:
4 PREFIX dbpo:
5
Person
18 6 SELECT ?Node1
7 WHERE {
8 ?Node1 a foaf:Person .
universi.. 9 ?Node1 dbpp:almaMater ?Node2 .
3 10 dbpr:Barack_Obama dbpo:almaMater ?Node2 .
11 ?Node2 a dbpo:University .
12 { ?Node1 ?Link5 dbpr:Barack_Obama . }
13 UNION { dbpr:Barack_Obama ?Link5 ?Node1 . }
Barack O.. 14 ?Node1 dbpp:party ?Node3 .
15 ?Node3 a dbpo:PoliticalParty .
16 }
Fig. 2: Example of a QueryVOWL graph, along with the SPARQL query resulting from
that graph (when class Person is focused, as indicated by the red border).
RDF graphs in Linked Data. The basic idea is to visually model a partial graph that
is presumed to exist in a dataset. The graph defines certain restrictions, with some of
its elements being placeholders. This mimics SPARQL, which allows to define graph
patterns where some elements are variables.
When a QueryVOWL graph is applied to a given RDF dataset, all subgraphs from
the dataset that match the query are retrieved, as with a SPARQL query. One differ-
ence is that the SPARQL query explicitly specifies the format and selection of results
(for instance, as a list of table columns), and so do visual queries in related query vi-
sualizations [18,29]. In contrast, QueryVOWL enables users to dynamically explore
the matches for parts of the graph. Therefore, result retrieval in QueryVOWL works
by selecting any of the elements in the visual query to retrieve the set of matching re-
sources. Visualization approaches outside the scope of QueryVOWL can then be used
to display the results in a user-friendly way, for instance, on a map or timeline as in
NITELIGHT [29] and similar tools.
The VOWL property notation is used to represent properties that connect specific
individuals or sets of individuals, analogously to related work [5,22,23]. Different from
VOWL, QueryVOWL allows to add properties without specifying the direction. In these
cases, matching properties can point in both directions. It also permits empty property
labels, in which case all matching properties are considered.
Table 1 outlines the visual elements that QueryVOWL consists of, as well as their
mappings to SPARQL query fragments. Figure 2 shows a small QueryVOWL graph
assembled from the visual elements, along with the SPARQL query that results from
the graph based on the selected element.
3.3 Interactive Editing
Our goal is to allow for WYSIWYG editing of the query graph, and to provide a foun-
dation for supporting users while extending their queries. Therefore, various interaction
elements for adding, removing, and editing of elements must be added to the visualiza-
Table 1: Visual elements of QueryVOWL and their translation into SPARQL.
QueryVOWL Element SPARQL Mapping
The VOWL class notation is Each set of individuals is repre-
used to represent sets of in- sented by a unique variable. If
dividuals. The label indicates the class of the individuals is re-
the class the individuals are re- stricted, that restriction is added
stricted to. If no label is set, the class of the individuals as a triple:
is not restricted. Similar to VOWL, the size of the circle ?x a dbpo:Volcano .
may be used to roughly indicate the number of matching The number of individuals is re-
individuals. The exact number is additionally displayed. trieved with the count function.
The VOWL notation for RDFS classes is used Single individuals are represented
to represent a single individual. by their IRI:
dbpr:Aracar
The VOWL property notation Properties are represented as
is used to represent properties predicates in the triples:
that connect sets of individuals ?x a dbpo:Album .
and/or single individuals. Like in VOWL, the arrow line ?x dbpp:artist
indicates the direction of the property. dbpr:Vangelis .
If the VOWL property notation ?y a dbpo:Politician .
is used without an arrowhead, { ?x dbpo:child ?y . }
matching properties can point in UNION
both directions. { ?y dbpo:child ?x . }
The VOWL literal Each literal is represented by a
notation is also used unique variable used in all triples
in QueryVOWL. It and filters that refer to that literal:
can be restricted either by using specific values or by ap- ?x a dbpo:Astronaut .
plying filters, such as range or pattern restrictions. Literals ?y a dbpo:Cyclist .
can be connected to more than one property to define that ?x foaf:surname ?v .
they shall have the same value as range. ?y foaf:surname ?v .
The VOWL notation for ?x a dbpo:Painter .
disjointedness is used to ?y a dbpo:Architect .
define that the individuals FILTER(?x != ?y).
in different sets are disjoint.
The VOWL union nota- ?x a dbpo:Bird .
tion is used to represent ?y a dbpo:Fish .
the set of individuals that { ?s a dbpo:Bird . }
are contained in at least UNION
one of the connected nodes. { ?s a dbpo:Fish . }
The VOWL intersection ?x a dbpo:Painter .
notation is used to repre- ?y a dbpo:Poet .
sent the set of individuals ?s a dbpo:Painter ;
that are contained in all xxxa dbpo:Poet ;
connected nodes. xxxfoaf:surname ?n .
tion. As they are only required for interaction, implementations may hide those elements
unless interaction is imminent, for instance, when an element is hovered (Figure 3).
Fig. 3: Interaction elements are hidden and only appear on demand.
To require a property connecting two existing nodes, the respective edge may be
added directly from one of the involved nodes. Likewise, when a property needs to
be added to an existing node, a list of properties that are connected to any individuals
matching the restrictions of the node may be displayed to help users find an appropriate
property.
Whenever the graph structure or restrictions are modified, any connected class nodes
will dynamically update their counts. This helps users immediately recognize the effects
of their changes and provides them with a way to estimate whether further extensions
or restrictions are required to retrieve a meaningful result. Some nodes can be excluded
from this update process to reduce server load: Subgraphs that are exclusively connected
via nodes restricted to specific individuals are only included in the SPARQL query if
they contain the focused element. To retrieve all that information, as well as the final
result set, the internally generated SPARQL queries are sent to a SPARQL endpoint that
can be chosen as a backend in the visualization.
3.4 Language Limitations
QueryVOWL covers a part of the SPARQL query language, but, to date, also omits
some elements. Literal nodes can be restricted based on constant values, and they can
be used to express that several individuals are connected to the same property value.
A visual representation for other types of relationships, such as inequality or asymmet-
ric relationships (greater than, less than, etc.), has not yet been defined. Furthermore,
we focused on a straightforward setup where a query is sent to the default graph of
a dedicated endpoint. Federated queries or named graphs are currently not included
in QueryVOWL, although it should be noted that implementations might support such
features as a part of their backend configuration, without any explicit indication in the
QueryVOWL visualization.
There are also some OWL concepts represented by graphical elements in VOWL,
for which we did not define related QueryVOWL elements yet. While it might be de-
sirable to create a query where something is connected to the complement of a set
restricted by filters, we have not yet devised a SPARQL mapping for such an element.
Likewise, cardinalities might be added to the visual notation—for instance, to search
for all individuals of a given type that have at most two values for a given property—,
but we deemed the SPARQL representation of such a restriction too problematic at the
current state of development.
4 Exemplary Queries
The following examples illustrate how the visual elements of QueryVOWL can be as-
sembled to query graphs. As QueryVOWL is independent of any particular dataset, we
are using different datasets in the examples, all accessed by their SPARQL endpoints.
movie
216
person person
102 108
Fig. 4: DBpedia knows about two persons who starred in movies together with at least
one of their children.
Who starred in a movie together with his or her child? Figure 4 shows a QueryVOWL
graph based on DBpedia for retrieving any movies along with two of their actors, one
of whom must be the child of the other. The latter actor is focused, as the graph is used
to identify the elder actor of the two (according to the direction of the property child).
Which authors published on both conferences ESWC and WWW in the same year?
The QueryVOWL graph created for the Faceted DBLP dataset [3] is depicted in Fig-
ure 5a. It asked for authors of two works, which are linked via the year of issue to
indicate that they were published in the same year (any same year). One of the works
should belong to the series ESWC, the other to the series WWW.
Which countries have at least two different industries and participate in the World
Health Organization? This query is shown in Figure 5b, based on the CIA World
Factbook [1]. A disjoint edge is used to indicate that the sets of individuals in the two
Industry nodes are supposed to be different. WHO is represented by an individual node.
5 Evaluation
We have evaluated the applicability and usability of the approach by implementing it in
two interactive prototypes and by conducting a qualitative user study.
(a) There are 188 authors who published at ESWC (b) The CIA World Factbook contains data
and WWW in the same year according to Faceted on 195 countries that have at least two dif-
DBLP. ferent industries and participate in the World
Health Organization.
Fig. 5: Examplary QueryVOWL graphs.
5.1 Implementations
The two prototypes are based on different technologies to verify various aspects of the
approach and to get an idea of how well it can be implemented with different frame-
works and development techniques.
Web-Based Implementation The web-based prototype (Figure 6a) implements the
main elements of the visual query language and provides an opportunity to try the look
and feel of an interactive QueryVOWL implementation.1 It is based on open web stan-
dards (HTML, JavaScript, CSS, SVG) and integrates some JavaScript libraries, most
importantly D3 [15] for the visualization of the query graph.
Users can create and modify QueryVOWL graphs by adding and removing visual
elements as well as positioning nodes with drag-and-drop. Restricted and unrestricted
class nodes, properties (both directed and undirected), individuals, and literal nodes are
supported. The union, intersection, and disjointedness operators, as well as literal filters
for types beside date-time, have not yet been included. Query building is supported by
automatic updates upon changes to the graph, asynchronous loading of lists of resources
compliant with the current selection, and configuration options that are displayed when
hovering over elements.
A sidebar provides information about the selected element, as well as options to
modify its filter restrictions and to add linked elements. A result list at the bottom shows
the labels and IRIs of all individuals that are valid replacements for the selected class
node.
1
The web-based prototype is available at http://queryvowl.visualdataweb.org.
A demo of that prototype has been presented at ESWC 2015 [20].
(a) Web-based implementation. (b) C# implementation.
Fig. 6: Screenshots of two prototypical QueryVOWL implementations.
Stand-Alone Desktop Application The desktop application (Figure 6b) runs on the
Microsoft .NET Framework and was created in C# with the Windows Presentation
Foundation (WPF) user interface toolkit. It is intended as a showcase for the object-
oriented implementation of the QueryVOWL elements that uses polymorphism for the
generation of SPARQL query strings based on the rules outlined in Table 1.
The desktop prototype implements all QueryVOWL elements listed in Table 1, but
has a limited degree of interactivity. It supports drag-and-drop, dynamic node scaling, as
well as the insertion of IRIs from the system clipboard. As in the web implementation,
SPARQL queries are automatically generated and sent to a given SPARQL endpoint.
Once the requests are answered, the retrieved result counts are displayed and nodes are
scaled accordingly.
5.2 User Study
We have conducted a qualitative user study to gather further insight into the compre-
hensibility of QueryVOWL, the usability of our interactive implementation, and some
general comments on the visual query language.
Tasks We prepared a total of eight tasks based on data from the DBpedia dataset. While
the study was conducted in German, much of the structural information in the DBpedia
dataset uses English. Therefore, all tasks were provided bilingually, to help participants
bridge any possible gaps in their English knowledge.
Pacific .. island volcano XMLSchem..
location located in area eruption date > "2010"
2 2
Fig. 7: One of the query graphs that participants of the user study had to construct. It can
be used to answer the question “How many islands contain a volcano and are located in
the Pacific Ocean?”
Seven tasks consisted of a natural language question, and possibly some more spe-
cific sub-questions. Users were asked to construct a QueryVOWL graph with our web-
based prototype that represents the question and to select the appropriate element in
the graph to find an answer to the question. Answering the question meant showing
the constructed graph and explaining briefly where on the screen the response to the
question can be found. The full set of construction questions is listed in Table 2.
person
13 death date XMLSchem..
first driver
death date
Grand Pr.. death place
27
location
person
place death place 14
11
Fig. 8: The query graph shown to the participants of the user study. Participants had to
recognize that this graph can be used to find people who passed away on the same date
and at the same place as the first driver of a Grand Prix.
The eighth task was a comprehension task, in which a QueryVOWL graph with a
selected node was shown (Figure 8). Users were asked to express the query represented
by the graph as a natural language question.
Material A MacBook Air with a 13.3 inch display, a screen resolution of 1440 × 900
pixels, and an external mouse was used during the study. The QueryVOWL implemen-
tation was executed in a Mozilla Firefox 31 browser in full-screen mode. All on-screen
activity was captured by a screen recording software to ease the analysis.
The tasks, as well as a questionnaire on demographic data and the participants’ im-
pression of QueryVOWL, were printed on paper. An introductory video with a runtime
of approximately 4.5 minutes was prepared. It explained QueryVOWL by constructing
an exemplary query step by step.
Table 2: English text of the construction tasks from the user study. For tasks spanning
several lines in this table, participants had to answer each step separately.
# Question
1 How many films did Bruce Willis star in?
Does anyone appear together with his or her child in any of these films?
What film and which child?
2 How many persons ...
... wrote a song ...
... and are connected to a band in some way ...
... that Freddie Mercury used to belong to?
How many bands are there?
3 How many persons ...
... are spouses of a senator ...
... and have any children born in or after 1935?
How many children are there?
4 How many mountains are there in Madagascar?
How many rivers ...
... originate from one of those mountains ...
... and flow into the Indian Ocean?
5 How many bridges are there in Pittsburgh?
How many of them span a river?
How many of them span the Ohio River?
6 How many islands ...
... contain a volcano ...
... and are located in the Pacific Ocean?
How many of the volcanos erupted after 2010?
7 How many politicians ...
... have a spouse ...
... and have the same birthdate as their spouse?
Participants Six participants (3 female, 3 male) between the age of 22 and 43 (median:
26) took part in the user study. All of them had different professions, none of them from
the field of information technology. None of the participants had any prior experience
with ontologies or the Semantic Web. Therefore, we could ensure that participants did
not bring any prior knowledge on querying Linked Data, which might bias the results.
Procedure The study was conducted in a closed room, with one participant at a time.
Participants were first shown the introductory video and were asked to complete a train-
ing task to get to know the visualization and the user interface. Subsequently, the sheet
with the questions was handed out, and screen recording was started.
After reading each of the tasks, participants were given an opportunity to ask ques-
tions in the case of doubts about the tasks. Participants would then start solving the
tasks, while the interaction steps were noted down.
Finally, participants were asked to complete the questionnaire to gather information
on which parts of the visualization caused confusion and which elements were helpful
for understanding the queries.
Results Participants could solve most of the tasks. Some adapted their initial query to
reach a correct solution. There was a noticeable preference for elements and features
that had been presented during the introductory video. Moreover, when constructing
QueryVOWL graphs, participants followed the provided questions very closely and
used exactly the words and the order of words found in the questions.
In general, the use of class nodes and properties was clear. Participants could under-
stand the basic graph structure and correctly identify which graph element represented
the entity searched for. Likewise, five of the six participants could easily read the visu-
alized query in the comprehension task. The only difficulty seemed to be the distinction
between class nodes and individual nodes, whose difference in color was either not
understood or not even consciously noticed by participants.
In a few cases, participants got confused during the composition tasks over the dis-
tinction between classes and properties. While they correctly identified spouse as a re-
lationship between two persons, they expected a class child rather than a child property.
Moreover, when participants were aware they had to use a property, some doubts about
the correct direction still surfaced, as they were often unsure whether, for example, the
child property points from the parent to the child (“has the child”) or vice-versa (“is
child of”).
Participants could flawlessly understand and use the literal node for single property
values, even though it had not been shown in the introductory video. The only difficulty
arose when two persons with the same birth date had to be found. Almost all participants
expected to make the comparison explicit by an equals sign or by two connected literal
nodes, rather than by simply linking the birthDate property of the two Person nodes to
the same literal node.
All participants stated that they could imagine using the approach in everyday sit-
uations. Two of them stated the technique could be used in cases where conventional
search engines are not sufficient, and two more participants could also imagine brows-
ing data in QueryVOWL without having a specific goal in mind, as the information
about possible extensions to the query is accessible in the interactive graph.
6 Conclusions and Future Work
We have built upon the ontology visualization VOWL to create QueryVOWL, a visual
query language for Linked Data. We have reused and adapted elements of VOWL, ex-
plained how they can be combined and extended, and defined how the resulting graphs
map to SPARQL queries. Based on our web-based prototype, we have conducted a
qualitative user study where we found that lay users could handle the basic query struc-
ture well, except from some more specific aspects of the visualization that were not
immediately clear to the study participants.
Based on our observations during the user study, we realized that a brief but com-
plete introduction to the elements of the notation is a successful way to quickly teach
previously untrained users how to use QueryVOWL. Furthermore, user comments sug-
gest that dynamically displayed explanations, as well as possibly a natural language
representation of the query of parts thereof, may further support comprehension. We
consider including these features in future implementations.
Other suggestions for change referred primarily to the interaction features of the
web-based implementation. Some interactive elements, such as the one for toggling the
property direction, might be placed so as to avoid accidental clicking. Also, literal nodes
could be equipped with more obvious signs to indicate that they can be connected to
more than one class or individual node.
Overall, QueryVOWL covers many concepts found in Linked Data. As the general
approach appears to be usable, we would like to consider more advanced features, such
as functions to process or transform property values for filtering. Likewise, beside en-
forcing that the property values of two or more objects match, enforcing a different
comparison relationship between these property values could also be desirable. On the
structural side, introducing existential or universal quantifiers as well as disjunctions
between alternative filter restrictions could make QueryVOWL even more powerful, if
an appropriate way of visualizing the concepts and mapping them to SPARQL can be
found.
References
1. CIA world fact book in DAML. http://www.daml.org/2001/12/factbook/
2. Disco. http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/
3. Faceted DBLP. http://dblp.l3s.de
4. Linked data. http://linkeddata.org
5. OpenLink iSPARQL. http://oat.openlinksw.com/isparql/
6. SPARQL endpoints status. http://sparqles.okfn.org
7. Ambrus, O., Möller, K., Handschuh, S.: Konduit VQB: a visual query builder for SPARQL
on the social semantic desktop. In: VISSW ’10. CEUR-WS, vol. 565 (2010)
8. Auer, S., Bizer, C., Kobilarov, G., Lehmann, J., Cyganiak, R., Ives, Z.: DBpedia: A nucleus
for a web of open data. In: ISWC ’07 and ASWC ’07, LNCS, vol. 4825, pp. 722–735.
Springer (2007)
9. Bārzdin, š, G., Rikačovs, S., Zviedris, M.: Graphical query language as SPARQL frontend.
In: ABDIS ’09, Workshops and DC. pp. 93–107. Riga Technical University (2009)
10. Becker, C., Bizer, C.: Exploring the geospatial semantic web with DBpedia Mobile. Web
Semantics 7(4), 278–286 (2009)
11. Berners-Lee, T., Chen, Y., Chilton, L., Connolly, D., Dhanaraj, R., Hollenbach, J., Lerer,
A., Sheets, D.: Tabulator: Exploring and analyzing linked data on the semantic web. In:
SWUI ’06 (2006)
12. Bizer, C., Heath, T., Berners-Lee, T.: Linked data - the story so far. International Journal on
Semantic Web and Information Systems 5(3), 1–22 (2009)
13. Blau, H., Immerman, N., Jensen, D.: A visual query language for relational knowledge
discovery. Computer Science Department Faculty Publication Series 105, University of
Massachusetts—Amherst (2001)
14. Borsje, J., Embregts, H.: Graphical query composition and natural language processing in an
RDF visualization interface. Bachelor’s thesis, Erasmus University Rotterdam (2006)
15. Bostock, M., Ogievetsky, V., Heer, J.: D3 data-driven documents. IEEE Transactions on Vi-
sualization and Computer Graphics 17(12), 2301–2309 (2011)
16. Bulter, G., Wang, G., Wang, Y., Zou, L.: A graph database with visual queries for genomics.
In: Proceedings of 3rd Asia-Pacific Bioinformatics Conference. pp. 31–40. Imperial College
Press (2005)
17. Dadzie, A.S., Rowe, M.: Approaches to visualising linked data: A survey. Semantic Web
2(2), 89–124 (2011)
18. Groppe, J., Groppe, S., Schleifer, A.: Visual query system for analyzing social semantic web.
In: WWW ’11. pp. 217–220. ACM (2011)
19. Haag, F., Lohmann, S., Ertl, T.: SparqlFilterFlow: SPARQL query composition for everyone.
In: ESWC ’14 Satellite Events, LNCS, vol. 8798, pp. 362–367. Springer (2014)
20. Haag, F., Lohmann, S., Siek, S., Ertl, T.: QueryVOWL: Visual composition of SPARQL
queries. In: ESWC ’15 Satellite Events. LNCS, Springer (to appear)
21. Heim, P., Lohmann, S., Stegemann, T.: Interactive relationship discovery via the semantic
web. In: ESWC 2010, LNCS, vol. 6088, pp. 303–317. Springer (2010)
22. Heim, P., Ziegler, J., Lohmann, S.: gFacet: A browser for the web of data. In: IMC-SSW ’08.
CEUR-WS, vol. 417, pp. 49–58 (2008)
23. Hogenboom, F., Milea, V., Frasincar, F., Kaymak, U.: RDF-GL: A SPARQL-based graphical
query language for RDF. In: Emergent Web Intelligence: Advanced Information Retrieval,
pp. 87–116. Advanced Information and Knowledge Processing, Springer (2010)
24. Lohmann, S., Dı́az, P., Aedo, I.: MUTO: the modular unified tagging ontology. In: I-
SEMANTICS ’11). pp. 95–104. ACM (2011)
25. Lohmann, S., Link, V., Marbach, E., Negru, S.: WebVOWL: Web-based visualization of
ontologies. In: EKAW 14 Satellite Events, LNAI, vol. 8982, pp. 154–158. Springer (2015)
26. Lohmann, S., Negru, S., Haag, F., Ertl, T.: VOWL 2: User-oriented visualization of ontolo-
gies. In: EKAW ’14, LNCS, vol. 8876, pp. 266–281. Springer (2014)
27. Negru, S., Haag, F., Lohmann, S.: Towards a unified visual notation for owl ontologies:
Insights from a comparative user study. In: Proceedings of the 9th International Conference
on Semantic Systems. pp. 73–80. I-SEMANTICS ’13, ACM (2013)
28. Negru, S., Lohmann, S., Haag, F.: VOWL: Visual notation for OWL ontologies. http:
//purl.org/vowl/ (2014)
29. Russell, A., Smart, P., Braines, D., Shadbolt, N.: NITELIGHT: A graphical tool for semantic
query construction. In: SWUI ’08. CEUR-WS, vol. 543 (2008)