# QAVAN: Query-answering approach for actionable numerical relationships over Knowledge Graphs

Luis Felipe Vargas-Rojas, Llorenç Cabrera-Bosquet, Danai Symeonidou

<figure><img src="image_1.png" /></figure>

## To cite this version:

Luis Felipe Vargas-Rojas, Llorenç Cabrera-Bosquet, Danai Symeonidou. QAVAN: Query-answering approach for actionable numerical relationships over Knowledge Graphs. Knowledge-Based Systems, 2024, 284, pp.111252. 10.1016/j.knosys.2023.111252. hal-04374989

HAL Id: hal-04374989

https://hal.inrae.fr/hal-04374989v1

Submitted on 10 Oct 2025

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>
<figure><img src="image_3.png" /></figure>

# QAVAN: Query-answering approach for actionable numerical relationships over Knowledge Graphs

Felipe Vargas-Rojas<sup>a,b,*</sup>, Llorenç Cabrera-Bosquet<sup>b</sup>, Danai Symeonidou<sup>a</sup>

<figure><img src="image_4.png" /></figure>

## ARTICLE INFO

**Keywords:**

Numerical relationships

Mathematical formulas

Derived data

Numerical data

SHACL

## ABSTRACT

Semantic Web (SW) technologies are suitable to represent taxonomic knowledge in Knowledge Graphs (KG). However, cases that do not fall in this category such as numerical relationships (e.g., algebraic operations or unit conversion) that can enrich the KGs data are poorly represented. Current approaches mostly trigger these relationships in a materialised fashion (i.e., perform all the relationships in advance), which leads to storage and updating problems. Besides, these relationships are often not represented using linked data formats ignoring the FAIR and LOD guidelines, which leads to issues of interoperability, reproducibility and adoption. In this work, we propose QAVAN, a query-answering approach that computes efficiently only the necessary numerical relationships relevant to answer to a given query. QAVAN exploits SW technologies such as SHACL for representing and computing these relationships while plays in favour of FAIR and LOD principles. We evaluated and compared QAVAN against a materialised approach using two real datasets extracted from two very well-known data sources, DBpedia and MeteoFrance. Results expose the numerous benefits of QAVAN in terms of execution time, memory usage, and disk space in different scenarios for example against big datasets. We also evaluated two QAVAN extensions, the nested numerical relationships and the inference services. Our results show that these extensions allow to apply the numerical relationships for a greater number of instances to provide more query results.

## 1. Introduction

Recent technological advances have exponentially increased the acquisition of massive and rich datasets in diverse domains (e.g. agriculture, biomedical, environmental, social). This context has raised new challenges regarding data organisation and reuse, as well as the need to adopt Findable-Accessible-Interoperable-and-Reusable (FAIR) data principles [1]. In that sense, Knowledge Graphs (KGs) have gained attention as a data structure to handle disparate datasets that contain numerical information of many individual observations.

In addition to common tasks performed over KGs: ontological reasoning [2], validation [3], mappings [4]; new needs such as representing and computing mathematical formulas that enhance KGs with new derived data are becoming more and more relevant in most of domains. For instance, the Body Mass Index (BMI) of a person can be derived from their current weight and height and can be used to enrich the initial data. Similarly, the Vapour Pressure Deficit (VPD) in the atmosphere can be derived from the air temperature and the air relative humidity. While experts are aware of such mathematical formulas, most of them are performed in adhoc programming languages limiting their

reusability and reproducibility. Besides, when KG data is transformed into tabular formats many contextual data and semantic links are lost, making more difficult the data processing task [5]. Additionally, solutions to handle data completion problems [6] are mainly based on graph embeddings and often ignore this numerical knowledge. Currently, there is no standard manner to represent this kind of knowledge while the existing SW alternatives present different limitations.

Many approaches [7–11] that allow somehow to represent numerical relationships over KGs compute the corresponding data in a materialised fashion. This means that all the mathematical relationships are performed against the initial KG to obtain a new enriched graph containing as well the resulting triples. For instance, SPARQL [7] and its extensions allow to express mathematical relationships and define derived data through CONSTRUCT queries. However, a mediated script should perform the materialisation to enrich the KG. This strategy has been followed by Bischof et al. [11] that used a Python script and CONSTRUCT queries to enrich the KG data. While the materialised strategy provides a first solution to this problem, it can lead to disk space and memory allocation issues on large KGs. Moreover, it is not

<footnote><sup>a</sup> INRAE-MISTEA, Institut Agro, Montpellier, France</footnote>

<footnote><sup>b</sup> INRAE-LEPSE, Institut Agro, Montpellier, France</footnote>

<footnote>* Corresponding author at: INRAE-MISTEA, Institut Agro, Montpellier, France. E-mail address: felipengine@gmail.com (F. Vargas-Rojas).</footnote>
an efficient strategy when it comes to KGs that are dynamic and have often updates. This is the case for example for experimental data and data that evolve through time. In this scenario the whole KG is updated every time the initial KG is modified.

Unlike previous works, Bischof & Polleres [12] propose another approach allowing to compute numerical relationships following a virtual manner (i.e. performing the relationships on demand). While this work is a first step towards query-answering in the presence of numerical relationships, these are represented in the form of text, neglecting the works of mathematical knowledge and SW [13] along with the FAIR [1] and Linked Open Data (LOD) [14] principles. As a result, the formulas do not have a URI nor metadata, are difficult to extend and are not interoperable with the numerical data existing in different ontologies or SW resources.

To fill these gaps, we propose QAVAN, a new approach to compute numerical relationships following a virtual manner. More precisely, given a specific query, a KG, and a set of numerical relationships, QAVAN computes on the fly only the triples that are part of the query result. Thus, tackling the problem of disk space and memory allocation. Additionally, this approach allows to provide answers over large KGs and data evolving through time, even in cases where materialisation is infeasible. QAVAN exploits the SHACL W3C recommendation and their Advanced Features (SHACL-AF) and demonstrates that this technology requires more attention in problems beyond constraints and validations. In this work we show that SHACL-AF can be adapted to our goals offering also alternatives to represent more FAIR and machine-readable formulas.

QAVAN has been designed with the following purposes: (i) easily extendable accepting new features, by taking advantage of the elements already validated and proposed by the W3C community, (ii) declarative and independent of a specific computation engine, (iii) encoded in a LOD format, (iv) easy to install and integrate in already deployed SW systems (avoiding the installation of third-party softwares). More precisely, the **contributions** of this work are:

* A theoretical comparison of the related approaches considering aspects relevant for big and heterogeneous KGs.

* QAVAN, an efficient query-answering approach able to perform on the fly numerical relationships that produce new derived data. QAVAN exploits SW engines and technologies to that goal.

* Two extended experimental evaluations of QAVAN, on (i) a meteorological dataset [15], composed mainly of numerical weather observations, demonstrating the high impact of such an approach in experimental data, and (ii) DBpedia<fnref n="1" /> and Eurostat<fnref n="2" /> data to demonstrate the generic nature of our approach and its capacity to be extended allowing new features relevant in the SW.

The rest of the paper is organised as follows: Section 2 describes the problem of representing actionable numerical relationships (ANRs). Section 3 shows the related work and Section 4 presents our query-answering approach QAVAN. Then, Section 5 exhibits the experimental evaluation of our approach. Finally Section 6 provides the conclusions and the future work.

## 2. Problem statement

In this work, we address the problem of representing mathematical formulas that exploit the numerical and contextual data of KGs in order to produce new derived data. To facilitate the understanding of the problem components, we introduce the concept of *Actionable Numerical Relationships (ANRs)*: a specific kind of rule that incorporates a mathematical formula in its Body. ANRs rely on KG data.

### 2.1. Knowledge graphs

In this work, KGs are represented using the Resource Description Framework (RDF). An RDF [16] graph consists of a set of triples. Each triple contains three elements $\langle subject, predicate, object \rangle \in (U \cup B) \times U \times (U \cup B \cup L)$ where U is the set of all the URIs,<fnref n="3" /> B is the set of all the blank nodes, and L is the set of all the literals (e.g. strings, numbers, dates). Alternatively, triples may be written as first order binary predicates of the form $predicate(subject, object)$, and for the special semantic of $rdf:type$ as $object(subject)$. In the special semantic of $rdf:type$, the object is referred as a *class* and the *subject* as an *instance* of that *class*.

### 2.2. Actionable Numerical Relationships (ANRs)

We define an ANR as a rule of the form $Head \leftarrow Body$, where the rule's *Body* incorporates a new kind of relation of the form $eval(\langle mathematical formula \rangle, \langle variable \rangle)$ to associate the result of a mathematical formula to a variable.

**Definition 1 (ANR).** Let $p$ be a property, $x$ be an instance of the class $C$, $eval$ be a relation that maps the result of a mathematical formula $M$ to a variable $w_1$. An ANR is defined as follows:

$$p(x, w_1) \leftarrow C(x) \wedge eval(M, w_1).$$

The trigger of this rule returns a new triple $p(x, w_1)$, which adds the property $p$ and its value $w_1$ to the instance $x$.

**Definition 2 (Query-Answering on Presence of ANRs).** Let $Q$ be a query, $G$ be a KG and $E$ be a set of ANRs. Assuming that $Q$ necessitates triples not present in $G$ but defined in $E$, to answer $Q$, the ANR $E$ should be performed against $G$ and the resulting triples stored in the new graph $G'$ should be merged with the initial graph $G$. Once this step is executed, $Q$ can be evaluated against $G \cup G'$.

**Example 1** shows a simplified KG $G$, a query $Q$ and a set of ANRs $E$ containing for the sake of simplicity only one ANR. $G$ contains triples providing the weight and the height of the person $p_1$. Although the query $Q$ is asking for the property $BMI$ which is not present in $G$, this property can be derived by performing the corresponding ANR in $E$ against $G$. The $eval$ statement contains a mathematical formula to compute the $BMI$ value and the variable $?bmi$ to store the result of this computation. The $?bmi$ can now be used to produce the necessary triple stored in a new graph $G'$ and thus $G \cup G'$ can be used to provide the answer to the query $Q$.

**Example 1.** Body Mass Index (BMI) calculation.

$$
\begin{align*}
G &= \{ \text{Person}(p1), \text{weight}(p1, 85), \text{height}(p1, 180) \} \\
E &= \{ \text{BMI}(?p, ?bmi) \leftarrow \text{Person}(?p) \wedge \\
& \qquad \text{eval}(\frac{\text{weight}}{\text{height}^2}, ?bmi) \} \\
Q &= \{ \text{SELECT } ?p ?bmi \\
& \qquad \text{WHERE } ?p \text{ a Person. } ?p \text{ BMI } ?bmi. \}
\end{align*}
$$

### 2.3. ANR computation aspects

ANRs perform two main steps: (i) to compute the mathematical formulas, and (ii) to assign the derived values in order to produce new triples and to enrich the initial KG. To do so, different methods and engines could be applied.

**Method.** Whether or not to perform ANRs in advance is an important decision to take. In database research, the concept of views [17] is used

<footnote n="1">¹ http://dbpedia.org/.</footnote>

<footnote n="2">² http://ec.europa.eu/eurostat/.</footnote>

<footnote n="3">³ Universal Resource Identifiers (URI).</footnote>
to define a new table produced by an SQL query. If the query results are not stored, it is known as a *virtual view*. On the contrary, if the query results are stored, it is known as a *materialised view*. Following the same principle in our context, depending on how the results are stored we define *materialised or virtual ANRs*. Note that the terms of backward and forward chaining are used in the domain of automated reasoning to represent similar concepts. Nevertheless, such methods do not mention the fact of storing the results, we therefore choose to use the database field concept.

**Engine.** Engines perform ANRs in two steps: (i) performing the mathematical formula inside the *eval* relation and (ii) triggering the ANRs to produce new triples. SW proposes technologies such as SHACL, SPARQL, SWRL and Reasoners able to perform the two steps. On the contrary, non-semantic technologies like Computer Algebra Systems (CAS) or traditional programming languages (e.g. Python, R, JavaScript) can only perform the first step and need a complementary technology to enrich the KG (e.g. SPARQL).

**ANR dependencies.** A mathematical formula can rely on the results of other formulas. Similarly, an ANR can be independent or can depend on the results produced by other ANRs. Related work offers different strategies to handle these dependencies. For instance, using a dependency graph or defining the ANR execution order manually.

## 2.4. Mathematical formula representation and description aspects

ANR mathematical formulas include two important parts: the mathematical formulas themselves and their metadata. The metadata is relevant to identify and describe the mathematical formula. More deeply:

**Mathematical formula representation.** A mathematical formula represents the internal structure of the computation. This formula can be expressed within a programming language script, a SPARQL query, an XML document or an RDF graph.

**Mathematical formula expressivity.** A mathematical formula can allow different operators such as algebraic functions, user-defined functions and aggregations. Let Z be the set of all the mathematical expressions, consider the distinct expressions $z_1, z_2, ..., z_x \in M$ then $m_1$ can be defined as follow:

* a literal number.

* a functional expression $\langle op \rangle (z_2, ..., z_x)$ where $\langle op \rangle$ can represent algebraic functions like $(+, -, \times, \div)$ or arbitrary functions.

* an aggregation expression for summarising multi-dimensional data (e.g. sum, count, avg).

**Metadata.** It refers to the mathematical formula description. This metadata might include basic information such as the mathematical computation name, description, creation date, as well as information for the target engine. It is usually machine- and human-readable.

