A UML-Like Visual Query Language

1 A UML-like Graphical Language for SPARQL-DL

For defining the graphical language for querying ontologies we consider the graphical-logical mapping depicted on Figure fig:process-sparqldl. Provided an ontology φ as input and a user graphical query Ω it can be processed by a SPARQL-DL engine and produces an output ontology φ'. For that purpose, we need a representation provided by $\theta$ of the visual query Ω in a SPARQL-DL that corresponds the most accurately as possible to the semantics the user interprets from Ω. The output ontology can be displayed visually representing the results in the same visual language as the query for the user consumption. This can be achieved by using ι on the textual results.

A UML-like language is selected for preserving the objective of being accessible to the user and easy to understand. This section describes a UML-like language and a mapping from some of its graphical primitives to a SPARQL-DL scheme, which allows us to compute the query.

1.1 A UML-Like Visual Query Language

We define a UML-like visual language in which classes, associations, generalisations are primitives that represents concepts, roles and inclusion in DL, respectively. Objects in UML are depicted similarly as classes, where the name is combined with the instance name, a colon (":") and the Classifier name, all of them underlined . This primitive is for representing ABox instances in DL, providing a way for querying about both TBox and ABox.

Associations can have names which we can use for representing roles names but multiplicity is not considered in this preliminary version. Class or instances classifier names are used as concepts names in the DL representation. All names can be replaced with variables for requesting a set of answers that matches any element in the TBox and/or ABox that meets the UML diagram representation. Variables are written prefixed with a question mark. Depicting an UML primitive named without a variable is considering as asking for existence of that element in the input ontology. For example, an UML class named "Project" will represent the concept Project in the ontology and the output will be asserted as true if founded in the input TBox or false otherwise.

1.2 SPARQL-DL Encoding

SPARQL-DL is used as a textual language for representing queries in crowd VQL. This language posses two types of queries: ASK sentence for querying about existence or assertions, which returns a true/false answer and SELECT queries for retrieving a set of elements that matches the provided condition.

On Figure fig:uml_primitives, a summary of UML primitives with variables are depicted with their respective SPARQL-DL encoding. Using variables in the graphical query is considered as a query for retrieving a set of elements that matches the user's condition, and thus, we use a SELECT sentence. The conditions are determined by the query atoms, which are constructed depending on the primitives used in the diagram. Classes are interpreted as Class() in SPARQL-DL, allowing the engine to search for concepts in the input. A generalisation requires the representation in SPARQL-DL of the two classes or objects involved and a DirectSubclassOf() sentence for searching a direct subclass relation between these two elements. For equivalence, the sentence EquivalentClass() is used. Associations are mapped into a Domain() and Range() query atoms for requesting the classes involved in the role.

Instances in the ABox can be queried by the objects UML representation, where we can use the name of the instance and class in a Type(?i, ?c) SPARQL-DL sentence which requests the instance "?i" of a concept "?c". Roles also can be mapped by a combination of three query atoms: a PropertyValue() and two Type(), the first one for searching the classes involved in the role, and the rest for retrieving the instance that can participate on it.

ASK queries are used when the graphical query provides names without variables. In this case, they are represented similarly as the SELECT queries but providing the name string. % and using ASK if no variable is found.

The SPARQL-DL encoding order which we currently support emphasise the primitives related to querying the TBox. First, classes are mapped, then generalisations and finally associations. Next, primitives related to the ABox are considered: objects, generalisations between objects and roles (associations between objects).

1.3 Example UML to SPARQL-DL

In the example presented on Figure fig:example the user creates a model which requests all classes involved in the model, where a class "X" is in relation named hasAuthor with another class "Z" and is a parent of class "Y". The conversion of this model to a SPARQL-DL sentence will start by creating a query atom for each class and then for each relation.

Then, it will detect the use of variables and create a SELECT statement with all of them. The sentence generated will be as follows:

  Class(?x), Class(?z), Class(?y), DirectSubclassOf(?y,?x), 
  Domain(?x,:hasAuthor), Range(?z,:hasAuthor)

Afterwards, the SPARQL-DL reasoner will be used for processing the query with the user ontology. All the results will be displayed on the user interface.

We can create a UML based visual query language. We consider only the following UML primitives depicted in Figure fig:uml-primitives and the SPARQL-DL representation we propose for the WHERE section is on table tab:primitives-sparqldl.

