Define a Measurement Level or similar

[keilw]

Based on discussions in #95 and related tasks in the RI like unitsofmeasurement/indriya#128 the API should be aware of a MeasurementLevel. The term is the most commonly used, also see Wikipedia and blends in very well with the "javax.measure" package or certain elements starting with "Measurement*".

Needs #95

[keilw]

Unless we come across needs for additional values the enum (can't think of anything better here) should contain the best-known classification with four levels, or scales, of measurement: nominal, ordinal, interval, and ratio by Psychologist Stanley Smith Stevens.

[desruisseaux]

Fine for me. On a minor topic, shouldn't we use LevelOfMeasurement instead of MeasurementLevel name? A search on Google gives:

• "Measurement level": 180,000 hits, with the first hits not all related to what we mean, and for those that are what we means the actual text on those page said "Level of measurement".
• "Level of measurement": 24,100,000 hits.

[keilw]

MeasurementLevel would blend in better with top level elements in the API (assuming it gets used by either Unit or Quantity that is the only natural package) like MeasurementException and it's shorter, but I am not too biased on that. While e.g. UCAR calls it UnitSystem we called the same SystemOfUnits for a somewhat similar reason. So we are flexible, let's do a very quick poll and stick to it.
The JDK has very few cases of classes in an AOfB structure. So API consistency is an argument for MeasurementLevel. The only cases I found were NumberOfDocuments, NumberOfInterveningJobs or SetOfIntegerSyntax all under javax.print. For a plural it makes more sense, therefore SystemOfUnits containing multiple units also makes sense, but there is just one level of one measurement, therefore IMO MeasurementLevel and LevelOfMeasurement make the same sense, but in the JDK the majority of elements are shorter like MeasurementLevel. The same javax.print package has an interface AttributeSet. Which says in the JavaDoc it is a "set of printing attributes". Therefore they could have called it SetOfAttributes, but it wasn't.

If we require additional levels, could also be later, the more recent Christman's topology sounds like a good extension to the original four.

So @unitsofmeasurement/experts and @unitsofmeasurement/contributors please vote on either of these options, only one each to make it easier;-)

[keilw]

A) MeasurementLevel

[keilw]

B) LevelOfMeasurement

[dautelle]

C) MeasurementType

I believe that measurement level in English means something completely different, e.g. the measurement level of the river is 2 meters above the average.
In data science, we use a much simpler typology: DataType
For us it would be: MeasurementType
I propose to add a vote for this :)

[keilw]

Done, @dautelle thanks for the reference. It also contains the 4 proposed types. If the group like Categorical or Numerical was of any help (IMO we at the very least need the two Numerical ones) that could be an additional sub-enum or other kind of attribute. I added option C and also voted (since you also voted on more than one ;-)
The JDK and other APIs also know plenty of "type" attributes or enums, AclEntryType just one that's at the very top alphabetically.

[desruisseaux]

It is of course not a scientific study, but Google give me only 378 hits for "Statistical data type". I get 386,000 hits for "measurement type", but most of them are not related to scale of measurement (I find relationship with frequency, rpm, rate, molecule, etc. instead. See for example MathWork).

At least according those non-scientific searches on Google, the most widely accepted term I have found so far is "Level of Measurement". What would be our criterion for choosing a term, if it is not the most accepted meaning?

[keilw]

Well https://en.wikipedia.org/wiki/Statistical_data_type differentiates between at least 7 data types each also has a Level of Measurement column, so the question is, what level of detail do we want to provide for users of the API? The name frankly I care a bit less. Even DataType in the context of our API would be sufficient, and it has not been used at all in a public API even in the JDK (only some internal hidden ones like com.sun or com.oracle. So the degree of detail we wish to model and define may determine the name. IMO we should not call it MeasurementType or DataType and simply stick the 4 to 10 levels of measurement defined by the likes of Stevens. If we agree, those 2, 3, 4 or more levels are the right classification to decide upon arithmetic functions, then we should call it something with "level", otherwise something with "type".

[dautelle]

@werner Thanks for the link, we see appearing again "Level of measurement" :)

[keilw]

Yep, so we have to decide which of them suits for decision making in relevant operations. There would be very little overhead from an enum, even with some additional information, should it even be necessary like "numerical" or otherwise. Before pruning stuff the API currently is around 40kb. I asked @otaviojava to also vote if he can. Right now we have C with 2 Spec Leads voted, but B has 3 votes. If others join on either of these options, we could come to a conclusion this week. @otaviojava and I are invited to say a few words on the progress of JSR 385 after the EDR and I already mentioned this as a feature we plan to work on before Public Review. So it would be perfect if the decision making worked out by tomorrow night (CET) rather than the week after. Since we all voted on more than one item (in the end the one with most +1 counts) I also did for B. To make it a little easier. As long as we're convinced that information (I would start with the 4 Stevens entries and see, if we need any more) helps us best to improve certain calculations, that'll do.

[desruisseaux]

May be safer to take a small, well accepted, set on the basis that it is easier to add elements in the future (if desired) than removing them. Steven's 4 LevelOfMeasurement seems the best-known classification, and is sufficient for JSR-385 needs.

[keilw]

Although not for JSR 385 AFAIK (if @otaviojava and I talk to the EC tomorrow about the progress of the JSR I'll try to ask that) if there is an update that goes beyond a MR, we would also try to file it as "iterative" JSR next, see JSR 387 which just started its PR. I don't think a JSR that started could be turned "iterative", otherwise we may consider that for 385 already.

[otaviojava]

I like ¨LevelOfMeasurement¨, maybe just remove the ¨of¨ to LevelOfMeasurement

[keilw]

@otaviojava Thanks, but how are the two different, or would you suggest LevelMeasurement? I guess that short cut may cause similar difficulties and misconceptions @dautelle claimed about MeasurementLevel.

[keilw]

Btw, especially the term LevelMeasurement literally means something else: http://encyclopedia.che.engin.umich.edu/Pages/ProcessParameters/LevelMeasurement/LevelMeasurement.html A measuring device for the level of liquid in toilets or container tanks.