Definition of om:Point is inconsistent
Opened this issue · 10 comments
The definition of om:Point is
"an element of an interval scale or a ratio scale, for example, 273.16 on the Kelvin scale indicates the triple point of water thermodynamic temperature"
I don't understand this: interval and ratio scales are very different [1]. The zero position on an interval scale is essentially arbitrarily located, while the zero position on a ratio scale is absolute. Values from a ratio scale can be compared and operated on using a much wider range of arithmetic (addition, subtraction, multiplication or division by a constant, comparison by ratio) while only ordering operations are valid in comparing values on an interval scale.
In fact it looks like the model for om:Scale might be the source of the (my?) confusion.
Is the om:hasOff-Set property intended to provide a way to record the datum? What is it relative to?
What about temporal or geometric scales?
I see you have om:Depth as a subclass of om:Length - that might apply to 'depth' used for the dimensions of a box or piece of furniture ('length x width x depth') or the 'thickness' of a water body etc, but not the common case of depth below an elevation datum which is 'elevation increasing downwards' (i.e. aligned to gravity).
Interval scales and ratio scales are indeed different; the absolute zero of the ratio scale is the (only) difference. But still both interval and ratio scales have points, such as 273.16 on the Kelvin scale, which is the same as the point 0.01 on the Celsius scale. I have to think about your remark on the arithmetic, but only ordering operations are valid for ordinal scales.
The om:hasOff-Set property of om:Scale allows to define a scale in terms of another scale, e.g., the Celsius scale is defined in terms of the Kelvin scale, where the om:hasOff-Set of the Celsius scale is 273.15.
Indeed, depth refers to spatial dimensions of objects (or space). It may be worthwhile to define something like elevation as another subclass of om:Length?
No - elevation is not a subclass of length.
Elevation is a measure of position in a 1-D coordinate reference system.
It is (i) relative to a specific datum; (ii) oriented in the direction of gravity; (iii) directed up.
The position of the datum (Off-Set in your terminology) can be specified relative to another scale, but the end of the chain is some earth reference. Note that the centre of mass is different to the centre of rotation (by about 200m).
OM is very scalar oriented, even though you have (perhaps inadvertently) strayed into a number of vector and tensor applications. I see you have included StressTensor but I don't see how it is intended to be used. In particular, stresses in a solid have an orientation, so that leads you over into geometry and geodesy. Geodesy is a significant discipline in its own right ... and as mentioned above the reference datum is generally related to some planetary frame which is difficult to specify as just 'another scale'.
I think you have a good point. There are in fact several measures used in coordinate systems that are defined in OM. Geographical longitude and latitude and astronomical coordinate measures like right ascension, declination, galactic longitude and latitude, etc. They can all refer to some specific reference frame, whether geocentric or barycentric like the ICRF. Currently there is no way to define the reference frame in OM.
And as you say, the reference frame is not just 'another scale'.
Thanks, both. Maybe good to emphasize/confirm that OM does only touch the field of vectors and tensors, and can not be used as such for expressing positions, twirls, etc. with reference frames indeed, Modelling/incorporating these in OM are indeed research projects in their own. However, we do have the intention to do so, but can't say when or if. Suggestions are of course welcome.
In fact, I would like to base the design of a model for geometric properties on two publications of Tinne de Laet et al. about Geometric Relations between Rigid Bodies:
There is a rich literature in this space. ISO 19107 and ISO 19111 consolidate some of it.
I would strongly advise against trying to roll geometry and geodesy into a basic (scalar) uom ontology.
If you really want to tackle this scope, then do it in a separate module.
Thanks for the refs.
Yes, I agree with that.