Contemplating qudt:symbol refactoring - requirements and options

[fkleedorfer]

In a recent PR that introduces multiple qudt:symbol triples for a few units, @steveraysteveray suggests a refactoring of 'qudt:symbol' for units:

More broadly though, the multiple symbols raise some options worth discussing:

Should we:

1. Disallow multiple symbols
2. Allow multiple symbols, each with a different language tag (like we do with rdfs:label)
3. Allow multiple symbols, possibly with the same language tag

These three new units are the only ones with more than one symbol at present. However, it's possible there there exist some units with > alternate symbols, yes?
Currently we do not validate against any of the three options above. Should we?

We do want symbols to be represented using Unicode.

This PR and the suggestions on how to handle such cases in the future affect my use of QUDT in QUDTLib, and probably other downstream use cases.

For symbols, as they are implemented right now, the rules implicit in the values are very strict. They can be enforced using SHACL, and symbols for derived units can be generated if missing.

Labels are not quite as strict, so SHACL validation would produce too many false positives, but there still is a rather clear (language-dependent) way of generating them if they are not present (Note that there has been a proposal to standardize labels)

So, the situation is better wrt to symbols than with labels when it comes to maintenance. Suggestions 2 and 3 above put symbols in the same category as labels, which will eventually lead to higher maintenance effort and/or lower data quality. They are a good starting point for discussion though.

What would be your requirements for symbols, and what implementation options do you see?

[fkleedorfer]

I believe it would be very helpful for me as a downstream user to know that every unit has a symbol, and that there can be only one. Zero hassle for choosing one or handling absence. No chance of confusing users by showing them different symbols at different times.

[fkleedorfer]

I've noted some unexpected symbols. For example, for unit:HR, it's hr, not h, as I would have expected. Maybe this is one of the cases that would motivate multiple symbols, because, apparently, some users prefer hr, some prefer h. Here I would ask the experts if there is a way of systematically differentiating them - does each of them belong to a distinct system, region, or other kind of context? Asking because if that's the case, then we could model this context in QUDT and use it to differentiate between symbols, as we already do with qudt:symbol and qudt:ucumCode.

[jhodgesatmb]

The problem with democratization of symbols and labels is that from a standards point of view there may be clashes in what a symbol or label is that the standards must clarify, while what is used in popular 'culture' (for a community) may differ. As a standards based model and vocabulary we try to accommodate both when possible, but clashes cannot be supported. A simple example, as you suggest, is HOUR. The QUDT symbol is "hr" and, as you say, some use "h". But if QUDT were to use "h" there might be a clash with HENRY for which the symbol is "H". In unicode we can differentiate between "h" and "H" but it starts to get dicey when these are strings and people don't differentiate between upper and lower case (let alone unicode).

[steveraysteveray]

We discussed this in the QUDT Board and agreed that we do not want to make life difficult for downstream users and applications, so we are adopting Option 1, i.e. only 1 qudt:symbol per unit. It should be noted that sometimes we have multiple aliases for the same unit (unit:LB and unit:LB_M, for example), and sometimes distinct units commonly use the same symbol (unit:BARN and unit:BIT), so the qudt:symbol value cannot be considered a unique identifier.

We are open to suggestions for a definitive source when choosing the symbol if there are multiple possibilities.

The qudt:symbol will not carry a language tag.

This discussion thread is a great place to have a last chance to make the case for a different decision!

[fkleedorfer]

You are saying that a clash of symbols is no reason for selecting a different symbol for either unit. In other words: when making the decision on which symbol to use, no other units need to be considered - correct?

Intuitively, this makes sense, as in each case the most widely used symbol will be one that, in its most important context of usage, will be unique, otherwise, its users would not have chosen it. (In QUDT terms, we should not expect to see symbol clashes within the same QuantityKind, or even the skos:broader transitive hull - and we could even SHACL that one and give a warning if we wanted to).

To showcase this, I would opt for using 'h' instead of 'hr' for unit:HR, with the rationale that
a) https://en.wikipedia.org/wiki/Hour says "An hour (symbol: h; also abbreviated hr) is a unit of time ..."
b) any widely used derived unit uses 'h', such as m/h, mph, km/h, kWh, Ah

(And if that showcase convinces, I would make more for unit:YR qudt:symbol "a" and unit:DAY qudt:symbol "d" with similar rationales.)

[steveraysteveray]

To your first question, correct.
I'm not sure we can go so far as to require no overlap in contexts. Probably true, but maybe this is an edge case.

[steveraysteveray]

To your specific suggested symbols, I'm open to those. Let's see if we have consensus.

[fkleedorfer]

If there is consensus, here is the PR: #899

[fkleedorfer]

Btw, we have recently also gotten duplicate qudt:ucumCode symbols, but it seems that they are systematically different, example:

unit:J-M-PER-MOL
  qudt:ucumCode "J.m.mol-1"^^qudt:UCUMcs ;
  qudt:ucumCode "J.m/mol"^^qudt:UCUMcs ;

could we devise a way of differentiating between them so we can query for the one that we want?

[fkleedorfer]

For example using qudt:UCUMcs and qudt:UCUMcsAlt, or somesuch?

[steveraysteveray]

The principal use case we anticipated for the ucumCodes was as an entry to QUDT, that is, "Find me the QUDT unit that has the following ucumCode". If this is indeed it's primary use, then having multiple values of ucumCode is fine. @dr-shorthair was the person providing most of the ucum modifications, so he may have thoughts on this as well. My understanding is that the x/y and x.y-1 versions are both in regular use.

[steveraysteveray]

@fkleedorfer, I just noticed that in addition to the 3 units with multiple symbols, we have 11 QuantityKinds and 1 Currency with multiple values. Recognizing that these classes don't have the naming grammar that we have with Units, do these 12 occurrences cause problems with your software?

[fkleedorfer]

They probably cause duplicate Quantitykind and and Unit instances that have gone unnoticed so far. The implicit assumption was that there is at most one symbol, but it's not ensured. Needs work.