Table 1: SPARQL-DL Representation for the UML primitives listed in the Figure fig:uml-primitives. tab:primitives-sparqldl
Description SPARQL-DL
Class Person ASK { Class("Person") }
Class ?x SELECT * WHERE Class(?x)
?x is subclass of ?y SELECT * WHERE DirectSubclassOf(?x, ?y)
Person is subclass of ?x SELECT * WHERE DirectSubclassOf("Person", ?y)
?x is in relation with ?y SELECT * WHERE Class(?x), Class(?y),
  PropertyValue(?x, aRelation, ?y)

In the following sections, we present example which we use the "Pizza" ontology available at https://protege.stanford.edu/ontologies/pizza/pizza.owl URL.

1.4 Asking for a Class Existence

For the primitive in Figure fig:class-prim, the user intention is asking if the class "Person" exists. We don't use a SELECT statement because we don't have variables which the reasoner can unify.

In the Figure fig:xml-ans-class1 and fig:json-ans-class1, we see the reasoners output in XML and JSON respectively when we try to use a SELECT statement like the following:

SELECT * WHERE {Class(<http://www.co-ode.org/ontologies/pizza/pizza.owl#AnchoviesTopping>)}

This statement queries the Pizza ontology for classes which name are the IRI "http://www.co-ode.org/ontologies/pizza/pizza.owl#AnchoviesTopping".

<?xml version="1.0" encoding="UTF-8"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#"><head xmlns="" /><results xmlns=""><result /></results></sparql>
        "head": {
                "vars": [

        "results": {
                "bindings": [


The reasoner cannot find variables to which bind values results. However, we need a simple "true/false" answer, and for that purpose we can use an ASK query as follow:

ASK { Class(<http://www.co-ode.org/ontologies/pizza/pizza.owl#American>) }

Now, this query request the reasoner if in the ontology exists a class named by the IRI "http://www.co-ode.org/ontologies/pizza/pizza.owl#AnchoviesTopping". The answer is "true", and is presented in two formats: an XML depicted in Figure fig:xml-ans-class1b and in JSON in Figure fig:json-ans-class1b.

<?xml version="1.0" encoding="UTF-8"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#"><head xmlns="" /><boolean xmlns="">true</boolean></sparql>
        "head": {
        "boolean": true

1.5 TODO N-ary Association

1.6 TODO Association with Multiplicity

1.7 ABox Queries

According to the UML 2.5.1 specification uml2017 (at section 9.8), an instance of a class can be notated similar as a classifier (i.e. a class) where the Classifier name appears an underlined concationation of the instance name (if any), a colon (":") and the Classifier name or names.

For preserving the same semantic in the query, we use the same graphical UML primitives for representing concept or class instances, or in other words, an ABox query. The Figure in fig:uml-abox-primitives displays various primitives and the SPARQL-DL representation we propose for the WHERE section is on table tab:uml-abox-sparqldl.

Table 2: SPARQL-DL Representation for the UML primitives listed in the Figure fig:uml-abox-primitives. tab:uml-abox-sparqldl
Description SPARQL-DL
Instance "peter" of class "Person" SELECT * WHERE { Type("peter", "Person") }
Instances of class "Person" SELECT * WHERE { Type(?a, "Person") }
Instance "peter" of any class SELECT * WHERE { Type("peter", ?a) }
Instances which are in a direct subclass SELECT * WHERE { Type(?x, ?y), Type(?z,?w),
  DirectSubclassOf(?y, ?w) }
Instances which are in a direct subclass SELECT * WHERE { Type(?x, "Person"),
and the parent class is "Person". Type(?y,?z) DirectSubclassOf("Person", ?z) }
Instances that are associated directly SELECT * WHERE { Type(?x,?y), Type(?z,?w),
  PropertyValue(?y, "aRelation", ?w) }

1.8 TODO How to use ASK instead of SELECT?

Maybe when a variable is found we use SELECT, else we use ASK?.

2 TODO Answer Graphical Representation

A graphical representation can be achieved by displaying results using UML classes and associations or painting in the ontology (if created using UML and crowd) the classes with a representative colour.

2.1 Answering SELECT questions

When queries have got variables, the underlying SPARQL-DL query is generated as a SELECT question. The answer is usually represented as a table with the variable as columns and possible value assignations as rows.

2.2 Answering ASK questions

2.3 Advantages and Disadvantages

A graphical answer could be a good way to express and read the values easily. However, if there are more than 10 possible values, the answer diagram will turn complex to make and interpret. Also, it could have got repeated structures that will express the same semantics as the query.

3 References