Quantity datatype (tracking)

Assigned To
T4007: Tracking bug - Do Not Use; superseded by the #Tracking tag
Blocked By
T117457: Do not apply rounding when formatting Quantities (unless unit conversion was applied)
T115269: [Story] When a Quantity is entered with no uncertainty/bounds given, do not guess uncertainty/bounds until needed.
T112082: [Bug] QuantityParser must pass-through valid unit representations
T110675: [Story] Editing units should show unit label instead of URIs right away.
T110728: [Bug] Quantity field has bad data (\n)
T77978: [Story] Support unit conversion
T102840: [Story] Disallow wikidata.org URIs to non-Item pages in unit/globe/calendar values
T110673: [Story] Meaningful ranking for the selectable units
T86528: [RFC] Unit Localization
T77983: [Story] Use localized unit symbols
T111111: [RFC] Wikibase should specify the significance level of lowerBound and upperBound
T108808: [Task] Diff for unit changes
T105623: [Task] Investigate quantification of quantity precision (+/- 1 or +/- 0.5)
T95425: [Bug] Quantity formatter rounding causes significant data loss
T100000: Add atomic mass
T77977: [Epic] Unit support
T67436: Cannot enter power of ten for quantity datatype
T58892: When rounding quantity margins, never round to zero.
T58715: Formatter and parser for QuantityValue should support explicite bounds
T58685: Apply localization when parsing or formatting quantities
T68580: Better support for exact values in Quantity DataType
T61768: Detecting correct precision when entering a quantity value using scientific notation
T59588: allow entering quantities in scientific notation
T59589: make it possible to show the + sign in quantities on item pages
T62951: [Task] Quantity datatype input extender in UI needed
T57515: Provide UI widget for entering "quantity" values
T57513: Define DataType for quantities
jeblad, DixonD, Darkdadaah and 19 others

The quantity datatype allows to enter quantities. It has quantity value, lower, upper, and a unit.

NOTE: Quantities are assumed to be uncertain per default, exact quantities are considered to be an exception. The idea is that quantities are usually measures. Since this leads to confusion and discussion, here's the rationale for reference: When doing arithmetics with quantities, such as unit conversion, defaulting to "exact" values would lead to "false precision" in the output.

From https://en.wikipedia.org/wiki/False_precision:

"In science and engineering, convention dictates that unless a margin of error is explicitly stated, the number of significant figures used in the presentation of data should be limited to what is warranted by the precision of those data."

And from https://en.wikipedia.org/wiki/Significance_arithmetic:

"If a calculation is done without analysis of the uncertainty involved, a result that is written with too many significant figures can be taken to imply a higher precision than is known".

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz54318.
Denny created this task.Via LegacySep 19 2013, 11:56 AM
Event added a comment.Via ConduitOct 16 2013, 3:29 PM

I wonder if the unit should be controlled by a predefined code list. Otherwise we will have a multitude of units for the same quantity type, e.g. W, kW, MW etc. for power.

Alternatively, in stead of unity type, allowing selection of a quantity type like "time", "length", "area", "power", "currency" etc. where the unit is predefined to a non-prefixed unit, correspondingly to "s", "m", "m2", "W", "unspecified".

Lydia_Pintscher added a comment.Via ConduitNov 27 2013, 4:15 PM
  • Bug 52916 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJan 29 2014, 8:36 AM

physik wrote:

I saw a RFC. Is someone working on that?
Semantic annotation of formulae that contain units is part of my PhD topic... therefore I'm very interested in that topic and open for potential contributions.

Lydia_Pintscher added a comment.Via ConduitJan 31 2014, 12:40 AM

Status update: We have just released the first version of the quantities data type on Wikidata.org. It does not yet support units.

@Physikerwelt: feel free to get in touch with me via email :)

Liuxinyu970226 added a subscriber: Liuxinyu970226.Via WebNov 27 2014, 7:30 AM
Snipre added a subscriber: Snipre.Via WebNov 29 2014, 12:39 PM
Lydia_Pintscher added a project: Wikidata.Via WebDec 1 2014, 2:23 PM
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Stryn added a subscriber: Stryn.Via WebDec 8 2014, 10:32 PM
Lydia_Pintscher moved this task to backlog on the Wikidata workboard.Via WebMar 12 2015, 1:06 PM
Ricordisamoa added a subscriber: Ricordisamoa.Via WebApr 2 2015, 11:33 PM
Kelson added a subscriber: Kelson.Via WebApr 24 2015, 2:05 PM
daniel edited the task description. (Show Details)Via WebMay 5 2015, 8:42 AM
daniel set Security to None.
MSGJ added a subscriber: MSGJ.Via WebJun 4 2015, 8:42 AM
Lydia_Pintscher added a project: Epic.Via WebJun 23 2015, 3:30 PM
Wolfvoll added a subscriber: Wolfvoll.Via WebJun 30 2015, 11:12 AM
Darkdadaah added a subscriber: Darkdadaah.Via WebJul 29 2015, 4:28 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldJul 29 2015, 4:28 PM
jeblad added a subscriber: jeblad.Via WebAug 25 2015, 12:56 PM

This is actually wrong "Quantities are assumed to be uncertain per default, exact quantities are considered to be an exception. The idea is that quantities are usually measures. " A quantity is exact, a measurement is inexact. You count the number of coins, and the number is exact. You measure the weight of the coins, and the weight is an inexact number with an error. That error isn't bound by limits but by an error function, which in the limit is an standard deviation.

daniel added a comment.Via WebAug 25 2015, 3:17 PM

@jeblad: so we agree about everything except the names. Perhaps I should have used "Measurement" instead of "Quantity"? But a measurement is a specific event, that would also be misleading. "MeasuredQuantity" would be more exact, but it's a bit long.

I say the bike shed should be yellow!

Darkdadaah added a comment.Via WebAug 26 2015, 1:35 PM

For what it is worth, "quantity" seems just fine to me. Both a measurement and a count can give a value for a given quantity. Also, a measurement is not only an event, but also its result, so there is no need for a "MeasuredQuality".

To be even more pedantic, there is also another kind of quantity: estimations. Those are not directly measured or counted; they are calculated using a model with known quantities (from which they inherit their precision), e.g. the age of the Universe is estimated at 13.798±0.037 Gy. In that case the error may come both from the measurement and from the model.

thiemowmde closed blocking task T108808: [Task] Diff for unit changes as "Resolved".Via DaemonsSep 7 2015, 12:52 PM

Add Comment