Jump to content

Wikifunctions:Type proposals/Wikidata quantity

From Wikifunctions

Summary

This type is modeled after Wikidata's quantity datatype, and will support the import of all values of that type from Wikidata into Wikifunctions. We acknowledge and draw upon an earlier type proposal, Quantity, with similar objectives.

Uses

  • Why should this exist?

Wikidata contains many statements with values of the quantity datatype. A wide variety of Wikifunctions use cases will be able to make use of these values, and this type will enable Wikifunctions to import these values from Wikidata.

  • What kinds of functions would be created using this?

Many kinds, including in particular functions that are called from Wikipedias and other MediaWiki projects to provide quantity values (or content computed from them), and Abstract Wikipedia functions that generate statements, paragraphs, and articles containing these values.

  • What standard concepts, if any, does this align with?

Wikidata's quantity datatype.

Structure

Wikidata quantity has these 4 keys, shown with proposed English labels:

Optionality

Wikidata's quantity documentation states that the K2/lowerBound and K3/upperBound properties are optional. Wikifunctions does not currently have an ability to declare keys as optional. When importing a quantity value, if either lowerBound or upperBoundis missing, Wikifunctions will assign the value of Z24/void to K2/lowerBound or K3/upperBound, respectively.

If there is no unit stated (e.g., the quantity is just a number), Wikifunctions will use a Wikidata item reference containing the ID Q199, the ID for the Wikidata item representing the number 1.

Example values

TBD

{
  "type": "…",
  "value": "…"
}
{
  "Z1K1": "Zxyz",
  "ZxyzK1": "…"
}

Validator

The validator ensures that:

  • The value of K1/amount is a valid Rational number.
  • The value of K2/lowerBound is a valid Rational number, and is ≤ K1/amount.
  • The value of K3/upperBound is a valid Rational number, and is ≥ K1/amount.
  • The value of K4/unit is a valid Wikidata item reference.

Identity

  • Two instances are the same if they have equal values for each of their keys. Equality of those values, in turn, is specified by the definitions & documentation of their respective types.

Converting to code

Python

We expect to get started by relying on the existing default conversion strategy; something more sophisticated could come later if needed.

JavaScript

We expect to get started by relying on the existing default conversion strategy; something more sophisticated could come later if needed.

Display function

How would a value of this type be displayed on Wikifunctions

…TBD

Read function

When entering a value for this type as a string, what format should that string have?

…TBD

Alternatives

In order to capture the idea presented in the summary, what alternative structures, display functions, read functions, etc. could have made sense too?

… Consider using dimensionless unit (Q1618549) or ratio (Q3481047) for values without units. --99of9 (talk) 06:41, 23 May 2025 (UTC)[reply]

Thanks! Wasn't aware of that option. Will consider it, as suggested. DMartin (WMF) (talk) 03:19, 3 June 2025 (UTC)[reply]
On this point, we decided to go ahead with Q199, as mentioned above, mainly because it seems easier to (mentally) associate that with the rather well-established Wikidata tradition of using "1". (If we've overlooked any important arguments, at this moment it could still be changed.) DMartin (WMF) (talk) 02:50, 12 June 2025 (UTC)[reply]

Questions

  • Is the value for unit, which comes back from Wikidata, always a URL for an item? Currently we are assuming it is, and always with a URL of the form http://www.wikidata.org/entity/Q12345.

Comments

For general comments, please reply to the proposer, or use the Discussion section below.

  • I don’t favour the insertion of values for upper or lower bounds that have no value in Wikidata. As far as is practicable, the Wikifunctions representation should correspond exactly to what is present (or absent) on Wikidata. One possible alternative to consider is a non-standard representation of zero or K1/amount, so that the display function can display a blank instead. (In this context, “non-standard” would be an unsimplified Rational number with a denominator that is not a power of ten.)
    • I completely agree. In fact the team discussed this yesterday and I am just about to update this page. We've decided when one of those properties is missing in Wikidata, we will indicate that by inserting the value Z24/Void in the ZObject. This will be handled as a special case for now, since we don't yet have a formal way of allowing for optional properties. Sound okay? DMartin (WMF) (talk) 16:54, 23 May 2025 (UTC)[reply]
    Sounds right in principle, so long as Z24 is not interpreted as an error, as seems to be the case generally (see 1 mod 0 is void (Z17184), for example). GrounderUK (talk) 22:14, 23 May 2025 (UTC)[reply]
  • The conversion of a Wikidata decimal to a Wikifunctions rational is ultimately worth while, but I worry about possibly losing the semantics of the original. I’m not 100.0000% convinced that 2.00, for example, always means the same thing (on Wikidata) as 2/1. I suggest that such a value should be represented as 200/100, so that the initial conversion from Wikidata is semantically lossless (I believe).
    Assuming no other arguments come up, we are adopting this suggestion (not reducing the terms of the rational), so yes, 2.00 will be represented as 200/100. It does seem potentially useful that the function writer could recover the original form of the decimal from Wikidata. DMartin (WMF) (talk) 00:23, 14 June 2025 (UTC)[reply]
    Yes, I'm comfortable with both of Al's suggestions. We may not use the unsimplified values much, but it could prove useful to have them. --99of9 (talk) 08:46, 16 June 2025 (UTC)[reply]
GrounderUK (talk) 10:07, 23 May 2025 (UTC)[reply]
  • Support Support strong support obviously (functions can be connected to Wikidata so we should support Wikidata types) and I'm not sure to understand the point above about the bounds. Cheers, VIGNERON (talk) 16:10, 1 June 2025 (UTC)[reply]

Discussion