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.

[steveraysteveray]

After following this discussion and thinking about some existing context-dependent units in our current units vocabulary, I have the following proposal:

1. Move existing units that are context-dependent to a new graph named something like http://qudt.org/$$QUDT_VERSION$$/vocab/contextualunit. Candidate entries include compound units that are not really units but are in common use, such as:

• unit:BEAT-PER-MIN as a measure of pulse, or heart rate
• unit:BREATH-PER-MIN as a measure of respiration rate rate
• unit:CASES-PER-KiloINDIV-YR for morbidity rate (probably should use singular unit:CASE)
• unit:DEATHS-PER-KiloINDIV-YR for mortality rate (again, probably unit:DEATH)
• unit:CYC-PER-SEC, which is qudt:exactMatch unit:HZ
• unit:FRAME-PER-SEC
• unit:SAMPLE-PER-SEC
• unit:EUR-PER-KiloW-HR, where EUR is a CurrencyUnit with prefix cur:
• unit:CFU, for Colony Forming Unit, a unit for Microbial Formation that is equivalent to unit:NUM
• unit:GM_Carbon-PER-M2-DAY, where the unit is being conflated with the measurement
  ...as well as other domain-specific units such as:

This last example is nicely addressed in the recent publication in Nature in which the authors point out:

"A particular difficulty is the conflation of units with other aspects of measurements, for example, an observation that combines nouns with a unit. For example, “milligrams of nitrogen” may be the name of a measurement or in the QUDT model, a Quantity but the unit is simply milligrams. There are advantages to separating units and measurements (quantities)."

2. Moving these units to a different graph means we can avoid deprecating any of them, and thus reduce disruption to current users.

3. None of these compound units would require factor units for all components. In other words, we would not include unit:BEAT or unit:BREATH.

4. Each of these new entries would have two triples that tie it to a Unit and a QuantityKind, e.g.

unit:BREATH-PER-MIN skos:related unit:NUM-PER-MIN  (or skos:broader could be used)
unit:BREATH-PER-MIN qudt:hasQuantityKind quantitykind:RespiratoryRate

This approach cleans up the QUDT units vocabulary graph, but still allows provision of terms that users sometimes think of as units and points them to the underlying "context-free" QUDT unit. QUDT.org could curate common ones, and the user community could provide additional graphs containing terms of art as extensions.

Thoughts?

[jhodgesatmb]

The only issue I see with this suggestion is where to draw the line of what is considered contextual. Taking the devil's advocate position, the same argument could be made for any 'qualified' units (i.e., with underscores after the unit). It is really a matter or perspective or threshold for what defines 'contextual'. If we don't define the threshold in such a way that it is clear and unambiguous we would really be pushing the problem down the road.

What is the rationale for this proposal? The discussion topic has roamed a bit, from contextual units, to profiles, and back again. The point that @toby and @florian made is that context opens up a virtually infinite number of units. So far, we have allowed domain experts to submit contextual units, and some standards bodies also have contextual units (at least, the qualifier types). Is that where profiles enter the discussion?

[steveraysteveray]

I agree that we will need to try to be as clear as possible. Some "underscored" units, I would argue, are not contextual in the sense used above, such as GAL_US vs GAL_UK, or DEG_C vs DEG_F. They are just different variants of an ambiguously defined unit. But your point is well taken.

The rationale for this became clear to me when looking at the factorization work that is underway. The first 7 examples I listed above exposed the fact that the component units were undefined (such as BEAT, BREATH, CASES, etc.) and are really not units, just countable phenomena. Rather than requiring the components to be defined, I feel it is better to simply define the compound units but not require full factorization.

The bigger picture I see is one that uses both contextual unit graphs (contributed by users plus one curated by QUDT.org) AND profiles that could be defined as the union of one or more contextual unit graphs and a filtered subset of the main unit graph.

[jhodgesatmb]

I agree that many of the 'qualified' units aren't contextual. What I was saying is that some of them are, and that extends the number of units affected by your proposal. Examples are: CAL_15_DEG_C, unit:CentiM_H2O, unit:IN_H2O_39dot2DEG_F, etc. One could argue that any material type or temperature specialization is a context. That argument is easily extended in any direction.

[steveraysteveray]

Yes, I think those would all move over. I agree that any material type or temperature specialization like these are contextual.

[fkleedorfer]

Yes, along those lines, and if really needed, we can split them up in multiple files in the target

[steveraysteveray]

That could work, but even better, let's figure out how to build profiles. The default would be "everything" - all units in one graph, all quantitykind in one graph, etc.

What I think we need is a way to invoke a build, presumably locally, that will do a combination of the following things:

1. Filter out things by means of some predefined SPARQL query. This could include FILTER statements like excluding currency units.
2. Add things stored in extension graphs that don't really belong in the main graphs. The extension graphs could include domain-specific units, plus contextual units.

I'm not sure what is the most elegant way to select arbitrary combinations of the above.
-P parameters in Maven?

[steveraysteveray]

And to your point, @fkleedorfer, certain users have made clear to me that they at least know parts of QUDT that they definitely do NOT want cluttering up their workspace.

[steveraysteveray]

Thinking of the user's perspective, it seems like the Maven -P mechanism might do the trick. The "P" stands for profile, after all. We could have options like:

• mvn -Pall install, which would work much like the current 'mvn install'
• mvn -Pcore install, where filtered versions of the vocabularies are staged for the install, and would not have currencies or the context-dependent units or quantity kinds.
• mvn -Pbiology install, which would filter out concepts clearly out of scope, such as astronomical, electromagnetic, etc., plus adding biology-context-dependent concepts.
• mvn -P install, ...
• etc.

Still to be determined how best to design the back end of such functionality.

Thoughts?

[fkleedorfer]

If we decide that self-generated profiles are sufficient for the 'profiles' feature, that would make things easy. As long asit is just a question of whether x is in profile a or not, no big deal, but I think there are going to be multiple dimensions along which people are going to want to choose. Then, a distribution zip becomes a tangled mess..

[Toby-Broom]

Sorry for late reply was sick, what sort of profiles would you have by domains like economics, biology.? I do like the idea of having smaller items, it seems tough when we have an ontology or vocab with 1000's of items when ofen we only need less than 100 items to decribe a problem, so it nice to have modularity, if we ever needed everything we can load all of the modules, the solutions seem more to a domain, so it fits to take the module for a domain.

My Endotoxin units were prescibed by US Pharmacopeia so recognised in some manner by domain experts.

We are using the IOF for measurements (e.g. https://spec.industrialontologies.org/ontology/202401/core/Core/MeasurementProcess) so we already have the higher level item that the nature article talks about. You can descibe things like Jack showed properly since the measurement process outputs more than one quantlity value the temperature and the energy. There is also materials included so we can attach the measurement to a material so we descibe what object that is being measured. I do see what the paper descibes in my work that how a person would descibe something e.g. "phosphate concentration in soil pore water" does seem to lend itself to something more ontologically complex, I feel that it has value from an answering questions perspective however if you had the question what do phosphates do then it would be hard to tell if you only had the concept of a "phosphate concentration".

I'm happy to contribute what I can.