contextual vs non-contextual quantities

[Toby-Broom]

I think @fkleedorfer brought the point about the usability/experiance from the user perspective as a fair one that having some more abstract units makes less easy to use. I think these are domain specific so we can model these lower down, which is what we have being doing in our projects.

In a more general sense I think that you would need to describe context in your data anyway so while the unit count maybe a little strange alone its never out of context.

like the meter example, I can measure a cells (has diameter), persons (has height), frames (has width) in this quantity also so many things could be expanded to be contextual which would be a lot of new things in qudt?

[Toby-Broom]

For the people that wanted to use CFU for example they could create their own instances and link back to QUDT?

[fkleedorfer]

Definitely. Although it requires a little bit of care: the applicableUnits triples are autogenerated for all units in QUDT. These must be added along with the unit for optimal user satisfaction.

[fkleedorfer]

We are currently thinking about domain specific or industry specific profiles.(#1077) Maybe the problem of domain/context specific units could be addressed with that mechanism.

The domain specific profiles could contain mappings from units used in the domain to the unit/quantitykind combination that represents it in QUDT. E.g. in the biology profile, there may ve a mapping CFU --> qudt:NUM/qk:ColonyFormingNumber (or whatever the qk is for cfu).

Moreover, context specific units (such as cfu) could be added to the profile, in which case the above mapping might be unnecessary as the core QUDT unit/qk can be referenced from that context specific unit (and maybe this would be the best way to define such mapping)

The profiles could invite contributions from users in the domain for those mappings/unit definitions, and maybe even for widely used quantities, if they can be defined for the domain.

[Toby-Broom]

I think this is in line with what I was thinking above

[Toby-Broom]

I think it should be handled with 2 triples since it a robust handling of all situations. You describe what you're counting and how much there is of the thing that you count. e.g.

The definition applies to entities B which should always be indicated by a subscript or in. parentheses, e.g. nB or n(B). When the chemical composition is written out, parentheses should be used, n(O2).

https://doi.org/10.1039/9781847557889 Chapter 2.10

This would be for the amount of oxygen, which is a count of the molecule.

We often display something slightly different to how the data is stored to improve the user experiance.

[fkleedorfer]

This would mean using such a string (e.g. "kg(CO2)") for the qudt:symbol of the context-dependent unit, which would be something like qudt:KiloGM_O2 (if the naming convention allowes it). The problem we have been trying to avoid there is that this leads to a combinatorial explosion of units (all relevant scalings of all relevant units for each chemical compound). By using a different QuantityKind for different chemical compounds, the vocabulary size grows only linearly with number of chemical compounds. This problem would not go away if we only defined such units in a profile.

If it's just about the symbol, would it be a problem to add a, say, qudt:symbolSuffix to the QuantityKind that is specific to the chemical compound? Thus, we could annotate the CO2 related quantitykind with qudt:symbolsSuffix "(CO2)", and applications that want to generate quantitykind-specific labels can use that information?

[Toby-Broom]

I meant from a ontology perspective, I would split things up:

CO2 has a quantity value
quantiity value is x kg

or for the bio things

Colonies have a count/number
count/number is 100

In the UI I would use the symbol rules and put 10 kg(CO2)

[fkleedorfer]

So the suggested additional triple would be a viable solution for this use case, right?

[Toby-Broom]

I think this is general solution for all, there is always a context to a quantity. In the end also not many people are interacting directly with the ontology. I my previous company we stored all the data in base SI units but people still wanted rpm or °C on the UI because its a better user experiance.