Wikidata is gaining attention to address scientific experimental information. In particular, users can exploit the notions of physical quantities and units of measurement already defined in its knowledge graph. However, when users perform queries over scientific data referring to such data, they can only retrieve the physical quantities in the units of measurement explicitly stored as statements, although the knowledge to transform these quantity values into diferent units required by the query is already (partially) defined in the units' metadata. We propose PhyQus a query-answering approach that allows to retrieve the physical quantities in any convertible unit by performing unit conversion on the fly based on the query information. To this end, our approach is based in the advanced features of the W3C recommendation SHACL and leverages the ontology of unit of measurements, QUDT. We showcase that the approach is feasible considering two main examples one about cities's area and the other about the boiling point of chemical substances.
CEUR ceur-ws.org
Wikidata (WD) has become a central and popular repository for not only encyclopedic
knowledge, but also as a knowledge base repository for science, e.g., life sciences [
2, 2, ∘ , ∘ , etc.).
Yet, while property constraints [
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). within WD and does not cover more complex conversions, such as for instance ∘ to ∘ , which involve more complex equational knowledge than multiplication factors.
The previous issues could be prevented by precomputing all possible unit conversions, which would allow the query service to provide all the complete results. However, this is currently unfeasible, regarding that the latest version of WD contains 158 properties of quantity values and they can be applied to millions of entities. To illustrate, consider the ”area” property, which is used from around 5,813,704 entities 1, and according to the “allowed unit” constraint, can be expressed in 20 diferent units 2. Consequently, a complete materialisation would demand over 116,274,080 additional triples.
It seems obvious, that leveraging existing work in the Semantic Web field on defining
exhaustive ontologies for units of measurements, such as QUDT [
In the remainder of this paper, after discussing related works Section 2, we describe our approach in Section 3, illustrated by examples, showcasing automated query-answering in diferent target units. We discuss potential impact, in terms of the incompleteness/heterogeneity of current unit data within Wikidata as well as an empirical evaluation in Section 4, before we conclude in Section 5.
The problem of performing unit conversions involves certain requirements and steps. In Section 2.1 we explain the most common approaches. Besides, in Section 2.2 we present alternatives to express data derived from mathematical computations that enrich the initial data graph. Finally, in Section 2.3 we present three relevant unit ontologies considering that their annotations and data models are required to perform this task.
The unit conversion task relies on a notion of quantity values. Diferent models can represent
this notion, for instance the ontology QUDT and Wikibase (used in the Wikidata) propose
properties and classes for that goal. A quantity value is a pair ( , ) which expresses the
numerical value of a quantity with respect to a unit of measurement [
Bearing in mind the notion of quantity, the most traditional way to perform this task is
by defining complex SPARQL queries. This approach was followed by [
Python4. Users should define manually the mappings between the library and the unit ontology
and expect that the library supports the units they are interested in.
2.2. Leveraging conversion rules and equations automatically
Property equations [
We explore three of the most used unit ontologies: (i) UO, the unit ontology from the OBO
foundation [
In this section we describe our approach PhyQus. For this approach we assume the data
conforms to the model of quantities used in Wikidata. This approach is inspired in the notions
addressed in QAVAN [
In this work we use some SHACL [10] notions, in SHACL a shape represents a group of constraints associated to a set of target nodes. The constraints are evaluated against each node to conclude if the data is valid against that SHACL shapes. During the evaluation a node is refereed as the focus node. For instance, a target can be the class City whilst a focus node can be the city of Montpellier. The same concepts are used to the definition of ANRs. 3.1. Performing Unit Conversions and Create Wikidata Quantities
Funtion toTargetUnit toWDfromQUDT
Description Transform a QuantityValue to a given target unit and returns the numerical value Transform a WIKIDATA unit into a QUDT unit
Domain
xsd:Double qudt:Unit (source) qudt:Unit (target) wikibase:Unit
Range xsd:Double qudt:Unit Plugin
Name
Description
SHACL rule SHACL expression
WDQuantityRule createWDQuantity
Enable WD quantity values as outputs Take a Wikidata property, a numerical value, and a Wikidata unit and constructs a Wikidata quantity value instance.
Table 1 presents the extensions added to SHACL-AF. We add two SHACL functions: toTargetUnit to transform a value into a target unit and toWDfromQUDT to transform a unit given in the Wikidata model to QUDT. These functions take advantage of the mappings to QUDT existing in Wikidata through the direct link property wdtn:P2968. Besides, Table 1 also presents two SHACL plugins, whilst SHACL functions are implemented as SPARQL queries and can be added through RDF, the plugins require to add some lines of code in the SHACL-AF implementation. These two kind of extensions are considered and are straightforward to add in SHACL-AF. In the next section we explain how to align these extensions with the query-answering process.
The query-answering steps are described in Figure 1 along with a simple example considering the automatic unit conversion for data related to the city of Montpellier. The approach takes as input a query retrieving some physical quantities of WD. In the example we mention the property p:P2046, which refers to the area of an object, however the query can be about others properties (e.g., the boiling point of a substance). Note that the query requires this property in the unit square miles (wd:Q232291). Shapes having as target, subjects of the Wikidata physical quantities, should be added in order to activate the automatic unit conversion. The example shows a shape called AreaShape and having as target subjects of the property area. Last input is a data graph, in this example is a graph containing information about the area of the city Montpellier (wd:Q6441). This graph contains the Montpellier’s area only in square kilometres (wd:Q712226). The initial query without our approach is going to return an empty result set. The steps to enable query-answering with automatic unit conversion are described as follow: 1. Query Interpretation. Taking into account the shape’s target, in this step PhyQus identifies the properties involved in the query that have also an associated shape. In the given example, it is the property area. From the triple patterns in the query, PhyQus obtains the variable that represents the targets (e.g., ?city). Besides, a map is generated from the query, which keys are the properties and which values are a list of required units. The example shows only the unit square mile, however, more units can be required in the same query. 2. ANRs Generation. PhyQus iterates on the map producing one ANR for each pair (property, unit). The new ANRs that are added to the shape using the property sh:rule are ephemeral and only exist during the query evaluation. These new ANRs, use the functions and plugins defined in Section 3.1. Given the space constraints, the complete ANRs are only shared in the experiment repository. We also add a policy to avoid the proliferation of calculations. If the current focus node (e.g., a city) already has a quantity value in the required unit, then we avoid to compute a new one. We express this policy as a SHACL constraint taking advantage that our approach is based on SHACL-AF. This policy requires further discussion since there are diferent reasons for which a focus node have several times the same property: (i) erroneous data, (ii) data in diferent time point, (iii) the same value in other unit of measurement but equivalent. 3. Update Target Nodes. First, PhyQus removes from the query all the statements about the identified properties. After that, for each identified property it adds a triple pattern having as predicate this property and as object a blank node. This pattern assures that at least the focus node has once the property, which can therefore enable the unit conversion. 4. Perform ANRs. Considering the ephemeral ANRs and the target node query the ANRs are performed in order to produce a virtual graph containing the new quantity properties. In our example, the derived graph contains triples about a new area property for the city of Montpellier with the quantity value in square miles. Note that this information was not presented in the data previously. 5. Query Evaluation. The query is evaluated against the union of the new virtual graph and the initial graph. Therefore, it produces a result set. In the given example, a result with the Montpellier’s area in square miles.
PhyQus Evaluation is illustrated with two Wikidata examples: one about the area of cities and their subclasses, and other about the boiling point of diferent substances. The former evaluation is carried out to demonstrate the limits of Wikidata units of measurements and to stress the necessity of using unit ontologies such as QUDT. Experiments are shared in this
A query Q ?city ?areaInSqMi ?city wdt:P31 wd:Q515. ?city p:P2046 ?valueNodeStm. ?valueNodeStm psv:P2046 ?qv. ?qv wkb:quantityAmount ?areaInSqMi. ?qv wkb:quantityUnit wd:Q232291.
A shape AreaShape - targetSubjectsOf p:P2046
A graph G wd:Q6441 wdt:P31 wd:Q515; p:P2046 [ psv:P2046 [wkb:quantityAmount 56.88 ; wkb:quantityUnit wd:Q712226. ]]
Wikidata info p:P2046, psv:P2046 (area) wd:Q712226 (square kilometres) wd:Q232291 (square mile) wd:Q6441 (Montpellier) wdt:P31 (instance of) wd:Q515 (City)
Create a map containing PQs and the required units map[p:P2046]=[wd:Q232291] 2) ANRs Generation For each PQ and unit
create a new ANR Add a policy condition: only execute the ANR if the value in that unit does not exist add a triple pattern for
each PQ
SELECT only the target variable ?city
4) Perform ANRs - only target nodes in Q’ - Produce virtual graph G’ 5) Query Evaluation Evaluate initial query
Q against G U G’
A Rewritten AreaShape - targetSubjectsOf p:P2046 - a new ANR that adds the property area (p:P2046) to the focus node (a city), the value is a new wikidata quantity in square miles (wd:Q232291). - Trigger condition.
Target nodes query Q’
?city ?city wdt:P31 wd:Q515;
p:P2046 [].
A virtual graph G’ wds:Q6441 p:P2046 [ psv:P2046 [wkb:quantityAmount 21.961 ; wkb:quantityUnit wd:Q232291. ]]
A Result Set ?city wds:Q6441 ?areaInSqMi 21.961
We evaluate PhyQus taking into account two main scenarios: (i) perform a query using the traditional Wikidata SPARQL endpoint, and (ii) evaluating the same query with PhyQus.
Table 2 shows the evaluation of diferent queries about the area of a given city in diferent units. Each “Unit Label” in the table represents a query that retrieves that specific unit. These results demonstrate that PhyQus improves the number of query results. For instance, the query about “square mile” only returns about 4% of the results for the Wikidata endpoint whereas the same query evaluated with PhyQus is able to retrieve about 103% of the data. We explore the data to find why it is returning more than the 100% of the data despite our policies. We found, for instance that a city such as Bönnigheim (wd:Q61837) has six times the property area in the same unit. If the unit is not the required by the query, PhyQus will return six new quantity values in the same required unit. That is because PhyQus, in the current version, cannot access the produced physical quantities and only perform the validation in the original data.
We observe as well that for the query about “square km” PhyQus shows less results than the Wikidata endpoint. It can be given to our preprocessing where we transform the data types to double and not all the values are correct numerical values. We remark that, although PhyQus
presents better results, it is also relevant to perform further improvements in order to handle the data incompleteness, heterogeneity and inconsistency thus contributing to the data quality.
Approach WDEndpoint WDEndpoint WDEndpoint PHYQUS PHYQUS PHYQUS
Unit Label square mile square meters square km square mile square meters square km
This second evaluation shows that PhyQus can handle more complex unit conversion such as those about temperature units, which require not only a conversion factor but also an ofset. Note that the Wikidata model does not allow that kind of conversions. Results in Table 3 exhibits a better number of results for the queries that were evaluated in PhyQus covering about 90% of the substances. The results for PhyQus about diferent units were not uniform because of the issues of data quality already mentioned on the previous evaluation.
In this work we present PhyQus, an approach to automate unit conversion during query evaluation. We exploit SHACL-AF and leverage the unit ontology QUDT for that goal. PhyQus produces on the fly ephemeral Actionable Numerical Relationships (ANR) relevant to answer a given query. We also remark that, although the Wikidata model ofers some properties to perform unit conversions, these annotation are limited and do not allow unit conversion for cases such as temperature units ∘ → ∘ . This scenario stress the idea of using a more robust unit ontologies such as QUDT. We evaluate PhyQus against two scenarios: cities’s area and boiling points of substances. Our results demonstrated that PhyQus is able to exploit the numerical knowledge about conversions to provide more results under certain queries that the traditional Wikidata endpoint could not handle. For instance, a query retrieving the area of a city in square miles returns only 802 results whereas with PhyQus it provides 21316. As future work, we plan to conduct further evaluations. Besides, the approach is also suitable to repair violations of constraints about units of measurement. There is also an interest to express mathematical formulas in diferent experimental domains which inputs and outputs are quantity values.
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 the EU project STARGATE H2020 952339 (https://stargate-hub.eu/). [9] H. Rijgersberg, M. Van Assem, J. Top, Ontology of units of measure and related concepts,
Semantic Web 4 (2013) 3–13. [10] D. Kontokostas, H. Knublauch, Shapes Constraint Language (SHACL), W3C Recommendation, W3C, 2017. Https://www.w3.org/TR/2017/REC-shacl-20170720/.