OM
OM copied to clipboard
HajoRijgersberg
Changes from version 1
It's not clear exactly what has changed from the first version of the units of measure ontology (and why). Is there a summary of changes somewhere?
Thanks!
The main difference is that the ontology is in Camel case now (e.g., degree_Celsius has become degreeCelsius now). The upper ontology has slight differences. Perhaps the most important one is that measures no longer refer to scales (only units); quantities should refer to a point on a scale directly through their hasValue property. In practice, scales are less often used than units of measure. They are in fact only relevant with absolute temperatures. If your need more detailed explanation about this subject, please let me know.
Hope this already helps!
In practice, scales are less often used than units of measure. They are in fact only relevant with absolute temperatures.
Scales are used ubiquitously for spatial and temporal phenomena. Also energy. And anything with 'potential' in its name is relative to some reference value.
Yes, in principle one can always work with scales, however in practice this often doesn't happen, since the use of units is sufficient. For example, one uses the units metre, inch, etc. for expressing lengths, rather than referring to the metre scale or the inch scale. With absolute temperatures, however, one must refer to e.g. the Celsius scale, since 3 degrees on the Celsius scale is something different than 3 degrees Celsius. 3 degrees on the Celsius scale corresponds to 276.15 on the Kelvin scale (i.e., 276.15 kelvin), where 3 degrees Celsius corresponds to 3 kelvin.
I'm not talking about length. I'm talking about position, elevation, offset along a route/trajectory, etc. Similar for time.
And as I pointed out, anything with the word 'potential' in its name is relative to some datum or reference value. Particularly energetic state.
You appear to be working in a narrow set of applications but making claims to universality.
I think what it is about is whether a scale has an absolute zero (that is called '0', so not he Celsius scale). With regard to for example energy, the concerning scales do have an absolute zero, isn't it? E.g. 0 joule really is "nothing"? (This is not the case with 0 °C, but is the case with 0 K).
I gather that many measurements (with units) are made in a context that defines whether they are on an absolute or relative scale. Sometimes the unit scale itself yields this information, like Kelvin, other times one has to add reference to the absolute or relative point, e.g. "observed 10m" --> 10m above sea level, vs. 10m in length, or 10m displacement.
I am curious though about one thing - have you explored a tighter coupling between types of quantity like om:Temperature and scales like om:CelsiusScale ? I.e. that a temperature measurement can only be expressed in temperature scale units? Not sure if this is challenging in OWL or not.
Sounds good what you're writing in your first paragraph. I think you see this correctly!
Indeed, quantities and unit/scales are coupled in OM. The class 'Quantity' has the properties commonlyHasUnit and hasScale. The former is used to indicate the commonly used units for a quantity, and the latter for the scales of a quantity. Quantity also has a restriction on the range of its om:hasValue property. This range is of the type Measure; a measure consists of a numerical value and a unit, for example 3 m, 4 K, 5 °C. The restriction is on the hasUnit property of these measures - and restricts them to all possible units (as far as they are defined in OM) for that quantity. This happens using collections of units, for example the LengthUnit collection represents the units for the class Length (which is a subclass of Quantity), containing units such as metre, inch, etc.
I wanted to include some RDF code here, to illustrate the above, but the indentation spaces appeared to get lost, which makes it quite unreadable. Does anyone know how to format that properly here?
- use Turtle - it is way more readable
- escape code blocks with ``` and ```
- use > and <
Thanks. However, it didn't work. It's probably me. For now, I hope to suffice with using dots (and XML, since I already had the code in that format).
So here are two class specifications to illustrate the above, first the class Length and then the class LenghtUnit:
<owl:Class rdf:about="&om;Length"> ..rdfs:subClassOf ....owl:Restriction ......<owl:onProperty rdf:resource="&om;hasValue"/> ......owl:allValuesFrom ........owl:Restriction ..........<owl:onProperty rdf:resource="&om;hasUnit"/> ..........owl:allValuesFrom ............<owl:Class rdf:about="&om;LengthUnit"/> ..........</owl:allValuesFrom> ........</owl:Restriction> ......</owl:allValuesFrom> ....</owl:Restriction> ..</rdfs:subClassOf> </owl:Class>
<owl:Class rdf:about="&om;LengthUnit"> ..<rdfs:label xml:lang="en">length unit</rdfs:label> ..<rdfs:subClassOf rdf:resource="&om;Unit"/> ..owl:equivalentClass ....owl:Class ......<owl:unionOf rdf:parseType="Collection"> ........owl:Class ..........<owl:oneOf rdf:parseType="Collection"> ............<om:Unit rdf:about="&om;angstrom"/> ............<om:Unit rdf:about="&om;astronomicalUnit"/> ............<om:Unit rdf:about="&om;chain"/> ............<om:Unit rdf:about="&om;cicero"/> ............<om:Unit rdf:about="&om;fathom-USSurvey"/> ............<om:Unit rdf:about="&om;fermi"/> ............<om:Unit rdf:about="&om;foot-International"/> ............<om:Unit rdf:about="&om;foot-USSurvey"/> ............<om:Unit rdf:about="&om;furlong-International"/> ............<om:Unit rdf:about="&om;inch-International"/> ............<om:Unit rdf:about="&om;lightYear"/> ............<om:Unit rdf:about="&om;metre"/> ............<om:Unit rdf:about="&om;micron"/> ............<om:Unit rdf:about="&om;mil-Length"/> ............<om:Unit rdf:about="&om;mile-Statute"/> ............<om:Unit rdf:about="&om;mile-USSurvey"/> ............<om:Unit rdf:about="&om;nauticalMile-International"/> ............<om:Unit rdf:about="&om;parsec"/> ............<om:Unit rdf:about="&om;pica-ATA"/> ............<om:Unit rdf:about="&om;pica-Postscript"/> ............<om:Unit rdf:about="&om;pica-TeX"/> ............<om:Unit rdf:about="&om;point-ATA"/> ............<om:Unit rdf:about="&om;point-Didot"/> ............<om:Unit rdf:about="&om;point-Postscript"/> ............<om:Unit rdf:about="&om;point-TeX"/> ............<om:Unit rdf:about="&om;rod-US"/> ............<om:Unit rdf:about="&om;solarRadius"/> ............<om:Unit rdf:about="&om;yard-International"/> ............<om:PrefixedUnit rdf:about="&om;gigaparsec"/> ............<om:PrefixedUnit rdf:about="&om;kiloparsec"/> ............<om:PrefixedUnit rdf:about="&om;megaparsec"/> ..........</owl:oneOf> ........</owl:Class> ........<owl:Class rdf:about="&om;PrefixedMetre"/> ......</owl:unionOf> ....</owl:Class> ..</owl:equivalentClass> </owl:Class>
Thank you for the responses. A follow-up question regarding the differences between version 1 and version 2: In attempting to capture a quantity for average speed, I noticed that it is represented different in version 1 than version 2. In version 1 there is a class for average speed represented as a subclass of speed, whereas the only mention of average that I can identify in version 2 is as an instance of the 'function' class (not entirely sure what the role of this class is). Is someone able to clarify this for me?
Best, Megan
Yes, I can clarify that. In an attempt to clean up OM a bit and to remove some imbalance among the quantity classes, we have removed the class average speed when we created OM 2. Sorry for this inconvenience; we assumed - probably not a very good assumption - that we could do that. I am certainly willing to add AverageSpeed as a subclass of Speed again in OM 2.0. Would that help?
In the future, to my opinion, all quantity classes should have subclasses like MinimumLength, AverageMass, MaximumSpeed, etc.
Indeed, the class 'Function' is meant to let quantities have an aggregate function, such as minimum, average, etc. Instances of Function are 'first', 'last', 'minimum', 'maximum', 'sum', 'average', 'count', 'standardDeviation', and 'product'. Of course, we can define further instances if needed. Quantity has a property 'hasAggregateFunction', with range 'Function'.
Thanks for the quick reply!
Certainly, having the AverageSpeed would help - but is there another way to represent this concept in the current version? For example, if I were to defined a subclass of Speed which 'hasAggregateFunction' value average, would that be equivalent to AverageSpeed in OM 2.0?
Also, has any thought been given to representing the number of objects that the average is taken over? Why or why not?
You're welcome! Yes, you could do that, but apart from that I will also define it in OM 2 again, so that we'll enable that everyone will work with exact the same class in the future. I hope/intend to do this next week; would that be suitable to you?
I have just uploaded a new version of om-2.0.rdf, where I have added the class AverageSpeed again. Thanks for your comment!
Hi there, I realize this issue is quite old now, but I had a follow-up question regarding the representation of averages and thought this might be the best place for it. Is there some notion of an "aggregated over" property for aggregate values? For example, if I would like to represent whether the average speed is taken over some duration, or over some collection of different (spatially distributed) readings. I was unable to find an appropriate property. Is this something that was considered and intentionally excluded? Or is there a different intended approach to capture such measures?
Hi Megan, This is a very interesting topic, thanks! However, it is not so easy to realize this, because we have to refer to another quantity (e.g., duration) or even a measure (e.g. 48 h). (A simple notion 'aggregated', of course, is within reach.) I'm going to think about this; I'll come back to this soon! Perhaps we could start with adding concepts like 'aggregated over time', 'aggregated over space', etc., next to 'maximum', 'minimum', etc., that we already have? Best, Hajo
'Average' is not intrinsic to units of measure, which is just a scale for a quantity. Average relates to the protocol used to obtain a value, so is a different part of the puzzle. Introducing it in units-of-measure would be out of scope.
No, but quantities are also within the scope of the 'units of measure domain'. And we already have such aggregates in the ontology.
I confess I am not clear on exactly how the boundaries for the Units of Measure domain are drawn. However, given the representation of aggregate quantities (in particular, I believe average is included as a type of function) in the current ontology it would make sense to me to expand on this to capture the nature of the average in more detail. At least superficially, I would think that there should be some notion of aggregated over that might relate an aggregate quantity to another quantity (i.e. aggregated over some length, duration, etc). However, I can see how including concepts like 'aggregated over time' might also make sense.
On Fri, Mar 15, 2019 at 4:12 AM Hajo Rijgersberg [email protected] wrote:
No, but quantities are also within the scope of the 'units of measure domain'. And we already have such aggregates in the ontology.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/HajoRijgersberg/OM/issues/9#issuecomment-473195777, or mute the thread https://github.com/notifications/unsubscribe-auth/ALuh2OmtJ2ZJG65ME0uwTlM-tysVecFPks5vW1X9gaJpZM4VyGO6 .
Sure, quantities, OK. That is essential since it relates to dimensionality. But statistical and other protocols (such as sensors) is straying into concerns that are not essential for quantities and units, but rather relates to experimental design. I strongly suggest doing that in a separate project.
Indeed, average is already part of OM, since one can have average quantities defined (like average length, etc.). For the definition of quantities such concepts are essential, otherwise it wouldn't be possible to define such quantities (average speed, etc.), which are very commonly used. Indeed, it also relates to experimental design, but I guess we should limit ourselves to quantities here. We would define 'aggregated' along existing instances in OM such as 'average', 'minimum', 'maximum', etc. Furthermore, we can define a class 'AggregatedOver', with property 'quantity' (range: quantity classes such as Length, Mass, etc.). Instances of 'AggregatedOver' can be 'aggregatedOverLength' (relating to Length), 'aggregatedOverTime', (relating to time), etc. The only thing that I'm wondering is what the instance 'aggregatedOverSpace' should relate to, since there isn't a quantity 'Space' in OM. Should we define 'aggregatedOverVolume' instead and refer to 'Volume' or define 'aggregatedOverArea' referring to 'Area'?