Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnitOfMeasure definition #73

Open
KathiSchleidt opened this issue Oct 15, 2024 · 6 comments
Open

UnitOfMeasure definition #73

KathiSchleidt opened this issue Oct 15, 2024 · 6 comments
Labels
ready Was discussed during a telecon and a decision was made

Comments

@KathiSchleidt
Copy link

In the SWE Common Spec, it is stated that UnitOfMeasure is taken from ISO 19103. Where is the encoding?

Requirement 59 states that a UnitOfMeasure must have a code or href, there is no full definition for UnitOfMeasure

We find a schema for UnitReference, but it is unclear if this is normative.

@alexrobin
Copy link
Collaborator

You are right that SWE Common does not define an encoding for the actual UnitOfMeasure class at the moment. It's there conceptually but we only define a reference to a UoM defined elsewhere. We should probably clarify this somewhere.

Would you like to have a class to define your own UoM of are we OK relying on external registries/ontologies to do that for us (just like we do for observed properties).

@hylkevds
Copy link

Since ISO 19103-2 (2024) only defines one single attribute for the UnitOfMeasure class (uomIdentifier), I think OGC needs to define its own class.

SWE-Common seems like a good place for such a definition.

The current definition from basicTypes seems like a good starting point.

@alexrobin
Copy link
Collaborator

Discussed during 10/17 telecon.

We will keep UnitReference in the schema as we consider defining a UoM model (which would provide the definition of the unit) is out of scope of SWE Common.
We will add some clarifications to explain that UnitOfMeasure is implemented by UnitReference in the JSON schema.

@alexrobin alexrobin added the ready Was discussed during a telecon and a decision was made label Oct 17, 2024
@KathiSchleidt
Copy link
Author

Shouldn't something as essential as UoM be shifted out of specific models to a common area? I'd believed over the years that SWE Common was exactly this common area for specs that go beyond pure spatial to measurements. But apparently I'm wrong.

This should be thematized to the OAB, as if each spec defines its own uom, fear we're doomed (or at least look exceedingly silly!)

@alexrobin
Copy link
Collaborator

@KathiSchleidt It depends what you mean by UoM:

  • If you are talking about the reference to a UoM definition, then SWE Common defines it, with optional label and symbol to better display it to a user.

  • But if you are talking about the UoM definition itself, then we decided that it is better left to ontologies or specialized UoM registries like UCUM.

This is similar to what we do for property definitions.

@hylkevds
Copy link

Yes, the thing that OGC should define is a class that references a formal definition somewhere else. And that is what the UnitReference is.

The issue here is that UnitReference is not normatively defined. The only normative references that I could find are requirements 59 and 60, only in the context of Quantity and Time, and they only define "uom/code" and "uom/href", and only in the context of the JSON encoding.

I think the cleanest solution is a proper UnitReference class (after 8.2.3?) that defines all four attributes. The JSON encoding for this class would fit best after 9.1.3, Requirement 59 can then be removed.

I just noticed that the AllowedTimes class in 8.2.19 does not have a uom attribute, but the JSON encoding in 9.1.17 does. The same goes for the AllowedValues class. Defining a proper UnitReference class also makes it easy to fix that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready Was discussed during a telecon and a decision was made
Projects
None yet
Development

No branches or pull requests

3 participants