Property proposal:	Generic	Authority control	Person	Organization
	Creative work	Place	Sports	Sister projects
	Transportation	Natural science	Computing	Lexeme

Physics/astronomy

Please review Wikidata:WikiProject Physics before proposing. Ping members of project using {{Ping project|Physics}}
See also Wikidata:Property proposal/Pending for approved items awaiting the deployment of currently unavailable datatypes.
Please look at Wikidata:List of properties/science/natural science before proposing a property.

Biology

Please visit Wikidata:WikiProject Taxonomy for more information. To notify participants use {{Ping project|Taxonomy}}

Please visit Wikidata:WikiProject Biology for more information. To notify participants use {{Ping project|Biology}}

‎anatomical structure in view

Under discussion

Description	the anatomical structure in view in the photo, e.g. head, wing, habitus (body)
Represents	anatomical structure (Q4936952)
Data type	Item
Domain	item, qualifier of image (P18); Commons images
Example 1	File:Eristalis proserpina NHMD 61966 dorsal habitus.jpg→habitus
Example 2	File:Dioprosopa clavata (23508816868).jpg→face (Q37017)
Example 3	Hypocritanus fascipennis (Q136415497)image (P18)File:Ocyptamus fascipennis wing.png→wing (Q161358)
Allowed values	subclass of (P279) anatomical structure (Q4936952)
See also	Wikidata:Property proposal/anatomical view, depicted part (P5961)
Wikidata project	WikiProject Anatomy (Q8487304)

Motivation

Allows images of animals to be labeled in a language-independent manner; e.g. rather than the text "habitus dorsal" for a top-down photo of an insect specimen, this property could be used with habitus (item should be created or a suitable one found), along with another property I would like to propose to specify the view (dorsal). Could enable auto-generated captions specifying what part of the animal am I looking at (and with the other property I am working on, what orientation am I viewing this from). Could also enable a wider variety of images on taxon items, with photos showing the face/head, wings, general appearance (habitus), diagnostic features such as genitalia (particularly for insects).

I'm not sure how much this could be extended to non-animal organisms (as I'm unfamiliar with their study) or if changes would need to be made to support that.

Should work well for labeling scientific drawings or figures.

Should be a subproperty of depicts (P180). On that note, I'd also be fine with the name "depicted anatomical structure". In the scope of Commons images, I suppose the qualifier depicted part (P5961) on depicts (P180) would work as well. --WrenFalcon (talk) 05:34, 28 October 2025 (UTC)[reply]

Discussion

