Simplify units and measures model.

[uscholdm]

This is a few bites from issue #759 which is too big a beast.

I propose the following:

• DONE Rename CoherentUnit to StandardUnit (have Coherent Unit be an altlabel)

• DONE StandardUnit

  • Define StandardUnit to be equivalent to a UnitOfMeasure that
    • has conversion=1
    • has itself as a standard unit
  • Add a scopeNote indicating that this captures the idea of dimension
  • New standard units
    • Add square meter as the standard AreaUnit
    • Add cubic meter as the standard VolumeUnit .

• DONE UnitOfMeasure

  • make equivalent to a Magnitude that
    • has numericValue =1 (it's not called 'unit' for nothing)
    • has itself at its unit of measure
    • has conversion=1
    • has a standard unit
  • remove unit of measure from disjoints where incorrect or redundant
  • Moved an annotation about units from Magnitude to a better home: UnitOfMeasure
  • Remove and deprecate SimpleUnitOfMeasure
  • Remove redundant typing of BaseUnits, can be inferred from enumeration.
  • Properties
    • Make hasStandardUnit functional
    • Remove and deprecate hasBaseUnit. Use hasStandardUnit instead

• DONE Remove product and ratio units and magnitudes

  • Remove: ProductUnit, CoherentProductUnit, ProductMagnitude
  • Remove: RatioUnit, CoherentRatioUnit, RatioMagnitude
  • Remove uses and mentions of product and ratio unit and magnitude classes and update definitions and annotations accordingly.
  • Percentage was redefined because it had been a subclass of RatioMagnitude which was defined in terms of RationUnit. The old definitions are inserted as blank nodes to retain same formal meaning.

• DONE Aspect

  • Make Aspect a not a subclass of Category. Aspects such as like length, or inner diameter or cycle time do not exist for the purpose of categorizing things.
  • Make Aspect a subclass of SchemaMetaData. An aspect is a representation of a property connecting two things. It has roughly the same meaning as an OWL property.

• DONE Magnitudes

  • Fixed erroneous definition of Magnitude
  • Added examples for Magnitude
  • Rename Extent to Distance for consistency.
  • Add scopeNote to hasPrecision to say the precision of a Magnitude must have the same StandardUnit as the Magnitude.

TODO

• 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

[rjyounes]

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

I don't think we want to include a formal restriction on skos:scopeNote as suggested here. I'm not even sure the reasoner will enforce it given that it's an annotation property.

I'd also like to provide some guidance about when to subclass gist:Magnitude, when to use an aspect, and when to use a property, as in the BillingRate / PayRate example I discussed, where these should not be subclasses of Magnitude.

[uscholdm]

I don't think we want to include a formal restriction on skos:scopeNote as suggested here. I'm not even sure the reasoner will enforce it given that it's an annotation property.

The OWL was correct, I documented it incorrectly. Now fixed.

[uscholdm]

I'd also like to provide some guidance about when to subclass gist:Magnitude, when to use an aspect, and when to use a property, as in the BillingRate / PayRate example I discussed, where these should not be subclasses of Magnitude.

Me too. That is out of scope for this issue. It may also be out of scope for gist itself, more like gist usage guidelines and/or examples. I just want to get a stake in the ground with a few key things.

In fact, I may be mis-using the git issue feature here. I did not intend or want comments at the moment, I'm just wanting to get clear on what I'm doing and track progress. There are a bunch of moving parts. A better way might be to close this comment and create a PR and mark it as in progress - that way people will ignore it till I have a showable result.

[uscholdm]

This is subsumed by #697