Wikifunctions:Type proposals/Chemical element
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)
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 as proposer. --99of9 (talk) 01:30, 23 July 2025 (UTC)
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)
Support --Ameisenigel (talk) 17:10, 23 July 2025 (UTC)
Support Dv103 (talk) 17:11, 23 July 2025 (UTC)
Support -- Asked42 (talk) 09:01, 26 July 2025 (UTC)
Support and that is funny about the Z-numbers. Speaking of, w:en:table of nuclides#Full table uses Z as one axis and N as another. Perhaps Wikifunctions:Type proposals/isotope would be a good companion type. Arlo Barnes (talk) 06:12, 3 August 2025 (UTC)