We present a novel way to draw SPARQL aggregate queries via diagrammatic query language - ViziQuer. Since the introduction of SPARQL different graphical languages have been proposed to make SPARQL more userfriendly. In SPARQL 1.1 aggregate queries were introduced that are key to meaningful query formulation. However, diagrammatic query languages lacked this important end-user feature to make the diagrammatic SPARQL extensions powerful enough.
SPARQL [
The diagrammatic query languages introduced to help formulating SPARQL
queries, for instance, an earlier version of ViziQuer [
The demonstration will show creation of aggregate SPARQL queries in the ViziQuer
notation that is the main novelty of this paper. An extended outline of the design of the
visual aggregate queries appears as [
The visual/diagrammatic query definition is based on the data schema definition as
OWL ontology or RDF Schema. We use the following example mini-University
ontology that is presented in Figure 1 in graphical OWLGrEd ontology editor notation [
Student studentNam e personID student 1 enrolled 1 AcademicProgram
programName nationality 0..1 Nationality nCode
Registration mark:integer
takes includes Course
courseName course 1 courseCredits :integer
A query in ViziQuer is a graph of class instance nodes connected with links
corresponding to triples connecting these instances. Each node shows the instance class
name (e.g. Registration, Student in Fig.2), possibly an explicit instance reference (e.g.
R and S), as well as conditions (e.g. mark>=4) and selection instances and attributes
(e.g. R and mark for Registration class). One of the classes in the query is marked as
the main query class (shown as orange round rectangle) while all other classes (shown
as violet rectangles) are called condition classes [
There can be affirmative (black solid line), optional (blue/light dashed line) or negation (red line with stereotype {not}) links within the query. The default interpretation of optional or negation link is to mark the entire subgraph placed behind the link (from the viewpoint of main query class) as optional or negated respectively. A negation link with {condition} stereotype is interpreted as the non-existence of the respective link between its end instances (the query graph is required to have a spanning tree consisting of all its non-condition links).
R mark>=4 R mark student course
sn=studentName
courseCredits>=6 cn=courseName
The aggregation options can be included into the queries just by introducing into class instance attribute lists aggregate expressions where an SPARQL aggregate function (e.g. count, sum, avg) is applied to a non-aggregated (i.e. plain) attribute expression, for instance, as in sum(courseCredits) in Fig. 3.
The semantics idea is to compute aggregate values taking as the grouping set all
nonaggregated attributes specified in the query. A direct implementation of this idea would,
however, lead to counterintuitive results since the aggregated instance attribute value
would be included into the aggregation as many times as the instance appears in some
instance graph matching the query. We offer a more refined semantics that we explain
for the case, if all aggregate attributes are placed within single class of the query, we
call it aggregation class. In the case of aggregate attributes in different classes separate
subqueries are to be made for each aggregation class with their results merged (cf. [
The SPARQL query generation follows three steps: (i) the raw query with aggregation function arguments (plain attributes) instead of aggregate attributes is generated; (ii) the distinctness list for aggregation computation over the raw query is formed, consisting of all attributes (both non-aggregated and aggregated ones alike) and instances of so-called multiplicative classes. The multiplicative class set by default includes the main query class and the grouping class; the set can be extended by ascribing the <<all>> stereotype to a class in the query, a class can be excluded from the set by the <<exists>> stereotype; (iii) the aggregation over the distinctness-list selection from the raw query is formed by aggregating the aggregation attributes and grouping on all non-aggregated attributes.
Figure 3 depicts two variants of the natural language query “find all nationalities and the sum of credit points of courses taken by students of this nationality”. The first query counts every course once per nationality, while the second one - once per nationality and student, since the Student class is in the multiplicative class set for the query and therefore an extra ?S appears in the query distinctness list (leading possibly to counting credit points of a single course several times per nationality).
N nCode
N nCode nationality nationality
S takes <<all>>
S
C ss=sum (courseCredits)
C takes ss=sum (courseCredits)
SELECT ?nCode ?ss WHERE{ {SELECT (SUM( ?courseCredits) as ?ss) ?nCode WHERE{ {SELECT DISTINCT ?N ?C ?nCode ?courseCredits WHERE{ ?N a ont:Nationality. ?N ont:nCode ?nCode. ?S a ont:Student. ?S ont:nationality ?N. ?C a ont:Course. ?S ont:takes ?C. ?C ont:courseCredits ?courseCredits.}}} GROUP BY ?nCode}} SELECT ?nCode ?ss WHERE{ {SELECT (SUM( ?courseCredits) as ?ss) ?nCode WHERE{ {SELECT DISTINCT ?N ?C ?S ?nCode ?courseCredits WHERE{ ?N a ont:Nationality. ?N ont:nCode ?nCode. ?S a ont:Student. ?S ont:nationality ?N. ?C a ont:Course. ?S ont:takes ?C.
?C ont:courseCredits ?courseCredits.}}} GROUP BY ?nCode}}
The ViziQuer tool supports also explicit subquery introduction via {group}
stereotype on affirmative and optional links [
The demonstrated ViziQuer tool is freely available online at viziquer.lumii.lv and the
users are welcome to download it, import their ontologies/RDF schemas and start
creating visually their own SPARQL queries. The introduced notation raises a hope of
introducing a wider range of specialists to direct use of RDF/SPARQL-organized data
as the ViziQuer tool will assist in creating complex statistical queries (the need for
initial user training is foreseen). The potential usage scenarios for the ViziQuer tool
involve both exploring SPARQL endpoints [
There is an important practical query pattern “find all x with their related most common y” (e.g. find all courses with the most often received marks in them) that can be expressed in a slightly extended diagrammatical query notation, still queries of this kind cannot be naturally expressed in SPARQL. A practical workaround to this problem would be either to re-formulate such queries to return larger result sets from which the needed results can be obtained e.g. in a spreadsheet, or to translate visual queries directly into SQL, if there is a relational database behind the SPARQL endpoint.
The use cases have also shown the possibility of attribute expression creation and
translation. Still, the standard SPARQL functions [