## 3. Related work

This section exhibits existing SW approaches and technologies that address two main issues, the representation of mathematical formulas in the SW and how to proceed to their computation. While many approaches have proposed solutions on different aspects of these problems over the last years, only few have been focusing on the specific problem of representing and computing mathematical formulas to enrich a KG. To tackle this issue, we put together works which have different goals but may contribute to some aspect of our problem. For instance, several ontologies have been proposed to represent mathematical formulas offering a rich description of the formula's components but they lack methods to enrich and query the KG data.

Bearing in mind this diversity, we propose a set of desired features to compare the related work. These desired features were inspired by

the challenges of modern KGs, which can be heterogeneous, incomplete and voluminous. Moreover, in our desired features to represent mathematical formulas, we take into account the FAIR and LOD principles in order to facilitate the adoption, the interoperability, and the reproducibility. In particular, we argue that a FAIR representation of the mathematical formula (e.g., in RDF) is aligned with the Semantic Web goals, offering a uniform format to express different KG tasks. On the other hand, it is also relevant to represent these formulas close to the mathematical notation to facilitate the adoption of non-IT experts. Finally, these desired features also pay attention to the use of W3C recommendations since these technologies are already validated and several active communities are contributing to improve them.

### 3.1. Desired mathematical formula features

**F1. Enable FAIR mathematical formulas.** Representations in machine-readable formats such as RDF or XML are more FAIR than programming language scripts. Besides, RDF is the preferred format for the Linked Open Data (LOD), which is why RDF is a better choice. The FAIR [1] guideline proposes good practices for data management. This guideline highlights the importance of applying FAIR principles for algorithms, tools, workflows and analytical pipelines. Additionally, a representation close to the mathematical notation may promote to share the mathematical formulas for a wider community including non-IT experts and can be aligned with the mathematical knowledge representation effort [13].

**F2. Include the computation-metadata.** The metadata facilitates the human comprehension and the traceability. A human-readable description encourages to adopt and use the mathematical computations.

**F3. Define algebraic and aggregations.** This feature is about the mathematical formula expressivity. Supporting algebraic and specific mathematical operators (e.g. power, square root, sin) is a basic desired feature while aggregations are also highly recommended considering that KG data can be often multi-scale.

**F4. Support different input models.** Often the related approaches assume that the mathematical formula inputs are data properties with literal numbers. However, in practice, inputs can be more complex. For instance, inputs can be quantity values. A *quantity value* is a pair (*value*, *unit*) that expresses the numerical value of a quantity with respect to a unit of measurement [18]. For example, following the data model of the QUDT [18] ontology, a measurement of 30 degree Celsius is expressed using three triples: *qudt:QuantityValue(x)*, *qudt:value(x, 30)*, *qudt:unit(x, unit:DEG_C)*. Thus, the mathematical formula definition requires means to navigate and operate on this kind of numerical data.

### 3.2. Desired ANR features

**F5. Enable virtual ANRs.** Mathematical formula results cannot always be stored in disk because of two sources of complexity: KG data volume and the virtually infinite number of equations. Materialisation is generally unfeasible. Besides, for KG data updates the triples produced by the ANRs can be out-to-date in a materialised approach, thus to avoid updating issues virtual ANRs are required.

**F6. Enable nested ANRs.** Nested ANRs rely on the resulting triples of other ANRs. This feature is required to represent more complex mathematical formulas in a modular manner and can allow handling heterogeneous data. For instance, let us consider an ANR over cities of DBpedia, a well-known KG in the SW that uses as input the *areaTotalKm* (total area in squared kilometres) property. Some cities in the data use this property to express the area of a city while some others have this information in square miles (*areaTotalSqMi*). Therefore, the property *areaTotalKm* can be derived by performing another ANR transforming
<caption>**Table 1**</caption>

Comparison of approaches and technologies for representing numerical relationships. “✓” means meet the feature while “/” means can meet the feature with little modifications.

<table><thead><tr><th>Approach</th><th>F1</th><th>F2</th><th>F3</th><th>F4</th><th>F5</th><th>F6</th><th>F7</th><th>F8</th><th>F9</th><th>Count</th></tr></thead><tbody><tr><td colspan="11"><strong>Query-language-based computation</strong></td></tr><tr><td>SPARQL1.1 [20]</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>4</td></tr><tr><td>LDScripts [21]</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>/</td><td>/</td><td>-</td><td>✓</td><td>✓</td><td>5</td></tr><tr><td>SPARQL<sup>λ</sup> [22]</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>✓</td><td>/</td><td>-</td><td>✓</td><td>✓</td><td>5.5</td></tr><tr><td>SPIN [9]</td><td>-</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>5.5</td></tr><tr><td colspan="11"><strong>Ontological-mediated computation</strong></td></tr><tr><td>Ontologies [23–25]</td><td>-</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>3</td></tr><tr><td>RDF-OpenMath [8]</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>-</td><td>-</td><td>✓</td><td>-</td><td>-</td><td>4</td></tr><tr><td colspan="11"><strong>Ontological-reasoning-based computation</strong></td></tr><tr><td>Iannone & Rector [26]</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>-</td><td>0</td></tr><tr><td>Bischof & Polleres [12]</td><td>-</td><td>-</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>-</td><td>4</td></tr><tr><td colspan="11"><strong>Rule-based computation</strong></td></tr><tr><td>SWRL [10]</td><td>/</td><td>-</td><td>-</td><td>✓</td><td>-</td><td>/</td><td>✓</td><td>✓</td><td>-</td><td>4</td></tr><tr><td>SHACL [3] SPARQL rules</td><td>-</td><td>-</td><td>✓</td><td>✓</td><td>-</td><td>/</td><td>-</td><td>✓</td><td>✓</td><td>4.5</td></tr><tr><td>SHACL [3] Triple rules</td><td>✓</td><td>/</td><td>-</td><td>✓</td><td>-</td><td>/</td><td>/</td><td>✓</td><td>-</td><td>4.5</td></tr><tr><td>SHACL [3] Value rules</td><td>✓</td><td>/</td><td>-</td><td>✓</td><td>-</td><td>/</td><td>✓</td><td>✓</td><td>-</td><td>5</td></tr><tr><td>Bischof et al. [11]</td><td>-</td><td>✓</td><td>✓</td><td>/</td><td>-</td><td>/</td><td>✓</td><td>-</td><td>/</td><td>4.5</td></tr></tbody></table>

the miles to kilometres. If this feature is not available, cities containing the property *areaTotalSqMi* will be omitted.

**F7. Link the ANRs to the KG data to facilitate query-answering.** The mathematical formulas should be associated to the existing KG data in order to create an abstraction of derivable data. Thus, a user can query this data even if it is not yet calculated. Approaches that produce arbitrary triples are not desired since they require materialisation for the query-answering task. A second alternative is to navigate and interpret complex expressions to identify the derivable triples, which could complicate the query-answering task. A last alternative is to require the user to manually add in the query the ANR URIs, which is not desired since users should not be aware about these details. In that sense, to know in advance the derivable properties facilitates the query-answering in the presence of ANRs.

**F8. Use SW engines to perform ANRs.** It facilitates the interaction with RDF graphs and the system adoption. It avoids the installation of third-party software.

**F9. Support more complex outputs.** Similarly to the mathematical formula inputs (F4), the related approaches often allow to produce only data properties with numerical literals. It is desired to produce more complex models such as quantity values. In that regards, ANRs should be extended with the expressivity of existential rules [19].

Regarding the desired features, we propose the Table 1 to compare the related approaches. We use the “✓” to state that approaches meet the feature and the “/” for cases where approaches can be easily adapted to meet the feature. Next sections further discuss each approach. We organise these approaches in categories: the *query-language-based* category groups SPARQL and its extensions; the *ontological-mediated* category groups ontologies related to mathematical computations; the *ontological-reasoning-based* groups extensions of OWL; finally, the *rule-based* category groups rule languages used in the SW domain.

### 3.3. Query-language-based computation

SPARQL1.1 [20] is a W3C standard to query RDF datasets. SPARQL queries can represent aspects of ANRs. Within queries it is possible to express algebras and aggregations (meet F3). These queries allow to navigate quantities and complex data models (meet F4). However, queries are not expressed in a LOD format (e.g., RDF); and they are far from the mathematical notation (not meet F1). Also, the structure of a query is not extensible to add the computation-metadata (not meet

F2). Concerning the rule aspects, an ANR can be represented as a CON-STRUCT query, which enables to produce new derived graphs (meet F9). Additionally, SPARQL queries facilitate the interaction with RDF datasets and they are performed by SW engines (meet F8). However, SPARQL does not enable query-answering on the derived data since one query cannot trigger other stored queries, and we are assuming that ANRs are stored as CONSTRUCT queries (not meet F7). For the same reason, ANRs in SPARQL cannot refer to each other (not meet F6). An alternative to enable query-answering using SPARQL would be to materialise the derived data in advance obtaining a new enriched graph which nevertheless is not a desired feature (not meet F5).

LDScript [21] is a SPARQL extension that allows to express functions directly in SPARQL. LDScript contributes to the modularity issue of SPARQL: a function can refer to other functions and a query can use them (partially meet F5 and F6). However, these functions are very restricted, they only allow to store a procedure, but they cannot be linked with the KG data to enrich the data (not meet F7).

SPARQL<sup>λ</sup> [22] extends the capabilities of SPARQL1.1 with a functional programming approach. SPARQL<sup>λ</sup> enables to define data analysis pipelines by injecting partial graphs calculated on the fly. This approach allows to store templates of RDF producing functions. Later, in a query, users can refer to the graph derivable from the template (meet F5). SPARQL<sup>λ</sup> templates can trigger other templates enabling nested ANRs (meet F6). However, these templates do not enrich the data, users defining a query must know the template URI to obtain the derived data, and cannot query it directly (not meet F7). On the other hand, the SPARQL Inference Notation (SPIN) [9] is an RDF vocabulary to store SPARQL queries in RDF. In RDF it is easier to add metadata (meet F2). SPIN can define ANRs as CONSTRUCT queries that are stored in RDF. Although SPIN allows to store SPARQL queries in a LOD format, this representation is far from the mathematical notations and it may be difficult for users not familiar with SPARQL to interpret the ANRs (partially meet F1). SPIN allows to define nested queries by establishing the execution order manually (partially meet F6). SPARQL engines can perform SPIN rules (meet F8). However, to our knowledge, SPIN requires to materialise the ANRs in advance to enrich the data (not meet F7).

### 3.4. Ontological-mediated computation

An ontology is an explicit, formal specification of a shared conceptualisation [27]. Ontologies allow to add the computation-metadata with explicit semantics. A delegated engine can use later these metadata to perform specific tasks (e.g. to trigger scripts). Proposals like the Function Ontology (FO) [24], the ontology of functions in R [25] and the ontology for quantitative research [23] enable a detailed definition of the computation-metadata (meet F2). However, they neglect the mathematical expressions (not meet F1), which are not explicitly declared. Often these mathematical expressions are defined in a target programming language (e.g. R, Python, Java). Also, these approaches do not intent to enrich the KG data (not meet F4, F7 and F9).

RDF-OpenMath [8] is an effort to represent mathematical objects in RDF, based on OpenMath: an standard to exchange mathematical objects in Computer Algebra Systems (CAS). In RDF-OpenMath the mathematical expressions are explicit (meet F1 and F2) and accompanied by a concrete semantic of symbols.<fnref n="4" /> Nevertheless, expressions are evaluated by Computer Algebra System (CAS) (not meet F8). At the moment, none of these systems is a W3C standard or recommendation. The current version of RDF-OpenMath does not allow inputs and outputs different from literals (not meet F4 nor F9). Although RDF-OpenMath allows to link the mathematical formula to the KG data (meet F7), the authors do not report any procedure to perform the formulas on demand (not meet F5). Besides, it is not clear if they allow nested ANRs (not meet F6).

<footnote n="4">⁴ Symbol *times* URI https://openmath.org/cd/arith1#times.</footnote>
<table><caption>**Table 2**
Alternatives to represent the BMI as SHACL rules.</caption><thead><tr><th>Listing 1: ValueRule</th><th>Listing 2: TripleRule</th><th>Listing 3: SPARQLRule</th></tr></thead><tbody><tr><td><pre>:PS a sh:NodeShape ;<br>sh:target :Person;<br>sh:property [ sh:path :BMI ;<br>sh:values [ sparql:divide (<br>[sh:path :Weight]<br>[sparql:multiply (<br>[sh:path :Height]<br>[sh:path :Height])]]<br>)];<br>];</pre></td><td><pre>:PS a sh:NodeShape ;<br>sh:target :Person;<br>sh:rule [ a sh:TripleRule ;<br>sh:subject sh>this ;<br>sh:predicate :BMI ;<br>sh:object [ sparql:divide (<br>[sh:path :Weight]<br>[sparql:multiply (<br>[sh:path :Height]<br>[sh:path :Height])]]];<br>];</pre></td><td><pre>:PS a sh:NodeShape ;<br>sh:target :Person;<br>sh:rule [ a sh:SPARQLRule ;<br>sh:construct """<br>CONSTRUCT {$this :BMI ?bmi .}<br>WHERE {<br>$this :Weight ?w .<br>$this :Height ?h.<br>BIND (?w / (?h * ?h) AS ?bmi.<br>}""" ;]</pre></td></tr></tbody></table>

