Make UnitOfMeasure a subclass of Magnitude. (Formerly: Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar.)

[uscholdm]

We now have:

• gist:_one_millisecond a gist:Magnitude
• gist:_millisecond a gist:UnitOfMeasure

Intuitively, they mean exactly the same thing, so it would be nice to only have one URI. With Magnitude and UnitOfMeasure currently disjoint, we are forced to do this. But what if we could view a unit of measure as simply a magnitude whose decimalValue is 1 and whose unit of measure is itself?

If this can be made to work, we can avoid this unseemly redundancy. I'm looking for a way to do this.

[rjyounes]

Not redundant: the magnitude is a shorthand for one _millisecond.

[uscholdm]

Say I have an individual called :_MichaelUschold and then I create a shorthand :_MikeUschold. The relationship between the two IRIs (e.g. shorthand) does not change the fact that two IRIs are referring to the exact same thing in the world. I am using the word 'redundancy' to refer to that situation.

[rjyounes]

That isn't what I meant by shorthand. I meant shorthand for a resource with a UofM of gist:_millisecond, and decimal value of 1.

[uscholdm]

Lets use a simpler example: second. In the world, this refers to an amount of time. There are two ways to represent this one thing in gist:

1. gist:_second as an instance of DurationUnit which is a subclass of UnitOfMeasure
2. gist:_one_second as an instance of gist:Duration where gist:_one_second gist:hasBaseUnit gist:_second gist:_one_second gist:decimalValue "1"^^xsd:double

This seems redundant to me, why have two different ways to convey the same information? A second is a second is a second which is a gist:Duration which is a gist:Magnitude. There are two things that are special about gist:_one_second.

1. it's decimalValue is 1 (hence the 'unit' in unit of measure)
2. it points to its ontological self (i.e. semantic double) as the base unit

Here is a sketch of an alternative proposal:

1. Define UnitOfMeasure as equivalentClass to a Magnitude with decimalValue=1
2. Define BaseUnit as equivalentClass to a UnitOfMeasure with itself (literally the same IRI) as its base unit. This will use the lonely underutilized hasSelf restriction.

This way there is no need to create a separate instance of Magnitude for unit magnitudes like 'one millisecond' and all base units.

Caveat:

• I'm not sure how this will work for complex ratio and product units

[rjyounes]

OK, now I see. This is very clever.

[rjyounes]

@uscholdm to prepare brief presentation for discussion on January 30.

[rjyounes]

gist Issue Review 2020-01-30

Michael presented his proposal, with mostly positive reception. For next meeting (Feb 20) he will implement it in a git branch and provide RDF samples.

SteveS finds it to be a category error to say a magnitude is also a unit, and runs counter to his intuition.

[rjyounes]

@uscholdm Is this a major or minor change? Can you please label accordingly? Thanks.

[uscholdm]

It would entail moving UnitOfMeasure to be a subclass of Magnitude which would change inferencing. So, strictly, it is major. In practice, however it may be fairly minor. There could be minimal impact. We'll see how the exact proposal evolves.

[tedhills]

Michael and I discussed this proposal further, and I am in complete agreement that implementing his proposal would enhance the correctness, consistency, and simplicity of gist.

In an email exchange, Michael said:

"BaseUnit is a subclass of UnitOfMeasure. . . . The self restriction . . . can be used to define BaseUnit as a UnitOfMeasure that has itself as a base unit.

Something like this, in Manchesterish syntax:

BaseUnit EquivalentTo (UnitOfMeasure and (hasBaseUnit self))

For example, kilometer has meter as its base unit so it’s not a base unit, but meter has itself as its base unit – that infers it into the class BaseUnit.

Currently, gist makes BaseUnit an enumerated class of an exact set of units."

The International System of Units (SI) enumerates its base units, so from that point of view an enumerated list of base units makes sense. However, there’s no limit on the number of base units that can be developed for other dimensions beside those identified in the SI, so the definition above captures the notion of a base unit nicely.

From https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.330-2019.pdf, p. 3: "The value of a quantity is generally expressed as the product of a number and a unit. The unit is simply a particular example of the quantity concerned which is used as a reference . . . ."

Image below provided by @uscholdm

[rjyounes]

Reopening for re-evaluation; @tedhills has some input, and @mkumba would like to consider it.

[rjyounes]

Deferred to major discussion on magnitudes and units of measure.

[rjyounes]

The particular magnitudes such as :_one_second will be removed as part of #692, but the subclass issue remains.

[uscholdm]

DEFERRED: until there is a revision to units and magnitudes in a future major release. #697

[Jamie-SA]

I suggest we start adding any existing UoM issues to the v13.0.0 project so we remember to try and address them all at the same time as the UoM refactor. As a start, I'm going to do that to this issue.

[uscholdm]

Jim and I added #697 to the v13.0.0 project. Therea are a dozen or more units related issues. I decided to NOT clutter up the project with every one of them, Instead Phil and I will make sure we go through them all first.

[rjyounes]

I agree with Jamie in this case. If it is slated for "a major release" and we know the next major release is 13.0.0, why not put it in the project?

[uscholdm]

To be clear, you want me to put the 20 or so issues relating to units in the 13.0.0 project? I paused because that will clutter things up quite a lot, making it hard to find anything NOT related to units.

[rjyounes]

I see your point - I didn't know there would be so many. I wonder if we want a new project for all the units and measures work - projects are not just for releases. Then #697 can stay in the 13.0.0 project, assuming they are all linked to that one. We may want to move them over to the release project as they get completed. What do you think of that?

[rjyounes]

Closing - superseded by new magnitudes model