Why doesn't depicts (P180) / depicted part (P5961) do what you want to do? Why is there a need for a new property according to your view? ChristianKl ❪✉❫ 13:22, 4 November 2025 (UTC)[reply]
The specific use case I envision is on projects such as Wikispecies or Commons, where a template could fetch image (P18) statements for an item (e.g. taxon) and associated qualifiers, and from that generate a caption automatically - akin to a structured data representation of a simple media legend (P2096), e.g. Hypocritanus fascipennis (Q136415497)image (P18)File:Hypocritanus fascipennis at white asters (cropped).jpgsex or gender (P21)male organism (Q44148)anatomical structure in viewhabitusanatomical viewdorsal (Q2602751) → Hypocritanus fascipennis (♂), habitus dorsal. While this is likely still possible if "anatomical structure in view" is replaced with depicts (P180), it is complicated on items of taxa above the rank of species, where one might see e.g. Hypocritanus (Q112895679)image (P18)File:Hypocritanus fascipennis at white asters (cropped).jpgdepicts (P180)Hypocritanus fascipennis (Q136415497)sex or gender (P21)male organism (Q44148). If depicts (P180) is used for the proposed property, it would be more difficult (and more expensive) to generate captions in this way (specifically, figuring out if it's a "depicts taxon" or a "depicts anatomical structure" qualifier).

depicted part (P5961) should work just fine on Commons, but I don't believe it would work on Wikidata—it seems like depicted part (P5961) should only be used as a qualifier of depicts (P180), so it would not be possible to use it as a qualifier of image (P18) statements. However, if the proposed property is used on Wikidata, I see no reason to not also use it on Commons. --WrenFalcon (talk) 15:43, 4 November 2025 (UTC)[reply]
In this case, I think depicted part (P5961) should do the work. You can use it with image (P18), Property:P5961##P2302 clearly allows it. You can see an example here. Paucabot (talk) 08:51, 24 December 2025 (UTC)[reply]

‎anatomical view

Under discussion

Description	view of an anatomical structure, e.g. ventral, dorsal, frontal
Represents	anatomical coordinate (Q66515060)
Data type	Item
Domain	item, Commons image. as qualifier of, or qualifier alongside, Wikidata:Property proposal/anatomical structure in view (likely as qualifier of image (P18) on Wikidata; potentially as qualifier of depicts (P180) on Commons)
Example 1	File:Dioprosopa clavata (23508816868).jpganatomical structure in viewface (Q37017)→frontal (Q66571830)
Example 2	Dioprosopa clavata (Q28608131)image (P18)File:Dioprosopa clavata (23508816868).jpg→frontal (Q66571830)anatomical structure in viewface (Q37017)
Example 3	File:Eristalis proserpina NHMD 61966 dorsal habitus.jpganatomical structure in viewhabitus→dorsal (Q66571829)
Allowed values	subclass of (P279) anatomical coordinate (Q66515060)
See also	Wikidata:Property proposal/anatomical structure in view, orientation (P7469)
Wikidata project	WikiProject Anatomy (Q8487304)

Motivation

See also Wikidata:Property proposal/anatomical structure in view. Alternative name: view of anatomical structure. Should be particularly helpful for labeling specimen photos and scientific drawings/figures, but should be applicable to anything depicting anatomical structures where said structures are the focus of the image. I've come across a number of papers with photos of insect specimens labeled e.g. "habitus dorsal", "habitus ventral", "habitus lateral", "face frontal"; I designed this and Wikidata:Property proposal/anatomical structure in view with that in mind.

Should generally be used with or as a qualifier of anatomical structure in view or another suitable property, as the value of this property is relative to the given anatomical structure. --WrenFalcon (talk) 16:05, 28 October 2025 (UTC)[reply]

Notified participants of WikiProject Biology

Notified participants of WikiProject Anatomy

Please see this and the proposal for anatomical structure in view. --WrenFalcon (talk) 16:12, 28 October 2025 (UTC)[reply]

Discussion

Question: Would this not be better generalised as "view", so it can be used for architectural and engineering drawings, etc? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:27, 28 October 2025 (UTC)[reply]
Good point! Yes, I think that would be better. I'm unsure of the details of what that expanded property would look like, though - is there an item describing orientations or view angles for buildings, etc.?

Also, may want to choose a name other than "view" (see view (P8517)). "view orientation", maybe? --WrenFalcon (talk) 20:02, 28 October 2025 (UTC)[reply]
Support I absolutely agree on this one. I've been trying to standarize image qualifiers (see Wikidata:WikiProject Taxonomy/Tutorial/Image qualifiers) and I had to add ventral (Q3429717) to these 693 images using depicts (P180). An ad hoc property would be a very good idea.

Regarding to the name, I agree to generalize it to buildings and other things and I propose the name point of view or perspective. Possible declarations of this property could be ventral (Q3429717), dorsal (Q2602751), front view (Q1972238), dorsal and ventral (Q137513280), side view (Q118582773), front view (Q118582767), back view (Q118582770), low-angle shot (Q2141207), high-angle shot (Q3392548), Q6077696, bird's-eye view (Q1153655), wide shot (Q3294287), American shot (Q3391185), close-up (Q296001), medium shot (Q4117826), three-quarter view (Q111290955), extreme close-up (Q61786017), etc. Paucabot (talk) 16:09, 23 December 2025 (UTC)[reply]

Perspectives like "habitus dorsal", "habitus ventral", "habitus lateral", "face frontal" are not anatomical anyway. "Anatomical" presumes a cutting into. - Brya (talk) 03:36, 27 December 2025 (UTC)[reply]

‎AntCat ID

Under discussion

Description	taxon identifier in AntCat
Data type	External identifier
Example 1	Syllophopsis infusca (Q13861306)→440555
Example 2	Polyrhachis loriai (Q3644840)→445891
Example 3	Lasius californicus (Q648541)→438734
Wikidata project	WikiProject Tree of Life (Q8503033)

Motivation

AntCat is an authoritative taxonomic database containing the most recent taxonomic status and revisions on the world's ants. It is written, reviewed, and updated by Barry Bolton, one of the world's leading taxonomic myrmecologists. Every taxon page on AntCat has a unique identifier ID, and it would go under the "Identifiers" category for taxa regarding ants as an ID number similar to that of GBIF or Plazi. I am relatively new to Wikidata so I am not yet too familiar with the structure, guidelines, templates, or rules, and I am open to suggestion or new opinions. Thank you! 2003 LN6 (talk) 05:56, 1 November 2025 (UTC)[reply]

Discussion

I don't know much about ants, but on the face of it I have no objections. How does this relate to AntWeb ID? - Brya (talk) 03:50, 3 November 2025 (UTC)[reply]
- Ah, I see that from an AntWeb page there is a direct link to the relevant AntCat page, so the added value is limited. - Brya (talk) 03:57, 3 November 2025 (UTC)[reply]

Australian National Kennel Council ID

Ready ^Create

Description	identifier of this dog breed at the official website of the Australian National Kennel Council (ANKC)
Represents	Australian National Kennel Council (Q38669)
Data type	External identifier
Domain	dog breed (Q39367)
Example 1	Labrador Retriever (Q38726)→34
Example 2	Golden Retriever (Q38686)→27
Example 3	French Bulldog (Q29149)→188
Example 4	German Shepherd (Q38280)→130
Source	https://dogsaustralia.org.au/BrowseBreed/browse-a-breed
External links	Use in sister projects: [ar] • [az] • [bn] • [de] • [en] • [es] • [fa] • [fr] • [he] • [hi] • [it] • [ja] • [ka] • [kn] • [ko] • [ml] • [mr] • [nl] • [pl] • [pt] • [ro] • [ru] • [sv] • [te] • [tr] • [ur] • [vi] • [zh] • [commons] • [species] • [wd] • [en.wikt] • [fr.wikt].
Mix'n'match	None
Number of IDs in source	190
Expected completeness	eventually complete (Q21873974)
Implied notability	Wikidata property for an identifier that suggests notability (Q62589316)
Formatter URL	https://dogsaustralia.org.au/BrowseBreed/browse-a-breed/$1/_
Country	Australia (Q408)
Applicable "stated in"-value	Australian National Kennel Council (Q38669)
Single-value constraint	yes
Distinct-values constraint	yes

Motivation

--Trade (talk) 21:08, 3 January 2026 (UTC)[reply]

Discussion

@Prototyperspective, Wd-Ryan:--Trade (talk) 21:08, 3 January 2026 (UTC)[reply]
Support makes sense, useful. --Prototyperspective (talk) 21:11, 3 January 2026 (UTC)[reply]
Know anyone who have time to make a catalog? Trade (talk) 21:15, 3 January 2026 (UTC)[reply]
Conditional support without slug at the end. Change the formatter to https://dogsaustralia.org.au/BrowseBreed/browse-a-breed/$1/_ and it will work with just the number. -wd-Ryan (Talk/Edits) 23:59, 3 January 2026 (UTC)[reply]

Biochemistry/molecular biology

Please visit Wikidata:WikiProject Molecular biology for more information. To notify participants use {{Ping project|Molecular biology}}

Chemistry

Please visit Wikidata:WikiProject Chemistry for more information. To notify participants use {{Ping project|Chemistry}}

‎molecular formula

Under discussion

Description	Description of chemical compound giving element symbols and counts
Represents	molecular formula (Q188009)
Data type	Item
Domain	type of chemical entity (Q113145171) group of stereoisomers (Q59199015)
Example 1	2-hydroxy-5-octanoylbenzoic acid (Q209407)→C₁₅H₂₀O₄ (Q129998552)
Example 2	abscisic acid (Q332211)→C₁₅H₂₀O₄ (Q129998552)
Example 3	Santonic acid (Q7420590)→C₁₅H₂₀O₄ (Q129998552)
Example 4	silver bicarbonate (Q27260276)→CHAgO₃ (Q130044611)
Allowed values	molecular formula (Q188009)
Expected completeness	always incomplete (Q21873886)
See also	chemical formula (P274)
Wikidata project	WikiProject Chemistry (Q8487234)

Notified participants of WikiProject Chemistry

Motivation

This proposal addresses the need for improved data structure and maintenance within Wikidata’s chemical compound data. Currently, the Wikidata:WikiProject Chemistry manages approximately 1 million chemical items, with many of them linked to chemical formula (P274) and mass (P2067). The main issues are:

Redundancy in Data: With about 300,000 unique chemical formula strings in use, redundancy is a significant problem. Some strings are associated with over 1,000 items, which complicates data management (see https://w.wiki/B2ax).

Efficiency and Maintenance: Transitioning from string-based formulas to item-based ones will simplify maintenance, reduce redundancy, and optimize query performance, especially for SPARQL queries involving formulas or masses.

Data Optimization: Moving mass (P2067) statements to the newly created formula items will reduce the number of triples and make data management more efficient. Additionally, this change will facilitate the use of different units for masses and allow for better structured data.

Improved Modeling: Switching to item-based formulas could eliminate the need for overly complex has part(s) (P527) statements on chemicals, allowing cleaner, more precise data models (e.g., identifying all chemical formulas containing more than five oxygen atoms).

This change is expected to bring numerous benefits, including reduced redundancy, improved query efficiency, and better data maintenance. The potential downside of increased label editing can be managed, and the overall gain for Wikidata’s chemical data justifies this proposal. If approved, I am prepared to create the necessary items and migrate existing data.

Any further input to refine this proposal is more than welcome!

P.S.: I have no strong opinions if current chemical formula (P274) should be deleted or used on the new items as "Chemical Formula String" – The preceding unsigned comment was added by AdrianoRutz (talk • contribs) at 15:00, August 28, 2024‎ (UTC).

discussion

Support sounds great! Egon Willighagen (talk) 15:25, 28 August 2024 (UTC)[reply]
Comment Last night on the boat between Finland and Sweden I thought of another aspect where this would help model the chemistry in Wikidata better. If chemical formula are items (and thanks to GZWDer for showing various Wikipedias decided it was useful too), then they can also subclass each other. We can have an isotope-agnostic chemical formula ( the common case) and subclasses for chemical formula with isotopes.As such it does much more than being something technical (e.g. just about scalability) but actually improve how we talk about the chemistry. Egon Willighagen (talk) 07:07, 29 August 2024 (UTC)[reply]
Some comments:

I will oppose "Additionally, this change will facilitate the use of different units for masses and allow for better structured data." - For consistency and machine-readability we should stick to one unit. I instead propose Wikidata:Property proposal/formula weight.
Many wikis has pages like C15H20O4 (Q1250089). Some wikis treat it as disambiguation pages; some as set indices; we need to discuss how to handle such existing items. GZWDer (talk) 21:10, 28 August 2024 (UTC)[reply]

I looked at the English Wikipedia sitelink-ed page, and that actually looks exactly like a page about a chemical formula. To be honest, this actually sounds like in argument in favor of this proposal and that C15H20O4 (Q1250089) should be of type chemical formula (Q83147). The same for the French WP page, and neither say they are disambiguation pages, but are far more like a category of things with the same property. Just like this proposal, not? Egon Willighagen (talk) 06:58, 29 August 2024 (UTC)[reply]

I was only partially able to follow your mind here. In your proposal, you mention this property if created, thus you would support it? I believe the discussion about mass (P2067) (and units) or other properties is an interesting one this proposal would allow to better discuss/implement, and what I mentioned about these or what is currently on the example item are just ideas, if this new property allows for these things to also improve, even better! AdrianoRutz (talk) 08:51, 30 August 2024 (UTC)[reply]

Weak oppose I cannot question arguments raised here about efficiency, but I don't see this as a proper way forward. This proposal completely fails to take into account the fact that for a given chemical entity there may be many – equally correct – chemical formulae (simple example in Q27260276#P274). Moving chemical formulae to another item will not help at all with the most important purpose for which WD exists – using this data. I would see the new property as being created only to assist with specific activities – but not to replace existing properties – and with appropriate disclaimers in the name and constraints that it is a strictly technical property only. Wostr (talk) 22:21, 28 August 2024 (UTC)[reply]
I think this proposal has no problems with alternative formula notations, e.g. like CHAgO₃ (Q130044611). Or? Egon Willighagen (talk) 06:51, 29 August 2024 (UTC)[reply]
CHAgO₃ and AgHCO₃ are not the same chemical formula. Just as e.g. XeF4O and XeOF4 which would require two different items for the same compound. In fact, for some compounds several new items would need to be created. For some chemical species we would have formulae that have different number of atoms of elements: C₃₀H₄₀F₂N₈O₉, C₁₅H₁₇FN₄O₃·1,5H₂O and C₃₀H₃₄F₂N₈O₆·3H₂O are correct formulae for the same compound, but I don't see a way for this to be reflected correctly by the current proposal. Everything looks fine if you consider only simple organic compounds and their formulae in Hill notation, but it's not that simple especially if we consider some inorganic compounds which are not molecules. Wostr (talk) 12:34, 29 August 2024 (UTC)[reply]
Thank you for this important point! I removed the single value constraint, thus allowing for what you mention. AdrianoRutz (talk) 08:47, 30 August 2024 (UTC)[reply]

Good point about non-molecular substances. I think the chemical concept we are trying to capture is that of isomerism: chemical entities are isomers when they have the same molecular formula (Q188009) or (non-structural) formula unit (Q1437643), enabling one molecule/ion/unit of the first chemical entity to be rearranged into one molecule/ion/unit of the second chemical entity by moving atoms/bonds around.
For example, the ionic compounds with structural formulas [CrCl(H₂O)₅]Cl₂•H₂O and [Cr(H₂O)₆]Cl₃ are (hydration) isomers, which we can recognise by assigning them the same formula H₁₂Cl₃CrO₆. This shows that all species in the crystal lattice of a compound should be combined together into a single entity when determining the formula. In the example you give above, the correct formula would be C₃₀H₄₀F₂N₈O₉, derived from combining together 2C₁₅H₁₇FN₄O₃•3H₂O, the smallest formula unit with integer multiples of all species.

Likewise, the molecular substance CO(NH₂)₂ and ionic compound NH₄OCN are considered isomers, which we can recognise by assigning them the same formula CH₄N₂O. This is the molecular formula of urea and the formula unit of ammonium cyanate, showing how molecular and non-molecular substances can be isomeric.

For ions, fulminate(1−) (Q27110286) (with structural formula CNO^-) and cyanate anion (Q55503523) (with structural formula OCN^-) are isomers, which we can recognise by assigning them the same formula CNO^-.

Clathrates are similar to coordination compounds. E.g. methane clathrate (Q389036) has structural formula 4CH₄•23H₂O, yielding the formula C₄H₆₂O₂₃. Likewise, the endohedral fullerene CH₄@C₆₀ should have formula C₆₁H₄.

Compounds should not usually map to multiple formulas: if C links to two different formulas, one the same as A (from reference 1) and one the same as B (from reference 2), this implies C is isomeric with A, and C is isomeric with B, but A is not isomeric with B. This only makes sense if 1 and 2 disagree as to what the correct formula of C ought to be.

When references disagree, we may need to support multiple formulas. Historically, w:en:copper monosulfide was thought to have structure [Cu²⁺][S^2-], corresponding to the formula CuS. It has now been assigned the structure [Cu⁺]₃[S^2-][S₂^-], which would correspond to Cu₃S₃. However, PubChem still has the old formula. We might want to update Wikidata to the new formula while also keeping the PubChem-referenced formula (with a note that it's not the correct formula).

Non-stoichiometric compounds, alloys, and mixtures of indeterminate composition are more complicated to support. E.g. pyrrhotite (Q421944) has formula Fe_1-xS (x = 0 to 0.125). Rather than trying to support formula units with atom counts that are algebraic expressions (e.g. 1 - x), I think it would be easier if we could list the formulas of the endpoints: Fe₇S₈ and FeS. Similarly, superconducting yttrium barium copper oxide (Q414015) has formula YBa₂Cu₃O_7−x (x = 0 to 0.65), with endpoint formulas YBa₂Cu₃O_6.35 (i.e. Y₂₀Ba₄₀Cu₆₀O₁₂₇) and YBa₂Cu₃O₇. I think it's hard to come up with a perfect solution though. InChI (P234) has similar issues for non-stoichiometric compounds: https://doi.org/10.1186/s13321-015-0068-4#Sec45.

Preimage (talk) 17:47, 31 August 2024 (UTC)[reply]
Support I also see more benefits than downsides. Support. Wostr I am not sure to understand how this would be a problem even for entities which could be described using different MF sequences of atoms like Q27260276#P274. Indeed the has part(s) (P527) and quantity (P1114) of the MF entity, see C₁₅H₂₀O₄ (Q129998552) would allow to efficiently retrieve such compounds represented in different MF notation systems. What would exactly be the inconvenient in this particular case? GrndStt (talk) 06:22, 29 August 2024 (UTC)[reply]
Support, conditional on change of representation to molecular formula (Q188009). As noted in w:en:chemical formula#Types, chemical formula (Q83147) has four separate meanings: empirical formula (e.g. formaldehyde and glucose both have empirical formula CH₂O), molecular formula (e.g. urea and ammonium cyanate both have molecular formula CH₄N₂O in Hill notation, indicating they are isomers), structural formula (a graphical representation of the structure, not so relevant here), and condensed (or semi-structural) formula (e.g. urea has condensed formula CO(NH₂)₂ whereas ammonium cyanate has condensed formula [NH₄][OCN]). Molecular formulas "indicate the simple numbers of each type of atom in a molecule, with no information on structure", which is what we need for mass calculations. They also avoid the issue raised by Wostr regarding non-uniqueness of chemical formulas (e.g. NH₄NO₃ and H₄N₂O₃ are both valid formulas for ammonium nitrate), as each chemical should have a single canonical molecular formula in Hill notation (with the exception of rare cases where there is disagreement regarding structure, e.g. w:en:copper monosulfide). One last potential issue: molecular formulas are often defined as not including isotopes, e.g. PubChem lists both deuterated chloroform and chloroform as having molecular formula CHCl₃. Egon Willighagen's suggestion to have a subclass of [molecular] formulas with isotopic information would resolve this issue though, I think. Preimage (talk) 12:22, 29 August 2024 (UTC)[reply]
Just revised the naming to change to molecular formula (Q188009), as suggested. 👍🏼 AdrianoRutz (talk) 07:16, 24 September 2024 (UTC)[reply]
Oppose A chemical formula is an abstract entity and not one that has a mass.

It's worth noting that unicode can't capture all chemical formula and Mathematical expression could express more. ChristianKl ❪✉❫ 16:29, 25 September 2024 (UTC)[reply]

You're wrong about that. Each chemical formula has a defined number of atoms of a defined number of elements. Although each element has multiple isotopes, for every element with stable isotopes there is a standard mass associated with it which is the atomic weight which will be found with a typical sample. So the molecular weight of a particular chemical formula very much can be expressed. David Newton (talk) 09:58, 27 September 2024 (UTC)[reply]

Currently, in Wikidata a chemical formula is a notation. Notations don't have inherent mass. The NCI description of what a chemical formula happens to be is "representation of a substance using symbols for its constituent elements". It's not the object that it's describing. While the object that a formula is describing can have mass the formula itself doesn't. It's a Document in NCI's ontology. In PROCO it's a quality and also not something that has mass. material entity (Q53617407) have mass and molecular formula (Q188009) isn't. ChristianKl ❪✉❫ 12:47, 9 October 2024 (UTC)[reply]

The proposed items for formulas could make sense if we interpret the items as representing classes of those chemical entities that consist of the specified number of each element, regardless of bonding. Those underlying chemical entities do have a particular mass (up to some tiny difference due to mass-energy equivalence). 73.223.72.200 05:23, 16 December 2024 (UTC)[reply]

Indeed. The form of "mass" we are trying to capture is w:en:Mass (mass spectrometry)#Average mass, within which formulas do have inherent mass and isomers have exactly identical masses. Preimage (talk) 14:37, 16 December 2024 (UTC)[reply]

Comment - This proposal strikes me as a hack to work around Wikibase's lack of support for computing properties. It seems more straightforward to update the software to compute the mass. As proposed, in the fairly common case that there's currently only one notable compound with a given formula, would we be creating an additional item just to hold properties like mass? That seems counterproductive wrt efficiency and redundancy. 73.223.72.200 05:23, 16 December 2024 (UTC)[reply]
Understood. But we have been waiting over eight years for Wikibase to support computed properties.

In the absence of computed properties, we should use a formula representation that makes downstream processing easier. E.g. suppose I want to set up property constraints to identify chemicals with molecular masses inconsistent with their molecular formulas. At present, chemical formula (P274) uses a string representation, which makes such processing more difficult than it ought to be. Switching to a molecular formula representation that links to elements using the has part(s) (P527) and quantity (P1114) properties would solve this problem.

Another example: organic compounds with F mol% (excluding H) >= 30% are considered to be per- and polyfluoroalkyl substances (Q648037) under the EPA's PFASSTRUCTv5 definition. At present, to test this for a given organic compound, we need to (1) split the chemical formula (P274) string up into element-specific chunks, (2) parse each chunk, (3) combine chunks matching the same element, (4) compute the number of atoms excluding H, (5) compute the number of F atoms, and (6) compute the F mol% (excluding H). The proposal we are discussing here would allow us to skip steps 1–3. Preimage (talk) 13:00, 17 December 2024 (UTC)[reply]
Support --Trade (talk) 20:21, 6 March 2025 (UTC)[reply]
Oppose mass (P2067) and has part(s) (P527) are properties of chemical compound, not its formula. Midleading (talk) 02:41, 2 April 2025 (UTC)[reply]
So, "CH₄N₂O" does not has part(s) (P527) "C", "H", "N", "O"? And you cannot determine the mass of such entity? A chemical compound also has no single mass (P2067), but the chemistry community on Wikidata still has the sensible approach to try to model things in a good consistent yet approximative way. This proposal won't solve all problems as mentioned above but will already allow to do slightly better. AdrianoRutz (talk) 05:55, 2 April 2025 (UTC)[reply]
CH₄N₂O should exist as a string value not as an item, this is the current modeling approach. Your proposal seems too big in scope that a RfC may be more appropriate. Midleading (talk) 16:57, 2 April 2025 (UTC)[reply]
Oppose It seems better to ~~create a property for isomer (Q127950)~~ and leave chemical formula (P274) as is. – The preceding unsigned comment was added by 慈居 (talk • contribs) at 17:04, April 24, 2025 (UTC).
- Modeling things this way would result in thousands of many-to-many relationships, making the situation significantly worse. AdrianoRutz (talk) 19:55, 4 May 2025 (UTC)[reply]
  - The current chemical formula (P274) will be enough. Items for chemical formulas carry no additional information other than the fact that the molecular weight is calculated based on them. 慈居 (talk) 21:32, 4 May 2025 (UTC)[reply]

‎Preferred IUPAC name

Under discussion

Description	Name of a chemical compound following the IUPAC nomenclature of (in)organic chemistry.
Data type	Monolingual text
Template parameter	PIN
Domain	chemistry
Example 1	methane (Q37129) -> methane (EN), methaan (NL)
Example 2	aspirin (Q18216) -> 2-acetyloxybenzoic acid (EN), 2-acetyloxybenzoëzuur (NL)
Example 3	alpha-tocopherol (Q158348) -> (2R)-2,5,7,8-tetramethyl-2-[(4R,8R)-4,8,12-trimethyltridecyl]-3,4-dihydrochromen-6-ol

Motivation

The W:Preferred IUPAC Name is an import type of title for chemical compounds. They are language specific, and the IUPAC nomenclature often translates from one language to another, like methane (EN) and methaan (NL). The previously proposed, formally pending previous proposal wants to couple those and has been waiting "Multilingual text". The oringal proposal discussion mentions the PIN but leaves the adoption in Wikidata a bit in the air (if there is more discussion elsewhere, not in that proposal, please leave that in as a comment).

This proposal requests the addition of property with the current available technology. This proposal does not request permission how to use the property.

Limitation

The current proposal does not accomodate for formatting tags yet. This remains to be explored.

Possible sources

English Wikipedia use the PIN property in the ChemBox template.

The previous proposal suggested to source names from PubChem, but the IUPAC names in PubChem cannot be considered publication and cannot be legally imported into Wikidata, which would effectively change the license.

There are various ongoing efforts releasing collections of CCZero licensed IUPAC names. But these do not currently indicate if the names are a Preferred IUPAC Name. These sources include https://zenodo.org/records/16755947 and https://github.com/BlueObelisk/iupac-names. Moreover, Wikidata also has many IUPAC names currently as label, which has been analyzed too.

However, manual curation would still be needed to determine which valid IUPAC Names are actually Preferred IUPAC Names, and this proposal therefore does not suggest to mass import these. Curation is important. --Egon Willighagen (talk) 05:31, 15 August 2025 (UTC)[reply]

Notified participants of WikiProject Chemistry

Discussion

Strong oppose The existence of CC0-licensed information does not mean we should resort to half-measures. Furthermore, this proposal lacks any details that would prevent this property from becoming a dumping ground for arbitrary names in any language, regardless of their actual correctness. Adding chemical nomenclature to WD is not as simple as it may seem and requires taking into account a large number of variables, even the part about tagging one of the names as preferred is clearly incorrect. In both organic and inorganic chemical nomenclature, there are a number of ways to derive a systematic name for the same chemical compound. Any proposal would need to include a mandatory qualifier specifying the method used to derive the name. Moreover, nomenclature changes over time; names that were systematic decades ago (and are still referred to as such in many sources) are sometimes no longer systematic. This requires qualifying each name with respect to specific IUPAC recommendations. In addition, there are non-systematic names used for systematic purposes or accepted traditional names used for systematic purposes. From a technical point of view, some names require an additional qualifier to allow the addition of certain formatting tags (italics, smaller font) to the name, which are an integral part of chemical nomenclature but cannot be added in this datatype. Last but not least, the sources indicated do not seem to be sufficiently reliable regarding the correctness of the names and their actual compliance with any IUPAC recommendations. The existence of a name in a database, patent, or scientific publication does not guarantee this, especially considering the existence of the CAS nomenclature, which in many cases is very similar to the IUPAC nomenclature. The only type of IUPAC names that I believe we are currently able to add to Wikidata are preferred IUPAC names because there are reliable sources (the IUPAC recommendations themselves translated into many languages by chemical societies) and only one name in one language is correct for a given chemical compound, so it only requires confirmation of the correctness in the source and the requirement to cite the source. In the current situation, any attempt to add other IUPAC names to WD will end up as in any other database where these names are added by simple import from other sources – a total garbage dump from which it is difficult to sift out valuable information. We already have an example in WD, where such names were added as aliases. We must wait, firstly, for the appropriate technical conditions in WD (datatype), and secondly, most likely for the appropriate software (LLMs) that will be able to properly verify such large amounts of data in terms of correctness and qualify them accordingly. Wostr (talk) 10:56, 10 August 2025 (UTC)[reply]
@Wostr, thank you for your elaborate reply. Maybe I should have added that the datasets listed have been tested with OPSIN (Q26481302) and are not arbitraty names. I am sorry to hear you think I think it is simple. I do have some background in the naming system, thank you.

I did not see these points on the original proposal and would have included them otherwise. I understand your general concerns. An intermediate solution is to check if the IUPAC name is a known preferred IUPAC name in the English Wikipedia. If so, then a trusted source says its the prefered name (assuming English WP is trusted).

I do not agree with that LLM s will be able to verify names, at least not as well as experts. But we can disgree on that. For now, OPSIN does quite well (and much better than any LLM will ever do). However, I will ask the OPSIN developer if their software can tell me of a valid IUPAC is the preferred IUPAC name.

I will await a few more comments and then improve the proposal. -- Egon Willighagen (talk) 20:29, 10 August 2025 (UTC)[reply]

Isn't there a pending proposal for an IUPAC name property (Wikidata:Property proposal/Pending)?

I'm no chemist, but I maintain systems that integrate chemistry KBs. One recurrent problem I face is the lack of an explicit property for representing IUPAC names in Wikidata.

Maybe @Egon Willighagen's proposal is not the best one, but it would be great if we could reach some middle ground. Guilherme A. F. Lima (talk) 13:22, 12 August 2025 (UTC)[reply]
Hi, yes, the pending proposal is linked to in the description. I tried to change as little as possible from that proposal. But if we want to change more, let's do it. Egon Willighagen (talk) 06:10, 13 August 2025 (UTC)[reply]

I made a first round of updates to the proposal. -- Egon Willighagen (talk) 14:59, 14 August 2025 (UTC)[reply]

Although English Wikipedia has some PINs they are mostly unsourced, and so may not be trustworthy. Graeme Bartlett (talk) 11:20, 9 September 2025 (UTC)[reply]
Support: While this proposal may not yet be perfect, it represents an important and overdue step toward a long-needed capability in Wikidata. The lack of an explicit, structured property for IUPAC names has been a bottleneck for chemistry-related data integration for years. Passively waiting for a “miracle” or an ideal all-encompassing solution has only prolonged the absence of any workable approach. I agree that there are complexities around systematic nomenclature, qualifiers for method and recommendation version, and verification of correctness. However, these are not reasons to halt all progress — they are reasons to start with a manageable, “good enough” solution and refine it as community experience, tooling, and best practices develop. OPSIN validation and trusted sources like English Wikipedia’s preferred IUPAC names can already help filter obvious errors and ensure a reasonable level of quality. As with the recent work on remodelling P31 for chemical entities and the pending property for chemical formulas, incremental improvement is better than indefinite delay. Implementing this property now will create the infrastructure we need to capture, test, and refine data — and we can introduce qualifiers, constraints, and validation workflows over time. Let’s take the first step rather than wait for a perfect one. AdrianoRutz (talk) 08:55, 15 August 2025 (UTC)[reply]

Environmental science

greenhouse gases emissions

Under discussion

Description	amount of greenhouse effect emited by a given company
Represents	greenhouse gas emissions (Q106358009)
Data type	Quantity
Domain	enterprise (Q6881511)
Example 1	Lundin Energy (Q253423)-> 614 tonne of carbon dioxide equivalentstart time (P580)2023-01-01end time (P582)2023-12-31determination method or standard (P459)GHG Protocol (Q56296245)object of statement has role (P3831)Scope 2 market-based (Q124883330)
Example 2	Lundin Energy (Q253423)-> 13 tonne of carbon dioxide equivalentstart time (P580)2024-01-01end time (P582)2024-12-31determination method or standard (P459)GHG Protocol (Q56296245)object of statement has role (P3831)Scope 1 (Q124883250)
Example 3	Adani Group (Q4680631)->8.07636177449011000000 MtCO₂edetermination method or standard (P459)Carbon Majors: Methods & Results Report (Q136718415)
Allowed units	MtCO₂e (Q136718229), tonne of carbon dioxide equivalent (Q57084755), gigatonne of carbon dioxide equivalent (Q57084776)
Source	https://climateaccountability.org/wp-content/uploads/2020/12/MRR-9.1-Apr14R.pdf
Planned use	Wikidata:WikiProject Climate Change has a data model to represent greenhouse gases emissions according to the GHG protocol. However, the property currently used by this model is carbon footprint (P5991). Said property is currently used to represent both companies' greenhouse gases emissions and products' carbon footprints. Our proposal is to have two different properties for these two different concepts in order to make the distinction more evident to users who are not domain experts. We plan to migrate the statements that use carbon footprint (P5991) with qualifier determination method or standard (P459) = GHG Protocol (Q56296245) to this new property. Eventually, carbon footprint (P5991) will be used only for actual carbon footprint statements like this one. We will also use the new property to import data about oil companies' emissions from Carbon Majors
Wikidata project	WikiProject Climate change (Q15305047)

Motivation

It's relevant to document in Wikidata the impact that a given company or productive sector has had in climate change. This property is part of a project that aims to improve the data modelling for fossil fuel industries.

This property is not equivalent to carbon footprint (P5991). According to the literature on the topic, carbon footprint is not the correct way to measure greenhouse gasses emissions. Carbon footprint as a concept has no scientific background and has no standardized methodology behind it. Wiedmann, T., & Minx, J. (2) made this clear in one of the first reviews of the concept, pointing to the ambiguity in its definition and the limitations of the system as its biggest obstacle. It is an inherently inconsistent metric. Pandey et al. (3) offer another excellent review of the methodologies and their inconsistencies

In contrast, “GHG Emissions” is a robust, quantifiable, and globally standardized property, making it ideal for reproducible and reliable analysis. It can be traced back to a documented methodology of determination like GHG Protocol (1) with its 3 well-defined scopes.

(1) GHG Protocol Corporate Standard: https://ghgprotocol.org/corporate-standard
(2) Wiedmann, T., & Minx, J. (2008). A Definition of 'Carbon Footprint'. Ecological Economics, 7(1), 1-11. https://www.researchgate.net/publication/247152314_A_Definition_of_Carbon_Footprint
(3) Pandey, D., et al. (2011). Carbon footprint: current methods of estimation. Environmental Monitoring and Assessment. DOI: https://doi.org/10.1007/s10661-010-1678-y

– The preceding unsigned comment was added by Nat (WDU) (talk • contribs) at 10:08, November 6, 2025 (UTC). Edited by Nat (WDU) (talk) 14:11, 17 November 2025 (UTC)[reply]

Discussion

Comment This should have a unit associated with the numeric quantity - tonnes of CO2 or something like that? ArthurPSmith (talk) 16:33, 6 November 2025 (UTC)[reply]
Hello! carbonmajors.org report uses the unit MtCO₂e (Q136718229), I'd recommend using that one or other unit related to carbon dioxide equivalent (Q1933140). Nat (WDU) (talk) 15:47, 7 November 2025 (UTC)[reply]
@Nat (WDU) please add this clearly to the proposal (especially the examples) as this information is both what people see at a glance and what guides the property creator later. Ainali (talk) 08:26, 12 November 2025 (UTC)[reply]
Hello! edited the proposal to add the unit to the examples. Nat (WDU) (talk) 14:21, 17 November 2025 (UTC)[reply]
Comment We already have carbon footprint (P5991). Could you please clarify how this would be different from the existing property so that people will now when to use which one? Ainali (talk) 19:37, 7 November 2025 (UTC)[reply]
Also waiting for an answer on this since doesn't have any explanation. However, I think it's that carbon footprint (a misnomer btw since it's not just CO₂) is about total emissions caused by an individual, event, organisation, or product, expressed as carbon dioxide equivalent while greenhouse gases emissions is about emissions of a time-span like mainly a year, especially recent year(s). Prototyperspective (talk) 10:36, 10 November 2025 (UTC)[reply]
The way Wikidata:WikiProject Climate Change has modeled it, is with start and end dates (and scope and measuring method), and it has quite extensive use already. Ainali (talk) 16:57, 10 November 2025 (UTC)[reply]
It linked to section Emissions so I thought you were describing how they modeled emissions but not carbon footprint. Sorry about the ambiguous quote; the better one is Carbon footprints are usually reported in tonnes of emissions (CO2-equivalent) per unit of comparison. Such units can be for example tonnes CO2-eq per year, per kilogram of protein for consumption, per kilometer travelled, per piece of clothing and so forth. A product's carbon footprint includes the emissions for the entire life cycle. from Carbon footprint. I meant more that carbon footprint is usually the footprint irrespective of duration or time for some life-cycle (regardless how long production and consumption take). Greenhouse gas emissions is the less ambiguous, more specific term so I still support this property if somebody such as the proposer – probably via quickstatements – move all the carbon footprints that have a start and end date to this new property. A info could be added to carbon footprint that this new prop should be used when it's about emissions with a start and end time. Carbon footprint would be for all the remaining cases, especially (and maybe eventually limited to) product-lifecycle footprints etc. Prototyperspective (talk) 12:29, 11 November 2025 (UTC)[reply]
You make good points about the normal terminology, but as the proposal is written, not specifying that the values should be for emissions per year and qualified with which year, the data could be the same. I'll ~~Oppose~~ until the proposal and the examples have been clarified that the purpose is to be sufficiently different in practice and not just something that could be solved with an alias on the current property. Ainali (talk) 08:22, 12 November 2025 (UTC)[reply]

As the main property proposers, me and my colleagues can commit time to review the current items that are already using the previous property and to the extent possible harmonize it. Please be aware that this might not be possible with every single item, because of the methodological differences previously described, but we hope that moving forward in the future this will allow us a more accurate description of the problem. Nat (WDU) (talk) 14:30, 17 November 2025 (UTC)[reply]

Hello! Thanks for weighing in in the discussion! I've edited the motivation in the property proposal to back up my claim that the proposed property is not equivalent to carbon footprint (P5991) Nat (WDU) (talk) 14:28, 17 November 2025 (UTC)[reply]
Support for GHG emissions per year etc. Please import this data from somewhere, maybe Our World in Data. It would be most useful if it was very complete so one could query for example for main sources of emissions in a country (an issue is that one can't query embedded emissions due to mainly imports and another issue is that many needed items like 'Transport sector of Chile' may not yet exist). --Prototyperspective (talk) 10:39, 10 November 2025 (UTC)[reply]
Comment. Do we want yearly values to added to items, or to point to a separate data file, which would allow more detail, like breakdown by different gasses. The latter would be my preference. If the desire is to have a single equivalent MtCO₂e (Q136718229) value, the property name should be changed to reflect that. The examples need to be edited to remove spurious precision. Please indicate how many values are in the dataset, and whether it has retrospective values, and for how long. Vicarage (talk) 16:00, 10 November 2025 (UTC)[reply]
Comment Under planned use, further modeling than what is shown in the examples are implied. I would like that all the examples show the proposed best practice use of this property as that makes it easier to understand the thoughts behind this property proposal. Ainali (talk) 08:28, 12 November 2025 (UTC)[reply]
I note that the OP has been slightly active on WD since they made the proposal, but until they return and address the issues raised here, I Oppose as I'd rather not have a half-baked solution accepted. Vicarage (talk) 08:37, 15 November 2025 (UTC)[reply]
Thanks for weighing in in the discussion! I appreciate your engagement. There is an important amount of literature that backs this proposal, which requires some time compiling. I've updated the motivation section to back up my original claim that this property is not the same as carbon footprint (P5991), and I've added the measure units to the examples as requested.

Let me know if there are other doubts left to clarify, thanks! Nat (WDU) (talk) 14:38, 17 November 2025 (UTC)[reply]
@Nat (WDU) I am still a bit confused. It seems like you are mostly arguing against the English label (and forgetting about the aliases) of the current property. I say so, because if you had checked the data model used by Wikidata:WikiProject Climate Change, you would see that the current property is being used with qualifiers of GHG Protocol (Q56296245) and Scope 1 (Q124883250)-Scope 3 (Q124883309) (even including the 15 types of the latter). If this modeling wouldn't be proper, bringing up on the project page might be better than immediately jumping to a property proposal to get the opinions of the users interested in the WikiProject.

While you're back, please also update the examples in the proposal to reflect the modeling you are talking about in Intended use. You might find Template:Statement+ to be good for such detailed modeling (you can be inspired by previously mentioned data model). Ainali (talk) 16:21, 17 November 2025 (UTC)[reply]
Hello @Ainali, seeing the way in which is being used, the property is a mess. Life cycle assessments and emissions according to the GHG Protocol are too very different things, they need separate properties. Scann (WDU) (talk) 19:09, 21 November 2025 (UTC)[reply]
@Scann (WDU) Here is perhaps a more useful query that is taking advantage of the scopes: https://w.wiki/GDTh

No mess there. Ainali (talk) 19:41, 21 November 2025 (UTC)[reply]
I don't see how a better query solves all of what has already been argued on the lack of precision of the terminology or the fact that is indeed being used for two very different things. Scann (WDU) (talk) 12:40, 24 November 2025 (UTC)[reply]
We have plenty of properties that are purposely vague in the description and use a huge number of aliases to make them findable as they can be used to model many things, and this is an example of where that is already the case. And it is still useful as it is possible to query for whichever of the meanings one is looking for. My whole point is that we don't need a new property to be able to model what you want to achieve because WikiProject Climate Change has already established a perfectly functional data model for this use case. Ainali (talk) 19:48, 24 November 2025 (UTC)[reply]
Hello @Ainali, ok, maybe I haven't been clear enough. The problem is not that the name of the property is vague, the problem is that the term is wrong and the scientific literature does not consider "carbon footprint" to be scientifically acurate as a measurement for GHG emissions. This is a bogus term invented by the fossil fuel industry, not a scientific standardized way of measurement. Scann (WDU) (talk) 17:47, 9 December 2025 (UTC)[reply]

You've not addressed whether data files are better than WD statements, nor the spurious precision in your examples. Vicarage (talk) 19:26, 21 November 2025 (UTC)[reply]
No response to my concerns, so Oppose as I said above. Vicarage (talk) 23:14, 19 December 2025 (UTC)[reply]
Hello! Sorry I was still working on my response. I don't believe data files are a good choice for this, since it would be important for us to be able to query on GHG emissions. Statements like this are already being used only that with an (in our team's opinion) an incorrect property. Nat (WDU) (talk) 23:27, 19 December 2025 (UTC)[reply]
Comment Hello, @Ainali, @Prototyperspective! I've updated the planned used and examples after our discussion, and also taking into consideration the extensive use of carbon footprint (P5991) as per Wikiproject climate change's model. Let me know what you think. I apologize in advance since the next 3 weeks I will have limited availavility to be online and follow up on the discussion. Thanks so much for taking time to think about this and weight in.
Support Okay, I can now see how the property is intended to be used. While this does overlap with the current use of carbon footprint (P5991) it makes sense to split this to a separate property for clearer semantic meaning. This also means that all current use of this type, and the data model on WikiProject Climate Change needs to be updated. When approved, we need to make a to-do list for statements to be moved. Ainali (talk) 08:19, 20 December 2025 (UTC)[reply]
- Daniel Mietchen (talk) 23:35, 2 October 2019 (UTC) Blue Rasberry (talk) 19:18, 4 October 2019 (UTC) Bodhisattwa (talk) 07:30, 7 October 2019 (UTC) Ainali (talk) 15:33, 7 October 2019 (UTC) MartinPoulter (talk) 14:24, 8 October 2019 (UTC) author TomT0m / talk page 12:01, 27 October 2019 (UTC) Rajeeb ^(talk!) 15:17, 29 November 2019 (UTC) John Samuel (talk) 18:12, 8 December 2019 (UTC) Pauljmackay (talk) 07:56, 31 December 2021 (UTC) Zblace (talk) 05:23, 23 June 2022 (UTC) Bukky658 (talk) 08:31, 28 January 2023 (UTC) Guettarda (talk) 16:32, 31 January 2023 (UTC) Dsp13 (talk) 11:50, 9 July 2023 (UTC) 168.5.41.197 17:33, 28 September 2023 (UTC) Lupe (talk) 15:25, 21 October 2023 (UTC) Guettarda (talk) 02:38, 19 March 2024 (UTC) Samoasambia ✎ 09:49, 8 April 2024 (UTC) Marsupium (talk) 23:19, 1 May 2024 (UTC) Manojk (talk) 17:09, 19 September 2025 (UTC)[reply]
  Notified participants of WikiProject Climate Change for awareness. Ainali (talk) 08:19, 20 December 2025 (UTC)[reply]

Medicine

Please visit Wikidata:WikiProject Medicine for more information. To notify participants use {{Ping project|Medicine}}

‎role in naming

Not done

Description	the role the namesake played in relation to this item, i.e. why the item is named after the namesake
Data type	Item
Domain	named after (P138)
Example 1	amyotrophic lateral sclerosis (Q206901)named after (P138)Lou Gehrig (Q357444)role in namingpatient (Q181600)
Example 2	amyotrophic lateral sclerosis (Q206901)named after (P138)Jean-Martin Charcot (Q20710)role in namingdiscoverer (Q1344452)
Example 3	Anne Dean Turk Fine Arts Center (Q135198272)named after (P138)Anne Dean Turkrole in namingemployee (Q703534)

Motivation

I thought it might be interesting to differentiate between medical conditions named after their discoverers and medical conditions named after prominent patients. Indeed, the relationship to a namesake can have many forms (e.g. museums named after founders vs. patrons vs. royalty vs. politicians vs. notable employees).

There is an open question as to whether the data type should be Item or Property, as relationships to namesakes can be expressed as both a concept (e.g. patient (Q181600)) or a property (e.g. medical condition (P1050)).

~~WhiteTimberwolf (talk) 11:18, 15 November 2025 (UTC)[reply]

Discussion

Oppose: object of statement has role (P3831) exists for this purpose. Swpb (talk) 17:33, 17 November 2025 (UTC)[reply]
Oppose I agree P3831 is good for this purpose. ChristianKl ❪✉❫ 22:20, 17 November 2025 (UTC)[reply]

Not done Midleading (talk) 10:06, 15 January 2026 (UTC)[reply]

Mineralogy

Please visit Wikidata:WikiProject Mineralogy for more information. To notify participants use {{Ping project|Mineralogy}}

Computer science

Please visit Wikidata:WikiProject Informatics for more information. To notify participants use {{Ping project|Informatics}}

Geology

Please visit Wikidata:WikiProject Geology for more information.

Geography

‎SOIUSA code

Under discussion

Description	Identifier of mountains, summits, mountain groups, etc. according to the International Standardized Mountain Subdivision of the Alps (SOIUSA)
Represents	SOIUSA code (Q1628678)
Data type	External identifier
Template parameter	codice in it:template:Montagna
Domain	mountain, summits, mountain groups: summit (Q207326), mountain (Q8502), ridge (Q740445), ridge section (Q131521567), arête (Q1334383), back of a mountain (Q820144), mountain shoulder (Q15787792), ranks of the SOIUSA taxonomy: alpine main part (Q131311255), alpine major sector (Q3775635), alpine section (Q3958626), sector of alpine section (Q3958438), alpine subsection (Q3965305), sector of alpine subsection (Q3958440), alpine supergroup (Q3977906), sector of alpine supergroup (Q3958437), alpine group (Q3777462), sector of alpine group (Q131604769), alpine subgroup (Q514999), sector of alpine subgroup (Q3958436)
Example 1	Punta Sommeiller (Q2279001) → I/A-4.III-B.6.b
Example 2	Hochgrat (Q459121) → II/B-22.II-B.5.b
Example 3	Winterstaude (Q2585140) → II/B-22.I-B.6.b
Example 4	Übelhorn (Q130718862) → II/B-22.II-D.12.a/b
Allowed values	[I\|II](/[A-C](-[1-36](/[A-B])?(\.[I\|II\|III\|IV\|V\|VI\|VII\|VIII](/[A-B])?(-[A-F](/[a-z])?(\.[1-22](/[a-z])?(\.[a-z](/[a-z])?)?)?)?)?)?)?
Source	https://it.wikipedia.org/wiki/Suddivisione_Orografica_Internazionale_Unificata_del_Sistema_Alpino
Planned use	Indification where different geographic features of the Alps (mountains, summits, groups on different levels, sections, sectors, parts) belong from an orographic perspective
Number of IDs in source	3498 (2 main parts + 5 major sectors + 36 sections + 132 subsections + 333 supergroups + 870 groups + 1625 subgroups + 31 sectors of sections + 30 sectors of subsections + 18 sectors of supergroups + 7 sectors of groups + 409 sectors of subgroups)
Expected completeness	eventually complete (Q21873974)
Single-value constraint	yes

Motivation

The IDs are already used to a certain extend by different Wikimedia projects in articles on mountain ranges and mountains of the Alps. Due to their hierarchical structure, they are useful to locate a summit or mountain in its closer or wider context. They can also support the identification of duplicates as well as to distinguish different summits/mountains that have the same name since the likelihood of two mountains or summits with the same name being located in the exact same alpine subgroup is low and therefore it is unlikely that two mountain features with the same name have the same SOIUSA code.

-- Harald Hetzner – The preceding undated comment was added at 20:00, 29 December 2024.

Discussion

Support, if restricted to the ranks of the SOIUSA taxonomy (as listed above), Oppose, if also intended for features like mountain (Q8502) (it is not a property of an individual mountain, but of the hierarchical embedding). The examples above all are mountains and do not match the use as I would restrict it. (see also User_talk:Herzi_Pinki#Property_Proposal_zu_SOIUSA-Code (German)). Don't see how this property supports the identification of duplicates as well as helps to distinguish different summits/mountains that have the same name (uniqueness is created by (label, description) pairs and putting such IDs to the description seems to be a bad idea). best --Herzi Pinki (talk) 12:01, 5 January 2025 (UTC)[reply]

As pointed out in the motivation, as the SOIUSA code only locates a mountain in an alpine subgroup or a sector thereof, it is not a unique identifier and therefore not a certain criterion to identify a duplicate. However, since subgroups or sectors thereof (ridge, small massif) are comparatively small mountain areas, the likelihood of two mountains or summits with the same name having the same SOIUSA code is low.

Further, having a property for this specific code is meant to provide a dedicated place that will ensure that SOIUSA codes will not need to be added to item descriptions to somehow store them.

The huge advantage of a dedicated property is that there is a straightforward way how to retrieve a SOIUSA code, e.g. in SPARQL queries. Due to its hierarchically structure, the SOIUSA code allows to compare e.g. the code of a mountain, which encodes all hierarchy levels down to its subgroup or a sector thereof, with any level of the SOIUSA taxonomy of the Alps. From my perspective, with the various unstructured ways how mountain range (P4552)} and part of (P361) are used it would not be possible to conclude on the entry point into the SOIUSA hierarchy based on these properties. -- Harald Hetzner (talk) 21:42, 5 January 2025 (UTC)[reply]

Discharge regime

Under discussion

Description	The discharge regime can be Glacial, Nival or Pluvial. It can be a combination of 2 : Nivo-pluvial, Pluvio-nival, Nivo-glacial, etc. Be specific (e.g. pluvial tropical, meridional, etc.). Or be complex
Represents	river regime (Q320072)
Data type	String
Template parameter	"régime" in fr:Modèle:Infobox Cours d'eau
Domain	propriété
Example 1	Angara (Q162737)→mixed river (Q60061427)
Example 2	Cooum River (Q1129931)→Pluvial tropical at monsoon
Example 3	Arc (Q631028)→rain river (Q1986504) and Arc (Q631028)→Q3455073
Planned use	To add in fr:Modèle:Infobox Cours d'eau and fr:Module:Infobox/Rivière
Wikidata project	Q15647699

Motivation

To complete the description in the infoboxes. – The preceding unsigned comment was added by Borvan53 (talk • contribs) at 07:45, December 2, 2025 (UTC).

Discussion

@Borvan53: "discharge" does not seem the right label for this - you are referring to the incoming source for a river, not the eventual outgoing discharge? Do you have some more references? Also your wikiproject link isn't a wikiproject, it seems to be a portal? But maybe that's ok? ArthurPSmith (talk) 21:27, 8 December 2025 (UTC)[reply]
Ah, following the frwiki link I see the wikidata item in question is river regime (Q320072) - so I think "river regime" would be the preferred English label for this. The discussion in enwiki seems confused, or maybe I'm just not familiar with the terminology. Anyway this does seem a useful concept, so Support with clarified label/description (the description has to be plain text, not wikitext, by the way). ArthurPSmith (talk) 21:34, 8 December 2025 (UTC)[reply]

Linguistics

Please visit Wikidata:WikiProject Linguistics for more information. To notify participants use {{Ping project|Linguistics}}

Mathematics

Please visit Wikidata:WikiProject Mathematics for more information. To notify participants use {{Ping project|Mathematics}}

underlying data

Under discussion

Description	this mathematical structure has these data as part
Data type	Item
Example 1	totally ordered set (Q3054922)underlying dataset (Q36161)
Example 2	totally ordered set (Q3054922)underlying datatotal order (Q369377)
Example 3	group (Q83478)underlying dataset (Q36161)
Example 4	group (Q83478)underlying databinary operation (Q164307)statement is subject of (P805)group operation (Q99839939)
Example 5	group (Q83478)underlying datanullary operation (Q3884029)statement is subject of (P805)identity element (Q185813)
Example 6	group (Q83478)underlying dataunary operation (Q657596)statement is subject of (P805)inverse element (Q338057)

Motivation

This is a property lying between underlying structure(s) (P12322) and has part(s) (P527). underlying structure(s) (P12322) is a stronger property in that it has to reflect (the object part of) a w:faithful functor between appropriate categories. I propose this property because there is now use of this stronger property to mean this weaker property. 慈居 (talk) 16:47, 2 May 2025 (UTC)[reply]

Discussion

@Charp238, I hope you like it! 慈居 (talk) 16:53, 2 May 2025 (UTC)[reply]

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha
John Samuel
Jeremy Dover
Toni 001
Bocardodarapti
Duckmather
HTinC23
fgnievinski
Paul-Olivier Dehaye
uni
Dexxor
慈居
 IntensionalLogican
VictorAyabe
Notified participants of WikiProject Mathematics --Dexxor (talk) 15:34, 5 May 2025 (UTC)[reply]

why not just use has part(s) (P527)? not saying that this has no use but so far it seems a bit dubious to me Uniwah (talk) 17:58, 5 May 2025 (UTC)[reply]

@Uniwah. Thank you for the comment. The reason that I want to refine has part(s) (P527) is that it does not indicate "has part in what sense". "Has part" for a mathematical concept as subject can also mean, say,

a term has a sense (as in Q21199#P527)
a structure has "defining data" (which is standard terminology of mathematics, by the way; the definition of a mathematical concept is typically phrased as "a ... consists of the following data ... satisfying the following conditions ...", and the terms "defining data", "underlying data", etc. are used explicitly throughout mathematical literature; see Mac Lane's Categories for the Working Mathematician for use of "data"; use of other terms is verifiable by google search)
a particular structure has these paticular underlying data (e.g., a 2-category has these as 0-cells, 1-cells or 2-cells)
(edited) notable substructures of structures (e.g., subset of a set, subgroup of a group, etc.)
logical conjunction of some of the above (which is a bad practice, I believe)

Currently I use object of statement has role (P3831) as qualifier to distinguish these meanings but I doubt this is the best practice. 慈居 (talk) 00:30, 6 May 2025 (UTC)[reply]

I'm struggling to see the point of this at the moment. If this is going to be useful, it needs to be absolutely rigorously defined, together with proposed properties for each of the other usages you give, and at the moment I think this is still too wooly. Using object of statement has role (P3831) qualifers on has part(s) (P527) seems like a simple and clear way to implement what you want that doesn't obscure the meaning for more simple-minded users. The Anome (talk) 07:21, 6 May 2025 (UTC)[reply]
- @The Anome Thank you for the comment. (edit: I rephrase my comment, to be brief.) The definitions of the usages of has part(s) (P527) are as follows:
  - A term has a sense: this is a non-mathematical property and has no rigorous definition.
  - A structure has "underlying/defining data": a class of structures ${\mathcal {S}}$ has the class of structures ${\mathcal {D}}$ as underlying data if there exists classes of structures ${\mathcal {D}}_{1},\dots ,{\mathcal {D}}_{m}$ , predicates $P_{1},\dots ,P_{n}$ and $i=1,\dots ,m$ such that $\forall S\colon S\in {\mathcal {S}}\iff (\exists D_{j}\in {\mathcal {D}}_{j}(i=1,\dots ,m)\colon S=(D_{1},\dots ,D_{m})\land (\forall k=1,\dots ,n\colon P_{k}(D_{1},\dots ,D_{m}))\land D=D_{i})$ .
  - A particular structure has these paticular underlying data: suppose ${\mathcal {S}}$ has ${\mathcal {D}}$ as underlying data; then $S\in {\mathcal {S}}$ has $D\in {\mathcal {D}}$ as underlying ${\mathcal {D}}$ -data if $S=(\dots ,D,\dots )$ .
  - (edited) notable substructures of structures: there is no definition of substructures which applies to all structures; there are canonical notion of substructures for particular classes of structures (algebraic substructure for universal algebraic structures, subspaces for topological spaces, submanifolds for ${\mathcal {C}}^{\infty }$ -manifolds, etc.)
  - underlying structure: ${\mathcal {S}}$ has ${\mathcal {D}}$ as underlying structure if ${\mathcal {S}}$ and ${\mathcal {D}}$ are categories (in a canonical way) and there exists a (canonical) faithful functor ${\mathcal {S}}\to {\mathcal {D}}$ ; if ${\mathcal {S}}$ has ${\mathcal {D}}$ as underlying structure then ${\mathcal {S}}$ has ${\mathcal {D}}$ as underlying data; not conversely.
- I'd strongly suggest making these qualifiers, not properties. We can then add a constraint that mathematical object "part-of" relationships should have one (can there be more than one?) of these properties. The Anome (talk) 17:17, 6 May 2025 (UTC)[reply]
  - Yes, there can be more than one; in my opinion qualifiers are better added to separate statements (with the same value) in that case. To clarify, I have listed these usages to explain what has-part can mean in mathematical context; the only one I want a new property for is the underlying-data one. I prefer a new property for this one because there are potentially many properties derived from this one. For example, redundancy of defining data, cf. here. A property for combination of data enough to completely determine the structure, might need an item-requires-statement constraint (Q21503247) which does not work for qualifiers, as far as I know. 慈居 (talk) 17:57, 6 May 2025 (UTC)[reply]

base mathematical structure

Under discussion

Description	base field of this vector space, base ring of this module, pair of base rings for this bimodule, base monoidal category of this enriched category, etc.
Data type	Item
Example 1	abelian group (Q181296)base mathematical structureinteger (Q12503)subject has role (P2868)module (Q18848)object of statement has role (P3831)base ring (Q121217200)
Example 2	quaternionic vector space (Q7269568)base mathematical structurequaternion (Q173853)subject has role (P2868)vector space (Q125977)object of statement has role (P3831)field of scalars (Q99240496)
Example 3	preadditive category (Q2099981)base mathematical structureabelian group (Q181296)subject has role (P2868)enriched category (Q5379515)object of statement has role (P3831)base monoidal category (Q134486094)
Example 4	topological category (Q7825022)base mathematical structurecompactly generated space (Q1738274)subject has role (P2868)enriched category (Q5379515)object of statement has role (P3831)base monoidal category (Q134486094)

Motivation

This property indicates which ring a module is over, which pair of rings a bimodule is over, which monoidal category an enriched category is over, etc, with label "over" chosen among standard wordings. Note that, for instacne, a "module over $R$ " is also phrased as an " $R$ -module", and I prefer that wording, but it doesn't seem applicable to a Wikidata statement anyway.

Note also that this property is to replace the deprecated property P642 (P642) which is previously used for these purposes. 慈居 (talk)

(Edit history: previous label was over; previously proposed as qualifier property.)

Discussion

Notified participants of WikiProject Mathematics

Comment I think the English label should be more descriptive than "over" to avoid misuse. -wd-Ryan (Talk/Edits) 16:29, 15 May 2025 (UTC)[reply]
@Wd-Ryan The best I can think of is "base mathematical structure" (?). Any suggestion will be appreciated! 慈居 (talk) 08:34, 17 May 2025 (UTC)[reply]
Comment I think I would prefer a relationship like this to be a main value, not a qualifier on subclass of (P279). ArthurPSmith (talk) 18:56, 15 May 2025 (UTC)[reply]
@ArthurPSmith No problem with that with change of label. This can be made a main value property unless confusion arises (perhaps when talking about something like ${\mathcal {M}}$ -module ${\mathcal {V}}$ -category?). 慈居 (talk) 08:20, 17 May 2025 (UTC)[reply]

covers

Under discussion

Description	this item is a paving or partition of this space or set
Aliases	covers, tesselates
Data type	Item
Domain	tessellation (Q214856)
Example 1	square tiling (Q1128619)→Euclidean plane (Q3391320)
Example 2	sphere tesselation (Q97367344)→spherical polyhedron (Q2785034)
Example 3	Penrose tiling (Q585688)→Euclidean plane (Q3391320)
Allowed values	tessellation (Q214856), graph (Q141488), space (Q472971), set (Q36161)
Wikidata project	WikiProject Mathematics (Q8487137)

Motivation

Notified participants of WikiProject Mathematics

Defining property for coverings or tesselations, graph partitions … author TomT0m / talk page 09:41, 16 June 2025 (UTC)[reply]

Discussion

Comment I would prefer the name "tesselates" to avoid confusion with common uses of the word "cover", like blanket (Q5852) or mobile phone case (Q10587165). -wd-Ryan (Talk/Edits) 16:35, 16 June 2025 (UTC)[reply]
I'd prefer "covers" as label and "tesselates" as alias. "Covers" applies to all tesselations, "tesselates" does not apply to all covers. 慈居 (talk) 22:59, 26 June 2025 (UTC)[reply]
@Wd-Ryan, would you like to give your opinion? Regards, ZI Jony ^(Talk) 17:37, 7 December 2025 (UTC)[reply]
I don't know anything about the subject so I can't suggest a better label with confidence, but the current one is vague to me and I think it would often be used incorrectly. Maybe "covers space" since both of the example values are subclasses of space (Q472971)? Feel free to proceed without my opinion as I'm not an expert. -wd-Ryan (Talk/Edits) 19:22, 7 December 2025 (UTC)[reply]
I agree this label will likely lead to misuse and confusion. "covers space" seems logical to me. Or "mathematically covers" maybe? ArthurPSmith (talk) 21:53, 8 December 2025 (UTC)[reply]

The standard ways to put this ("covers" or "is a cover of") are indeed ambibuous, but in my opinion should be kept. So perhaps "covers (in mathematics)" will be fine. 慈居 (talk) 19:52, 9 December 2025 (UTC)[reply]
TomT0m, could you please response comments above. Regards, ZI Jony ^(Talk) 16:40, 10 December 2025 (UTC)[reply]
No strong opinion about the naming, anyway it can be changed later. Descriptions are here for disambiguation anyway, same for labels, and constraints are there to sort out any ambiguities also, so …

Also this term is used in english, for example set cover problem (Q1192100)   the set covering problem. But digging a bit more for ideas I find that "partitions" or "is a partition of" is a good fit too.

always weird to me to see the english label naming is a blocker for a creation ? Is there any case where the initial labeling of a property has caused major problems ? Should it be a blocker ? author TomT0m / talk page 17:55, 10 December 2025 (UTC)[reply]
Support. 慈居 (talk) 22:57, 26 June 2025 (UTC)[reply]
Comment Can you remove Example 3? The Vitali set does not cover the unit interval. 慈居 (talk) 00:28, 27 June 2025 (UTC)[reply]

‎algebraic closure

Under discussion

Description	‎algebraic closure of this field
Represents	algebraic closure (Q428290)
Data type	Item
Domain	mathematical structure (Q748349)
Example 1	field of real numbers (Q135524587)algebraic closurefield of complex numbers (Q18192650)
Example 2	field of rational numbers (Q6585992)algebraic closurefield of algebraic numbers (Q135524598)
Example 3	F₂ (Q5513324)algebraic closurealgebraic closure of 𝔽₂ (Q135524517)
Example 4	field of complex numbers (Q18192650)algebraic closurefield of complex numbers (Q18192650)
Allowed values	mathematical structure (Q748349)
Single-value constraint	yes
Wikidata project	WikiProject Mathematics (Q8487137)

‎real closure

Under discussion

Description	real closure of this formally real field
Represents	real closure (Q136347235)
Data type	Item
Domain	mathematical structure (Q748349)
Example 1	field of real numbers (Q135524587)real closurefield of real numbers (Q135524587)
Example 2	field of rational numbers (Q6585992)real closurefield of algebraic real numbers (Q135524734)
Example 3	field of hyperreal numbers (Q135524982)real closurefield of hyperreal numbers (Q135524982)
Allowed values	mathematical structure (Q748349)
Single-value constraint	yes
Wikidata project	WikiProject Mathematics (Q8487137)

Motivation

慈居 (talk) 04:19, 31 July 2025 (UTC)[reply]

Discussion

Support the first (algebraic), but not sure we need the second (real) - algebraic closure of a field seems a much more general thing. How many fields are there for which the real closure would apply? Also shouldn't we use set of real numbers (Q1174982) (declared to be an instance of a field) instead of creating new items like field of real numbers (Q135524587)? I don't think small mathematical distinctions should result in additional Wikidata items... ArthurPSmith (talk) 17:03, 31 July 2025 (UTC)[reply]
@ArthurPSmith, thanks for your comment! Not many for now (not more than ten), I'd say, even for algebraic closure. That said, if someone are willing to create instances of finite field (Q603880) and real quadratic extension (of which there are infinitely many), then we'll have more items to apply these two properties, respectively.

I believe set of real numbers (Q1174982) and field of real numbers (Q135524587) are different things, in that the former can have various field structures, whereas the latter has a unique one fixed among them. However, the ring of real numbers is the same thing as the field of real numbers, since being a field is an "extra property" rather than an "extra structure". An nLab article has a good explanation on the distinction of extra property and structure. 慈居 (talk) 01:09, 1 August 2025 (UTC)[reply]
Do you mind filling out the rest of the proposal? This is pretty empty @慈居: --Trade (talk) 02:46, 22 September 2025 (UTC)[reply]
Done. 慈居 (talk) 03:29, 22 September 2025 (UTC)[reply]
@Trade, would you like to give your opinion? Regards, ZI Jony ^(Talk) 17:50, 7 December 2025 (UTC)[reply]
NeutralI am not knowledgeable enough about the subject to have an opinion--Trade (talk) 17:54, 7 December 2025 (UTC)[reply]

‎Erdős Problem number

Ready ^Create

Description	Erdős Problem number
Data type	External identifier
Example 1	Erdős–Ulam problem (Q27999391) -> 212
Example 2	Erdős conjecture on arithmetic progressions (Q1991239) -> 3
Example 3	Happy Ending problem (Q1033772) -> 107
Formatter URL	https://www.erdosproblems.com/$1

Motivation

There is a website devoted to collecting Erdős Problems and giving each a unique number. Recently there has also been an effort organised by Terence Tao to record the links between each of those problems and any integer sequence that is relevant to it. The system used for indexing the integer sequences is OEIS, which already exists in Wikidata as Property:P829. It would be helpful to that effort and to mathematicians generally if the links between sequences and problems could be explored using the tools that Wikidata makes available, and this could also be a useful test case for building other structures that help automate searches through the accumulated corpus of mathematical literature. (This proposal for an Erdős Problem number should not be confused with Property:P2021 which is the Erdős collaboration distance number.)

– The preceding unsigned comment was added by ~2025-43552-15 (talk • contribs) at 15:02, December 28, 2025 (UTC).

Discussion

It's worth noting that, for example, Erdős Problem Number 11 is listed as being related to OEIS A001220, which is the sequence of Wieferich primes. The relevant Wikidata item is "Wieferich prime" (Q966601), and it includes A001220 as the relevant OEIS ID, under the Identifiers section. If this proposal is accepted, then Erdős Problem Number would be another available identifier, with a value of 11 in this case. I don't expect all Erdős Problems to already exist within Wikidata, and it may not be worth importing them all, but for any item in Wikidata which does have a relevant OEIS ID with an associated Erdős Problem, it would be valuable to be able to record that connection. – The preceding unsigned comment was added by ~2025-43552-15 (talk • contribs) at 2025-12-28T13:35:15 (UTC). --Tinker Bell ★ ♥ 19:47, 28 December 2025 (UTC)[reply]

Support. 慈居 (talk) 02:13, 3 January 2026 (UTC)[reply]
Comment @~2025-43552-15: I have altered the datatype in your proposal as this seems to be an external id value. However, we need to clarify the property examples - they should link a wikidata item (for example Erdős–Ulam problem (Q27999391)) with the id value. Please look at other proposals to see how this is done in the template. It is also not clear to me how this allows you to connect the problems with the related integer sequences (if any) - what you want to do may require two different property proposals. ArthurPSmith (talk) 17:10, 3 January 2026 (UTC)[reply]
Comment. The problem #11 describes a problem "closely related to" the Wieferich primes. Examples should be exact matches. 慈居 (talk) 14:22, 4 January 2026 (UTC)[reply]
@慈居: It looks like the proposal has been corrected, do you think this is ready now? ArthurPSmith (talk) 20:24, 5 January 2026 (UTC)[reply]
Yes, I do. Thank you for reminding me! 慈居 (talk) 20:47, 5 January 2026 (UTC)[reply]
Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha
John Samuel
Jeremy Dover
Toni 001
Bocardodarapti
Duckmather
HTinC23
fgnievinski
Paul-Olivier Dehaye
uni
Dexxor
慈居
 IntensionalLogican
VictorAyabe
Notified participants of WikiProject Mathematics

Material

Please visit Wikidata:WikiProject Materials for more information. To notify participants use {{Ping project|Materials}}

Meteorology

Beaufort scale max

Under discussion

Description	empirical measure describing wind speed based on observed conditions
Aliases	Beaufort, Bf
Represents	wind (Q8094)
Data type	Item
Template parameter	WikiProject Weather observations
Example 1	Cyclone Lothar (Q520286)→whole gale (Q12714822)
Example 2	Q104601398→hurricane force storm (Q20918044)
Example 3	Cyclone Xynthia (Q926626)→hurricane force storm (Q20918044)
Wikidata project	WikiProject General meteorology (Q14943918)

Motivation

(Ajoutez ici vos motivations pour la création de cette propriété et votre signature) – The preceding unsigned comment was added by Bouzinac (talk • contribs) at 16:16, May 3, 2025 (UTC).

Discussion

The property name needs to indicate its recording the peak wind speed for the event. While strictly the Beaufort scale is a number, I can see the merits of linking to the named values on the scale, but the property would need advice on the SPARQL logic to deduce one from the other, as sorting items would be done numerically. How would you handle the values 13-17 on the extended Beaufort scale? How would you prevent people entering storm (Q81054) rather than the correct whole gale (Q12714822). At the same time it would be good to add the speed ranges to each Beaufort value, as they are currently missing.Vicarage (talk) 17:02, 5 May 2025 (UTC)[reply]

That property would have something like in this https://www.wikidata.org/wiki/Property:P8615#P2302 in order to make sure correct items are entered. I don't know how to make Q12714822 ranking 10th on Beaufort scale (to help for the sorting in the queries). Bouzinac ^{💬●✒️●💛} 16:10, 8 May 2025 (UTC)[reply]

Glaciology

All

‎GBIF ID

Under discussion

Description	identifier for an occurrence record in the Global Biodiversity Information Facility (Q1531570)
Data type	External identifier
Example 1	holotype of Mecodema haunoho (Q136831989)→1315627641
Example 2	holotype of Asaphodes ida (Q136936057)→3323009351
Example 3	holotype of Izatha acmonias (Q136832210)→131563547
Allowed values	item, type specimen (Q51255340), herbarium specimen (Q61726742), biological specimen (Q2075980), botanical specimen (Q120431565), zoological specimen (Q2114846), fossil (Q40614), specimen (Q85869058)
Allowed units	String of numbers representing a GBIF identifier resolving to an occurrence record
Source	https://www.gbif.org/
Planned use	My hope is to integrate this into holotype data contributed by museum and research institutions, additionally this will be helpful for the BHL Wikidata project
Expected completeness	always incomplete (Q21873886)
Formatter URL	https://www.gbif.org/occurrence/$1
See also	GBIF taxon ID (P846)
Single-value constraint	yes
Distinct-values constraint	yes
Wikidata project	https://www.wikidata.org/wiki/Wikidata:WikiProject_Natural_History_Specimen_Data_Model https://www.wikidata.org/wiki/Wikidata:WikiProject_Taxonomy https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_BHL

Motivation

GBIF is a global website that aggregates records about individual specimens and observations from many institutions. Each GBIF occurrence record has a unique GBIF record number (the digits at the end of a URL like https://www.gbif.org/occurrence/5871964409). Similar in spirit to other identifiers for platforms with the same content, ie; Flickr photo ID (P12120).

This proposal adds a dedicated external identifier property to store just the GBIF record number, while Wikidata can still generate the clickable link automatically using the formatter URL. That follows the same pattern Wikidata uses for many other database identifiers, and it makes it easier to reliably connect the same specimen/observation record across Wikidata, GBIF, and other platforms.

This property would be used in lieu of the current convention which is to include a link to the GBIF occurrence record via described at URL (P973) and then extract the GBIF ID from the tail of this URL.

I am hoping to propose this property in a continuation of the fleshing out a specimen data model that aligns with DarwinCore ontologies for the description of natural science data within SDC and in Wikidata items.

Please note that this is a distinct and different proposal to the prior property proposal for GBIF Occurrence ID (see: https://www.wikidata.org/wiki/Wikidata:Property_proposal/GBIF_occurrence_ID). While GBIF Occurrence IDs are important in literature, and have valid usage within the Natural Sciences community, the GBIF ID is relevant in Wikidata as a persistent identifier that associates digital twins of a specimen across different platforms hosting scientific knowledge. Should there be demand in the future for the addition of GBIF Occurrence ID as a property to also be included within the specimen data, we would be interested in supporting that proposal.

Ngā mihi, Dactylantha (talk) 21:36, 17 December 2025 (UTC)[reply]

Discussion

Support - I support this proposal as this identifier ties in with work I'm undertaking at the Manaaki Whenua - Landcare Research group of the New Zealand Bioeconomy Science Institute to create Wikidata items for holotype specimens held at that institutions natural history collections. Ambrosia10 (talk) 21:48, 17 December 2025 (UTC)[reply]
I'm not 100% sure about the description of what this is. Can you try to rephrase the explanation more clearly with less biology-specific jargon? Imagine you're explaining it to a MBA whose only knowledge of biology is that pork bellies are somehow related to pigs. Stuartyeates (talk) 21:59, 17 December 2025 (UTC)[reply]
Support - maybe rename to "GBIF specimen ID" to differentiate from GBIF taxon ID (P846) and "GBIF Occurrence ID" which includes both specimens and observations. --Bamyers99 (talk) 17:18, 22 December 2025 (UTC)[reply]

Nutrition