Extend support for Logarithmic Units

[mgberg]

On occasion, it is the case that data is presented in the logarithm of a dimensional unit. For example, viscosity data is sometimes reported in log of Pa⋅s (expressed as log₁₀(Pa⋅s) or log₁₀(𝜈/Pa⋅s) depending on the preferred system of notation) or log of Poise. It would be convenient to be able to express these in QUDT, even though it would be ideal to not express these values logarithmically.

Already defined is the property qudt:isScalingOf which is used to say one unit is equal to another multiplied by a conversion multiplier, e.g. unit:MilliM qudt:isScalingOf unit:M. It would conceivably be possible to add one or more properties to express something similar but for logarithms, e.g. qudt:isLog10Of, in order to capture that values expressed as log₁₀(𝜈/Pa⋅s) are numerically equivalent to the logarithm of a value expressed in Pa⋅s.

It would also be conceivably possible to do some conversions between units in that log scale using the existing conversion framework via qudt:conversionOffset, e.g.:

log₁₀(𝜈/Poise) = log₁₀(𝜈/Pa⋅s) + 1

A challenge comes in with the representation of the dimensionality of these units. Especially if the notation log₁₀(𝜈/Pa⋅s) is considered, it could be expressed as dimensionless with a Quantity Kind that is also dimensionless. Perhaps the qudt:isLog10Of property could be used to connect the dimensionless logarithmic Quantity Kind to qudt:DynamicViscosity as well in this case.

A few questions for the community:

1. Has this use case for logarithmic units been considered by QUDT before and/or is it considered out of scope? If not:
2. Does the qudt:isLog10Of approach seem reasonable?
3. Does treating the Quantity Kind of these units as dimensionless that are logs of the relevant Quantity Kinds seem reasonable?
4. Does anyone see any problems with this approach?

If this functionality is found to be in-scope and acceptable, I'd be happy to create a PR with the appropriate additions.

[mgberg]

@steveraysteveray Any thoughts on this?

[steveraysteveray]

Hi. Sorry for being non-responsive. Until today I was out for personal reasons.
We have indeed talked about these things in our Board, as part of a larger conversation involving complex datatypes. We haven't yet resolved how we plan to approach the bigger questions, but you offer an interesting incremental step that could at least handle logarithms. Let me put this back on our agenda to consider whether we want to at least do this before we tackle the bigger issue.

[mgberg]

Sounds good!

[steveraysteveray]

@mgberg, we discussed your idea, and could use your help with some clarification. Take unit:PH for example. What would the triple look like that relates this unit to another? We have unit:MOL-PER-DeciM3, but would we need to define a new unit that is the reciprocal of that, for your qudt:isLog10Of to point to? More generally, since the object of the triple is a unit and not a mathematical expression, would this always be the case?

[mgberg]

That's a good point, I hadn't thought specifically about pH. I suppose one could define a reciprocal unit as you suggest; that would probably be the simplest thing that can be done and would likely be the simplest thing to interpret programmatically.

Perhaps there's a larger capability to be considered here than just what I was originally suggesting. If the capability to express more complicated mathematical expressions existed, it could be used elsewhere for other mathematical relations. This could be used to capture knowledge about a broader range of interesting transformations/inferences besides just unit conversions within a given dimensionality. Some basic examples include capturing that Period is the inverse of Frequency, that Density is Mass/Volume and is the inverse of Specific Volume, that pH is log₁₀ of the inverse of (hydrogen ion) activity, and enabling conversion between miles per gallon and liters per 100 kilometers. However, making those mathematical expressions be machine interpretable and actionable might be challenging and/or verbose.

Perhaps there exists a middle ground that consists of a set of properties, e.g.:

quantitykind:Density
    :isInverseOf quantitykind:SpecificVolume ;
    :numerator quantitykind:Mass ;
    :denominator quantitykind:Volume ;
.
unit:KiloGM-PER-M3 :isInverseOf unit:M3-PER-KiloGM .

What prompted this post was specifically related to some data being presented in Poise some places and log(Poise) other places and wanting a reliable way to standardize or convert between them but having the ability to be more expressive than that would presumably be good in general. I'd be interested to hear what the QUDT board has in mind, if this flavor of more advanced expressiveness has been discussed before, and if this kind of information is even considered to be in scope for QUDT.

[steveraysteveray]

I believe you have come to the same conclusion we have, namely that it would be nice to be able to express arbitrary mathematical relations between some units and/or quantity kinds, but it is non-trivial to do right, and possibly out of scope for QUDT.

Creating intermediate units so that triples such as the inverse of (hydrogen ion) activity seems (to me) a bit of a slippery slope.

Finally, your choice of :isInverseOf is probably not the best, as it will be confused with owl:inverseOf, which means something completely different. Something more like :isReciprocalOf might be better. However, this information is derivable by comparing the dimension vectors, so the counter-argument is "DRY" (Don't repeat yourself).

So at this point, there doesn't seem (again, to me) to be a silver bullet solution that is both elegant and generally applicable...

[mgberg]

I agree, I don't see a silver bullet solution either. And I also agree that creating intermediate units so does seem like it could be a slippery slope. And good point about :isInverseOf vs :isReciprocalOf.

If there's no good path forward on these kind of issues at this point in time, I'd definitely be interested to know if a future effort falls in this area. In the meantime, perhaps we'll just have to do something internally.

However, I will note that only comparing dimension vectors for some operations as you suggest is not always fully sufficient, so I'm not sure the isReciprocalOf example fully falls under DRY. For example, the reciprocal of Angular Frequency is not really Time (even though the dimension vectors are opposite), and the reciprocal of Inverse Energy (which currently is a Quantity Kind) is Energy, not Torque (even though Energy and Torque have the same dimension vector).

[dr-shorthair]

Is MathML still a thing? https://www.w3.org/TR/MathML3/

[steveraysteveray]

@mgberg, in thinking and discussing the :isReciprocalOf relation with the QUDT Board, including your examples for AngularFrequency etc., it seems like choosing what quantity kinds are considered reciprocals of others can be contextual. Also, there will be the need to specify n x m such relations, which will not scale well (assuming we continue to publish explicit relations rather than dynamically computed relations). For these reasons, we are concluding that for now it's probably best to support these relations within applications that build on QUDT.

@dr-shorthair, yes, I suppose MathML is a possibility. I think the QUDT Board would need convincing before we jump into the rabbit hole of using a general mathematical markup for content (rather than, say LaTeX, which we already use for presentation of expressions).