Jump to content

Wikifunctions:Type proposals/Chemical element

From Wikifunctions
Done --DVrandecic (WMF) (talk) 13:53, 25 September 2025 (UTC)reply

Tried, but currently buggy. Hopefully will be fixed soon. Draft: Z27951 --DVrandecic (WMF) (talk) 18:10, 4 September 2025 (UTC) -- Fixed now! --DVrandecic (WMF) (talk) 13:53, 25 September 2025 (UTC)reply

Summary

Chemical elements are the most important classification of atoms, crucial to describing matter scientifically. Chemical elements are categories of atoms which share the same number of protons in their nucleus. So for example, all atoms with 6 protons are the chemical element carbon, no matter how many neutrons they have. This classification is the underlying metric for the Periodic Table of the Elements, the most important knowledge-representation concept in Chemistry.

Uses

  • Why should this exist?

It's really important for describing chemical compounds. Chemical compounds are a massive class of items on Wikidata (although it only represents a tiny fraction of the compounds in public chemical databases). But very few compounds have articles written about them in even the biggest Wikipedias. This area is ripe for short automated descriptions.

  • What kinds of functions would be created using this?

I made a little diagram of some of the interrelated functions here. Some examples:

  • atomic number
  • element symbol
  • atomic mass
  • elements in compound
  • next element
  • period of element
  • group of element
  • next element in group
  • What standard concepts, if any, does this align with?

This is a core scientific concept.

Structure

This would be a lightweight enum (a call to the function Typed enum of Wikidata references (Z6884)) with values matching the Wikidata item reference (Z6091) (QIDs) of all known chemical elements (and any unrealised synthetic ones that have enough literature to get an item on Wikidata).

For example: carbon (Q623) represents carbon.

Here is a query with the complete list. We could consider leaving out the hypothetical elements that have not yet been synthesised if we need to limit the number of possible values.

Validator

No validator is required for lightweight enums.

Identity

All lightweight enums can use the same equality function same Wikidata enum instance (Z6894).

Converting to code

Custom mapping functions will be written that map between chemical elements and existing types. For example, atomic_number(element) will return the natural number of protons in atoms of that element. Code implementations will usually operate on these regular Types, and then compositions of the mapping functions will return them to the chemical element type where necessary. For example, next_element(element) will compose atomic_number_from_element, increment natural number (Z13578), and element_from_atomic_number.

Display function

Display functions are not required for lightweight enums, because they all share the front-end code for displaying all Wikidata item reference (Z6091).

Read function

Read functions are not required for lightweight enums, because they all share front-end code which generates a drop down that only has the valid values.

For chemical elements, I'm concerned that since not all items will fit on a single dropdown page, we may have some issues, but this will be a good test of how to expand for other large enumerations.

Alternatives

I've been thinking for a while about how to do this best with traditional types. It would be much more complex, because there are at least three core ways of expressing the value: QID, chemical symbol, and atomic number (the original Z identifier!). Whichever type we create will need conversion functions between these three, but the challenge for a traditional type is that they correspond with different primary sources of data, labels, and values in code. So it was going to be hard to choose between some or all of them for a typical key representation, especially for a search or read function to allow you to specify the right element. Lightweight enums are hopefully an ideal solution to this issue.

Comments

For general comments, please reply to the proposer.

Support Support Lovely proposal. I’d be inclined to exclude instances of hypothetical chemical elements, but I don’t see how they would become included once they stop being hypothetical (or “purely” hypothetical, in some sense). These comments from four or five years ago still seem relevant. A lightweight enumeration becomes a “frozen cache” of the SPARQL query results, so we should consider its lifecycle. This is similar to my observation about QID from globe name, python dictionary (Z26405). In general, I think all Wikidata IDs used in Wikifunctions objects should be traceable from Wikidata. What that means in practice is very much an open question, but it shouldn’t be a blocker for this proposal. GrounderUK (talk) 08:58, 23 July 2025 (UTC)reply