Jump to content

Wikifunctions:Type proposals/Wikidata geocoordinates

From Wikifunctions

Summary

This type is modeled after Wikidata's geocoordinates 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, Geographic coordinate, with similar objectives.

Uses

  • Why should this exist?

Wikidata contains many statements with values of the geocoordinates datatype. A wide variety of Wikifunctions 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 geocoordinates 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 geocoordinates datatype.

Structure

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

Optionality

Wikidata's DataModel documentation seems to imply, by the use of the word "default", that K3/precision and K4/globe properties might be missing sometimes. Wikifunctions does not currently have an ability to declare keys as optional. When importing a geocoordinates value, if either of those properties is missing, Wikifunctions will assign the value of Z24/void to these keys.

Example values

TBD

{
  "type": "…",
  "value": "…"
}

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

Validator

The Wikidata geocoordinates validator checks that:

  • The value of K1/latitude is a valid Rational number in an appropriate range of values.
  • The value of K2/longitude is a valid Rational number in an appropriate range of values.
  • The value of K3/precision is a valid Rational number in an appropriate range of values.
  • The value of K4/globe is a valid instance of Wikidata item reference. (In most cases, per Wikidata practice, its value will be the Wikidata item reference for Q2, the Earth, which means WGS84.)

Identity

For each of the above types:

  • 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

Questions

  • The JSON encoding of a geocoordinates value includes a property "altitude", but so far I've only seen null values for that property. It doesn't seem to be documented anywhere. I've found an old discussion indicating that there were no plans to make use of it (at least, not at that time). Does anyone know if it has any values in Wikidata, or if it might still be used?
    • In the meantime every bit of documentation I've seen indicates altitude was deprecated and would not be used, so we are currently not planning to include altitude in this type.
  • Some values for precision, coming back from Wikidata, end with an exponent part, like this: "precision": 2.777777777777778e-5. The exponent part isn't mentioned in Wikibase/DataModel, and doesn't conform to the Wikidata Object Notation given for decimal there. It would be good to know if all properties with decimal values are allowed to include the exponent part, or just precision.

Alternatives

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

  • Regarding K4/globe, it would be possible to create a "lightweight enum type", but we have an estimate (from Denny) of about 20 different globes currently in use in Wikidata, and we believe that many elements would make the enum type a bit unwieldy. Also, would like to avoid the maintenance overhead as additional globes get used over time.

Comments

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

…

Discussion

  • IMO a lightweight enum is right for globe, even if it needs occasional maintenance to add globes over time. The community will have rights to do this maintenance eventually. Enum will help enforce constraints on the values, and will help guide editors dropdown choices. --99of9 (talk) 23:32, 10 June 2025 (UTC)[reply]
    Thanks, just saw this; will give it some additional consideration. DMartin (WMF) (talk) 02:57, 12 June 2025 (UTC)[reply]
    We had some team discussion about this. Although everyone agrees a lightweight enum could allow for a better user experience, we concluded that globe isn't a good candidate for an enum. It's too open-ended and conceptually unconstrained. For example, this doc says This would typically refer to a data item on wikidata.org. This is usually just an indication of the celestial body, but could be more specific, ... Even if some bot were checking that it refers to an astronomical body, one could imagine many more globes coming into use. So, at least for now, regrettably there's no plan to employ lightweight enum type for this. However, when composing an input to a function, one will be able to use the existing Wikidata item selector, with its search capability. DMartin (WMF) (talk) 17:01, 12 June 2025 (UTC)[reply]
Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Type_proposals/Wikidata_geocoordinates&oldid=195126"