Reuse existing standard vocabulary for units and their conversions

[jdacoello]

• D: 3 action points
• 1. Check how we can reuse existing standards, including conversion, D can investigate

Originally posted by @erikbosch in #824 (comment)

Enhance the VSS modeling approach by importing or reusing established standards to avoid re doing it from scratch.

• Would this better fit the vss-tools instead?

[jdacoello]

Important criteria for adopting a unit model:

• Quantity kind. Must have a quantity kind (aka., dimensions) to indicate a collection of compatible units. For example: length can be measured as Km/h or m/s.
• Conversion information. Must cover conversion factors or formulas.
• Identifiers. Must have unique future proof identifiers for the concepts that are defined.

[jdacoello]

Alternatives:

• https://www.qudt.org --> Most complete option with conversion information
• https://ucum.org
• http://www.ontology-of-units-of-measure.org

[jdacoello]

Example on how we could adapt VSS to reuse existing QUDT units.

Let's say we want to reuse the kilometre km from the reference standard QUDT.

Case A: Specifying UNIT

Option A1: Add identifier of QUDT definition to VSS units file

km:
  definition: Length measured in kilometers
  unit: kilometer
  quantity: length
  allowed-datatypes: ['numeric']
  unitRef: http://qudt.org/vocab/unit/KiloM  # <--- This is the pointer to the resource

This file can also follow the YAML-LD approach to write compact pointers by using prefixes.

@context:
  qudtUnit: "http://qudt.org/vocab/unit/"
  unitRef: "@id"
km:
  definition: Length measured in kilometers
  unit: kilometer
  quantity: length
  allowed-datatypes: ['numeric']
  unitRef: "qudtUnit:KiloM"  # <--- This is the pointer to the resource

Option A2: Use the URI of the unit directly in the units file

km: http://qudt.org/vocab/unit/KiloM  # <--- This is the pointer to the resource

Option A3: Use the URI of the unit directly in the unit field of the spec

Vehicle.TraveledDistance:
  type: sensor
  datatype: int
  unit: http://qudt.org/vocab/unit/KiloM  # <--- This is the pointer to the resource
  ...

Case B: Specifying QUANTITY KIND

Option B1: use quantity kind directly with each property

Vehicle.TraveledDistance:
  type: sensor
  datatype: int
  quantityKind: http://qudt.org/vocab/quantitykind/Length  # <--- This is the pointer to the resource
  ...

Option B2: Use quantities file instead of units file as the main reference and use pointers there

lenght: http://qudt.org/vocab/quantitykind/Length  # <--- This is the pointer to the resource
  ...

[jdacoello]

Once the unit is known, the QUDT model has already conversion information.

For example, converting km to inches would be:

unit:KiloM
   quit:conversionMultiplier "1000.0"^^xsd:double . # to base unit meter

unit:IN
   quit:conversionMultiplier "0.0254"^^xsd:double . # to base unit meter

That RDF data is part of the QUDT model.

One can compute the conversion as:
value_in_target = value_in_source * (source_multiplier / target_multiplier)
value_in_target = 1 km * (1000 / 0.0254) =3937.07 inches

[erikbosch]

MoM:

• Daniel presented idea
• Sebastian:
  • Possibly link it in the unit file
  • Today datatype is linked to unit, selecting a datatype that match the unit range
• Daniel: Could be a step forward
• Daniel: There is a process to define own units. If we define unit file we can still maintain custom units
• Erik: Just adding info in unit/quantity file would be first step
• E: if we just have quantity, how to handle that in APIs? For "stupid simple APIs" one must have some deployment info on which unit to use.
• D: In some APIs you can request which unit to use
• Ted: In general support qudt, should be in unit file
• T: Prefer to have multiple, like references instead of unit_ref to be able to use it also for other purposes.
• D: Would rather stick to a single reference, otherwise there might be maintenance problems, confusing
• Conclusion: No one seems to object adding qudt links/references in the unit file.
• T: vss:km could reference qudt: km