Academia.eduAcademia.edu

Figure from:Extended UML Class Diagram Constructs for Visual SPARQL Queries in ViziQuer/web

See full PDFdownloadDownload figure
Figure 15. Direct SPARQL examples. 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 syn- tax 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 ‘?’).

Figure 15 Direct SPARQL examples. 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 syn- tax 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 ‘?’).

Related Figures (10)

Figure 1. Hospital domain ontology fragment coincide with the target class name with lowercase first letter’. There is default maxi mum and minimum default cardinality 1 assumption for properties, as well.
Figure 1. Hospital domain ontology fragment coincide with the target class name with lowercase first letter’. There is default maxi mum and minimum default cardinality 1 assumption for properties, as well.
Figure 2. Select top 10 most expensive hospital episodes, show episode length in days, total cost and case record number, together with patient name and surname, as well as name and sur- name of referring physician, if specified. 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 [13,4]).
Figure 2. Select top 10 most expensive hospital episodes, show episode length in days, total cost and case record number, together with patient name and surname, as well as name and sur- name of referring physician, if specified. 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 [13,4]).
Figure 6. Select all hospital episodes with at least 4 treatment wards, show episode case record number and number of treatment wards; order descending by the treatment ward count 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.
Figure 6. Select all hospital episodes with at least 4 treatment wards, show episode case record number and number of treatment wards; order descending by the treatment ward count 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.
Figure 7. Count patients with at least 3 hospital episodes, running over at least 5 wards each Figure 7 shows a simple example of nested subqueries. 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 epi- sodes without any treatments in wards, should there be ones. — — 4 4+ + a es
Figure 7. Count patients with at least 3 hospital episodes, running over at least 5 wards each Figure 7 shows a simple example of nested subqueries. 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 epi- sodes without any treatments in wards, should there be ones. — — 4 4+ + a es
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 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.
Figure 10. Count patients having at least three hospital episodes without a matching outpatient episode for the same patient within the 30 day range before the hospital episode. 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.
Figure 10. Count patients having at least three hospital episodes without a matching outpatient episode for the same patient within the 30 day range before the hospital episode. 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.
Figure 12. Query with union node: Count all (distinct) patients that are related to diagnosis “A69.2’ (Lyme disease) either as admission or as discharge diagnosis of a hospital episode. Extended UML Class Diagram Constructs for Visual SPARQL Queries in ViziQuet/web
Figure 12. Query with union node: Count all (distinct) patients that are related to diagnosis “A69.2’ (Lyme disease) either as admission or as discharge diagnosis of a hospital episode. Extended UML Class Diagram Constructs for Visual SPARQL Queries in ViziQuet/web
Figure 13. Limit-bound “global” subquery example: Select top 5 most expensive hospital epi- sodes (show the episode case record number and total cost), list them together with all their treatment wards (show the order number and the ward). —e 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.
Figure 13. Limit-bound “global” subquery example: Select top 5 most expensive hospital epi- sodes (show the episode case record number and total cost), list them together with all their treatment wards (show the order number and the ward). —e 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.
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 [4]: (a) select all classes together with their instance count, (b) select all properties together with all class pairs connected by them (select distinct specification is necessary since the raw data graph is computed on data instance level); (c,d) two forms of selecting all triples from the data set (in (d) ‘a’ denotes the “current instance”, p — the property, ‘b’ — the “target instance”; {+} marks a required triple presence); (e,f) select all properties together with their usage count (in (f) the triple has to be marked as required by {+} as well as by {internal} not to have its re- sulting value included in the selection set); (g) if an explicit query variable is introduced within a subquery, a reference to it within an enclosing query is to be made by the variable name without the preceding variable mark ‘?’. 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 que- ries 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).
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 [4]: (a) select all classes together with their instance count, (b) select all properties together with all class pairs connected by them (select distinct specification is necessary since the raw data graph is computed on data instance level); (c,d) two forms of selecting all triples from the data set (in (d) ‘a’ denotes the “current instance”, p — the property, ‘b’ — the “target instance”; {+} marks a required triple presence); (e,f) select all properties together with their usage count (in (f) the triple has to be marked as required by {+} as well as by {internal} not to have its re- sulting value included in the selection set); (g) if an explicit query variable is introduced within a subquery, a reference to it within an enclosing query is to be made by the variable name without the preceding variable mark ‘?’. 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 que- ries 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).
Extended UML Class Diagram Constructs for Visual SPARQL Queries in ViziQuet/web 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 envi- ronment 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 vis- ual 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.
Extended UML Class Diagram Constructs for Visual SPARQL Queries in ViziQuet/web 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 envi- ronment 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 vis- ual 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.