More alternative labels for `one`?

[fosterlynn]

We're using om:Measure for all our quantities in Valueflows (VF), and using your unit definitions. Since applications that use VF are mostly "business" rather than "scientific" applications, we need a different label(s) for one. Suggestions: each, count.

Can these be added as alternative labels for one? Or perhaps they should rather be new units? I don't know what is best for you.

If you are open to this, let me know if I should do a PR, or if you can do so. (Might be better if you do so, but I am willing to try.)

[HajoRijgersberg]

Thanx for your issue! Sorry for my late reply. It's a very valuable and important issue. I think I need some further clarification: do you mean quantities like NumberOfApples or amounts of money? I think the former, since you refer to 'each' and 'count'? 'Count' seems more like a quantity than a unit. Do you perhaps mean that? Count-quantities usually have units like 'one'. Would you need units like 'apple', so that one could formulate: number of products = 3 apple, i.e., where 'apple' acts as unit? Looking forward to your response. P.S.: Maybe a stupid question, but what is doing a PR?

[fosterlynn]

Thanks for your response! Please ask more if this is not clear.

do you mean quantities like NumberOfApples or amounts of money?

Number of apples is a good example. "Apple" would not be the unit though, it is something like a "resource or product type", Valueflows calls it ResourceSpecification. (I believe you have something like that in OM but I would have to look for the name.) Or any product that is quantified with a count or number would be the same. So if I give you 40 apples, or if I consume 40 apples to make applesauce, those look like (syntax not exact):

action: consume
resource specification: apple
quantity:
   hasNumericalValue: 40
   hasUnit: one

On the other hand if I make 30 pounds of applesauce, that looks like:

action: produce
resource specification:  applesauce
quantity:
  hasNumericalValue: 30
  hasUnit: pound

"Produce 30 pounds applesauce" makes sense to people. "Consume 40 one apples" doesn't make sense. "Consume 40 count apples" makes more sense. I still search for better terms. :) You already have piece, which also makes sense to people in some cases, but it seems you have that related to your work with food, which makes it more limited. You already have number if I remember correctly, which can also work in some cases, but not all.

Side note: In terms of currencies, we decided that currencies shouldn't be units, even though they do often appear in unit taxonomies. So US Dollar or Euro would be also a ResourceSpecification for us. So again, I suppose the unit is one, or maybe that is not correct since the numerical value might be 54.78? One aspect of our thinking was that we support alternative currencies, and local currencies, and people make those up all the time. While units seem more permanent, more universal. We don't want to support user-defined units, we want to use your list. :) But this was an area of a lot of discussion, I don't know if we made the best recommendation.

I think the idea of "one dimensional unit" probably makes sense with the scientific origins of unit vocabularies. But not so much in business or economic applications.

Maybe a stupid question, but what is doing a PR?

So sorry! My fault, I meant a pull request (in github).

[HajoRijgersberg]

Thanx again for your response! It is certainly getting clearer now. :) Here some points, the one perhaps more valuable than the other, in more or less synchronous order:

• Indeed, your ResourceSpecification corresponds to hasPhenomenon in OM.
• And indeed, we have Number in OM.
• The unit one is a very special unit (of course not made up by OM but simply only represented there): how the unit one is meant and defined in the paper standards underlying OM, is that its symbol ('1') should not be used after a number, so then it is simply omitted. We can infer from that that the same would go for the full unit name 'one'. So, in your example, 'Consume 40 one apples' would become 'Consume 40 apples'. This would solve your issue, am I correct? The only thing is that we can not specify such in OM, so it should be defined in any program that uses OM as an additional rule.
• Same for your approach to currencies, I guess.
• I understand your point of the made-up currency units and that there is/was a lot of debate ;). Of course, objectively considered, every unit is made up by human beings, from metre to inch. As to what would be the best recommendation, I think they should be defined as units, as one encounters that approach by far the most in the world. Of course, a very special, intricate aspect of such units is their time-varying definition, i.e., their exchange rates, and the fact that there is not any base currency so the exchange rates of every currency to every other currency should be defined in any unit ontology. So, ideally we would obtain a long list of time-dependent exchange rates for every currency to every other currency in OM (i.e., also representing "historical" exchange rates, for "historical" purposes. This has however not yet been worked out in OM.
• But thanx for wanting to use the list of units that are defined in OM only! :) That is of course a huge honour for OM. Please let me know if I have to define any additional currencies, since the list so far is still very limited.
• Interesting hypothesis of yours, that one-dimensional units probably make sense with the scientific origins of units but not so much in business or economics. I have to think about that. Hope to get back to it soon! :)
• No prob, now 'PR' is clear to me! ;) Of course you're free to do a PR, since that is the idea of (this) Git, but be sure that you work in the original text file, not in Protégé, TopBraid, or probably any other ontology editor, because so far as I have experienced these mess up the quite neat and structured organization of the text file of OM. And perhaps a lot more convenient for you would be that I implement any additions to OM, which I would be happy to do! :) For both approaches goes that we should of course be careful in what we add and how, but that's probably obvious.

Hope the above already helps. Looking forward to your response! :)

[fosterlynn]

I am closing this request, it seems to not fit well with how you think of OM2. There are also other labels that are I'm sure technically correct, but not so friendly to "normal" people (not doing scientific work), like pound (avoirdupois). So I think we will just add something like labelOverride to your Unit, and let individual installations define an override for themselves if they like, while keeping the OM2 identifier so that everyone knows what unit is being talked about. This way people also will not have to add logic to eliminate "one" on user interfaces.

Thanks for considering it.

[HajoRijgersberg]

Ah, I see what you mean; perhaps your other labels are more domain-specific. As to the currencies: in my comment above I argued they be defined as units, but now that I have read it back I think I should also have mentioned that "in the world" there is also an important type of units: constants and other (physical) quantities. Like the mass of the sun, it is a quantity, i.e., a specific mass, but it is often used as unit. Note that in OM we have not incorporated this idea yet. This is something that I have already been wanting to tackle for a long time, but it is difficult of course. It will lead to certain consequences, etc. It is something that I would like to include in OM 3. Maybe good to know this and of course feel free to reopen the issue anytime you want. And thanx for the contribution, discussion, so far! :)