search

semanticarts / gist

Semantic Arts gist upper enterprise ontology
Creative Commons Attribution 4.0 International
163 stars 18 forks source link

Scale granularity is underspecified #1174

Open pppelll opened 4 hours ago

pppelll commented 4 hours ago

There are, in my opinion, potential issues with magnitudes with respect to their scales. At present, all magnitudes have a gist:numericValue

Consider 2 scales that measure weight. One measures to the nearest tenth of a kilo, the other to the nearest hundreth. Currently, we distinguish via gist:hasAccuracy

say we weigh some block ex:_Block that has, in reality, a weight of 10.54321. The first scale shows 10.5, the second shows 10.54 . We'd probably model this using gist:hasAccuracy to distinguish the two magnitudes.

Take, then, two brokerages, A and B. A sells whole shares, but B allows for fractional shares (i can buy .5 of a share). $50 in apple stock, when apple stock costs $220, is then in the eyes of A impossible, and in B, equivalent to 50/220 th of a share.

Maybe a bakery sells bagels by the dozen, but bread by the loaf. When selling bagels, the magnitude of items in an order can only be 12, 24, etc. But with bread, it can be 1, 2, 3, etc.

I think some issues can pop up with stuff like this, mostly with respect to data validation, but also when it comes to merging two datasets. If we merge data from brokers A and B, or mix some of their SHACL together, clashes would happen.

Conceptually, I think that there's a gap in the expressivity of Magnitude. I think these situations have two things measuring the same aspect (mass, shares held, items in order), with the same units of measure (kg, shares, item count), but the magnitudes are still different, in ways. And if theyre not different in UoM or Aspect, we dont currently have tools to differentiate them. We have gist:hasAccuracy, but this doesn't quite work for the latter two examples. And while we could say that fractional and whole shares use two different units of measure (whole share vs hundredth of share), it's not quite a satisfactory way of differentiating.

In some cases, we might want to build into a model the idea that a measurement must be somewhere on a discrete scale (the magnitude of number of children must be an integer), or a continuous scale (a line's length is infinitely divisible). But presently, all magnitudes just use the same Numeric Value data property. I think there might be ways to expand on the ways of differentiating either by making different Numeric Value options, or adding something like gist:Scale, and a magnitude has a numeric value on a specific scale.

MichaelSullivanArchitect commented 3 hours ago

somewhat related is a need to compare two things that are effectively the same but use different UOMs that are effectively the inverse of each other. To wit: in the USA electric vehicles measure their "efficiency" using miles per kWh, whereas in Europe they measure EV efficiency using kWh per 100 kilometers. Both describe the exact same thing (with a different emphasis). Yet I don't think there is an elegant way of being able to compare one type with the other. Perhaps these two issues reveal an underlying missing ingredient?

pppelll commented 3 hours ago

@MichaelSullivanArchitect could you expand upon that? I'm not sure I understand your whole point.

MichaelSullivanArchitect commented 3 hours ago

So you and I have identified two shortcomings of the current (and proposed) Magnitude model. The question is simple (perhaps simplistic): could these shortcoming be related somehow and/or could they be resolved using a similar extension to the current model? Just throwing it out there. No ideas as to how to resolve it.

pppelll commented 3 hours ago

@MichaelSullivanArchitect sorry! I should have specified. When you say that there is no elegant way to compare one type to another, do you mean that there's a lack of conversion between miles/kWh to kWh/100km despite them being magnitudes of an EV's efficiency?