qudt:isScalingOf inconsistent with qudt:prefix because of unit:KiloGM #548
Comments
|
Your suggestion, which makes things nice and easy within QUDT, would make us inconsistent with the SI, which sounds like a problem to me... |
|
Although the suggestion makes Sense from KMS point of view, QUDT supports other systems of units, such as CMS. The problem is real from your point of view (I.e., having a consistent and automated way to convert units based on the base unit and the prefix. Why is it that using the conversion multiplier without backing out the base unit and prefix is the desired approach?
Perhaps KiloGM should not be considered a multiplier (Kilo) since it is a base unit in the KMS SOU. We were applying our qname convention to all units and this one is clearly problematic as your analysis shows.
Jack Hodges, Ph.D.
Arbor Studios
… On Aug 26, 2022, at 4:30 AM, Florian Kleedorfer ***@***.***> wrote:
This is an attempt to reformulate more #455 concisely and suggest a simple solution. The current state of the ontology is causing downstream problems.
The way qudt:isScalingOf, qudt:prefix/qudt:prefixMultiplier and qudt:conversionMultiplier (and qudt:conversionOffset) work, one should be able to find the "unscaled" unit for any unit in the subject of a qudt:isScalingOf triple, and to convert a quantity between those units consistenly, either using the prefix multiplier or the normal unit conversion. This is not the case at the moment because of unit:KiloGM.
For example, unit:DecaGM converts to unit:KiloGM and is a scaling of unit:KiloGM, but has the prefix prefix:Deca. Normally, we can divide by the prefix' multiplier to get the quantity in the unscaled unit, but not here.
The inconsistency is incurred by Kilogram being the standard SI unit despite having a kilo prefix, and therefore, somehow, it may seem right to make gram a scaling of kilogram. However, no other unit in the ontology cares about what unit it converts to when considering scaling - otherwise, e,g, unit:LB would have to be a scaling of unit:KiloGM - and I cannot think of any reason why SI mass should be an exception. Conversely, having this exception makes simple things complicated.
The remedy is simple: Fix unit:KiloGM and its scalings. Let unit:GM be the base unit of all those scalings, ie.:
unit:KiloGM qudt:isScalingOf unit:GM; qudt:prefix prefix:Kilo.
unit:DecaGM qudt:isScalingOf unit:GM; qudt:prefix prefix:Deca.
unit:CentiGM qudt:isScalingOf unit:GM; qudt:prefix prefix:Centi.
... and so on
Then, we only need to know which unit another unit is a scaling of, and we can always do normal unit conversion (i.e. using the conversionMultiplier and the conversionOffset). I am pretty sure the result is consistent with the respective prefixes' multipliers in all cases.
BTW, there are many currently unmarked scalings in the ontology, like X-PER-(timeunit) , or the scalings of imperial units, such as pound, stone, etc. - which could all be added consistently with this change.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
|
Good point, Jack. To be truly consistent, the URI should be KILOGRAM or KILOGM rather than KiloGM, and there might be MilliKILOGRAM, etc. Of course, this would blow the minds of users, I imagine. It's a shame the SI unit of mass wasn't just called something totally new, like a BLOB. |
|
It all depends on what |
|
Sad to say I am ignorant of the isScalingOf property. If it was introduced
before Steve became a part of QUDT, and I have not used it (a bit before
Steve), then the semantics of its intended use would be from the Nexiom
project at NASA Ames and Ralph would be the one to clarify it.
I happen to think that it is unfortunate that KiloGM doesn't have a BLOB
qname, as Steve suggests in jest.
Jack
…On Fri, Aug 26, 2022 at 8:42 AM Florian Kleedorfer ***@***.***> wrote:
It all depends on what isScalingOf is supposed to mean. If you have a
clear definition, maybe could you add it to the vocabulary?
—
Reply to this email directly, view it on GitHub
<#548 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AATQRWOFIMDSDW74MBH42CDV3DQWTANCNFSM57WMPM6A>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
Jack
|
|
If nobody is happy with the current - implicit - interpretation, and nobody relies upon it anyway, might I suggest we add a clear explanation to the property, make the suggested change, and have a wholly consistent qudt? After all who would, without any additional documentation, think it is safe to assume that DecaGM is a scaling of KiloGM? Especially when it is linked to a Prefix with multiplier 10? Everyone knows, that decagram is 10 g. Everyone trying to build code based on these triples will stumble upon this in the form of a bug in their own code, and mitigate by some more or less ugly special case handling. Why go against the straightforward intuition? The fact that kilogram is the si base, I believe, is a different concern, that, if needed, can be adressed in a different way without bending something that works well for hundreds of other units. |
|
I would defer to Ralph for the property semantics but we would all agree that DecaGM is 10 grams.
Jack Hodges, Ph.D.
Arbor Studios
… On Aug 26, 2022, at 11:50 AM, Florian Kleedorfer ***@***.***> wrote:
If nobody is happy with the apparently current interpretation, and nobody relies upon it anyway, might I suggest we add a clear explanation to the property, make the suggested change, and have a wholly consistent qudt?
After all who would, without any additional documentation, think it is safe to assume that DecaGM is a scaling of KiloGM? Especially when it is linked to a Prefix with multiplier 10? Everyone knows, that decagram is 10 g. Everyone teying to build code based on these triples will stumble upon this in the form of a bug in their own code, and mitigate by some nore or less ugly cse handling. Why go against the straightforward intuition?
The fact that kilogram is the si base, I believe, is a different concern, that, if needed, can be adressed in a different way without bending something that works well for hundreds of other units.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
|
UCUM has struggled with this as well. They just decided to make gram the base unit. |
|
FWIW, IFC also uses gram: https://standards.buildingsmart.org/IFC/RELEASE/IFC4/FINAL/HTML/schema/ifcmeasureresource/content.htm |
|
Note that UCUM is not an enumeration of units of measurement, it is a grammar for building complex unit symbols from primitive symbols. Since the prefixes are part of the primitive symbol set, having The reasons for all this are historic and cultural. SI is not 'wrong', it just inherits patterns developed in the 18th century, before automated processing of the sort we are thinking of was conceivable. In a sense life is easier for QUDT since it is an enumeration. But automating conversions using QUDT definitions uncovers this challenge again. |
|
As I just mentioned in #547, I think the inclusion of qudt:isScalingOf causes more confusion than any benefits it brings. This discussion is one example. |
|
We have discussed this in our Board, and we propose to deprecate the qudt:isScalingOf property altogether. As has been pointed out, it is subject to misinterpretation, does not generalize to multiple systems of units supported by QUDT, and the conversionmultiplier provides the information needed for conversions. Unless someone presents a compelling reason to keep it, we will take this action in due course. |
This is an attempt to reformulate more #455 concisely and suggest a simple solution. The current state of the ontology is causing downstream problems.
The way
qudt:isScalingOf,qudt:prefix/qudt:prefixMultiplierandqudt:conversionMultiplier(andqudt:conversionOffset) work, one should be able to find the "unscaled" unit for any unit in the subject of aqudt:isScalingOftriple, and to convert a quantity between those units consistenly, either using the prefix multiplier or the normal unit conversion. This is not the case at the moment because ofunit:KiloGM.For example,
unit:DecaGMconverts tounit:KiloGMand is a scaling ofunit:KiloGM, but has the prefixprefix:Deca. Normally, we can divide by the prefix' multiplier to get the quantity in the unscaled unit, but not here.The inconsistency is incurred by Kilogram being the standard SI unit despite having a kilo prefix, and therefore, somehow, it may seem right to make gram a scaling of kilogram. However, no other unit in the ontology cares about what unit it converts to when considering scaling - otherwise, e,g,
unit:LBwould have to be a scaling ofunit:KiloGM- and I cannot think of any reason why SI mass should be an exception. Conversely, having this exception makes simple things complicated.The remedy is simple: Fix
unit:KiloGMand its scalings. Letunit:GMbe the base unit of all those scalings, ie.:Then, we only need to know which unit another unit is a scaling of, and we can always do normal unit conversion (i.e. using the conversionMultiplier and the conversionOffset). I am pretty sure the result is consistent with the respective prefixes' multipliers in all cases.
BTW, there are many currently unmarked scalings in the ontology, like
X-PER-(timeunit), or the scalings of imperial units, such as pound, stone, etc. - which could all be added consistently with this change.The text was updated successfully, but these errors were encountered: