Adding plural strings for units

[olinux]

For display purposes, it would be nice to register the plural for a unit in the controlled term (e.g. "years" for "year").

https://github.com/HumanBrainProject/openMINDS_controlledTerms/blob/d8bc03dce7c5764f80e2ced630dde4e572ffbb7b/schemas/unitOfMeasurement.schema.tpl.json#L1

[UlrikeS91]

I just closed the PR, thinking that this is not required anymore: #61.

In one of the comments, @lzehl was against adding plurals. But maybe worth discussing again?

[UlrikeS91]

PS: I'm keeping this issue in the controlledTerms-repo for now. This may affect the instances-repo as well, since all UnitOfMeasurement instances would need to be updated. But we can still move it when we see the need for it.

[lzehl]

@olinux @UlrikeS91 @apdavison I suggest we discuss this in our Dev meeting.

I would like to discuss the schema and registration of units in general, because I think they should be a bit more complex than our usual controlled term. I personally do not like that we are currently registering every multiples of a unit (g, kg, mg, ng, etc) and I'm missing explicit information (e.g. unit of what? (mass, time, etc), abbreviation, plurals for fullNames). I also would like to be able to more clearly register SI based units separate from other units.

[lzehl]

To pick this up again:

Revision of Units as something else than controlledTerm, but still as instance libraries:

Schema: UnitOfMeasurement (library)

• name [1] (string)
• pluralName [1] (string)
• symbol [1] (string)
• prefix [0-1] (linked type: MetricPrefix)
• quantity [1] (linked type: controlledTerm:Quantity)
• definition [1] (string)
• alternateName [0-N] (string)
• alternateSymbol [0-N] (string) (if applicable add in SI units)
• dimensionSymbol [0-1] (string)

Schema: MetricPrefix (library)

• name [1] string
• symbol [1] string
• base10 [1] string ?

MetricPrefix (library terms): 10^-30 (quecto) to 10^30 (quetta)

Quantity (library terms): time, length, mass, electric current, temperature, amount of substance, luminous intensity, angle, frequency, force, pressure, energy, power, electric charge, electric potential difference, capacitance, electrical resistance, electrical conductance, magnetic flux, magnetic flux density, inductance, luminous flux, illuminance, absorbed dose, dose equivalent, catalytic activity, radioactivity, area, volume, velocity, acceleration, inverse length, density, etc.

@apdavison @olinux would that work with all our units and providing better information about the unit of measurements?

[apdavison]

I am against complexifying the handling of units, it feels like over-engineering.

Separating prefix from base unit

• advantages: fewer instances to register, can represent any new unit without needing to add new instance
• disadvantages: more complex (slower) queries, more complex code for working with units

My view is that the disadvantages greatly outweigh the advantages. In a given domain (e.g., neuroscience), only a small subset of the possible prefixes are actually used for a given base unit.

Link from units to physical quantities

For SI units, this is such standard, universally-understood information ("ampere is a unit of electric current") that I don't think it needs to be represented in openMINDS. For non-SI units, I think it is sufficient to mention it in the definition.

Concerning the original topic of the issue, there are only three irregular plurals [ref]: lux, hertz, siemens. Perhaps it is easier for UI code to handle these three exceptions explicitly than to handle this in openMINDS?

[lzehl]

@olinux you need this for openMINDS v5.0?

If yes I would suggest the following:

• add namePlural to the UnitOfMeasurement schema
• add symbol to the UnitOfMeasurement schema (although not originally topic of this issue)

Assumption:

• name is the preferred long name for the unit
• pluralForm is the plural form of the preferred long name for the unit
• symbol is the symbol/short form of the preferred name for the unit
• synonyms hold any other alternatives (names or symbols, no plurals though)

@apdavison okay?

[olinux]

this is not necessarily needed for openMINDS v5.0 (also because it could potentially be integrated in a minor version due to backwards-compatibility. It can be handled externally if needed (as suggested by Andrew) - but would just be convenient. Let's skip this.