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

simplify Magnitude and Unit of Measure #451

Closed
philblackwood opened this issue Apr 7, 2021 · 16 comments
Closed

simplify Magnitude and Unit of Measure #451

philblackwood opened this issue Apr 7, 2021 · 16 comments
Assignees
Labels
closed: duplicate Duplicate issue or subsumed by another issue impact: major Non-backward compatible (changes inferences; e.g., adding a restriction, domain, range) topic: units / magnitudes / aspects

Comments

@philblackwood
Copy link
Contributor

philblackwood commented Apr 7, 2021

Updated May 5 with more complete description and comparison with gist 9.6.0
Also includes a spreadsheet with examples.
Change the .txt suffix to .owl to open the owl file.

Updated May 24 to include annotations in owl file, change unitSymbol to symbol, and include 200+ business metrics in spreadsheet. The WORD document includes the example of adding a new unit (watt hours per mile) and minor editorial changes to WORD document.

gist issue 451.docx

abox unit of measure.xlsx

magnitude_pdb.txt

An agile approach to evaluating this would be to get a high level sense of whether it makes sense to consider it, then understand the proposal and tweak it until it does everything it needs to, and then figure out how to get "from here to there". Point-by-point comparison of old vs. new is a larger effort and prone to forgetting things like changing hasUoM to hasUnitOfMeaure. My 2 cents.

@philblackwood
Copy link
Contributor Author

Probably subsumes the following:

#146 CoherentRatioUnit
#160 numerator, denominator, multiplier, multiplicand
#302 add Magnitude as domain of hasPrecision (I agree with Michael's suggestion to close)
#381 terms for Magnitude and Unit IRIs

I incorporated the proposed solution for #171 and #172: introduce numericalValue

@philblackwood
Copy link
Contributor Author

For Enterprise customers, it would be more natural to use the term "standard unit" rather than "coherent unit".

@rjyounes
Copy link
Collaborator

Dave's thoughts in the attached PowerPoint.
notes on UoM.pptx

@uscholdm
Copy link
Contributor

@philblackwood
I'm struggling to get the essence of the idea so I can evaluate it. I want to be able to look at some definitions and immediately see what it would look like in gist 9.6. I cannot see how to do that yet.

  • You say to use Aspect to capture the idea of dimension, but there was no class for dimension in gist.
  • It is not clear what is to be used for the broader notion of unit, other than the coherent ones.

The turtle has the following:

:_distance
	a
		owl:NamedIndividual ,
		:Aspect
		;
	skos:definition "The spatial aspect that is measured in meters (coherent unit)."^^xsd:string ;
	skos:scopeNote 'The term "distance" is used instead of the term "length" as in the International System of Units. This allows the term "length" to be used along with "width" and "height" to describe physical objects.'^^xsd:string ;
	.

:_distance_above_sea_level
	a
		owl:NamedIndividual ,
		:Aspect
		;
	skos:definition "An aspect that is measured in meters (coherent unit)."^^xsd:string ;
	skos:scopeNote "The term can be used for the elevation of a geo point or for the altitude of an object."^^xsd:string ;
	.

I cannot easily determine what is similar or different about these two. There is no semantic link to indicate that both have the same coherent unit. The text definitions say how they are similar, but say nothing about how they differ.

  • The spatial aspect that is measured in meters (coherent unit).
  • An aspect that is measured in meters (coherent unit).

@uscholdm
Copy link
Contributor

There is no class in gist for dimension, on purpose. Each coherent unit corresponds to exactly one dimension, so the latter is unnecessary.

@philblackwood
Copy link
Contributor Author

all my comments from this thread have been folded into the updated WORD document in the first comment (box)

@philblackwood
Copy link
Contributor Author

Attached is a hopefully realistic scenario of an Enterprise that needs to introduce a new unit of measure.

It illustrates the kind of guidelines needed for manual calculation of conversion factors and identifies some obstacles to automation of the conversion factors.

This example will be added to the WORD document. The Excel file will be updated with a list of 248 common business metrics and what some of them would look like if the aspect were folded into the unit itself.

Simple example of new units.docx

@rjyounes
Copy link
Collaborator

Consider pulling magnitudes and units of measure out of gist core into a separate module as a first step. Not sure if there's a clean breaking point.

@philblackwood
Copy link
Contributor Author

Interesting idea, Rebecca.

Maybe get some more experience and start to add things back in to the core as they prove themselves (kind of the opposite of removing things that are not being used; add things that are being used).

@uscholdm
Copy link
Contributor

I'd have to have a look, but I think there are a few places where Magnitudes are used to define other things, but even if so, there won't be many.

@philblackwood
Copy link
Contributor Author

The original entry has been modified to include updates to WORD document (example of watt hours per mile, plus editorial changes).

The .txt file (owl content) has been updated with annotations and to change unitSymbol to symbol.

The excel sheet now includes 200+ examples of business metrics.

@philblackwood
Copy link
Contributor Author

Here is some data from the QUDT ontology (Quantities, Units, Dimensions, and Types) at http://qudt.org

QUDT units, quantity kinds, quantity kind dimension vectors (with SI terms added), and disciplines.

