Visual notations based on customized entity relationship and basic UML class diagram paradigm of classes, associations and attributes are successfully used in data modeling and data querying alike, both in relational database and in semantic/conceptual model setting. We propose a number of constructs for extending the basic diagrammatic framework in the setting of visual specification of SPARQL select queries for enabling visual specification of hierarchic data instance and aggregated queries. Our proposal includes: (i) a visual notation for subqueries, (ii) separate lists of aggregated and grouping attributes in aggregated queries, (iii) query control nodes (unit and union) not corresponding to data instances, and (iv) integration with textual SPARQL fragments. We report on an initial user study validating the understandability of the subquery notion by users without specific IT training, as well as announce implementation of the proposed notation constructs in a web-based diagrammatic (multi-modal) query tool.
The ontology-based data access (OBDA) paradigm (cf. [
The visual/diagrammatic notations, along with approaches based on keyword search,
forms (e.g. [
Most of the existing diagrammatic notations for RDF data access, including Optique
VQs [
The notations of [
We propose here to extend the basic UML-style query formulation paradigm with means for visual formulation aggregated and nested queries, so to enable the users preferring the visual query formulation style, to work also with this kind of queries.
The previous work by authors on aggregate queries within the UML-style ViziQuer
tool [
We report also on a pilot user study testing the understandability of simple constructs from the introduced notation; the study results show the understanding ability of the subquery notion also by domain experts that are not IT professionals.
The visual query notation proposed here is supported by a web-based diagrammatic (multi-modal) query tool, available at viziquer.lumii.lv.
In what follows, Section 2 reviews the revised basic visual notation. Section 3, the central one of the paper, presents the extended query constructs. Section 4 discusses the SPARQL construct coverage; Section 5 describes the user study for notation evaluation. Tool environment is outlined in Section 6. Section 7 concludes the paper. 2
The visual/diagrammatic query definition is based on data model containing the
vocabulary of entities, each identified by a local name and optional name prefix and
providing the full entity URI, and the schema information stating the applicability,
ordering and cardinalities of properties in the context of the model classes. We shall
consider here example queries over a simple mini-hospital data schema, developed
originally in [
<<EnumClass>>
CPhysician personCode:string name:string surname:string
<<EnumClass>>
CDiagnosis code:string name:string
Patient personCode:string name:string surname:string gender:{"male", "female"} birthDate:date familyDoctor:CPhysician OutpatientEpisode visitDate:date visitDuration:duration * visitCost:decimal physician:CPhysician
HospitalEpisode referringPhysician:CPhysician[0..1] * raedsmpiosnssioibnleTiPmheys:dicaitaenT:iCmPehysician dischargeTime:dateTime dischargeReason:{"cured", "deceased", "other"}[0..1] lengthInDays:integer totalCost:decimal caseRecordNo:integer
TreatmentInWard attendingPhysician:CPhysician ward:string * arrivalTime:dateTime transferTime:dateTime orderNo:integer
AdmissionDiagnosisRecord * odiradgenrNosoi:isn:tCeDgeiargnosis
DischargeDiagnosisRecord diagnosis:CDiagnosis * orderNo:integer
The ontology is organized around the patient class, with possibly both hospital and outpatient episodes for each patient. A hospital episode can run over several treatments in hospital wards, each identified by an order number. A hospital episode has records of admission and discharge diagnoses, pointing to the CDiagnosis classifier. Hospital and outpatient episodes and treatments in wards may have associated physicians in different roles, as well.
A basic visual query (cf. [
Figure 2 shows an example visual query and its translation into SPARQL. The query
is based on three related classes, a mandatory link (HospitalEpisode -> Patient) and an
optional link to CPhysician. The attributes are by default assumed to be optional, not
to bypass entire solution rows because of missing attribute values (this contrasts [
The required attribute specification (corresponding to the class instance, attribute property and attribute value triple in RDF/SPARQL sense) can be achieved by a single check box click for ‘Required Values’ in the query tool user interface, and is marked by the ‘{+}’ mark besides the attribute (expression) specification, as in Fig. 3 (a).
Figure 3 (b) illustrates the notation for conditions and the ‘*’- notation for selecting all attributes defined in the data model for the query class (the optional attribute semantics is essential here not to have counter-intuitive results). Fig. 3 (c) shows a negated link to a condition class and the option to hide the link name from the query presentation, if it is unanimously clear from the class name specifications in the link start and end nodes (the hiding could have been applied also to the patient link in Fig. 2).
In this section we explain advanced query structuring facilities that go beyond the simple class – attribute – link – condition paradigm for query specification. 3.1
The multiple aggregation possibility shall be exploited with care not to induce the query raw result set blow-up due to additional dimensions introduced by possibly multiple-valued various attributes and expressions that are to be aggregated (the additional data dimensions can be introduced by the “usual” field values, as well).
The count_distinct(.) aggregation option allows counting only the distinct instances from the raw result set. The subquery and control node constructs, explained in the following sections, can be used to create queries without multiplicative effects, as well. 3.2
The SPARQL 1.1 notation allows for subquery specification. In combination with
aggregation, the subquery construct allows inter alia selecting data instances together
with their aggregate characteristics within the data environment (e.g. the count of
related instances). There is no common similar construct in UML-style query notations,
neither within the semantic technology domain (cf. [
Since the primary target of the subquery notation is to describe subqueries over instances related to a certain main query node instance, it is natural to associate the main query to subquery relation with an edge in the query. Both plain (non-subquery) and subquery edges typically correspond to a link in the data model; the options for query links not matching exactly the data links are described in Section 3.3.
The subquery links in the visual notation are starting by black bullets. The example in Fig. 6 example (left) contains a subquery link based on the single treatmentInWard link between HospitalEpisode and TreatmentInWard classes in the data model. The scope of the subquery involves the subquery edge itself and the part of the query graph below it in the graph’s tree shape structure. The selection list of the subquery contains the explicitly specified query outputs, as well as all references to query nodes and fields outside the subquery scope (typically including the instance of the subquery hosting node). The subquery results are projected into the hosting query; they can be used in conditions, further field definitions and ordering lists in the same way, as instance model attributes. To include a subquery output in the selection list for the main query, it has to be explicitly included in the subquery hosting node field list.
The Fig. 6 (right) single-node query shows the option to define a single-number subquery over property-linked instances in a textual form; in this case the value T is by default included in the main query selection list, as well as it is computed also for episodes without any treatments in wards, should there be ones.
Figure 7 shows a simple example of nested subqueries. The subquery mechanism is not bound to just local aggregate computation. In the case, if a subquery does not return any result except the host node instance for which it has been created, it works as an existential filter, as in Fig. 8, left. The right single-node query models the same behavior, using explicit predicate exists and property paths.
It has been an explicit design decision to stay with simple join semantics in the case of queries with nodes linked by plain required or optional edges. Should the link in Fig. 8 not have been marked as a subquery, the raw data set consisting of patients and all their hospital episodes would have been created leading to counting each patient as many times as it has the hospital episodes lasting for at least 10 days. In the case of counting the instances one could use count_distinct(.), however using the subquery mechanism leaves a clean un-duplicated result set of subquery host node instances, ready for output, as well as participation in further aggregate operations.
The count of patients having a hospital episode and not having an outpatient episode can be specified by either of query diagrams in Fig. 9 since the non-existence of a related instance would not cause any data graph blow-up.
Further subquery notation usage possibilities are discussed in Section 3.3. 3.3
The visual notation discussed so far is suitable for visual query specification, if the query has a tree form that is matching a data model fragment. The query structure can be extended either by visual condition links (visualized by a thinner line with diamonds on both ends, cf. Fig. 10a) that are added on top of the query tree structure, or by explicit (other) node references in the node attribute expressions (e.g. H and P in Fig. 10b). The non-model links (marked by the label ++), allow to have structural query links that do not correspond to links in the data model.
In Fig. 10 the non-existence of an outpatient episode is considered not for a patient but for a hospital episode. Therefore, the query structure link is drawn from the HospitalEpisode to OutpatientEpisode (in the example it happens to be a negated link) while the necessary model link between the Patient and OutpatientEpisode is encoded either as a condition link (a), or as an explicit condition within the OutpatientEpisode node (b).
As a more radical structure extension, the control nodes: unit (denoted by [ ]) and union (denoted by [ + ]), not describing any data instance, can be introduced to the queries. The unit node can typically be used as an outer query structuring layer, able to collect the results from a single or multiple subqueries, combine, project, filter them, as well as apply distinct or aggregation clauses over them. The example queries in Fig. 11 use the statistics by attribute notation from Section 3.1 within a subquery, embraced within an outer main query consisting of a union node.
Figure 11a shows the possibility of modeling the SPARQL having clause over the aggregated result set. The technique of unit nodes offered here, however, allows for much richer aggregate result handling than just filtering, as can be seen e.g. in Fig. 11b.
The union node introduces a disjunction of its sub-trees into the query (the link to the subtree from the union node is perceived as the link from the parent of the union node), as illustrated in Fig. 12. There are options to use subquery links both above and below the union node, as well.
The idea of the subquery concept, as explained in Section 3.2, is to offer means of computing local characteristics of a data node within a query. Since the semantics of the query language constructs is defined on the basis of their translation into SPARQL, the local characteristics computing subqueries cannot be allowed to contain the slicing limit and offset modifiers (in SPARQL the subqueries are computed globally). For the situations where the ordering and slicing modifiers are important within a subquery the global subquery notation (a white bullet at the edge start) has been introduced.
As an example, consider the query in Fig 13. The ‘==’ notation marks the query link to connect a resource (or a data value) to itself. It is necessary to take 5 most expensive hospital episodes before their joining to the treatment in ward data.
As far as the translation into SPARQL semantics is considered, there is no difference between local and global subqueries (except that slicing is not allowed in local subqueries). The main difference between local and global subqueries is in the mindset of reading the queries (local vs. global context). Should other visual query language implementations become available (e.g. by translating the visual queries directly into SQL), the slicing could be introduced also for local subqueries, with a principally different semantics of computing the slice (e.g. the topmost or the top n records) from the subquery for each data instance tuple forming the subquery context. 3.4
The ViziQuer/web notation allows also for explicit query variable usage in the place
of class and property names. Using an explicit query variable in place of a class or
property name creates the SPARQL query variable with the same name, uses it within
the query just as the class or property name, then adds it to the query output. Fig. 14
shows examples of exploratory queries over a SPARQL endpoint in the visual notation,
re-worked and extended from [
The visual notation has not been designed specifically to ease the formulation of the exploratory queries, Fig. 14 just shows the possibility and options for exploratory queries in the visual notation, outlining also the usage variability of the notation constructs (e.g. using query nodes with empty class names or with no content at all).
For the situations where the visual notation constructs either do not support the query definition, or are not convenient for it, there is an option (clearly meant for expert users) to introduce explicit textual SPARQL fragments into the visual symbols. Both the syntax of SPARQL group graph patterns and SPARQL select queries are supported. Fig. 15 shows two options of a simple example of selecting all data set triples. The variables selected out of the direct SPARQL clause can in the enclosing query be referred to by their name (without the preceding variable mark ‘?’). pattern can be a set of graph pattern fragments, interconnected by free edges; a variable from several patterns can go into a single query node. The filters correspond to conditions at query nodes; the variable binding and selection – to field lists at query nodes.
The projection can be modeled by adding a new unit node to the query and connecting the original query to it as a subquery; the unit node provides the context of selecting the fields corresponding to the projection variables; further operations on initial query results in the unit node are possible, as well. If the initial query is aggregated one, a filter in the unit head node can model SPARQL having clause of the initial query.
The optional blocks correspond to optional edges, existence filters to subqueries with empty result sets, non-existence filters to negated edges. There are also direct counterparts in the visual notation to aggregation, subqueries, select distinct and union constructs. Although not described here, the SPARQL minus construct can be handled by negated global subqueries.
The main limitations of the current visual notation are the requirement of queries to be placed over single graph, non-covered advanced property path expressions, select * (in SPARQL sense) and reduced. None of these constructs is of principal difficulty for the visual notation with SPARQL-based implementation, however, they are not so clear for eventual other implementations, e.g. by translating queries directly into SQL. 5
The hospital data schema shown in Figure 1 corresponds to a fragment of data structure of Children’s Hospital in Riga, Latvia. The resource point viziquer.lumii.lv/med illustrates a number of queries that have been important during the analysis of the real hospital data. An expert assessment of the query creation process allows to judge that it should be possible for an IT-trained expert, who has learned the notation, to successfully create the queries.
An early pilot study on visual notation understandability was performed on a group of Master degree medical students at University of Latvia and their teacher, together 7 participants, neither of whom have a specific IT training.
The participants were given an ontology (a fragment of Fig. 1 ontology, with vocabulary expressed in Latvian), and a simple data instance graph with two patients, altogether with 2 hospital episodes and 1 outpatient episode, and related diagnoses. The participants were asked to interpret 10 simple queries, shown in Fig. 16, over the given data set. The introductory time for notation presentation was 40 minutes, followed by 40 minutes query answering time. The results are collected in Fig. 17, where each row corresponds to replies by one participant (Row 1 are the teacher’s replies).
The results indicate that 6 of 7 participants were able to interpret at least 70% of the queries, with similar results both for non-aggregated and aggregated queries. The subquery notation used in examples (6), (7), (8) can be observed as not causing a particular difficulty. For the queries (4) and (5) the difficulty was to interpret a condition placed outside the main query class. The unexpected difficulty with query (9) can indicate the need for appropriate examples in query notation presentation since an analogous statistics query (10) presented over several data nodes, was answered quite well.
++: correct interpretation +: almost correct /: part of constructs understood correctly (difficulty with conditions outside the main class) -: incorrect interpretation empty cell: no answer
A web-based prototype tool supporting the visual notation presented in this paper is available from http://viziquer.lumii.lv/. After the registration and logging into the environment the user has an option to create and manage projects. Each project has to be configured by uploading the data schema (used e.g. for SPARQL generation from visual representations of entity local names, as well as for code completion) and setting up project parameters (e.g. connection to the SPARQL endpoint for direct execution of generated SPARQL queries). The containers for queries within a project are diagrams; each diagram can typically contain multiple visual queries; the user each time makes a visual selection of the query to be executed within the query diagram.
The tool architecture allows both for a centralized server with each user uploading a custom data schema, as well as configurations that are dedicated for work with specific SPARQL endpoints. We plan to release the tool code as open source. 7
The presented notation and examples demonstrate the possibility of extending the UML-style diagrammatic query creation paradigm of classes, associations, attributes and conditions by simple visual means for specification of advanced query building constructs, including subqueries, aggregations and additional query control structures.
The performed pilot user study has shown that it is possible to introduce the visual notation, including the aggregation and subquery constructs to domain experts without specific IT training. The visual format of the query presentation in the style of UML class diagrams, together with the notation expressivity, may allow the notation to have a potential to ease the query formulation work of a semantic technology and/or database professional, as well.
The visual notation can be extended, for instance, by a practically important construct of sliced local subqueries, not supported directly in SPARQL 1.1, if alternative query language implementations to translation into SPARQL are considered.
We expect that the availability of a web-based visual query environment infrastructure would initiate also use cases of the technology outside the group of its developers.