## 3.5. Ontological-reasoning-based computation

OWL 2.0 [2] is the W3C standard to define ontologies. In addition to vocabularies it enables to define axioms that interpret an inference engine in order to make explicit the implicit data. OWL lacks methods to define mathematical computations [28]. Studies in OWL with concrete domains (e.g., numbers and strings) demonstrate that adding calculations to the knowledge base increases the inference complexity and leads to undecidable scenarios [29]. Iannone & Rector [26] propose to add an annotation property linked to a data property for defining the computation-body avoiding to interact with the OWL axioms. Thus, the mathematical expression is not machine readable. Efforts in that direction do not meet our desired features.

OWL QL is a tractable fragment of OWL aiming to provide a solution to query-answering. Inference tasks in OWL QL use query-rewriting to expand the query with the OWL axioms. Bischof & Polleres [12] propose to extend a query-rewriting algorithm to support basic equations. Their algorithm processes the equation during query execution, thus avoiding the disk space problems (meet F5). However, they represent the equation as a String, which is not machine-readable nor FAIR (not meet F1). Computation-metadata is also ignored in this approach (not meet F2). Additionally, they only consider data properties, therefore paths to quantities cannot be defined with this approach (not meet F4).

## 3.6. Rule-based computation

Rule languages allow to define mathematical formulas through built-in functions. The Semantic Web Rule Language (SWRL) [10] is a language to define rules tightly aligned with OWL axioms. However, concerning the desired features, a SWRL rule cannot produce new instances (not meet F9) and lacks support for more advanced calculations (not meet F3) like aggregations [30]. SWRL rules also neglect the computation-metadata and they never were sufficiently adopted to become a W3C recommendation. Moreover, while SWRL rules can be expressed in RDF, the mathematical formulas cannot be stored as expressions in a linked data format (partially meet F1). Since SWRL rules have native ontological reasoning, KG data can be linked with the mathematical formulas (meet F7). For the query-answering problem (virtual ANRs), SWRL rules can lead to rounding and infinite loop errors [12]. This is because SWRL rules are not intended to handle numerical data. Examples of rule languages like Apache Jena<fnref n="5" /> rules and N3 [31] present similar limitations (see Table 2).

The Shapes Constraint Language (SHACL) [3] is a W3C recommendation since 2017 for RDF graph validation. While SWRL rules extend the expressivity of OWL, the SHACL semantics is rather given as mappings to SPARQL endpoints [32]. SHACL improves SPIN by focusing more in the validation and representing the constraints as RDF

triples. With SHACL, one can express constraints such as “*a person only can have one property value for their weight and height*”, “*weight and height should be decimal values*”. Besides, SHACL is gaining more popularity within the Semantic Web community. The machinery used to validate SHACL constraints can be adapted to perform other useful tasks in KGs (e.g., performing functions and rules). The SHACL Advanced Features (AF) draft<fnref n="6" /> is an example of those extensions. In this draft, the authors present three kinds of rules that differ in their expressivity and their representation:

* *SPARQLRules (Listing 3)* are rules that contain a SPARQL CONTRACT query. These rules allow to produce an arbitrary graph for each SHACL focus node (meet F9). However, to enable query-answering, these rules require materialisation (not meet F5). Note as well that linking an arbitrary graph to the KG data is complex without materialisation (not meet F7). Besides, in these kind of rules the mathematical formulas, in form of queries, are added as text (not meet F1 nor F2). Notice that all the SHACL rules require a manual definition of the execution order (partially meet F6).

* *TripleRules (Listing 2)* are less expressive than SPARQLRules, they are based on three components: the subject, the predicate and the object. For each component a *NodeExpression* is defined. *NodeExpressions* can express mathematical computations in RDF (meet F1) similar to RDF-OpenMath [8]. However, since the Node-Expressions are blank nodes, a URI is not incorporated, which difficulties to add metadata (partially meet F2). Knowing the triple predicate, it is easy to associate the expression to the existing KG data. Nevertheless, *TripleRules* may allow to generate a triple with a subject different to the current focus node (partially meet F7). Additionally, these rules cannot produce more than one triple (e.g. a quantity value is represented with three new triples, not meet F9).

* *ValueRules (Listing 1)* allow to add a data property to each instance, the derivable property is known in advance (meet F7). A *NodeExpression* evaluation produces the value for the new property (URI nodes or literals). *ValueRules* are the most restricted SHACL rules since they create a specific triple ((*focus node* , *<property>*) , *<value>*). We highlight that this structure facilitates the query-answering task.

Bischof et al. [11] propose an approach related to SHACL SPARQL-Rules to compute and materialise demography indicators (not meet F5). Moreover, the authors define a Python script that mediates to perform the rules (not meet F8). While the equations are defined as string literals (not meet F1), they provide a URI to them (meet F2). However, the kind of inputs and outputs are specialised for the Data Cube [33] model (partially meet F4 nor F9).

<footnote n="5">⁵ https://jena.apache.org/.</footnote>

<footnote n="6">⁶ https://www.w3.org/TR/shacl-af/.</footnote>
To sum up, SPARQL extensions improve the definition of queries and their modularity but need intermediate technologies to infer derivable data and to be stored in an linked format as RDF. While SPIN rules could appear to fill these gaps the SPARQL queries are still far from the mathematical notations. Later on this paper, SHACL rules are presented as an improvement of SPIN rules. In addition to the SPARQLRules, they offer the TripleRules and the ValueRules and along with them the NodeExpressions. In contrast to SPARQL queries, NodeExpressions are closer to the mathematical notation. Although ValueRules are limited in the expressive power, they fulfil many of our desired features (F1, F4, F7, F8) whereas other features are straightforward to include (F2 and F6). However, they can be improved in two directions: to allow virtual ANRs (F5) and produce quantities (F9).

## 4. QAVAN: Query-answering approach for ANRs over KGs

In this work, we propose QAVAN, a new query-answering approach addressing the problem of querying KG data in the presence of virtual ANRs by enhancing ValueRules.QAVAN can also handle nested ANRs. To our knowledge, current SHACL engines only execute rules in a materialised fashion leading to memory allocation issues when handling (i) large volumes of data and (ii) an important number of ANRs. On the contrary, given a KG, a query and a set of ANRs QAVAN can provide efficiently answers computing only the data referring to the given query.

### 4.1. Incorporating ValueRules to SHACL schemas

To facilitate the understating of QAVAN and future extensions, we incorporate ValueRules to the definition of a SHACL schema.

**Definition 3 (A SHACL Schema [32]).** A SHACL schema *S* is represented as a triple <S, *targ*, *def*> where *S* is a set of URIs referred as shape names, *targ* is a function that assigns a target query for each shape name *s* ∈ *S*, and *def* is a function that assigns a conjunction of constraints for each shape name *s* ∈ *S*.

In this work, each *targ(s)* of a SHACL schema, is a unary query about an RDF class that can be evaluated against a given KG *G*. This query returns a set of URIs called *target nodes*.

Given the definition of a SHACL schema, **Example 2** illustrates a shape named :PS having as target a SPARQL query returning all the instances of the class :Person (i.e. the target nodes). *def(:PS)* contains two constraints stating that an instance of the class :Person can only have one :weight and one :height property. If an instance has twice the property :height SHACL reports that the KG is invalid against the person shape :PS.

**Example 2.** A SHACL shape for the class Person named :PS

$$ 
\begin{array}{l}
\mathit{targ}(:\mathit{PS}) = \mathbf{SELECT} \ ?x \\
\qquad \mathbf{WHERE} \quad \{?x a :\mathit{Person}\} \\
\\
\mathit{def}(:\mathit{PS}) = (=_1 :\mathit{weight}.\mathit{T}) \land (=_1 :\mathit{height}.\mathit{T})
\end{array}
$$

ValueRules are comparable to SHACL constraints, both are declared within a shape but they have different purposes. The first for validation and the later for data production. We propose to incorporate to a SHACL schema a new function called *numRel* that associates a set of ANRs to a shape *s* ∈ *S*. Therefore, we redefine a SHACL schema as *S* = <S, *targ*, *def*, *numRel*>

With the new definition of a SHACL schema, **Example 3** illustrates the new notations. This example includes a graph *G* with one person instance containing two properties (:weight and :height), a set of shapes *S* containing in this case one shape :PS, a set of ANRs containing one ANR concerning the :BMI property, and finally a query *Q* that retrieves instances of person class and their calculable property :BMI.

Additionally, an ANR in *numRel(s)* is defined as a pair (*path*, *nodeExp*) where *path* is the path to the new property and *nodeExp* contains a mathematical formula. Note that for our research the set of constraints is empty. Extensions of QAVAN with constraints will be tackled in the future work.

**Example 3.** Body Mass Index (BMI) calculation using ANRs in form of ValueRules.

$$ 
\begin{array}{l}
G = \{ :Person(p1), :weight(p1, 85), :height(p1, 180) \} \\
S = \{ :PS \} \\
\\
\mathit{targ}(:\mathit{PS}) = \mathbf{SELECT} \ ?x \ \mathbf{WHERE} \ \{ ?x a :Person \} \\
\\
\mathit{numRel}(:\mathit{PS}) = \{ ( : \mathbf{BMI}, \frac{:weight}{:height^2} ) \} \\
\\
Q = \mathbf{SELECT} \ ?p \ ?bmi \ \mathbf{WHERE} \\
\qquad \{ ?p a :Person, ?p :BMI, ?bmi. \}
\end{array}
$$

### 4.2. SHACL NodeExpressions

NodeExpressions play a fundamental role in QAVAN since they are the mean to encode mathematical formulas in RDF. NodeExpressions are similar to XPath [34] and XQuery [35] expressions (two languages used to query data in XML documents). So far we have described mathematical formulas in a human-readable fashion as shown in **Examples 1 and 3**. However, as we established in Section 3 the different domains can benefit from a representation that plays in favour of FAIR principles [1], i.e. providing more robust metadata for the mathematical formulas and allowing independence from a specific programming language. NodeExpressions are declarative and express the formulas in a LOD format. We argue that NodeExpressions and RDF-OpenMath [8] expressions are convenient for that purpose. Besides, this kind of expressions are close to the mathematical notation. Thereby, here we choose NodeExpressions since they are already aligned with SHACL and can be computed by SW engines avoiding dependency of CAS. We define NodeExpression grammar as follows:

