This vocabulary was originally based on VIM3 (see https://jcgm.bipm.org/vim/en/info.html); however, the VIM3 distinction between quantity [VIM3: 1.1] and kind-of-quantity [VIM3: 1.2] led to using Prof. Rene Dybkaer's seminal work, An ontology on property, as a source of guidance for formalizing a VIM3-like vocabulary of metrology for quantities and units.
The VIM4 Committee Draft of January 11, 2021 constitutes a welcome improvement in the precision and meaning of the vocabulary, that, together with related JCGM documents explaining the significant changes from VIM3 to VIM4 greatly facilitated formalizing VIM4 as an ontology. This formalized vocabulary is made publicly available with the objective of providing additional input to the upcoming 25th meeting of the JCGM scheduled for 05 December 2022 with respect to publication options considered for VIM4 (see 'Development Line 2: adding machine readability' in Report from WG2 JCGM/2020-07).
VIM4.1-general,individual,units,values
Note that this representation supports multiple SystemsOfQuantities and SystemsOfUnits.
The formalization ensures that the following turtle pattern must be consistent
for all tuples of SQ, SU, Q, M:
SQ a vim4:SystemOfQuantities ; vim4:systemHasUnitaryQuantity Q .
SU a vim4:SystemOfUnits ; vim4:given SQ ; vim4:systemHasUnit M .
M vim4:instantiates Q .
The formalization ensures that any UnitaryQuantityValue must be consistent
in the sense that the following paths must lead to pairs of GeneralUnitaryQuantity, (uq, aq),
defined as follows:
-
uqis anyGeneralUnitaryQuantityreachable via the following SPARQL expression:unit.isMultipleOf*.instantiates -
aqis theGeneralUnitaryQuantityreachable via the following SPARQL expression:isAttributedTo.instantiates
Then for each such pair, one of uq.specializes* must be the same as aq.
Dimensional analysis is a procedure for determining what VIM4CD: 1.7 quantity dimension defines as the:
relation of a quantity to the base quantities of a system of quantities as a product of powers of factors corresponding to the base quantities, omitting any numerical factor
This analysis requires closed-world knowledge of the following:
-
Instances of
SystemOfQuantities(VIM4CD: 1.6) -
For each such system:
- Instances of
GeneralUnitaryQuantitythat are its VIM4CD: 1.4 base quantities - Instances of
GeneralUnitaryQuantitythat are its VIM4CD: 1.5 derived quantities Each derivation in turn requires information about the derivation factors w.r.t otherGeneralUnitaryQuantities
- Instances of
Formalizing this analysis in SPARQL 1.1 Query and Update should be possible in principle, see src/sparql/dimensional-analysis for such an attempt.
The strategy involves the following induction principle:
- The initial step involves the special case of a base quantity,
bq, for which the dimension is trivially 1 forbqand 0 for all other base quantities. - Find a derived quantity,
dq, whose factors involve quantities with known dimensions. Calculate the dimension of - Repeat step (1) until all derived quantities have been processed.
Trying to implement this strategy with SPARQL 1.1 queries and updates resulted in a few practical problems using Apache Jena 4.3.2 (see: https://jena.apache.org/download/index.cgi):
- According to the SPARQL 1.1 Update, an update operation results in either success or failure. However, the specification does not stipulate the exact form of such a result. This makes it difficult to verify whether a particular update produced the desired triples.
For example, the update corresponding to step 0 is here:
0-base-quantity-dimension.sparql
When submitting this update to Jena Fuseki, the server responds simply: Update succeeded.
Fortunately, one can easily confirm the update indeed worked with the following query: quantity-dimensions.sparql
For step 1, the following update was intended to handle the case of derived quantities that depend on a single quantity with a dimension: 1-derived-quantity-dimension.sparql
When submitting this update to Jena Fuseki, the server responds simply: Update succeeded.
However, performing the query again shows that no new triples were inserted!
Changing the update to a query (see the commented select statement) produces
tuples that confirm the where clause is working properly.
It is unclear why the insert for the same where clause does not actually insert these tuples.
- Even if sparql query/update had worked, this approach for formalizing an inductive algorithm is very awkward.
To encode the closed-world semantics of this analysis in SPARQL, it is necessary to use non-trivial filter clauses to ensure that the where clause checks for all relevant cases.
This exercise warrants looking for a different strategy to implement dimensional analysis.