Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
uscholdm opened this issue Apr 10, 2019 · 20 comments
Assignees
Labels
status: deferred Deferred to a later release for reasons other than it is a major change topic: units / magnitudes / aspects

Comments

@uscholdm
Copy link
Contributor

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
Copy link
Collaborator

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

@rjyounes rjyounes added the priority: nice to have Low priority feature or bug fix label Dec 19, 2019
@uscholdm
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Contributor Author

uscholdm commented Dec 19, 2019

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
Copy link
Collaborator

OK, now I see. This is very clever.

@rjyounes
Copy link
Collaborator

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

@rjyounes
Copy link
Collaborator

rjyounes commented Jan 30, 2020

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
Copy link
Collaborator

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

@uscholdm
Copy link
Contributor Author

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.

@uscholdm uscholdm added effort: medium Requires 1-2 days to complete impact: major Non-backward compatible (changes inferences; e.g., adding a restriction, domain, range) labels Jan 31, 2020
@rjyounes rjyounes added closed: wontfix and removed effort: medium Requires 1-2 days to complete impact: major Non-backward compatible (changes inferences; e.g., adding a restriction, domain, range) priority: nice to have Low priority feature or bug fix status: under review In triage status: triaged labels Apr 9, 2020
@rjyounes rjyounes closed this as completed Apr 9, 2020
@rjyounes rjyounes changed the title Undesirable redundancy with gist:_millisecond and gist_one_millisecond and similar. Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar. Sep 11, 2020
@tedhills
Copy link
Contributor

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

image001

@rjyounes rjyounes reopened this Sep 27, 2021
@rjyounes rjyounes added status: deferred Deferred to a later release for reasons other than it is a major change and removed status: under review In triage labels Mar 24, 2022
@rjyounes
Copy link
Collaborator

Deferred to major discussion on magnitudes and units of measure.

@rjyounes rjyounes added status: under review In triage and removed status: deferred Deferred to a later release for reasons other than it is a major change labels May 12, 2022
@rjyounes rjyounes changed the title Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar. Make UnitOfMeasure a subclass of Magnitude. (Formerly Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar.) Jul 28, 2022
@rjyounes
Copy link
Collaborator

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

@rjyounes rjyounes changed the title Make UnitOfMeasure a subclass of Magnitude. (Formerly Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar.) Make UnitOfMeasure a subclass of Magnitude. (Formerly: Undesirable redundancy with gist:_millisecond and gist:_one_millisecond and similar.) Aug 11, 2022
@uscholdm uscholdm added status: deferred Deferred to a later release for reasons other than it is a major change and removed status: under review In triage labels Aug 31, 2023
@uscholdm
Copy link
Contributor Author

uscholdm commented Aug 31, 2023

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

@Jamie-SA
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Collaborator

rjyounes commented Sep 1, 2023

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
Copy link
Contributor Author

uscholdm commented Sep 1, 2023

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
Copy link
Collaborator

rjyounes commented Sep 1, 2023

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 rjyounes moved this from To Do to In Triage in gist Version 13.0.0 Nov 8, 2023
@rjyounes
Copy link
Collaborator

rjyounes commented Feb 8, 2024

Closing - superseded by new magnitudes model

@rjyounes rjyounes closed this as completed Feb 8, 2024
@github-project-automation github-project-automation bot moved this from In Triage to Done in gist Version 13.0.0 Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: deferred Deferred to a later release for reasons other than it is a major change topic: units / magnitudes / aspects
Projects
None yet
Development

No branches or pull requests

5 participants