QUDT has many, many properties, not always used consistently, so I did not include them.

QUDT documentation talks about systems of units other than SI, but their vectors seem to represent SI units (not entirely clear ... that's a topic for a different post).

qudtUnits.txt
qudtQuantityKinds.txt
qudtVectorsWithSITerms.txt
qudtDisciplines.txt

@philblackwood
Copy link
Contributor Author

To better understand QUDT data for Quantities, Units, Dimensions, and Types, consider the following questions and answers:

  What does the unit MicroGRAY measure?   Absorbed Dose

  What disciplines deal with Absorbed Dose? Radiology and Atomic Physics

You can answer similar questions with the attached data set derived from QUDT (change the .txt suffix to .owl)

qudtValues.txt

@rjyounes rjyounes added the impact: major Non-backward compatible (changes inferences; e.g., adding a restriction, domain, range) label Sep 15, 2021
@philblackwood
Copy link
Contributor Author

philblackwood commented Sep 20, 2021

Here are a few slides to give concrete examples that span a good range of use cases and identify some desirable characteristics of any solution. It includes a sketch of how SI and QUDT are different, and some references (I doubt if we need to go deep into Gaussian or Planck systems).

unit of measure jumpstart.pptx

@uscholdm
Copy link
Contributor

The following notes were the basis for a discussion on 13-Oct-22.

The points below are based on feedback from @philblackwood

  • Existing terminology is pretty geeky, assuming more math and physics familiarity than may be warranted for our clients. For example, CoherentUnit. There is also an verbiage inconsistency we have a property called hasStandardUnit that has range CoherentUnit.

  • When one wishes to introduce a new kind of unit, gist is designed with the expectation that the user will create new Magnitude and UnitOfMeasure subclasses, and specify detailed composition of units from other units using numerator, denominator, multiplier and multiplicand. This expectation and the work involved is considerable. The benefits are not clearly worth the effort.

  • There is an alternative way to express the units in SI terms, which is an option to consider should the need arise.

  • ProductUnit and RatioUnit are ambiguous concepts. The exact same unit can be expressed as a product or a ratio.

  • We do not now have a consistent way in gist to represent a wide variety of business units and metrics, including statistical measures such as average or maximum. We have modeled statistics such as this in client work, but it is not currently exposed in gist. It is adequate, but there might be better ways to do this. It is an open question whether to keep this separate from gist proper, given it is pretty niche.

  • We do not now have a way in gist to express the fact that two different physical measures that cannot meaningfully be added nevertheless have the same unit. An example from Schneider Electric is reactive power and real power. Both have the same SI base unit exponents: kgm2⋅s−3 Other units that have the same base units are: watt, volt-ampere-reactive and volt-ampere (not to mention our good friend joules-per-second). Again, from our prior client work, we did have a mechanism for expressing this linkage between units, which is not exposed in gist.

If I were King, I would be inclined to:

  • Rename CoherentUnit to StandardUnit (have Coherent Unit be an altlabel)
  • Remove Aspect from being a subclass of Category. Aspects such as like length, or inner diameter or cycle time are not categorizing anything that I can think of.
  • UnitOfMeasure is a subclass of Magnitude
  • Define StandardUnit to be a UnitOfMeasure that
    • has conversion = 1
    • has itself as a standard unit
    • has a scopeNote indicating that this captures the idea of dimension.
  • Get rid of RatioUnit, RatioMagnitude, ProductUnit and ProductMagnutide
  • Make it clear that there is a simple way to create new units. This is currently supported in gist, no need to change anything.
    • Create the unit as a new instance of UnitOfMeasure
    • Make sure it has a standard unit
    • Make sure it has a conversion
  • If there is a need to represent the internal structure of a unit, that can be done in two ways.
    • The current method: hard to create, easier to understand once created, hard for computer to do recursive computation.
      • Create new subclass of Magnitude
      • Create new subclass of UnitOfMeasure
      • Use numerator, denominator, multiplier and multiplicand to show how to construct the new unit
    • The current method (simplified):
      • Create new subclass of Magnitude
      • Create new subclass of UnitOfMeasure
      • Specify a direct conversion to the standard unit
      • Do NOT bother with numerator, denominator, multiplier and multiplicand
    • The vector exponent method: this is used by QUDT. It is easier to create, harder for humans to understand but easier computationally

Open questions:

  • How to handle things that have same units but mean different things and cannot be added.
  • Underlying meaning of percentages, rather then pure number unit
  • Unless it falls in our lap for free, defer creating a special mechanism for statistics like average and maximum that apply to collections. It is pretty niche.
  • Business units like unemployment rate, average cost to acquire a customer
  • How include characteristics and specifications

@rjyounes
Copy link
Collaborator

Closing this issue as the proposals are now out of date. See current discussion and proposals in issue #759.

@rjyounes rjyounes added closed: duplicate Duplicate issue or subsumed by another issue and removed status: under review In triage labels Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: duplicate Duplicate issue or subsumed by another issue impact: major Non-backward compatible (changes inferences; e.g., adding a restriction, domain, range) topic: units / magnitudes / aspects
Projects
None yet
Development

No branches or pull requests

3 participants