What is the UnitOfMeasure class/type?

[ldesousa]

Hi there. In the Soil Theme domain model there are various properties of the UnitOfMeasure type, e.g. SoilThemeParameterType.uom. This type is not identified as a code-list, is this by design? I can not find it in the model, although the HTML version is not so searchable.

Where can I find the specifics of this type? Is it bounded in any way (e.g. controlled content)?

Thank you.

[pvgenuchten]

The TG at one of the examples suggests 'cm' as a value for UOM, so I guess it is currently not bound to a code list. I agree that it would make sense.

[heidivanparys]

In general, it is recommended to use the code values defined in The Unified Code for Units of Measure (UCUM) for units of measure. This is not an official INSPIRE recommendation, though (see also #32).

Note that the UCUM actually defines to sets of code values:

1. a set of case-sensitive codes (c/s)
2. a set of case-insensitive codes (c/i)

From the specification:

Although The Unified Code for Units of Measure does not encourage use of case insensitive symbols where not absolutely necessary

Hence, the set of case-sensitive codes is recommended for use. In most examples I've seen, including the one in the TG for the soil theme, the case-sensitive codes are indeed used.

UnitOfMeasure from the UML schemas is encoded in GML using the gml:UnitOfMeasureType. This does not require URIs to be used for units of measure (although it is possible to do so). An example of an instance using a UCUM-defined symbol:

<so:SoilThemeParameterType>
    <so:soilThemeParameterName xlink:href="http://link/to/theme/parameter" />
    <so:uom uom="cm" />
</so:SoilThemeParameterType>

[ldesousa]

Article 12 (page 89) provides the only guidance in this regard:

All measurement values shall be expressed using SI units or non-SI units accepted for use
with the International System of Units, unless specified otherwise for a specific spatial data
theme or type.

Since QUDT includes SI units, it is probably the most appropriate option at this moment to cover this gap. The URIs for each unit are most useful. QUDT is also simple to extend.

Thank you for the replies.

[pvgenuchten]

Sorry, I miss the link between ucum and qudt, how are they related? Or is qudt an alternative suggestion here Luis?

Wouldn’t it be useful to bring these endorsement to some of the tg documents?

[KathiSchleidt]

No link between UCUM and QUDT, 2 alternatives for providing UoM

• UCUM provides the syntax for encoding a UoM as a string
• QUDT is an ontology for Quantities, Units, Dimensions and Data Types, thus letting you provide a URI for the UoM

To my memory, QUDT fully emerged after INSPIRE was specified, this we only mention UCUM

[heidivanparys]

There is a link of some kind, as QUDT defines this property: https://qudt.org/schema/qudt/ucumCode.

For example:

I would say that what makes most sense also depends on the format you use. If you use RDF, then using QUDT makes sense. If you use Shapefile, GeoPackage, or another kind of database, using the UCUM codes may make more sense.

[sgrellet]

indeed as @kathi said UCMU and QUDT are 2 alternatives for UoM.

#32 refers to GML 3.2.2 spec but W3C Spatial Data on the Web Best Practices defines a bit more the context around this : https://www.w3.org/TR/sdw-bp/#c-unitofmeasure

I checked INSPIRE D2.9 (https://inspire.ec.europa.eu/id/document/tg/d2.9-o%26m-swe) and we did not recommended one or the other back then.
Same goes for the recently published "Observations, measurements and samples" ISO 19156:2023 (-> see : 8.2.16 Constraint unit of measure where we mention both).

I tend to agree with @ldesousa and would recommend using as much as possible a system that provides URIs be it in a full LinkedData system (with triple store & Co) but also in a simple Shapefile, Geopackage situation.
In our systems we just have the label (rdfs:label) and the corresponding URI next to another so that all UseCases are covered.

QUDT would be appropriate for this.