QueryVOWL - Visual Query Language for Linked Data

Language Reference for Version 1.0 – 27 May 2015


Authors:
Florian Haag, University of Stuttgart
Steffen Lohmann, University of Stuttgart
Stephan Siek, University of Stuttgart
visualdataweb.org »

Abstract

QueryVOWL is a visual language that can be used to express queries on Linked Data. Visually, it is based on VOWL. Semantically, it is defined by mappings to SPARQL fragments.


Table of Contents

  1. Overview
  2. Visual Notation
  3. Results Preview
  4. Acknowledgments
  5. References

Overview [back to top]

QueryVOWL is a visual query language. It can be used to express restrictions on data being searched for in a graphical way. QueryVOWL represents the search restrictions in the form of visual graph patterns.

The QueryVOWL notation is based on the ontology visualization VOWL. Graphical elements from VOWL were reused for QueryVOWL and redefined for query contexts where appropriate.

The elements of the QueryVOWL notation are semantically defined by means of SPARQL query fragments, or instructions how to generate such fragments, based on the graph context of the QueryVOWL elements.

QueryVOWL queries can be applied to RDF graphs (or to any other graphs with an equivalent triple-based structure). For the sake of simplicity, the following text will only refer to RDF graphs. The result set of a query is the set of all subgraphs from the RDF graph that match the pattern expressed by the QueryVOWL query. More concretely, each matched subgraph is a set of IRIs and literal values mapped bijectively to the nodes and edges of the QueryVOWL query. Every IRI and literal value that is mapped to a node or edge of the QueryVOWL query in at least one result shall be called 'eligible' (for being mapped to said QueryVOWL graph element).


Visual Notation [back to top]

The following tables list the graphical representations of concepts supported by QueryVOWL. The representations are provided as Scalable Vector Graphics (SVG) in this document.

The results preview is represented by the text "[results]" in the tables. The actual appearance of the results preview depends on the implementation.

Table 1. Graphical representations of individuals and literal values.
Graphical representation Description SPARQL mapping
[results]

A placeholder for an arbitrary individual.

The individual may be restricted by connections to other nodes. Each result for the complete query assigns a particular individual to a placeholder.

Circle with the same visual appearance as a VOWL OWL class. The circle contains a results preview.

A new variable is created for each individual:

?x
Class [results]

A placeholder for an individual of a given type.

An individual can be restricted to belong to a given class. In that case, the class name is indicated above the results preview.

The variable representing the individual is included in a triple that restricts the type:

?x a example:Class .
Individual Individual [results]

A specific individual is represented by a circle whose visual style matches that of a VOWL RDFS class.

Such a specific individual node can either be interpreted as a constant value in the graph pattern, or as a set of values restricted to exactly one value. In order to reflect the latter interpretation, a results preview can be optionally displayed below the name of the individual.

The IRI of the individual appears in the query:

example:Individual
Class1 [results] Class2 [results]

A Union node acts as a placeholder for any one individual or literal eligible for the connected nodes.

The VOWL Union notation is used to represent a Union node.

A new variable is generated for each Union node. Restrictions valid for any connected nodes (restrictions defined both in the connected nodes and the first level of connections to other nodes) are applied to the new variable and combined to a UNION:

?x a example:Class1 .
?y a example:Class2 .
{
  ?s a example:Class1 .
} UNION {
  ?s a example:Class2 .
}
Class1 [results] Class2 [results]

An Intersection node acts as a placeholder for individuals to which all restrictions of all connected nodes apply.

The VOWL Intersection notation is used to represent an Intersection node.

A new variable is generated for each Intersection node. Restrictions valid for any connected nodes (restrictions defined both in the connected nodes and the first level of connections to other nodes) are applied to the new variable:

?x a example:Class1 .
?y a example:Class2 .
?s a example:Class1 ;
   a example:Class2 .
Literal

A rectangle with a dashed border, like the VOWL RDFS literal, and the text "Literal", or the name of a datatype, represents an unrestricted literal value.

Just like an unrestricted individual, an unrestricted literal value is represented by a new variable:

?l
="Value"

A restricted literal value is displayed as a rectangle with the same visual style as a VOWL RDFS datatype node. The restriction is displayed as a text consisting of a comparison operator and a value supplied for the comparison.

The restriction is added as a FILTER expression:

FILTER(?l = "Value") .

In the following table, edges are depicted connected with individual nodes. The same edges can also be used with literal nodes.
Table 2. Graphical representations of properties and other relationships between individuals and literals.
Graphical representation Description SPARQL mapping
[results] [results]

The connection of two individuals, or an individual and a literal, by a property can be enforced with a property edge.

The property edge looks like a VOWL ObjectProperty.

For unrestricted properties (i.e., properties that may have any IRI as long as they connect the indicated individuals in the specified direction), the label box on the property edge is empty.

A new variable is generated for the property and used as a predicate in the triple pattern between the connected nodes:

?x ?p ?y .
[results] property [results]

The connection of two individuals, or an individual and a literal, by a property can be enforced with a property edge.

The property edge looks like a VOWL ObjectProperty.

The property is supplied as a predicate in a triple pattern between the connected nodes:

?x example:property ?y .
[results] property [results]

Undirected property edges can be used to express a connection of two individuals, or an individual and a literal, by a property without specifying its direction.

The undirected property edge looks like other property edges but lacks an arrowhead. Both unrestricted and restricted properties can be undirected.

The two triples expressing the two directions are combined to a UNION:

{
  ?x example:property ?y .
} UNION {
  ?y example:property ?x .
}

For restricted properties, the SPARQL property path syntax may be used alternatively:

?x example:property|^example:property ?y .
[results] (disjoint) [results]

To enforce that two individuals or literals are different, they can be connected with a disjoint edge.

The disjoint edge looks like the VOWL DisjointWith notation.

A FILTER expression is used to enforce that the two connected nodes are different:

FILTER(?x != ?y) .


Results Preview

QueryVOWL provides several options to integrate previews of results. The following table gives some information about the different options.

Table 3. Overview of results previews.
Graphical representation Description
42

Elements representing sets of individuals can indicate a preview of the results for that set in their text. Typically, this will be the number of elements in the set (i.e., the number of individuals that can be inserted for the respective node, as determined by the SPARQL Count function on the variable linked to the individual node), but other information could also be displayed, depending on the dataset and the use case.

Class1 10 Class1 90

If the set of individuals is represented as a circle, the radius can optionally be modified to indicate the number of eligible individuals. To prevent inconveniently small or large nodes, minimum and maximum radii are adviseable. Also, use of a non-linear scaling function is recommended.

Acknowledgments [back to top]

The authors would like to thank Thomas Ertl and Stefan Negru for their valuable feedback, suggestions, and support.


References [back to top]

(References have been updated on June 06, 2015)