Generalize fraction quantities
Opened this issue · 16 comments
I think the current approach to fractions does not scale well. A quality fraction can be a part of anything. For example, I would like to add qualities for fractions of elements in an alloy, this would add many classes to the ontology: copper mass fraction, iron mass fraction etc.
This concept of fractions of something could also be modeled with a relation like:
<MassFraction> <fractionOf> <copper>
Did you already try this approach?
A naive try:
copper mass fraction would be then
<x> a <Fraction> ;
<of> <Copper> ;
<by> <Mass> .Thanx for your suggestion. Indeed we have something like that in OM, but with some differences:
- One can have all kinds of fractions. In your example there is a mass fraction. That quantity, i.e., om:MassFraction is defined in OM. There are also other quantities defined in OM with dimension one, such as (from the top of my head): om:VolumeFraction, om:LengthFraction, etc.
- These fractions are subclasses of om:Quantity, like om:Length, om:Mass, etc. So they inherit the om:hasPhenomenon property to indicate the "owner" of a specific property, like in the mass of copper: the om:Quantity would be om:Mass; we create an instance of the latter, i.e., ex:copperMass, where the property om:hasPhenomenon will have the value ex:copper.
- In case of the mass fraction of copper in an alloy, we would define an instance of om:MassFraction, i.e., ex:massFractionOfCopperInAnAlloy, with om:hasPhenomenon again having the value ex:copper, and om:hasContext having the value ex:anAlloy. The latter property, om:hasContext, is defined in OM but not yet used in OM, for defining specific quantities. om:hasPhenomenon has been used, for defining the standard quantities that base units such as metre, kilogram, etc. are defined in.
The definition of quantity and unit fractions is a very intricate subject. There are issues on this GitHub about it. Please let me know if I dive them for you up.
Hope the above helps. The issue you raise is an important one, so I hope also other people will be helped by this issue and the examples that I have given now.
Thank you for your detailed answer!
"In case of the mass fraction of copper in an alloy, we would define an instance of om:MassFraction, i.e., ex:massFractionOfCopperInAnAlloy, with om:hasPhenomenon again having the value ex:copper, and om:hasContext having the value ex:anAlloy. The latter property, om:hasContext, is defined in OM but not yet used in OM, for defining specific quantities. om:hasPhenomenon has been used, for defining the standard quantities that base units such as metre, kilogram, etc. are defined in."
I do not understand, why ex:copper is the object of om:hasPhenomenon? Should not the ex:anAlloy Instance be the thing that has the Quantity ex:massFractionOfCopperInAnAlloy?
And om:hasContext feels a bit generic, the context could be also something like an experiment where the measure is taken. Would not for fractions a more specific object property be useful. One with the meaning "fraction of"?
In the example it would be "ex:massFractionOfCopperInAnAlloy om:fractionOf ex:copper"
Thnx! :)
Sorry for my late answer.
Should not the ex:anAlloy Instance be the thing that has the Quantity ex:massFractionOfCopperInAnAlloy?
No, in metrology - other than in IT - it is not a subject that has a metrological concept such as mass, volume, etc., but the metrological concept (i.e., the om:Quantity) has as a property the object that it "belongs to" (through om:hasPhenomenon. That's a typical OM term - there is no standard term for that in the standards). So, then the mass fraction has the copper as its om:hasPhenomenon. In case of non-relative quantities such as length and mass this is easier to follow (that copper is the phenomenon). One could say that the context of such quantities is undetermined (one could think of the environment, the world, the universe, etc.) - in case of relative quantities such as mass fraction the context is determined, in the case of the example it would be the alloy.
And om:hasContext feels a bit generic, the context could be also something like an experiment where the measure is taken.
No, the experiment is more the obtainment method, the provenance. Might be worthwhile to use PROV there.
Would not for fractions a more specific object property be useful. One with the meaning "fraction of"?
No, it does not always concern fractions, such as in concentrations, densities, etc.
In the example it would be "ex:massFractionOfCopperInAnAlloy om:fractionOf ex:copper"
The other way round, I think: the copper would be a fraction of the alloy, right? But in OM it would be:
ex:massFractionOfCopperInAnAlloy om:hasPhenomenon ex:copper
ex:massFractionOfCopperInAnAlloy om:hasContext ex:anAlloy
But thanx for your questions and suggestions! :)
Hope my answers help.
Thanks a lot for the clarifications. I think my misunderstandings come from the om:hasPhenomenon property.
Is there a reason, that no inverse property for om:hasPhenomenon is defined? Maybe I am adding the wrong one in my head. I am using "hasQuantity" as an inverse and with that assumption: "alloy hasQuantity fractionOfCopper" sounds better than "copper hasQuantity fractionOfCopper".
Glad to help! :)
Is there a reason, that no inverse property for om:hasPhenomenon is defined?
Interesting suggestion. I think we could try to analyze whether that is possible or useful. My first feeling/thought is that an object that refers to a quantity class using e.g. hasQuantity kind of skips the instances that we define of om:Quantity (that have a phenomenon, i.e., the object). So I'm not sure, but it would be a good thing to think about and discuss this further.
Maybe I am adding the wrong one in my head. I am using "hasQuantity" as an inverse and with that assumption: "alloy hasQuantity fractionOfCopper" sounds better than "copper hasQuantity fractionOfCopper".
Yeah, there is some kind of mixup in what you suggest, I can't put the finger on it immediately. But I guess we'll find out together.
If we would have om:hasQuantity, then the corresponding statements would be:
copper hasQuantity om:MassFraction
But now I don't know where to "put" the alloy. So something is wrong in this approach, I guess.
What would fractionOfCopper be kind of instance in your view?
Interesting suggestion. I think we could try to analyze whether that is possible or useful. My first feeling/thought is that an object that refers to a quantity class using e.g. hasQuantity kind of skips the instances that we define of om:Quantity (that have a phenomenon, i.e., the object). So I'm not sure, but it would be a good thing to think about and discuss this further.
I did not know that you have om:hasQuantity already defined. In this diagram I have the proposed om:hasQuantity property highlighted in red. The red and black om:hasQuantity naturally should differ. Also if you use the red entities in om it you would not have to define a fraction of Thing by Quantity for every possible thing and quantity.
But now I don't know where to "put" the alloy. So something is wrong in this approach, I guess.
What would fractionOfCopper be kind of instance in your view?
I modeled it for copper, fractions are a special case, because they are dimensionless and do not have a unit. And I did punning with el:Copper and om:Mass, I am not sure if this is a good design.
Thanx for your efforts and diagrams!
I did not know that you have om:hasQuantity already defined.
It is only defined to indicate the standard quantity that base units (such as metre, kilogram) and the fixed points that span a scale (such as the freezing point of water for 0 °C) are defined. Not for indicating for a unit which quantities it can express.
Suppose we would define such a relation, e.g., om:expressesQuantity, should that relation be defined as a class restriction? I think so. That might have consequences for reasoning with OM. If you know more about that, that would be great.
Studying your diagrams, there is something wrong, I think. The suggestion of om:Fraction is certainly interesting, however - naming it like om:QuantityDivision, in correspondence with om:UnitDivision - it should not be a division of a Thing and a Quantity, but the division of two quantities. It would be strange to divide a Thing by a Quantity. I'm afraid that does not make sense... :/
fractions are a special case, because they are dimensionless and do not have a unit
In the way that you have defined it now, they are have a dimension: ex:foo namely has the dimension M^-1 (where M refers to the mass dimension).
Looking forward to your response. Hope my response does not demotivate in any way. If so, that was certainly not my purpose! Really appreciate discussing these things with you! :)
Suppose we would define such a relation, e.g., om:expressesQuantity, should that relation be defined as a class restriction? I think so. That might have consequences for reasoning with OM. If you know more about that, that would be great.
It could be inverse property for om:hasPhenomenon, so it would just have a range restriction to om:Quantity. Should not have a big impact on reasoning.
I see this issue through the eyes of our domain experts, aka "WTF is a phenomenon? I just want to know how long this thing is?"
That might have consequences for reasoning with OM. If you know more about that, that would be great.
My use case is actually reasoning, I have some standards expressed as OWL classes which put restrictions on alloys. For example a "PureCupper" has a mass fraction of copper higher than 99%. Then I want to reason which alloy instances belong to which standard.
Studying your diagrams, there is something wrong, I think. The suggestion of om:Fraction is certainly interesting, however - naming it like om:QuantityDivision, in correspondence with om:UnitDivision - it should not be a division of a Thing and a Quantity, but the division of two quantities. It would be strange to divide a Thing by a Quantity. I'm afraid that does not make sense... :/
The division would be massOfCopper / massOfAlloy, but I overlooked, that you already have the unitless quantities defined, so the om:by is already expressed with the Mass in MassFraction so it boils down too:
om:of is maybe ambiguent. It should mean, of what thing do I have the fraction of. Ex: I have the fraction of copper in an alloy...
P.S. Then we are good, I was afraid I would annoy you with stupid questions ;)
P.S. Then we are good, I was afraid I would annoy you with stupid questions ;)
Haha, no I appreciate your questions very much! They have to do with a very relevant topic, expressing relative quantities so to say. And probably more people run into such issues, so I would say this is - like the other issues on this GitHub - a very relevant issue.
Looking at your new nice graph, this is the way how it is defined in OM, except that:
- the use of om:hasPhenomenon would be to express the el:Copper,
- om:of is called om:hasContext in OM,
- which would be used to express the ex:alloy.
So, if you rename om:of to om:hasContext, and swap ex:alloy and el:Copper, you would have a perfect OM diagram so to say, fully in correspondence/compliance with OM! :)
I have raised the proposal of om:expressesQuantity (or similar naming) to my colleagues. Hope to get back to this issue soon!
Looking at your new nice graph, this is the way how it is defined in OM, except that:
- the use of om:hasPhenomenon would to express the el:Copper,
- om:of is called om:hasContext in OM,
- which would be used to express the ex:alloy.
I have two issues with this:
A quantity in the general sense is a property ascribed to phenomena, bodies, or substances that can be quantified for, or assigned to, a particular phenomenon, body, or substance. Examples are mass and electric charge.
If you say om:MassFraction om:hasPhenomenon ex:Copper or equivalently ex:Copper om:expressesQuantity om:MassFraction the semantics of this expression are problematic, because the mass fraction of copper in copper is always 1. And if ex:Copper is the element copper, all other mass fractions would be zero.
- Practically, this would mean that when you have a graph with different measurements of an alloy, like mass, conductivity etc.. You would have to write two queries to get all the quantities, because for mass the alloy would be connected to the quantity with
om:hasPhenomenonbut for fraction it would be connected withom:hasContext
A quantity in the general sense is a property ascribed to phenomena, bodies, or substances that can be quantified for, or assigned to, a particular phenomenon, body, or substance.
Correct. Now, in science and unit standards however the quantity is considered to be the central concept, not the phenomenon. The quantity, such as mass, length, etc. can have a phenomenon, such as copper. We have extended that approach with the hasContext property for referring to e.g. the alloy.
In IT, the approach is the opposite round, as you illustrate in your example:
ex:Copper om:expressesQuantity om:MassFraction
Good b.t.w. that you give this example. I see now that you have intended the expressesQuantity property for phenomena, not for units. I had understood the latter. I would say, in this sense the name would perhaps better be: om:hasProperty.
But as mentioned this a different approach than adopted in science and unit standards. We have not yet accomplished the combination of both approaches. But I do think it is very important to think about that goal - in fact in this thread we're doing that. Not sure however what we can accomplish in OM. In fact, I'm afraid it will be difficult. But I think it will be a very good goal for the next version of OM, 3.0.
In the mean time, let's continue this discussion, understand each other better, and see what we can do in OM 2.0.
If you (...) ex:Copper om:expressesQuantity om:MassFraction the semantics of this expression are problematic, because the mass fraction of copper in copper is always 1. And if ex:Copper is the element copper, all other mass fractions would be zero.
We don't have this problem when use hasPhenomenon and hasContext:
massFractionOfCopperInMyAlloy a MassFraction.
massFractionOfCopperInMyAlloy om:hasPhenomenon ex:Copper.
massFractionOfCopperInMyAlloy om:hasContext ex:myAlloy.
Practically, this would mean that when you have a graph with different measurements of an alloy, like mass, conductivity etc.. You would have to write two queries to get all the quantities, because for mass the alloy would be connected to the quantity with om:hasPhenomenon but for fraction it would be connected with om:hasContext
Why would the alloy have to be connected with om:hasPhenomenon?
Hope the above helps a bit. Looking forward to your response! :)
Ok, now I get it. A fraction has a numerator and a denominator, and you can start with either of those, because it is not possible to measure this quantity directly.
With OM 2.0 you start with the mass of copper and set it in relation to the mass of the alloy.
I started with the mass of the alloy and then set it in relation to the mass of the copper in it.
Because of this, I would connect the alloy with om:hasPhenomenon as this is equivalent to: alloy hasProperty MassFractionOfCopper.
I close this for now, when I am still working on this when you start with OM 3.0 we should continue this discussion.
Thanks for your help!
Because of this, I would connect the alloy with om:hasPhenomenon as this is equivalent to: alloy hasProperty MassFractionOfCopper.
But where do you store the copper then?
I close this for now, when I am still working on this when you start with OM 3.0 we should continue this discussion.
Yes, we should definitely do that. Once again, thanx for your issue and the discussion so far! :)