Unit tuples

[HajoRijgersberg]

Dear people,

We are thinking to extend OM with what may be called unit tuples. For instance, 5 foot 10 (inch), or 33 hours 15 minutes 12 seconds for an angle, are unit tuples. Now we are wondering what this class of units should actually be called. UnitTuple? UnitAddition? ...? The term CompoundUnit is already being used as a superclass of UnitDivision, UnitMultiplication, and UnitExponentiation. By the way, we propose that UnitTuple (or another name) will be a subclass of that particular class. Looking forward to your response! :)

Best, Don and Hajo

[jmkeil]

I would avoid the term "tuple", as it already has a meaning in RDF context. What about

• "concatenation",
• "chain",
• "mixture"
• "(natural language) presentation"?

Which use case you want to address with this feature?

[HajoRijgersberg]

As I reread my message now, I have to correct it: 5 foot 10 (inch), and 33 hours 15 minutes 12 seconds are measure tuples (or chains), not unit tuples or (chains). The particular unit tuples (or chains) that are used there are 'foot-inch' and 'hour-minute-second'.

[HajoRijgersberg]

UnitConcatenation may be a nice suggestion! :) Use cases: the examples that I mentioned, like 5 foot 10 en 33:15:12. Thanks for your suggestions!

[HajoRijgersberg]

Would the term UnitCouple be a good term? Inspired by 'concatenation' and 'chain'.

[GeorgJung]

Hi Hajo,

I think the way to look at these is indeed in terms of value chains (or measure chains) rather than quantity or unit chains.

Your quantity in the foot-inch example has dimension 'length dimension'. It then has multiple (partial) values (all of the same dimension), each with its own unit that matches the dimension. The total is the sum of the measures. To calculate it, the measures' units need to be unified. However, each partial value has its own unit, so there is not necessarily a "chain unit".

This way you would allow quantities of 5 foot and 20 centimeters...

How about 'has conjugate value' as an alternative to 'has value'? (Sorry, I am not an ontology designer.) Also, this relates to issue #51, complex units.

[HajoRijgersberg]

Hi Georg, Thanks for your comment and confirmation of the idea! Indeed, measure chains; value refers to the property, om:hasValue, that has om:Measure as range. A specific kind of om:Measure would then be the MeasureChain or MeasureTuple, depending on which name we would consider best. By the way, would you think 'chain' better or 'tuple'?

Just for my understanding: with "chain unit" you refer to one unit for the entire chain/tuple?

Not sure about the hasConjugateValue property... Then people would have to use two different properties for specifying values, where the role of both properties is the same. And it's not necessary I guess. Why would it be necessary, just for my understanding? :)

And indeed, I see the relation of complex values with tuples/chains, good point. A difference with the above mentioned chains/tuples is that the two parts of the tuple would have different roles, and that here there would be one "chain unit", if I understand you correctly.

[GeorgJung]

Hi Hajo,

Just for my understanding: with "chain unit" you refer to one unit for the entire chain/tuple?

No, I believe that every element of the chain has its own unit. They only all have to be of the same dimension.

So yes, you are right, it is a measure chain (not a value chain). It is a chain of, for example, two partial measurements, each with its own numerical value and unit (6 feet, 22 inches).

And indeed a different matter than my issue #51...

[HajoRijgersberg]

Thanx, clear! :) Indeed a different matter than #51, simply because with complex number measures there indeed is only one unit applying to both parts of the measure (the real part and the imaginary part). See also https://github.com/qudt/qudt-public-repo/issues/420 for very fruitful discussion about this subject, in relation to OM! :)

[HajoRijgersberg]

I've been thinkin in the meantime, and below is from a post of mine in issue #52 (just posted), but it is also relevant in this issue. I modified it a bit (the last bit related to CompoundIntegerMeasure, etc.).

We now have the measure in OM (om:Measure). It has a numerical value (om:hasNumericalValue) and a unit (om:hasUnit). This is actually the simplest measure one can think of. So, in the future we would like to define more complex types. We will therefore have to reserve the term om:Measure as an umbrella term for all the different types of measures that will be introduced. We should perhaps call the mentioned simple measure: om:SimpleMeasure. There will for example also be an om:CompoundMeasure. It would consist of several other measures, usually simple measures such as in the case of 5 foot 10 (inch). om:CompoundMeasure should then, I think, only have one property, with a cardinality > 1: om:hasMeasure. For example, the compound measure 5 foot 10 could then be defined as follows:

:_5Foot10 a om:CompoundMeasure ; om:hasMeasure :_5Foot ; om:hasMeasure :_10Inch .

Another point: om:hasNumericalValue is currently of datatype string, so anyone is free to specify a number, range, list of numbers, or whatever. In the future I think we should use xsd datatypes. Then we may get different kinds of measures, like in the case of the om:SimpleMeasure:

• SimpleIntegerMeasure,
• SimpleDoubleMeasure,
• etc.

I'm not sure, but it's one of my thoughts. This will perhaps be the case with other kinds of measures too, such as the compound measure (CompoundIntegerMeasure, CompoundDoubleMeasure, etc.).

Looking forward to your response!

Cheers, Hajo

[dr-shorthair]

This is also relevant - https://w3id.org/cdt/ucum

[HajoRijgersberg]

Thanx, Simon (sorry for my late reply - I missed your comment). We should indeed also define something like SimpleScientificMeasure (with e and an integer).