$$ 
\begin{array}{l}
\langle \mathit{NodeExpression} \rangle ::= \{ \langle \mathit{Symbol} \rangle \{ \langle \mathit{Expression} \rangle [\', \langle \mathit{Expression} \rangle ]^* \} \} \{ \}' \}' \\
\\
\langle \mathit{Expression} \rangle ::= \langle \mathit{Literal} \rangle | \langle \mathit{URINode} \rangle | \langle \mathit{NodeExpression} \rangle \\
\\
\langle \mathit{Symbol} \rangle ::= \langle \mathit{SHACLSymbol} \rangle | \langle \mathit{DASHSymbol} \rangle | \langle \mathit{UserDefinedSymbol} \rangle \\
\\
\langle \mathit{SHACLSymbol} \rangle ::= \{ \mathit{sh:path} \} | \{ \mathit{sh:if} \} | ... \\
\\
\langle \mathit{DASHSymbol} \rangle ::= \{ \mathit{sparql:add} \} | \{ \mathit{sparql:multiply} \} | \{ \mathit{sparql:divide} \} | \\
\qquad \{ \mathit{sparql:substract} \} | ...
\end{array}
$$

In the SHACL-AF proposal NodeExpressions are constructed as RDF blank nodes, and more precisely, a blank node that contains a unique predicate (the symbol) and a list as object. The list in the object part can contain Literals, URINodes, or NodeExpressions. Listing 1 presents the person shape :PS with the BMI as a NodeExpression in Turtle format. The NodeExpression in this listing corresponds to the part after the property *sh:values*. Note that Listing 1 contains two NodeExpressions; one with the symbol *sparql:divide* and the other with the symbol *sparql:multiply*.

SHACL incorporates two kinds of symbols to use with NodeExpressions, the DASHSymbols and the SHACLSymbols. The DASHSymbols defined with the prefix *sparql*: refer to the DASH vocabulary,<fnref n="7" /> a set of SHACL functions that defines the built-in SPARQL 1.1 functions. The

<footnote n="7">⁷ https://datashapes.org/sparql.</footnote>
SHACLSymbols defined with the prefix sh-, refer to a set of SHACL built-in functions used in the SHACL constraints. Listing 1 shows the use of the SHACLSymbol sh:sh path aiming to link the NodeExpressions with the RDF graph. These path expressions allow to query data conforming to the literal and QuantityValue models.

<caption>Listing 4: NodeExpressions as URINodes</caption>

```c
exp:bmiExp a sh-math:NodeExpression;
sparql:divide([sh: path :weight] [sparql:multiply([sh: path :height] [sh: path :height])])];

:PS a sh:NodeShape;
sh:target :Person;
sh:property [sh: path :BMI; sh:values exp:bmiExp.];
```

However, having NodeExpressions as blank nodes leads to some issues: (i) difficulty to add metadata about the mathematical computation, (ii) difficulty to conform FAIR and LOD principles due to the lack of a URI identifier, (iii) complex expressions, difficult to write and read in one blank node. Therefore, we propose some modifications on SHACL-AF to enable NodeExpressions as URINodes.

Listing 4 shows the BMI NodeExpression as a URINode. Then in the SHACL shape, instead of writing a complex blank node one can refer to the URINode. We include the namespaces sh-math: and exp: to distinguish the URIs we add from the SHACL URIs.

### 4.3. QAVAN algorithm

So far, we have presented ValueRules as a means to enrich the KG data and NodeExpressions as an approach to represent “FAIR” mathematical formulas. Here, we explain how to execute these ANRs in demand. For that goal, our approach exploits the contextual data provided by the ValueRules that includes: the target class and the path to the derivable property. In the remains of the paper ANRs refer to ValueRules. Broadly, our approach is based on the following five steps:

1. **Query interpretation.** Extract from the query information about the target class and variable.

2. **Shapes and rules activation.** Activate the shape and the ANRs involved in the query. When an ANR is deactivated the SHACL engine ignores it.

3. **Target node acquisition.** Remove all the expressions in the query that concern calculable properties. Thus, this new query is used to extract target node URIs.

4. **ANRs performance.** Produce the inference graph by performing the activated ANRs considering the set of target nodes.

5. **Query evaluation.** Evaluate the query against the union of the inference graph with the initial graph.

Algorithm 2 provides a detailed view of QAVAN. For comparison, we also present the Algorithm 1 with the necessary steps to materialise ANRs inspired from the SHACL-API<fnref n="8" /> implementation.

**Conventions.** Within the algorithms we use the notations:

- $\llbracket q \rrbracket^G$ to state that the query $q$ is evaluated against the graph $G$. This evaluation produces a SPARQL solution mapping (variables, values). If the query $q$ only returns one variable, we assume that the result is a list of values instead of a mapping.

- $\llbracket e \rrbracket^{T,G}$ to state that the ANR $e$ is performed against $G$ but only for the target nodes in $T$. This evaluation produces a set of triples.

Moreover, we use capital letters for sets of items (e.g. a graph $G$) and lower case to one element (e.g. a query $q$).

Algorithm 1 takes as inputs an initial graph $G$ and a SHACL schema $S$. Note that the query is irrelevant for this algorithm. For each shape

### Algorithm 1 Materialised ANRs

Require: $G, S = \langle S, \targ, \def, \numRel \rangle$

Ensure: $G''$

1. $G' \leftarrow \emptyset$

2. **for all** $s \in S$ **do**

3. $T \leftarrow \llbracket \targ(s) \rrbracket^G$

4. **for all** $e \in \numRel(s)$ **do**

5. $G' \leftarrow G' \cup \llbracket e \rrbracket^{T,G}$

6. **end for**

7. **end for**

8. $G'' \leftarrow G \cup G'$

9. **return** store($G''$)

▷ get all the target nodes

### Algorithm 2 QAVAN

Require: $G, S = \langle S, \targ, \def, \numRel \rangle, q$

Ensure: $\llbracket q \rrbracket^{G''}$

1. $T_c \leftarrow \text{getTargetClasses}(S)$

2. $(tc^q, tv^q, P^q) \leftarrow \text{getQueryInfo}(q, T_c)$

3. $s^q \leftarrow \{s_i \mid \targ(s_i) = tc^q \land s_i \in S\}$

4. $P^s \leftarrow \text{getCalcProperties}(s^q, S)$

5. $P \leftarrow P^q \cap P^s$

6. **deactivateAllRules**(S)

7. **activateRulesInShape**(s^q, P, S)

8. $q' \leftarrow \text{rewriteQuery}(q, tv^q, P)$

9. $T \leftarrow \llbracket q' \rrbracket^G$

▷ get only the query target nodes

10. $G' \leftarrow \emptyset$

11. **for all** $e \in \numRel(s^q)$ **do**

12. **if** activated(e) **then**

13. $G' \leftarrow G' \cup \llbracket e \rrbracket^{T,G}$

14. **end if**

15. **end for**

16. $G'' \leftarrow G \cup G'$

17. **return** $\llbracket q \rrbracket^{G''}$

name $s$, the target nodes are obtained by evaluating $\targ(s)$ against $G$ (Line 3). Lines 3–5 evaluate all the ANRs in $E$ for each focus node in order to produce an inferred data graph ($G'$). Then, $G'$ and $G$ are merged to produce the new enriched graph $G''$.

Algorithm 2 shows our proposal QAVAN that takes as input a graph $G$, a SHACL schema $S$ and a query $q$ and relies on the following functions:

* $\text{getTargetClasses}(S) \to T_c$. Given a SHACL schema $S$, we create a new set with the RDF classes involved in each $\targ(s)$, where $s \in S$.

* $\text{getQueryInfo}(q, T_c) \to tv^q, tc^q, P^q$. Given a query $q$, and a set of target classes $T_c$, this function transforms $q$ into an Abstract Syntax Tree (AST) and iterates on its Basic Graph Patterns (BGP). For patterns about types, e.g $(?p \text{rdf:type:Person})$, the method checks if the class (object in the BGP), is in $T_c$. If this is the case, the variable associated to that pattern is marked as the target variable $(tv^q)$ and the class as the target class $(tc^q)$. In addition, the function iterates again in the BGP to find patterns involving $tv^q$ and extracts its predicates $(P^q)$.

* $\text{getCalcProperties}(s^q, S) \to P^s$. Given a SHACL schema $S$ and a shape $s^q \in S$. For each ANR $e \in \numRel(s^q)$, where $e$ is a pair $(\text{path}, \text{nodeExp})$, this function extracts the path and creates a set with the URIs of those paths $(P^s)$.

* $\text{activateRulesInShape}(s^q, P, S) \to s'$. Given a shape name $s^q$ and a set of properties $P$, this function activates the ANRs in $\text{numRel}_s^q$ that have a path contained in $P$.

* $\text{rewriteQuery}(q, tv^q, P) \to q'$. Given a query $q$ and a set of property URIs $(P)$, this function rewrites $q$ by removing all the expressions

<footnote n="8">⁸ https://github.com/TopQuadrant/shacl.</footnote>
that involve properties in P. After that, the method rewrites the SELECT statement to only project the variable that identifies the target nodes. This method returns a new query q'.

These functions are used to describe QAVAN. Following, we relate the five steps mentioned of QAVAN with the corresponding lines from the Algorithm 2:

1. **Query interpretation.** It concerns lines 1–3, $T^S$ contains the list of target classes from S, QAVAN invokes the function `getQueryInfo` to obtain `(tc^q, tt^q, P^q)`: the target class, the target variable, and the properties list, respectively. Note that $P^q$ can contain properties that are already in the data G and not only calculable properties. Finally, using $tc^q$ in Line 3 QAVAN can obtain from S the shape involved in q referred as $s^q$.

2. **Shapes and rules activation.** It concerns lines 4–7, knowing $s^q$ it is possible to extract all the calculable properties its ANRs can produce ($P^s$). Moreover, P in Line 5 represents the intersection of $P^q$ and $P^s$, in other words: the calculable properties used in q. In Line 6, QAVAN performs the deactivation of all the ANRs and shapes in S. In line 7, QAVAN invokes `activateRulesInShape` to activate the specific ANRs in $s^q$.

3. **Target nodes acquisition.** It concerns Lines 8–9. This step begins with the rewriting of q by invoking the function `rewriteQuery`. It generates the new query $q'$. Therefore, QAVAN evaluates $q'$ against G. Without the rewriting of q to $q'$, this line may produce an empty set. T contains the evaluation results, those are the target nodes.

4. **ANRs performance.** It concerns lines 10–15. For each element $e \in numRel(s^q)$, QAVAN asks if e is an activated ANR. For the true case QAVAN performs the ANR e against G considering target nodes T, otherwise the ANR is ignored. Besides, the inference graph $G'$ is the union of the resulting triples after performing each activated ANR.

5. **Query evaluation.** Finally, $G''$ is the union of the inference graph $G'$ and the initial data graph G. Then, QAVAN evaluates q against $G''$.

### 4.4. QAVAN extensions: Nested ANRs and inferences

QAVAN has two optional features, the *Nested ANRs feature* that takes into account dependencies between ANRs and the *inference feature* that allows to increase the number of target nodes by considering not only instances of the target class but also instances of their subclasses.

The *Nested ANRs feature* requires to define an execution order for the ANRs. An example described in Section 3.2 shows how properties expressing the same information in different units can be taken into account to provide more answers. To implement this feature, we redefine the function `activateRulesInShape` to its recursive version as detailed in Algorithm 3. When the function finds an ANR e to activate, in line 5 the function will obtain all the paths contained in the current NodeExpression of e referred in the function as `nodeExp`. Having this list of properties the function performs a recursive call decreasing the order. By decreasing the order, SHACL engines know that the following ANRs must be computed before. Besides, SHACL engines groups ANRs based on the order, performing the ones with the lowest value first. Then, when the order changes, SHACL engines updates the inference graph. Therefore, following ANRs groups will have access to the new produced triples.

The *inference feature* is useful to access instances that were annotated only with subclasses of the defined target class. For example, given a graph with these triples: `Person(p1)`, `Actor(p2)`. The default behaviour of QAVAN is to ignore the instance $p2$ for queries asking for `Person` ANRs. After activating this feature, and considering the axiom `Actor ⊑ Person`, QAVAN can recognise that $p2$ is also a target node of the class Person. To activate this feature, QAVAN relies on the engine

that executes the query to obtain the target nodes ($q'$). Line 9 from Algorithm 2 shows that evaluation. If the engine enables ontological reasoning, then it will obtain all the subclasses instances as well. Note that an alternative way to obtain the same results would be to apply a saturation step in the data before performing the queries.

### Algorithm 3 Nested ANRs

1. **function recursiveActivateRulesInShape(s^q, P, S, order)**

2. **for all e ∈ numRel(s^q)**
   | e = (path, nodeExp, True, order) **do**

3. **if path ∈ P then**

4. e ← (path, nodeExp, False, order)

5. $P^e \leftarrow getAllPathsNodeExp(nodeExp)

6. recursiveActivateRulesInShape(s^q, $P^e$, S, order - 1)

7. **end if**

8. **end for**

9. **end function**

### 4.5. Examples using QAVAN

Example 4 presents a data graph G that contains several triples about instances of the :Person class. Each instance has the properties :height and :weight. The set S contains one shape name (:PS) and the `targ(:PS)` is a query that retrieves all the instances of the class :Person. `numRel(:PS)` contains two ANRs: one to produce the Body Mass Index (:BMI) and the other to produce the Body Surface Area (:BSA). Both are clinical indexes based on people' height and weight. Finally, Example 4 presents two queries: $q_1$ that asks for the :BMI for people (:p1, :p2) and $q_2$ asks for the :BSA only for people that have weight greater than 90. Since QAVAN takes one query as input, we use $q_1$ and $q_2$ in two different executions.

Example 4. Body Mass Index (BMI) and Body Surface Area (BSA) calculation via Virtual ANRs.

$$ 
\begin{aligned}
G = & \{ :Person( :p1), :height( :p1, 1.73), :weight( :p1, 75.3), \\
    & :Person( :p2), :height( :p2, 1.56), :weight( :p2, 60.3), \\
    & :Person( :p3), :height( :p3, 1.89), :weight( :p3, 90.2), \\
    & :Person( :p4), :height( :p4, 1.82), :weight( :p4, 80.5) \}
\end{aligned}
$$
$$ S = \{ :PS \} $$
$$ 
\begin{aligned}
\targ( :PS) = & \text{ SELECT } ?x \text{ WHERE } \{ ?x a :Person \} \\
\text{numRel( :PS)} = & \{ ( :BMI, exp :bmi), ( :BSA, exp :bsa) \}
\end{aligned}
$$

$$ q_1 = \text{ SELECT } ?p \ ?bmi \ ?h \text{ WHERE } \{ ?p a :Person. \\ ?p :BMI ?bmi. ?p :height ?h. \} $$

$$ FILTER(?p in (:p1:p2)) $$

$$ q_2 = \text{ SELECT } ?p \ ?bsa \text{ WHERE } \{ ?p a :Person. \\ ?p :BSA ?bsa. ?p :weight ?w. \} $$

$$ FILTER(?w > 90) $$

We detail the execution scenarios using 3 tables. These tables have two columns, the *Step* and the *Scope*. The *Step* column enumerates the mentioned steps:

1. Query interpretation

2. Shapes and rules activation

3. Target nodes acquisition

4. ANRs performance

5. Query evaluation

The *Scope* column shows, for each step, the variables scope when the execution of such step is over.

Table 3 illustrates the execution of Algorithm 1. In this algorithm the query is irrelevant. Therefore, steps 1 and 2 do not apply for this algorithm. In step 3, we begin with the shape $s = :PersonShape$
<table><caption>**Table 3**
Algorithm 1 (Materialised) execution.</caption><thead><tr><th>Steps</th><th>Scope</th></tr></thead><tbody><tr><td>3.</td><td>s = :PersonShape, targ(s) = SELECT ?p WHERE ?p a :Person, T = { :p1, :p2, :p3, :p4}</td></tr><tr><td>4.</td><td>G' = { :BMI (:p1, 25.1595), :BSA (:p1, 1.8905), :BMI (:p2, 24.7781), :BSA (:p2, 1.5959), :BMI (:p3, 25.2512), :BSA (:p3, 2.1765), :BMI (:p4, 24.2724), :BSA (:p4, 2.0167)} Executed ANRs = 2, Instances = 4, Total Computations = 8</td></tr></tbody></table>

<table><caption>**Table 4**
QAVAN execution steps for $q_1$ and $q_2$.</caption><thead><tr><th>Steps</th><th>Scope for $q_1$</th><th>Scope for $q_2$</th></tr></thead><tbody><tr><td>1.</td><td>T<sup>S</sup> = { :Person} (tc<sup>q</sup> = :Person, tv<sup>q</sup> = ?p, P<sup>q</sup> = { :BMI, :height}) s<sup>q</sup> = :PersonShape</td><td>T<sup>S</sup> = { :Person} (tc<sup>q</sup> = :Person, tv<sup>q</sup> = ?p, P<sup>q</sup> = { :BSA, :weight}) s<sup>q</sup> = :PersonShape</td></tr><tr><td>2.</td><td>P<sup>s</sup> = { :BMI, :BSA} P = { :BMI} numRel(s<sup>q</sup>) = { :BMI, exp :bmi, activated = True}, ( :BSA, exp :bsa, activated = False) } P<sup>s</sup> = { :BMI, :BSA} P = { :BSA} numRel(s<sup>q</sup>) = { :BMI, exp :bmi, activated = False}, ( :BSA, exp :bsa, activated = True) } T<sup>s</sup> = { :p1, :p2} q' = SELECT ?p WHERE ?p a :Person. ?p :height ?h. FILTER(?p in (:p1 :p2)) T = { :p3} q' = SELECT ?p WHERE ?p a :Person. ?p :weight ?w. FILTER(?w > 90) T = { :p3} G' = { :BMI (:p1, 25.1595), :BMI (:p2, 24.7781)} G' = { :BSA (:p3, 2.1765)} Result = {(?p = :p1, ?bmi = 25.1595, ?h = 1.73), (?p = :p2, ?bmi = 24.7781, ?h = 1.56)} Result = {(?p = :p3, ?bsa = 2.1765)} Executed ANRs = 1, Instances = 2, Total Computations = 2 Executed ANRs = 1, Instances = 1, Total Computations = 1</td></tr><tr><td>4.</td><td></td><td></td></tr><tr><td>5.</td><td></td><td></td></tr></tbody></table>

to extract the target nodes. In this case, the complete list of :Person instances is (:p1, :p2, :p3, :p4). For each instance, the algorithm performs the ANRs in s to calculate the :BMI and the :BSA properties. As a result, the inference graph G' presents 8 new triples. This execution involves 2 ANRs and 4 instances leading to 8 computations. This execution serves as baseline for the other scenarios.

Table 4 illustrates the different steps of the QAVAN execution for the queries $q_1$ and $q_2$. In this table, the column Scope for the query $q_1$ presents in the step 1 the set $T_c$ with the class :Person, since we only have the shape :PersonShape. Then, from the input query, QAVAN identifies :Person as the target class, ?p as the target variable, and :BMI and :height as the properties associated to the variable ?p. Knowing tc<sup>q</sup> = :Person, QAVAN extracts the specific shape name and assigns to s<sup>q</sup>. In step 2, QAVAN obtains, using s<sup>q</sup>, the two properties their ANRs can produce. Having the information from the shape and from the query, QAVAN detects that $q_1$ only requires to compute the ANR that produces :BMI. Thus, QAVAN activates this ANR, whereas deactivates the others. In step 3, QAVAN rewrites $q_1$, now the SELECT clause is only asking for the variable ?p while the expressions concerning the :BMI are deleted. We can compare this step with the step 3 in Table 3 where the query to retrieve the target nodes is more generic and obtains more instances. Step 4 shows that the inference graph is smaller than in Table 3, only presenting two new triples, it means that QAVAN only performs two computations. For the execution of query $q_2$, the scope is similar to the scope of $q_1$. Main changes appear in the properties that are asked and the type of filter. In this example, only one computation is performed, and the ANR activated is the one concerning the property :BSA. Note that executions of $q_1$ and $q_2$ demonstrate two scenarios where QAVAN performs less computations than Algorithm 1.

## 5. Experimental evaluation

Two experiments were conducted to evaluate the performance of QAVAN. The first experiment aimed (i) to compare QAVAN against a materialised approach (considered as a baseline), and (ii) demonstrate the benefits of QAVAN in terms of processing time and disk space. This experiment used the Météo-France dataset [36], a typical scientific dataset containing meteorological records. The second experiment

aimed to show the generality of our approach for representing real mathematical formulas using two public heterogeneous datasets: DBpedia [37] and Eurostat.<fnref n="9" /> Based on both datasets, we created a dataset containing instances of the class Settlement and its subclasses City and Town. Additionally, this experiment allowed to show the interest of the extensions of QAVAN (See Section 4.4) and how they can affect the number of results in a positive manner providing more answers. In order to compare our approach with a baseline method, we have performed our own implementation of the query-answering method proposed by Bischof and Polleres [12] (since the original code was not available), referred in the rest of this work as PerfectRefEQ.

### 5.1. Implementation and settings

QAVAN was implemented based on Apache Jena<fnref n="10" /> and SHACL APIs.<fnref n="11" /> The QAVAN approach along with the datasets used in the experimental evaluation and its results are available at the git repository: https://github.com/felipe-vargas-inrae/qavan as well as the PerfectRefEQ implementation https://github.com/felipe-vargas-inrae/PerfectRefEQ

The experiments were conducted in a machine with the following features: Ubuntu 20.04.4 LTS, Intel(R) Core(TM) i7-8665U CPU @ 1.90 GHz Cores: 6. Additionally, we used as JVM parameters: -Xms30 g -Xmx30 g -Xdump:none -XX:+UseParallelGC to control the memory usage and the Java Garbage Collector.

### 5.2. Comparison of QAVAN against materialised approaches

In this first set of experiments, the goal was to demonstrate the advantages of QAVAN against a materialised approach.

<footnote n="9">⁹ https://ec.europa.eu/eurostat/.</footnote>

<footnote n="10">¹⁰ https://jena.apache.org/.</footnote>

<footnote n="11">¹¹ https://github.com/TopQuadrant/shacl.</footnote>
<table><caption>**Table 5**

Statistics of the properties for the dataset D50.</caption><thead><tr><th>Property</th><th>% of nulls</th><th>Mean</th><th>Min</th><th>Max</th><th>Unit</th></tr></thead><tbody><tr><td>Air temperature</td><td>10.47</td><td>284.2</td><td>236.6</td><td>311.2</td><td>°K</td></tr><tr><td>Dew point temperature</td><td>36.65</td><td>281</td><td>253.6</td><td>514.8</td><td>°K</td></tr><tr><td>Air relative humidity</td><td>36.64</td><td>82.5</td><td>14</td><td>100</td><td>%</td></tr><tr><td>Wind speed</td><td>49.22</td><td>3.6</td><td>0</td><td>27.1</td><td>m/s<sup>-1</sup></td></tr><tr><td>Wind direction</td><td>49.26</td><td>191.8</td><td>0</td><td>360</td><td>°</td></tr><tr><td>Precipitation</td><td>7.58</td><td>0</td><td>0</td><td>25</td><td>mm</td></tr></tbody></table>

<table><caption>**Table 6**

Dataset size detail in terms of the number of triples, the number of instances and the file size in disk; after transforming Météo-France records into RDF.</caption><thead><tr><th>-</th><th>Number of triples</th><th>Number of instances</th><th>File size (MB)</th></tr></thead><tbody><tr><td>D1</td><td>2,896,133</td><td>87,640</td><td>80</td></tr><tr><td>D5</td><td>11,122,202</td><td>429,518</td><td>321</td></tr><tr><td>D10</td><td>18,471,158</td><td>863,350</td><td>549</td></tr><tr><td>D20</td><td>39,189,818</td><td>1,777,205</td><td>1160</td></tr><tr><td>D50</td><td>106,506,111</td><td>4,349,937</td><td>3107</td></tr></tbody></table>

<figure><img src="image_5.png" /><figcaption>**Fig. 1.** Ontological data model based on SOSA and QUDT.</figcaption></figure>

### 5.2.1. Data graph

The Météo-France<fnref n="12" /> dataset [15] contains time-series data over 500 weather stations in a delimited area on the Brittany coasts. This dataset contains instances of weather observations taken in a specific time period (initially described in a CSV format and transformed into RDF for the sake of this experiment). In particular, each weather observation is described by six properties: :windSpeed, :airTemperature, :airRelativeHumidity, :precipitation, :windDirection and :dewPointTemperature 5.

Note that we choose to model all these properties as object properties storing not only the values but also their units of measurements. Fig. 1 shows our data model which uses terms from QUDT [18] and SOSA [38] ontologies. These ontologies are widely used in numerous research domain to model observational data.

To evaluate the robustness of our approach against different sizes of KGs, we split the Météo-France dataset in five datasets varying in the number of weather samples as shown in Table 6. For each dataset, Table 6 includes the number of triples and the RDF file size. The name of each dataset $D \langle N \rangle$ refers to the top N weather stations. For instance, D1 refers to data coming from one weather station whereas D20 to data coming from 20 stations. Therefore, the bigger the N the bigger the size of the dataset evaluated in this experiment.

### 5.2.2. Shapes and ANRs

To validate our approach over the five datasets created from Meteo-France dataset, we generate different sets of ANRs (e.g. 5, 10, 20, ..., 100) using a random generator. More precisely, the ANRs are generated

<table><caption>**Table 7**

Queries used in the evaluation, each group vary the number of instances involve $\langle q_0, q_1, q_2 \rangle, \langle q_3, q_4, q_5 \rangle, \langle q_6, q_7, q_8 \rangle, \langle q_9, q_{10}, q_{11} \rangle$, at within each group, every query retrieves a different number of calculable properties. The $q_0$ also refers to the materialised approach.</caption><thead><tr><th>-</th><th>Derivable properties</th><th>Time</th></tr></thead><tbody><tr><td>q<sub>0</sub></td><td>All</td><td>All</td></tr><tr><td>q<sub>1</sub></td><td>One</td><td>All</td></tr><tr><td>q<sub>2</sub></td><td>50%</td><td>All</td></tr><tr><td>q<sub>3</sub></td><td>All</td><td>One day</td></tr><tr><td>q<sub>4</sub></td><td>One</td><td>One day</td></tr><tr><td>q<sub>5</sub></td><td>50%</td><td>One day</td></tr><tr><td>q<sub>6</sub></td><td>All</td><td>One week</td></tr><tr><td>q<sub>7</sub></td><td>One</td><td>One week</td></tr><tr><td>q<sub>8</sub></td><td>50%</td><td>One week</td></tr><tr><td>q<sub>9</sub></td><td>All</td><td>One month</td></tr><tr><td>q<sub>10</sub></td><td>One</td><td>One month</td></tr><tr><td>q<sub>11</sub></td><td>50%</td><td>One month</td></tr></tbody></table>

<table><caption>**Table 8**

Number of instances (target nodes) by query and dataset.</caption><thead><tr><th>-</th><th colspan="5">Dataset</th></tr><tr><th></th><th>D1</th><th>D5</th><th>D10</th><th>D20</th><th>D50</th></tr></thead><tbody><tr><th>q<sub>0</sub></th><td>87,640</td><td>429,518</td><td>863,350</td><td>1,777,205</td><td>4,349,937</td></tr><tr><th>q<sub>3</sub></th><td>1</td><td>5</td><td>10</td><td>21</td><td>50</td></tr><tr><th>q<sub>6</sub></th><td>1441</td><td>7204</td><td>14,399</td><td>29,915</td><td>72,294</td></tr><tr><th>q<sub>9</sub></th><td>7430</td><td>33,026</td><td>70,186</td><td>151,995</td><td>370,726</td></tr></tbody></table>

using the DASH operators (i.e., add, subtract, divide, multiply), the data graph properties (e.g. :windSpeed, :airTemperature, :relativeHumidity) and random numerical literals.

### 5.2.3. Evaluation queries

In order to demonstrate the behaviour of our algorithm QAVAN against different types of queries, we defined eleven queries summarised in Table 7 covering different cases of time frames and calculable properties. Since the datasets contain time series data, we employ time as filter (e.g. observations of one-day) to assess QAVAN with different query result sizes. Note that all and 50% in the derivable properties is relative to the number of ANRs whereas one is always fixed. For instances, 50% of 100 ANRs represent a query asking for 50 calculable properties.

This evaluation aims to answer the following research questions:

* (RQ1) Is QAVAN able to improve the processing time for queries requiring few instances in their answers?

* (RQ2) Is QAVAN able to improve the processing time for queries involving few properties to be computed?

* (RQ3) Which processes are more time-consuming for QAVAN?

* (RQ4) How many ANRs do materialisation unfeasible considering different data graph sizes?

### 5.2.4. Results

We assess the performance of QAVAN on different datasets and queries by using as a baseline the query $q_0$ that retrieves all the ANRs over all the instances (see Table 7). Since $q_0$ is computing all the ANRs available for all the data, it is employed to simulate a materialised approach (see Algorithm 1) (see Table 8).

**Results of queries processing time:** Fig. 2 shows the impact of the number of ANRs on the processing time over 4 different queries, $q_0, q_3, q_6$ and $q_9$. All these queries contain the full list of calculable properties from the set of ANRs available. Note that $q_0$ retrieves data concerning a full year, $q_3$ data of a specific day, $q_6$ data of a specific week and finally $q_9$ data of a specific month. Fig. 2 aims to show the boundaries of the materialised approach and how QAVAN improves the processing time for queries that involve less instances. We observe that the materialised approach ($q_0$) processes fast (less than 1 min) small datasets (e.g., D1)

<footnote n="12">¹² The Dataset is licensed by METEO-FRANCE under Etalab Open Licence 2.0.</footnote>
<figure><img src="image_6.png" /><figcaption>**Fig. 2.** Comparison of processing time for queries obtaining all calculable properties and filter the time as follows: $q_0$ = one year, $q_3$ = one day, $q_6$ = one week, $q_9$ = one month. Processing time is presented in logarithm scale.</figcaption></figure>

over few ANRs (e.g., 20). This is not the case for big datasets (e.g., D50) over few ANRs (e.g., 20) that demonstrate an excessive processing time (about two hours). Note that in some domains a two-hour delay may be inadequate. Even worst was the case of the big dataset D50 with a large number of ANRs (e.g., 100) where no answer was obtained due to memory allocation issues. Indeed, this behaviour was observed from 30 ANRs. Therefore, query-dependent approaches such as QAVAN may be the only alternative in cases where materialisation is infeasible (e.g., D50 and 40 ANRs).

Results on Fig. 2 shows that QAVAN when evaluating queries $q_3$ and $q_6$ is able to provide results for all dataset scenarios avoiding the memory allocation issues, and also improving the processing time. Moreover, on the scenario of evaluating the query $q_9$ against the dataset D20 with 100 ANRs available, QAVAN demonstrates a great improvement in the processing time over the materialised approach ($q_0$), i.e., 8 min against 122 min showing an improvement of 92%. Thus is explained due to the capability of QAVAN to avoid unnecessary computations when less instances are required in the query results

While our experiments demonstrate the superiority of QAVAN against the materialised approach in terms of processing time, the size of datasets has an impact on QAVAN as well. Therefore, the evaluation of $q_9$ (returning 3,707,26 instances) against the biggest dataset (D50) showed that QAVAN experimented a higher processing time going up to 23 min whereas for $q_6$ and $q_3$ it was about 9 and 7 min, respectively. Note that queries returning numerous instances can have similar time executions for both approaches since no optimisation strategy can be applied for the case of QAVAN. Therefore, we can say that QAVAN is a much more appropriate for queries returning few instances against big datasets over many ANRs in terms of efficiency and processing time.

Fig. 3 shows the processing time for all the evaluated queries, grouped by the time filter. Since these results are more comparable, figures are not presented in logarithmic scale. Results depicted on Fig. 3 aim to demonstrate that QAVAN improves the processing time when less calculable properties are involved in the queries. In particular, Fig. 3(a) compares queries that retrieve all the instances (one-year queries) and vary the number of calculable properties. These results show that QAVAN improves the processing time when less calculable properties are invoked even against big datasets (e.g. D50 and D20). In particular, the evaluation of $q_1$ against the biggest dataset (D50) is processed in less than 4 min even for a large number of ANRs (around 100). Comparing $q_1$ and $q_2$ we observe an increase in the processing time since the second query expects more calculable properties in its answer. Note that, when $q_2$ is executed on D50 with 50 ANRs it reaches its limits. In Fig. 3(d), we observe that for one-month queries (returning 370,726 instances), the query $q_{11}$ that contains 50% of the calculable properties exhibits a processing time improvement of 60% compared to $q_9$ (i.e., 23 min for $q_9$ and 14 min for $q_{11}$), when evaluating against the dataset D50 over 100 ANRs.

To conclude, in this experimental evaluation we notice that QAVAN is able to handle all datasets involving millions of triples as long as the queries contain up to 50% of the calculable properties found in the ANRs. Additionally, when queries contain few calculable properties, QAVAN performs well even against datasets containing millions of triples and hundreds of ANRs. On the other hand, when queries return few instances, the number of calculable properties does not have a relevant impact on the processing time of our approach.

**Effect of query steps on processing time:** Fig. 4 exhibits the steps that are taking place in QAVAN, (e.g. load a graph G, perform ANRs, etc, using different colours) in order to demonstrate the importance of each step in the processing time for queries $q_0$, $q_3$, $q_6$ and $q_9$. Our main observation is that concerning the same query, each time step takes approximately the same proportion of time independently of the dataset size. In comparison, Fig. 4(a) shows the materialised approach ($q_0$). We notice that in this scenario, the step ‘Perform E’ is the most time-consuming step and dominates the total time, in particular when the number of ANRs increases. Conversely, ‘Load G’ is more time consuming when few ANRs are invoked. However, for 100 ANRs ‘Load G’ is irrelevant in terms of execution time as most of it is allocated to ‘Perform E’. ‘Store Rs’ also gains relevance when the number of ANRs increase, even overcoming the ‘Load G’ process. Fig. 4(d) details the evaluation of the one-month query $q_9$. Since this query returns less instances than $q_0$, for few ANRs the ‘Load G’ step is more dominant, whereas for many ANRs ‘Perform E’ takes more time. Moreover, for queries returning few instances as those shown in Figs. 4(c) and 4(b), ‘Load G’ step dominates the entire execution. These results demonstrate that ‘Load G’ and ‘Perform E’ are the most time-consuming steps during the execution of the queries. Thus, efforts may be focused in optimising those steps in the future.

**Inference graph size results:** Fig. 5(a) shows the storage saving of QAVAN during the evaluation of several queries and against the materialised approach. To guarantee a uniform comparison, we define a ratio relative to the evaluation of $q_0$. More precisely, we present the size of the new graph produced by a query evaluation divided by the size of the corresponding graph produced by $q_0$. Moreover, for a further analysis, we demonstrate on each sub-figure the size of the initial dataset G. Note that G corresponds on Fig. 5(a) to D10, D20 or D50. The comparison of G and the inference graph of $q_0$ ($G'_{q_0}$), for all the datasets, shows that after 20 ANRs $G'_{q_0}$ becomes bigger than the initial graph G. Bear in mind that an inference graph bigger than an initial graph could be undesired. We notice that D10 and D20 display similar results. This is not the case for D50 that experiments memory allocation issues to evaluate $q_0$ from 20 ANRs. Concerning the other queries referring to QAVAN, we observe that evaluations improve the G' size reducing its size. For instance, evaluation of $q_6$ and $q_3$ require a G' 90% and 99% smaller than $G'_{q_0}$, respectively.
<figure><img src="image_7.png" /><figcaption>Fig. 3. Query evaluation time comparison for sets of queries that share the same time filter and vary the number of calculable properties (all, 50%, one).</figcaption></figure>
<figure><img src="image_8.png" /><figcaption>Fig. 4. Impact of the execution steps on the total time.</figcaption></figure>
<figure><img src="image_9.png" /><figcaption>Fig. 5. Inference graph size ($G'$) relative to the inference graph required to evaluate $q_x$. Y axis presented in logarithmic scale.</figcaption></figure>

Fig. 5(b) exhibits similar results depicting the storage saving for small number of calculable properties. Size of $G'$ for $q_{10}$ and $q_{11}$ were smaller than the one for $q_0$. Therefore, as long as less instances are expecting as result of a query and when less calculable properties are existing in the query QAVAN will provide a much more compact graph. Note that unlike the materialised approach, QAVAN is going to keep this graph in memory during the query execution, giving to the our approach even more flexibility in terms of space saving.

### 5.2.5. Discussion of the performance of QAVAN versus the materialised approach

Our results show that QAVAN allows virtual ANRs and to express FAIR mathematical formulas over KG data modelled as quantity values. To our knowledge, this is the first attempt to address these two desired features in a single approach using SW technologies. Although similar works such as Bischof & Polleres [12] enable virtual ANRs and SHACL-API allows to express mathematical formulas, none of these works have combined both features in a single approach. Each of the research questions defined on Section 5.2.3 are discussed next.

**Answer to RQ1.** We evaluated QAVAN against different queries, those returning less instances (e.g., one-day or one-week data) presented a better processing time than the materialised approach. QAVAN took advantage of the filters used in the query to avoid to perform the ANRs for instances not involved in the query.

**Answer to RQ2.** For each group of queries we evaluated the impact of retrieving less calculable properties. The queries retrieving only one calculable property and 50% of them showed a better processing time compared to retrieve all of them. This improvement was more relevant for those queries returning millions of instances.

**Answer to RQ3.** In general, 'Load G', 'Perform E' and 'Store Rs' were the most time-consuming steps during query executions. More in detail, regarding the queries that return few instances, 'Load G' was the most time-consuming step. Conversely, for queries returning several

instances, even for few ANRs (e.g. 10), 'Perform E' was the most time-consuming step. We also noticed that for the materialised approach with few ANRs 'Load G' was more time-consuming whereas for many ANRs 'Perform E' overcomes 'Load G'.

**Answer to RQ4.** We found a boundary for the materialised approach on 30 ANRs against a big dataset (106,506,111 triples and 4,346,937 instances) where this approach does not provide any results since its execution never finishes. On the contrary, QAVAN succeeded to provide answers to such contexts.

### 5.3. Evaluation on DBpedia and eurostat datasets

We evaluated our approach's behaviour on from two very well known open datasets, DBpedia<fnref n="13" /> and Eurostat Urban Audit.<fnref n="14" /> Note that similar data coming from DBpedia and Eurostat have been also used in the Bischof et al. [12] experiments. This experimental evaluation allowed us to demonstrate the utility of our approach in datasets coming not only from experimental data but also in other domains. Along with this goal we also exhibit the importance of the inference and nested ANRs features of our approach in order to obtain more valuable answers.

DBpedia is currently one of the biggest and more used public KGs. DBpedia is an effort to structure and publish Wikipedia<fnref n="15" /> data on the web. On the other hand, Eurostat is a portal of the European Union (EU) that periodically publishes statistics and indicators concerning its country members. Eurostat data is published in tabular format and since organisations can voluntarily upload information, it is often incomplete. In the next sections, we describe the process to acquire the data from DBpedia and Eurostat as well as the definition of the ANRs and queries to evaluate these datasets.

<footnote n="13">13 https://databus.DBpedia.org/DBpedia/ version: 2022.09.01.</footnote>

<footnote n="14">14 https://ec.europa.eu/eurostat/web/cities/data/database.</footnote>

<footnote n="15">15 https://www.wikipedia.org/.</footnote>
<table><caption>**Table 9**
Full list of properties from the DBpedia (dbp:) and Eurostat (eurostat:) datasets with their frequency.</caption><thead><tr><td>Property</td><td>Frequency</td></tr></thead><tbody><tr><td>rdf:type</td><td>869</td></tr><tr><td>dbp:name</td><td>527</td></tr><tr><td>dbp:areaKm</td><td>69</td></tr><tr><td>dbp:areaMetroKm</td><td>52</td></tr><tr><td>dbp:areaTotal</td><td>452</td></tr><tr><td>dbp:areaTotalKm</td><td>452</td></tr><tr><td>dbp:areaTotalSqMi</td><td>22</td></tr><tr><td>dbp:areaUrbanKm</td><td>53</td></tr><tr><td>dbp:urbanAreaKm</td><td>23</td></tr><tr><td>dbp:populationMetro</td><td>114</td></tr><tr><td>dbp:populationTotal</td><td>356</td></tr><tr><td>dbp:populationUrban</td><td>112</td></tr><tr><td>dbp:urbanPop</td><td>24</td></tr><tr><td>eurostat:code</td><td>867</td></tr><tr><td>eurostat:populationFemale</td><td>753</td></tr><tr><td>eurostat:populationMale</td><td>753</td></tr><tr><td>eurostat:populationTotal</td><td>757</td></tr></tbody></table>

Listing 5: Montpellier & Barcelona resources after merging DBpedia & Eurostat

```
dbr:Montpellier rdf:type dbo:Settlement;
dbp:areaKm "56.88"^xsd:double;
dbp:name "Montpellier";
dbp:urbanAreaKm "310"^xsd:double;
dbp:urbanPop "449187"^xsd:double;
eurostat:code "FR011C";
eurostat:populationFemale "192670"^xsd:double;
eurostat:populationMale "172053"^xsd:double;
eurostat:populatscientificTotal "364723"^xsd:double.
```

```
dbr:Barcelona rdf:type dbo:City;
dbp:areaTotalKm "101.4"^xsd:double;
dbp:populationMetro "5474482"^xsd:double;
dbp:populationUrban "4840000"^xsd:double;
eurostat:code "ES002C";
eurostat:populationFemale "1942188"^xsd:double;
eurostat:populationMale "1813324"^xsd:double;
eurostat:populationTotal "3755512"^xsd:double.
```

### 5.3.1. Data graph acquisition

We have created a new dataset containing information from both DBpedia and Eurostat. From both sources we have extracted data of type: **dbo:Settlement**, **dbo:City**, and **dbo:Town**. Note that in the DBpedia ontology<fnref n="16" /> the classes **dbo:City** and **dbo:Town** are subclasses of the class **dbo:Settlement**. Therefore, we use the term settlement to refer to all of them. We also notice that certain big cities such as Montpellier are annotated in DBpedia with their superclass **dbo:Settlement** rather than the more precise annotation **dbo:City**. Eurostat data has been transformed into RDF and related with their WikidataID then associated to DBpedia using the owl:sameAs relation. Eurostat and DBpedia datasets have been merged obtaining 5841 triples corresponding to 869 instances with 16 properties. Table 9 summarises the whole list of properties along with the number of instances using them in the data. In DBpedia we find settlements' properties such as **dbp:TotalPopulation** and **dbp:areaTotalKM**. Notice that each settlement instance may report the **area** in different units, which is reflected in the property name (e.g. **dbp:areaTotalSqlKm**, **dbp:areaTotalSqMi**). Moreover, DBpedia presents different names for the property population such as **dbp:populationUrban** or **dbp:urbanPop**. Properties **eurostat:populationFemale** and **populationFemale** were only present in the

<table><caption>**Table 10**
Mathematical formulas about DBPedia & Eurostat in a human-readable fashion.</caption><tr><td>:populationDensity</td><td>=</td><td>dbp:populationTotal<br>dbp:areaTotalKm</td></tr><tr><td>:populationRateFemale</td><td>=</td><td>eurostat:populationFemale<br>dbp:populationTotal</td></tr><tr><td>:populationRateMale</td><td>=</td><td>eurostat:populationMale<br>dbp:populationTotal</td></tr><tr><td>dbp:areaTotalKm</td><td>=</td><td>10<sup>6</sup><br>dbp:areaTotalSqMi</td></tr><tr><td>dbp:areaTotalKm</td><td>=</td><td>2.589988110336</td></tr><tr><td>dbp:areaTotalKm</td><td>=</td><td>dbp:areaKm</td></tr><tr><td>dbp:populationTotal</td><td>=</td><td>dbp:urbanPop</td></tr><tr><td>dbp:populationTotal</td><td>=</td><td>dbp:populationUrban</td></tr><tr><td>dbp:populationTotal</td><td>=</td><td>eurostat:populationTotal</td></tr></table>

Eurostat dataset whereas **eurostat:populationTotal** exists for some instances in the DBpedia dataset with different URIs. Listing 5 shows the settlements **dbr:Montpellier** and **dbr:Barcelona** with their corresponding triples. This points out the data heterogeneity because Montpellier presents the population as **dbp:urbanPop**, whereas Barcelona presents it as **dbp:populationUrban**. It is also the case for the area in KM that is reported using different names.

### 5.3.2. Shapes and ANRs for representing mathematical formulas of settlements

We define a shape for the class **dbo:Settlement**, considering that in the DBpedia ontology a **dbo:City** and a **dbo:Town** are subclasses of **dbo:Settlement**. Therefore, we define three main ANRs and other auxiliary ANRs. To be concise, Table 10 presents the different formulas in a human-readable format.

### 5.3.3. Evaluation queries

For this evaluation, we defined three queries for the class **dbo:Settlement**: $q_1$ retrieves the **:populationDensity**, $q_2$ retrieves the **:populationRateFemale** and $q_3$ retrieves the **:populationRateMale**.

Considering the previous inputs (data graph, shapes and ANRs, and queries), we propose the following research questions:

* (RQ1) How to represent ANRs about cities of DBpedia and Eurostat using QAVAN?

* (RQ2) What is the impact of allowing nested ANRs in terms of the number of results for certain queries?

* (RQ3) What is the impact of allowing nested ANRs and inferences in terms of the number of results for certain queries?

* (RQ4) What are the main differences of QAVAN against PerfectRefEQ?

### 5.3.4. Results for the nested and inferences scenarios

In this section we present the results obtained using QAVAN in the DBpedia-Eurostat dataset. We expose in detail our findings and we answer the proposed research questions.

Table 11 presents the results of QAVAN on DBpedia Eurostat considering three different scenarios, i.e., the default one, one using Nested ANRs and finally one using both Nested ANRs & Inferences, over three different queries ($q_1$, $q_2$ and $q_3$). QAVAN allowed us to represent the above mentioned mathematical formulas in form of ANRs for the class **dbo:Settlement**. However, relying on the scenario that each formula was or not activated, later we explain in detail the ANRs activated by scenario. Note that in all scenario the execution time was less than 2 s for all the tests showing that QAVAN is also efficient for such datasets. Along with the different configurations, we evaluate the same inputs with a baseline approach referred in this work as PerfectRefEQ [12].

The default scenario returned the population density ($q_1$) of 169 settlements out of 869 present in the data (corresponding to the 19% of

<footnote n="16">¹⁶ https://DBpedia.org/ontology/.</footnote>
<table><caption>**Table 11**
Execution results for QAVAN considering three different scenarios: default, activation of nested ANRs, and nested along with inferences.</caption><thead><tr><th rowspan="2">Query</th><th colspan="2">Default</th><th colspan="2">Nested ANRs</th><th colspan="2">Nested &amp; Inferences</th><th colspan="2">PerfectRefEQ</th></tr><tr><th>Time (s)</th><th># Results</th><th>Time (s)</th><th># Results</th><th>Time (s)</th><th># Results</th><th>Time (s)</th><th># Results</th></tr></thead><tbody><tr><td>q<sub>1</sub></td><td>1.31</td><td>169</td><td>1.63</td><td>279</td><td>1.89</td><td>516</td><td>1.73</td><td>890</td></tr><tr><td>q<sub>2</sub></td><td>1.3</td><td>118</td><td>1.51</td><td>274</td><td>1.72</td><td>701</td><td>1.24</td><td>1043</td></tr><tr><td>q<sub>3</sub></td><td>1.35</td><td>118</td><td>1.39</td><td>274</td><td>1.73</td><td>701</td><td>1.48</td><td>1043</td></tr></tbody></table>

settlements). This result is mainly explained by the heterogeneous nature of the dataset. For instance, *dbr:Barcelona* is annotated as *dbo:City* and not as a *dbo:Settlement* therefore it is being ignored by QAVAN in the case of the default scenario. Overall, this was the case of 289 *dbo:City* and 174 *dbo:Town* instances. Similarly, the absence of some properties such as *dbo:populationTotal* and *dbp:totalAreaKM* necessary to perform the population density also reduced the number of returned cases. This was the case of *dbr:Paris* that reported *dbp:urbanPopulation* instead of *dbp:populationTotal*. Note that if the Nested ANR feature was activated, QAVAN would be able to compute the population density of Paris since a rule transforming *dbp:urbanPopulation* to *dbp:populationTotal* already exists. Regarding another aspect, the query *q*<sub>1</sub> returned more results than the queries *q*<sub>2</sub> and *q*<sub>3</sub>. The queries *q*<sub>2</sub> and *q*<sub>3</sub> expose the same issues as *q*<sub>1</sub> where the inference and nested features can have a high impact. For the queries *q*<sub>2</sub> and *q*<sub>3</sub> that are very similar both computing rates for female and male population we notice that even if the *eurostat:populationMale* and *eurostat:populationFemale* properties are highly present in the data (753 settlements out of 869) the default setting of QAVAN manages to compute these queries for 118 settlements. This highlights once more the importance of inference and Nested features as we will see in the following results.

The Nested ANRs scenario increased the number of results up to 32% (279 settlements out of 869) for the query *q*<sub>1</sub>. This can be explained by the auxiliar ANRs enabling to obtain the properties *dbp:populationTotal* and *dbp:areaTotalKm* from other ANRs when they were absent. For instance, the equivalences with *dbp:urbanPop* and *dbp:populationUrban* and *eurostat:populationTotal* allowed to obtain *dbp:populationTotal* from far more records (e.g. *dbr:Paris*, *dbr:Colmar*, *dbr:Madrid*). This feature also allowed to obtain these properties from a derived calculation. Particularly, the *dbp:areaTotalKm* property was obtained from the *dbp:areaTotalSqMi* for settlements such as *dbr:Belfast*. This settlement only reported the area in squared miles (*dbp:areaTotalSqMi* 51.16) thus QAVAN performed "on the fly" the total area in kilometres (*dbp:areaTotalKm* 133.6434) before performing the population density formula. Note that the percent of answers obtained for *q*<sub>2</sub> and *q*<sub>3</sub> increases to 32% activating the Nested ANRS.

Nested & inference scenarios also increased significantly the number of results going up to 59% (516 settlements out of 869) for the query *q*<sub>1</sub>. This feature enabled to perform the ANRs for subclasses of *dbo:Settlement*: *dbo:City* and *dbo:Town*. Cases, such as *dbr:Barcelona*, *dbr:Berlin*, annotated as *dbo:City*, were now part of the results. Results of queries *q*<sub>2</sub> and *q*<sub>3</sub> performed better going up to 80% (701 settlements out of 869) from 14%. This can be explained because of the high frequency of properties *eurostat:populationFemale* and *eurostat:populationMale* in the data graph.

Finally, we compared our results with our implementation of the *PerfectRefEQ* approach (Table 11). Our evaluation for the two approaches exhibited similar execution time although QAVAN performs a partial materialisation before answering the query. In this experiment, we notice that *PerfectRefEQ* provides more results that QAVAN. Note that in *PerfectRefEQ* if a property participating in a formula (i.e., calculable property) exists in both datasets and has different values for the same instance, two different answers are going to be created. For example, for the resource *dbr:Montpellier*, having the properties *dbp:urbanPop* = 449187 and *eurostat:populationTotal* = 364723, *PerfectRefEQ* returns two answers for the population density of this resource. This is not the case for our approach since we set priorities in the input

dataset based on their quality. For the moment this step is performed manually for QAVAN but an automatic strategy can be deployed in the future. Besides, the rewriting of *q*<sub>1</sub> using *PerfectRefEQ* produces about 51 queries. We notice that the query size can grow exponential if many OWL axioms are added which is not a problem for QAVAN that performs a partial materialisation instead of a rewriting.

### 5.3.5. Discussion of QAVAN extension evaluations on DBpedia and eurostat datasets

In this second evaluation, in addition to the processing time, we were also interested to evaluate the number of results obtained when the nested and inference features are activated. This evaluation demonstrates that our approach is generic and it may apply for well-known KG. Moreover, we show that, since we follow W3C recommendations, extending the approach with new features is straightforward. In particular, the implementation of the nested feature was facilitated by having the mathematical formulas in a LOD format, whilst the inference feature was facilitated by enabling ontological reasoning in the query-answering engine. Each of the research questions formulate on Section 5.3.3 are discussed next.

**Answer to RQ1.** QAVAN allowed to represent several mathematical formulas concerning demographic indicators. It was the case of the population density and the male and female rate. Additionally, we were able to represent auxiliary formulas that provided different alternatives to obtain some calculable properties from missing due to incomplete data. QAVAN exploited NodeExpressions and SHACL ValueRules for this aiming. Formulas were stored as RDF conforming to different FAIR and LOD principles.

**Answer to RQ2.** Results in Table 11 showed a very positive impact of the Nested ANRs feature in terms of the number of results. More precisely, the population density query – that only gave results for 19% of the instances with the default scenario – increased the number of results going up to 32%. QAVAN was able to extract the formula inputs from alternative paths (e.g., *dbp:areaTotalKM* from *dbp:areaTotalSqMi*).

**Answer to RQ3.** Results in Table 11 also demonstrate the remarkable impact of enabling inferences along with Nested ANRs with respect to the number of results. This feature allowed to access new instances annotated with sub-classes. For instance, the population density query performed better going up to 59% from 19%. Our findings suggest that inference feature plays a fundamental role for public KGs where data can be often highly incomplete.

**Answer to RQ4.** When comparing QAVAN and *PerfectRefEQ* in quantitative terms, both methods give similar processing time although QAVAN accepts inputs as object properties. *PerfectRefEQ* provides more query results not necessarily of better quality since it does not consider input priority. In a qualitative comparison, we first observe that QAVAN is inspired by SHACL whereas *PerfectRefEQ* is an extension of a query rewriting algorithm and more related to the OWL QL profile. **Equation vs. Rule:** QAVAN allows complex formulas involving power, root square or trigonometric functions (e.g., sin, cosin, tan). For that expressivity, QAVAN limits the equations to one way, in contrast to *PerfectRefEQ* that permits the multiple forms of an equation but limiting the expressivity to only simple equations (e.g., +, -, *, /). **Class vs. Property:** in QAVAN the formulas and the calculable properties are related to a specific class instead to be linked to a specific property that
applies to the global graph. Cases such as the calculation of the property 'ideal weight' of a person cannot be expressed with the *PerfectRefEQ* approach because the formula is different for men and women. We recall that QAVAN allows to define more FAIR formulas than *PerfectRefEQ*. Finally, in order to contribute to the science reproducibility, we have shared the implementation and evaluation of both methods.

# 6. Conclusion and future work

In this work, we present QAVAN, an efficient query-answering approach to perform ANRs on the fly over large and heterogeneous KGs. Thus, enriching these KGs with new derived data. To our knowledge, QAVAN is the first approach that combines virtual ANRs along with a linked data representation of the mathematical formulas contained in the ANRs. QAVAN shows to be easily extensible, independent of a specific programming language and easy to integrate within existing SW systems, thereby giving room for further extensions. QAVAN was evaluated on two experiments, the first one to test its robustness against hundreds of ANRs, complex queries requiring different size of answers and different calculable properties, and against KGs having millions of triples. This evaluation confirmed the superiority of QAVAN against a materialised approach as performed always significantly better than the materialised approach. Besides, it is important to highlight that in many cases QAVAN became the only option since the materialised approach did not provide any results due to memory allocation issues. We also demonstrated that in some scenarios, the new graph derived after performing the ANRs can be bigger than the initial KG, supporting the importance of a virtual approach. This evaluation also showed that QAVAN can reduce the processing time for queries that require access to few instances and few calculable properties reducing the processing time up to 92% in some cases. In a second experiment, using DBpedia and Eurostat data sources, we demonstrated the interest and genericity of QAVAN for handling data from different domains. In this evaluation, we represented new numerical relationships and extended the original KG with new knowledge. Moreover, this evaluation pointed out the benefits of enabling the nested ANRs and the inference extensions for public KGs, allowing to apply the ANRs for a bigger number of instances and therefore providing more query results. Additionally, we compare QAVAN with our implementation of a baseline approach refereed as *PerfectRefEQ*. Whilst QAVAN fulfilled our initial goals, it proved to be as efficient as *PerfectRefEQ*, in terms of processing time, for cases that require less expressive features. As future work, extensions of QAVAN with SHACL constraints will be tackled since SHACL is in the core of QAVAN. Besides, a better integration with the ontological reasoning task is relevant to explore. Additionally, current expressivity of ANRs can be extended to produce numerical data that conforms to more complex data models, such as the quantity value model. QAVAN can also play a role in less traditional KG tasks such as query processing over stream data [39], question answering with reasoning [40], and next location prediction [41] where the representation of these numerical relationships can improve the approaches' accuracy.

# CRediT authorship contribution statement

**Felipe Vargas-Rojas:** Writing – review & editing, Writing – original draft, Visualization, Validation, Software, Methodology, Investigation, Funding acquisition, Formal analysis, Data curation, Conceptualization.
**Llorenç Cabrera-Bosquet:** Writing – review & editing, Visualization, Validation, Supervision, Project administration, Methodology, Investigation, Funding acquisition, Formal analysis, Data curation, Conceptualization.
**Danai Symeonidou:** Writing – review & editing, Visualization, Validation, Supervision, Project administration, Methodology, Investigation, Funding acquisition, Formal analysis, Data curation, Conceptualization.

# Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

# Data availability

Data is available in a git repository.

# Acknowledgments

This work was supported in part by INRAE, #DigitAg, by the French National Research Agency under the Investments for the Future Program, referred as ANR-16-CONV-0004 and by the EU project STARGATE H2020 952339 (https://stargate-hub.eu/).

# References

[1] M.D. Wilkinson, M. Dumontier, I.J. Aalbersberg, G. Appleton, M. Axton, A. Baak, N. Blomberg, J.-W. Boiten, L.B. da Silva Santos, P.E. Bourne, et al., The FAIR guiding principles for scientific data management and stewardship, Sci. Data 3 (1) (2016) 1-9, Publisher: Nature Publishing Group.

[2] W.O.W. Group, OWL 2 Web Ontology Language Document Overview (Second Edition), W3C Recommendation, W3C, 2012, https://www.w3.org/TR/2012/REC-owl2-overview-20121211/.

[3] D. Kontokostas, H. Knublauch, Shapes Constraint Language (SHACL), W3C Recommendation, W3C, 2017, https://www.w3.org/TR/2017/REC-shacl-20170720/.

[4] A. Dimou, M. Vander Sande, P. Colpaert, R. Verborgh, E. Mannens, R. Van de Walle, RML: A generic language for integrated RDF mappings of heterogeneous data, Ldlw 1184 (2014).

[5] D. Arend, D. Psaroudakis, J.A. Memon, E. Rey-Mazón, D. Schüler, J.J. Szymanski, U. Scholz, A. Junker, M. Lange, From data to knowledge – big data needs stewardship, a plant phenomics perspective, Plant J. 111 (2) (2022) 335-347, http://dx.doi.org/10.1111/tpj.15804, arXiv:https://onlinelibrary.wiley.com/doi/pdf/10.1111/tpj.15804. URL https://onlinelibrary.wiley.com/doi/abs/10.1111/tpj.15804.

[6] Z. Chen, Y. Wang, B. Zhao, J. Cheng, X. Zhao, Z. Duan, Knowledge graph completion: A review, IEEE Access 8 (2020) 192435-192456.

[7] E. Prud'hommeaux, S. Harris, A. Seaborne, SPARQL 1.1 Overview, W3C Recommendation, W3C, 2013.

[8] K. Wenzel, H. Reinhardt, Mathematical computations for linked data applications with openmath, 2012.

[9] H. Knublauch, J. Hendler, K. Idehen, SPARQL Inferencing Notation (SPIN), Tech. Rep., W3C, 2011, URL https://www.w3.org/Submission/spin-overview/.

[10] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosofand, M. Dean, Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission, W3C, 2004.

[11] S. Bischof, A. Harth, B. Kämpgen, A. Polleres, P. Schneider, Enriching integrated statistical open city data by combining equational knowledge and missing value imputation, J. Web Semant. 48 (2018) 22-47, Publisher: Elsevier.

[12] S. Bischof, A. Polleres, RDFS with attribute equations via SPARQL rewriting, in: P. Cimiano, O. Corcho, V. Presutti, L. Hollink, S. Rudolph (Eds.), The Semantic Web: Semantics and Big Data, Springer Berlin Heidelberg, Berlin, Heidelberg, 2013, pp. 335-350.

[13] A. Elizarov, A. Kirillovich, E. Lipachev, O. Nevzorova, V. Solovyev, N. Zhiltsov, Mathematical knowledge representation: Semantic models and formalisms, 2014, http://dx.doi.org/10.48550/ARXIV.1408.6806, CoRR Publisher: arXiv Version Number: 2. URL https://arxiv.org/abs/1408.6806.

[14] C. Bizer, The emerging web of linked data, IEEE Intell. Syst. 24 (5) (2009) 87-92.

[15] G. Larvor, L. Berthomier, V. Chabot, B. Le Pape, B. Pradel, L. Perez, Meteonet, an open reference weather dataset by meteo-France, 2020, 2020.

[16] G. Klyne, J.J. Carroll, Resource Description Framework (RDF): Concepts and Abstract Syntax, Tech. Rep., W3C, 2004, URL http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.

[17] V. Vassalos, Answering queries using views, in: L. Liu, M.T. Özsu (Eds.), Encyclopedia of Database Systems, Springer US, Boston, MA, 2009, pp. 92-98, http://dx.doi.org/10.1007/978-0-387-39940-9_849.

[18] R. Hodgson, P.J. Keller, J. Hodges, J. Spivak, QUDT-quantities, units, dimensions and data types ontologies, 2014, USA Available http://qudt.org March 156.

[19] M.-L. Mugnier, M. Thomazo, An Introduction to Ontology-Based Query Answering with Existential Rules, Springer International Publishing, Cham, 2014, pp. 245-278, http://dx.doi.org/10.1007/978-3-319-10587-1_6.

[20] E. Prud'hommeaux, S. Harris, A. Seaborne, SPARQL 1.1 Query Language, Tech. Rep., W3C, 2013, URL http://www.w3.org/TR/sparql11-query.
[21] O. Corby, C. Faron-Zucker, F. Gandon, Ldscript: A linked data script language, in: C. d'Amato, M. Fernandez, V. Tamma, F. Lecue, P. Cudré-Mauroux, J. Sequeda, C. Lange, J. Heflin (Eds.), The Semantic Web – ISWC 2017, in: Series Title: Lecture Notes in Computer Science, vol. 10587, Springer International Publishing, Cham, 2017, pp. 208–224, http://dx.doi.org/10.1007/978-3-319-68288-4_13, URL http://link.springer.com/10.1007/978-3-319-68288-4_13.

[22] C. Vogelgesang, T. Spieldenner, R. Schubotz, SPARQŁ: A functional perspective on linked data services, in: R. Ichise, F. Lecue, T. Kawamura, D. Zhao, S. Muggleton, K. Kozaki (Eds.), Semantic Technology, in: Series Title: Lecture Notes in Computer Science, vol. 11341, Springer International Publishing, Cham, 2018, pp. 136–152, http://dx.doi.org/10.1007/978-3-030-04284-4_10, URL http://link.springer.com/10.1007/978-3-030-04284-4_10.

[23] H. Rijgersberg, J. Top, B. Wielinga, Towards conceptual representation and invocation of scientific computations, Int. J. Semant. Comput. 6 (04) (2012) 447–489, Publisher: World Scientific.

[24] B. De Meester, A. Dimou, R. Verborgh, E. Mannens, An ontology to semantically declare and describe functions, in: European Semantic Web Conference, Springer, 2016, pp. 46–49.

[25] O. Corby, C. Domerg, J. Fabre, C. Faron-Zucker, A. Granier, I. Mirbel, V. Negre, P. Neveu, A. Tireau, Using ontologies for r functions management, in: The R User Conference, UseR! 2010, 2010, p. 18.

[26] L. Iannone, A. Rector, Calculations in OWL, Vol. 432, 2008.

[27] T.R. Gruber, A translation approach to portable ontology specifications, Knowl. Acquis. 5 (2) (1993) 199–220, http://dx.doi.org/10.1006/knac.1993.1008, URL https://www.sciencedirect.com/science/article/pii/S1042814383710083.

[28] J. Aust, D. Pons, Taxonomy of gas turbine blade defects, Aerospace 6 (5) (2019) 58, Publisher: MDPI.

[29] F. Baader, J. Rydval, Description logics with concrete domains and general concept inclusions revisited, in: N. Peltier, V. Sofronie-Stokkermans (Eds.), Automated Reasoning, in: Series Title: Lecture Notes in Computer Science, vol. 12166, Springer International Publishing, Cham, 2020, pp. 413–431, http://dx.doi.org/10.1007/978-3-030-51074-9_24, URL https://link.springer.com/10.1007/978-3-030-51074-9_24.

[30] A. Sánchez-Macián, E. Pastor, J.F. de López Vergara, D. López, Extending SWRL to enhance mathematical support, in: M. Marchiori, J.Z. Pan, C.d.S. Marie (Eds.), Web Reasoning and Rule Systems, Springer Berlin Heidelberg, Berlin, Heidelberg, 2007, pp. 358–360.

[31] M. Farnbauer-Schmidt, V. Charpenay, A. Harth, N3X: Notation3 with SPARQL expressions, in: A. Harth, V. Presutti, R. Troncy, M. Acosta, A. Polleres, J.D. Fernández, J. Xavier Parreira, O. Hartig, K. Hose, M. Cochez (Eds.), The Semantic Web: ESWC 2020 Satellite Events, in: Series Title: Lecture Notes in Computer Science, vol. 12124, Springer International Publishing, Cham, 2020, pp. 79–83, http://dx.doi.org/10.1007/978-3-030-62327-2_14, URL https://link.springer.com/10.1007/978-3-030-62327-2_14.

[32] J. Corman, F. Florenzano, J.L. Reutter, O. Savković, Validating shac1 constraints over a sparql endpoint, in: C. Ghidini, O. Hartig, M. Maleshkova, V. Svátek, I. Cruz, A. Hogan, J. Song, M. Lefrançois, F. Gandon (Eds.), The Semantic Web – ISWC 2019, in: Series Title: Lecture Notes in Computer Science, vol. 11778, Springer International Publishing, Cham, 2019, pp. 145–163, http://dx.doi.org/10.1007/978-3-030-30793-6_9, URL http://link.springer.com/10.1007/978-3-030-30793-6_9.

[33] D. Reynolds, R. Cyganiak, The RDF Data Cube Vocabulary, W3C Recommendation, World Wide Web Consortium, 2014, http://www.w3.org/TR/2014/REC-vocab-data-cube-20140116/.

[34] J. Clark, S. DeRose, XML Path Language (XPath), Tech. Rep., W3C, 1999, URL https://www.w3.org/TR/1999/REC-xpath-19991116/.

[35] J. Robie, M. Dyck, J. Spiegel, XQuery 3.1: An XML Query Language, Tech. Rep., W3C, 2017, URL https://www.w3.org/TR/xquery-31/.

[36] G. Larvor, L. Berthomier, V. Chabot, B. Le Pape, B. Pradel, L. Perez, MeteoNet, an open reference weather dataset by meteo-France, 2020, 2020.

[37] J. Lehmann, R. Isele, M. Jakob, A. Jentzsch, D. Kontokostas, P.N. Mendes, S. Hellmann, M. Morsey, P. van Kleef, S. Auer, C. Bizer, Dbpedia - a large-scale, multilingual knowledge base extracted from wikipedia, Semant. Web 6 (2) (2015) 167–195, URL http://dblp.uni-trier.de/db/journals/semweb/semweb6.html#LehmannIJJKMHMK15.

[38] K. Janowicz, A. Haller, S.J.D. Cox, D.L. Phuoc, M. Lefrançois, SOSA: a lightweight ontology for sensors, observations, samples, and actuators, 2018, CoRR abs/1805.09979, arXiv:1805.09979, URL http://arxiv.org/abs/1805.09979.

[39] Y. Jia, Z. Gu, Z. Jiang, C. Gao, J. Yang, Persistent graph stream summarization for real-time graph analytics, World Wide Web (2023) 1–21.

[40] X. Bi, H. Nie, G. Zhang, L. Hu, Y. Ma, X. Zhao, Y. Yuan, G. Wang, Boosting question answering over knowledge graph with reward integration and policy evaluation under weak supervision, Inf. Process. Manage. 60 (2) (2023) 103242.

[41] J. Liu, Y. Chen, X. Huang, J. Li, G. Min, GNN-based long and short term preference modeling for next-location prediction, Inform. Sci. 629 (2023) 1–14.