Missing triples: qudt:isScalingOf, qudt:prefix, qudt:conversionMulitiplier

[fkleedorfer]

The following is all based on the 2.1.19 data. Units and prefixes data is enough.

A few triples are missing. Using this query reveals them (result in missingTriples.txt). Most of the results of this query are missing one or two triples - possibly not all of them, because some units are speical cases.

PREFIX qudt: <http://qudt.org/schema/qudt/>

SELECT * where
{
    ?unit a qudt:Unit.
    optional {
        ?unit qudt:isScalingOf ?base .
    }
    optional {
        ?unit qudt:prefix ?prefix .
    }
    optional {
        ?unit qudt:conversionMultiplier ?conversionMultiplier .
    }
    filter(!contains(str(?unit), "-"))
    filter(regex(str(?unit), "(.+/Atto.+|.+/Centi.+|.+/Deca.+|.+/Deci.+|.+/Deka.+|.+/Exa.+|.+/Exbi.+|.+/Femto.+|.+/Gibi.+|.+/Giga.+|.+/Hecto.+|.+/Kibi.+|.+/Kilo.+|.+/Mebi.+|.+/Mega.+|.+/Micro.+|.+/Milli.+|.+/Nano.+|.+/Pebi.+|.+/Peta.+|.+/Pico.+|.+/Tebi.+|.+/Tera.+|.+/Yobi.+|.+/Yocto.+|.+/Yotta.+|.+/Zebi.+|.+/Zepto.+|.+/Zetta.+)"))
    filter(!bound(?base) || !bound (?prefix) || ! bound (?conversionMultiplier))
} order by ?prefix ?base ?unit ?conversionMultiplier

[steveraysteveray]

I have a question for you. You have talked about the notion of scaling as being related to the base units, not just the prefix multiplier. However, some units such as KiloPA are not just a scaling of PA, but rather a scaling of KiloGM-PER-M-SEC2. In other words, many units (of force, energy, etc.) are defined as various combinations of the base SI units. Is it your intention that the scaling be to the true base SI units?

[steveraysteveray]

I should add that this is how we calculate the conversion multipliers. My question to you is which "base" units to list. Your query lists PA as the base unit for KiloPA.

[fkleedorfer]

I am trying to interpret the semantics of qudt:isScalingOf in the existing ontology, and it seems that it connects pairs like KiloPA and PA, or maybe TONNE-PER-MIN and TONNE-PER-SEC, but neither does it cross unit systems (e.g. SI/imperial), nor does it cross combined units, as in your example - as far as I have seen.

[steveraysteveray]

I agree. The isScalingOf relation was added before my time. I have never been entirely comfortable with it because of the complications that we are discussing now. So, some clear, crisp definition would be welcome!

[fkleedorfer]

Ok, let me try:

‘X qudt:isScalingOf Y‘ expresses the scaling relationship between two units, and the following rules apply:

• There is a real scalar s that converts from unit Y to unit X by multiplication.
• For each unit X, there is at most one ‘x qudt:isScalingOf Y‘ triple. It means that X depends on Y.
• The ‘qudt:conversionOffset‘s of X and Y must be equal, i.e., both undefined (implicitly 0) or identical.
• The scalar s is calculated as any other unit conversion factor, using ‘qudt:conversionFactor‘s of both units.
• If X is scaled by virtue of having a prefix, Y must not have a prefix, and the prefix' multiplier must be equal to s.
• X and Y are both simple units, meaning that they are not scalar combinations of other units. Exception: Y may be a unit that is defined as a combination of other units, such as Watt or Newton; in that case, X is a simple scalar multiplication of Y (such as Megawatt or Kilonewton)
• scaling is independent of which unit is defined as the base unit in some unit system. Prominently, therefore, kilogram is a scaling of gram, not the other way around, even though kilogram is the base unit in the SI system

[fkleedorfer]

That would rule out that TONNE-PER-MIN be a scaling of TONNE-PER-SEC, nor KiloM-PER-HR a scaling of M-PER-SEC. We would have to remove all those and similar triples - which would be a relief, because, if we left them in, they would imply that countless more triples of the sort are missing, including more scaling triples for those units, such as TONNE-PER-MIN being a scaling of GM-PER-MIN, and so on.

I think scaling should only be defined for 'simple' units. One reason is coherence with prefixes: the prefix is always unambiguous for those, but if a complex unit is scaled, there is no way to annotate the prefixes unambiguously, and there are as many ways to scale them as the complex unit has constituent units.

So if we want to make the structure of a complex unit explicit, isScalingOf is not the way to go - but that is a different discussion, I believe.

[steveraysteveray]

I am beginning to be convinced that isScalingOf is a somewhat arbitrarily-defined relation, for the reasons you are giving above. For this reason, I'm not a big fan of maintaining it in the QUDT vocabulary.

[fkleedorfer]

Quite the opposite of what I was trying to get at! I think it is a useful relationship, but we may want to restrict its use to 'simple' units, where it integrates with the qudt:prefix relationship nicely, and if we want something similar for complex units, define something more appropriate.

If it were removed from qudt, we might as well think about removing qudt:prefix - for isn't it quite useless to know a prefix and multiplier, when you don't know the base?