UnitOfMeasure requiring UCUM

[KathiSchleidt]

REQUIREMENT 59 states Whenever it can be constructed using the UCUM specification, the unit of measure shall be specified using a UCUM code as the value of the “uom/code” property. Otherwise the “uom/href” property shall be used to reference an external unit definition.

While this made sense when SWE Common was originally defined, today many users prefer the use of QUDT or the SI DIGITAL FRAMEWORK. Do we still need to keep UCUM mandatory?

[alexrobin]

I personally think that UCUM is still much more powerful/expressive than any uom ontology out there. But I think we could relax this requirement by making it a recommendation only.

[hylkevds]

Would it be possible to require UCUM when a UCUM code exists, but also allow a href regardless? So allow both at the same time? Currently it's "oneOf".

[alexrobin]

@hylkevds Yes, that's also a possibility. I remember the discussion we had now and I like this option better in fact. I believe it will make things more interoperable while still allowing to refer to ontologies when desired.

[alexrobin]

Discussed during 10/17 telecon.

Ok to make use of UCUM a recommendation instead of a requirement. We will also allow both UCUM code and href with anyOf. A requirement will still say that the code has to be a UCUM code. (this is testable)

[Sam-Bolling]

Discussed during 10/17 telecon.

Ok to make use of UCUM a recommendation instead of a requirement. We will also allow both UCUM code and href with anyOf. A requirement will still say that the code has to be a UCUM code. (this is testable)

I shared the latest discussion and outcome of this issue with a colleague and interoperability stakeholder, who then drew my attention to an OGC API implementation example that references QUDT instead of UCUM. I have attached a screenshot. For the purposes of best interoperability experience for both system implementers and operational users, I request that the OGC Connected Systems SWG thoroughly explore this specific scenario in regards to the final approach decided upon during the 17OCT2024 SWG meeting. How would a CSAPI implementation handle the data shared from a system / source such as the UK MET Office's implementation? What would it look like using the approach decided upon during the 17OCT2024?

I am hopeful that a relatively suitable narrative that describes the workflows and relationships in sufficient detail to thoroughly explain how the CSAPI standard will truly accommodate interoperability with non-UCUM systems.

Here is the example I am referring to, I hope this enables us to get very specific with some informative information that can be added to the standards to really inform and accommodate non-UCUM implementers as well as give QUDT-implementers a head start on how to dive in and thrive with the CSAPI to the best extent possible:

@KathiSchleidt @hylkevds @ghobona @chris-little

[alexrobin]

@Sam-Bolling The solution agreed upon during the 10/17 telecon will allow the use of QUDT URIs.

UCUM will not be mandatory anymore, just a recommendation, and we will allow both UCUM code and URI to be provided simultaneously to get the best of both worlds.

[chris-little]

@alexrobin @Sam-Bolling I recently came across a NIST sponsored researcher at UCal or UofMaryland (I think) who has successfully produced a tool to map between many UoM systems, including UCUM, QUDT and others. I can rummage through my archives for details if you are interested.

[Sam-Bolling]

@Sam-Bolling The solution agreed upon during the 10/17 telecon will allow the use of QUDT URIs.

UCUM will not be mandatory anymore, just a recommendation, and we will allow both UCUM code and URI to be provided simultaneously to get the best of both worlds.

@alexrobin , I cannot speak for the issue author, @KathiSchleidt , but I think it might be diligent to draft a quick example with this recently decided approach to illustrate that it will satisfy the intent of the issue raised; then we can circle back and ask @KathiSchleidt to review the decided approach, along with the draft example, to confirm that the issue has been resolved. Perhaps using the sample information from the UK MET example offers a starting place for a draft example of data in compliance with CSAPI and supporting standards, while leveraging the new approach, and accommodating the use of QUDT.

Respectfully,

Sam

[alexrobin]

Below is an example of how one could reference a UoM with both a UCUM code and QUDT URI:

{
  "type": "Quantity",
  "definition": "http://qudt.org/vocab/quantitykind/Temperature",
  "label": "Air Temperature",
  "description": "Air temperature measured at 2m above ground",
  "uom": {
    "label": "°C",
    "code": "Cel",
    "href": "https://qudt.org/vocab/unit/DEG_C"
  },
  "value": 21.5
}

@KathiSchleidt @hylkevds Is that what you guys had in mind?

We will have a requirement that both code and URI SHALL reference the same unit. This can be tested programmatically for QUDT URIs as the ontology also contains the corresponding UCUM code.

[hylkevds]

Yep, that's exactly what we were thinking of.