Wikidata:Property proposal/Natural science

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

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.
Do not use the Visual editor, because it will mess up the content of your request (the order of the template parameters will be shuffled and paragraphs are concatenated as one long string of text).

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See property creation policy.

  On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2022/05.



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}}

Nextstrain identifierEdit

   Under discussion
DescriptionIdentifier for a virus clade used by the Nextstrain project
Data typeString
Domainvirus (Q808)
Example 1SARS-CoV-2 Omicron variant (Q109739412) → 21K
Example 2SARS-CoV-2 Alpha variant (Q104376647) → 20I (V1)
Example 3SARS-CoV-2 Delta variant (Q107055182) → 21A, 21I, 21J
Example 4SARS-CoV-2 Gamma variant (Q104819269) → 20J (V3)
SourceNextstrain (Q89296216)
Expected completenessalways incomplete (Q21873886)
See alsoPANGO lineage code (P9632)
Wikidata projectWikiProject Taxonomy (Q8503033), WikiProject Medicine (Q4099686)


Nextstrain ( is a system for promoting the rapid sharing of virus data, including for influenza and SARS-CoV-2 viruses. It assigns identifiers for individual virus clades. It is complementary to systems such as PANGOLIN and GISAID. -- The Anome (talk) 10:02, 27 November 2021 (UTC)


  WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. This would be very useful right now, as tracking SARS-Cov-2 variants is a live subject right now; this can also be extended to tracking other infectious virus clades, per the Nextstrain mission statement. -- The Anome (talk) 10:02, 27 November 2021 (UTC)

  WikiProject Medicine has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Since no-one in the Taxonomy group has yet commented here, I thought I'd bring this to the attention of the Medicine WikiProject. Any comments very welcome. -- The Anome (talk) 00:22, 29 November 2021 (UTC)

I think it's better use an external identifier with this formatter URL: Germartin1 (talk) 23:08, 3 December 2021 (UTC)

  Weak oppose From the examples it seems the property currently only includes the last part of groups/neherlab/ncov/21I.Delta, so it seems specific to something called "neherlab" and COVID-19, not a general property for viruses. --Haansn08 (talk) 02:31, 13 December 2021 (UTC)

TiagoLubiana 01:35, 16 March 2020 (UTC)
Daniel Mietchen 01:42, 16 March 2020 (UTC)
Jodi.a.schneider 02:45, 16 March 2020 (UTC)
Chchowmein 02:45, 16 March 2020 (UTC)
Dhx1 03:38, 16 March 2020 (UTC)
Konrad Foerstner 06:02, 16 March 2020 (UTC)
Netha Hussain 06:19, 16 March 2020 (UTC)
Bodhisattwa 06:56, 16 March 2020 (UTC)
Neo-Jay 07:04, 16 March 2020 (UTC)
John Samuel 07:31, 16 March 2020 (UTC)
KlaudiuMihaila 07:53, 16 March 2020 (UTC)
Salgo60 09:11, 16 March 2020 (UTC)
Andrawaag 10:12, 16 March 2020 (UTC)
Whidou 10:16, 16 March 2020 (UTC)
Blue Rasberry 15:07, 16 March 2020 (UTC)
TJMSmith 16:15, 16 March 2020 (UTC)
Egon Willighagen 16:49, 16 March 2020 (UTC)
Nehaoua 20:32, 16 March 2020 (UTC)
Andy Mabbett (UTC)
Peter Murray-Rust 00:00, 17 March 2020 (UTC)
Kasyap 02:45, 17 March 2020 (UTC)
Denny 16:21, 17 March 2020 (UTC)
Kwj2772 16:56, 17 March 2020 (UTC)
Joalpe 22:47, 17 March 2020 (UTC)
Finn Årup Nielsen fnielsen) 10:59, 18 March 2020 (UTC)
Skim 11:45, 18 March 2020 (UTC)
SCIdude 15:15, 18 March 2020 (UTC)
Evolution and evolvability 01:23, 20 March 2020 (UTC)
Susanna Ånäs (Susannaanas) 07:05, 20 March 2020 (UTC)
Mlemusrojas 15:30, 20 March 2020 (UTC)
Yupik 20:23, 20 March 2020 (UTC)
Csisc 23:05, 20 March 2020 (UTC)
OAnick 10:26, 21 March 2020 (UTC)
Gnoeee 12:28, 21 March 2020 (UTC)
Jjkoehorst 14:27, 21 March 2020 (UTC)
So9q 08:58, 22 March 2020 (UTC)
Nandana 14:58, 23 March 2020 (UTC)
Addshore 15:56, 23 March 2020 (UTC)
Librarian lena 18:19, 24 March 2020 (UTC)
Jelabra 19:19, 24 March 2020 (UTC)
AlexanderPico 23:34, 27 March 2020 (UTC)
Higa4 02:51, 29 March 2020 (UTC)
JoranL 19:56, 29 March 2020 (UTC)
Alejgh 11:04, 1 April 2020 (UTC)
Will (Wiki Ed)) 17:36, 1 April 2020 (UTC)
Ranjithsiji 04:47, 2 April 2020 (UTC)
AntoineLogean 07:35, 2 April 2020 (UTC)
Hannolans 17:22, 2 April 2020 (UTC)
Farmbrough 21:15, 3 April 2020 (UTC)
Ecritures 21:26, 3 April 2020 (UTC)
  Notified participants of WikiProject COVID-19 TiagoLubiana (talk) 17:01, 21 December 2021 (UTC)

  •   Support Useful for organizing strain information. TiagoLubiana (talk) 17:01, 21 December 2021 (UTC)

designation typeEdit


The Nationally designated areas inventory (Q1116062) includes lots of details of official protected areas in the European Environment Information and Observation Network (Q1378198). It's hard to characterize a protected area (Q473972) since there are dozens of varieties, a lot of more if you consider all the designations each country uses. These not always can be mapped easily so the EIONET chose to identify each national designation and assigns a unique ID with the designationTypeCode attribute. The European Environment Information and Observation Network (Q1378198) database (more than 60K items) characterize each entry with the designationTypeCode and the IUCN protected areas category (P814). With the proposed property we can use that code for any CDDA included entry. Through the property we can link the protected area with related public office and law references.

This proposal complements with Wikidata:Property proposal/CDDA designationTypeCode.

—Ismael Olea (talk) 22:57, 9 August 2021 (UTC)


  •   Support ArthurPSmith (talk) 16:49, 10 August 2021 (UTC)
  •   Comment if Wikidata:Property proposal/CDDA designationTypeCode maps national designation types, shouldn't the values on protect areas be national designations and the label of the proposed property reflect that? BTW The proposed datatype is "item", but the samples currently use string. Maybe it's clearer once we see three samples with actual items as values. You could reuse the ones made for the other proposal. --- Jura 10:30, 11 August 2021 (UTC)
    @Jura1 Yes, I made a system to use the national designation as main label in native language and as official name (P1448) and the English name is used in the EN label. This is easy to do because data is provided in the source database. You can check some elements I'm uploading. I've updated the examples in the proposal as you suggest too. —Ismael Olea (talk) 14:42, 11 August 2021 (UTC)
    • It's much clearer now with the updated samples. Thanks! Couldn't we label this property simply "protected area designation"? This would be consistent with heritage designation (P1435). --- Jura 10:28, 12 August 2021 (UTC)
      @Jura1 I'm not sure about a more generic labeling because this CDDA database covers countries in the European Environment Information and Observation Network (Q1378198), European and Euroasain, AFAIK :-/ —Ismael Olea (talk) 11:03, 12 August 2021 (UTC)
      • I don't see a downside if the property also includes classifications for countries that aren't mapped by that database. --- Jura 11:11, 12 August 2021 (UTC)
      Honestly, it's not a thing about downsides but I'm simply not sure if it would be practical or not. Don't have experience neither confident enough to evaluate if would imply a potential future misunderstandings or not. This is why I act conservative. OTOH, if you and others consider the change appropriate, by the same premise I can't be against :-) —Ismael Olea (talk) 11:49, 12 August 2021 (UTC)
  •   Support User:JavierMunozF (talk) 22:33, 11 August 2021 (UTC)
  •   Comment Given the above discussion I wonder if it would be simpler to just rely on instance of (P31) for this purpose? ArthurPSmith (talk) 17:20, 12 August 2021 (UTC)
  •   Comment Some premises seem off here. As slightly covered in above discussion, designations in question are not of or by CDDA dataset. This dataset just references and records national designations that for the most part existed in other (national) databases before this dataset was even created. So it's misleading to say these are "CDDA designation types" or alike. For the same reason it also looks odd to set these designations as instances of designation type (Q108028209) [update: as of August 19th this metaclass has been amended]. Similarly, in related database there are also IDs for species (EUNIS ID for species (P6177)), but we probably wouldn't classify species with EUNIS ID as "EUNIS species". Possibly items for Spanish national designations (examples above) didn't exist on Wikidata before, but several others are the very same that have been in use for a while, e.g. Nationalpark (Q21815132) (CDDA code DE01) or nature reserve in the Czech Republic (Q21101734) (CDDA code CZ02).
    instance of (P31), or heritage designation (P1435) in case of serveral countries, is already used to link to these designations. If we seek consistency, then I think there wouldn't be any significant downside if existing heritage designation (P1435) was used for all such designations. The problem with something like "protected area designation" would be that it would contribute to an endless confusion around the fact not all protected natural objects are protected areas. CDDA dataset, WDPA and other related databases also include designations for protected natural objects that are not protected areas (like variants of "natural monument" designation for individual boulders and trees). For such objects designation being given as P31 also doesn't seem quite right as individual tree or boulder isn't essentially its current protection status (designation). Previously I've commented on this issue more thoroughly e.g. here. 2001:7D0:81DA:F780:D0F2:C01B:737C:BC2B 08:54, 15 August 2021 (UTC)
Also description for designation type (Q108028209) ("developed by the CDDA to classify protected areas according national regulation") is simply wrong. Designations in question are developed/assigned by national authorities, and CDDA (EIONET) just references and uses these as they are. The same way it's odd to define individual designations like nature reserve (Q108061047) (duplicating Q28055269) by association to CDDA, while CDDA is merely one of several datasets where national designations can be found. 2001:7D0:81DA:F780:8CA:CAD8:3CA5:E487 17:30, 15 August 2021 (UTC)
The duplicity of designations, like the case you explain is because it's almost impossible to me the identify en WD the correct ones. Also, it could depend on how wikidaters organize their country data (you know there are more or less sutiles differences). The good thing is the problem is really easy to solve just merging with the correct ones by someone with knowledge about. This is why I added the legal references of each case. I know is not a perfect job but it's a beginning I expect to be useful. Personally I made some effort to detect correct elements but for the most of the languages is near to imposible to me to do without help.
About the labeling/descripting problem, would be great to hear your suggestions. Seems you have better knowledge than me and I'm always open to enhancements 👍 —Ismael Olea (talk) 19:08, 15 August 2021 (UTC)
My suggestion is to drop "CDDA" from propety label, and otherwise not associate given designation to CDDA apart from just providing CDDA designation code among other identifiers. Or rather consider this property proposal redundant to already existing heritage designation (P1435). Above some other more specific label than that of P1435 has been considered, related to natural heritage, but note that CDDA data anyway also references designations that are not for natural heritage, such as code EE25 for cultural heritage. 2001:7D0:81DA:F780:4CCD:3CA1:A616:3488 09:23, 16 August 2021 (UTC)
I too have mixed feelings about this property, but I see it as similar with IUCN protected areas category (P814) with the main difference that there is usually a 1:1 correspondence between the national protected area type and the ID, so it is somewhat redundand information. But same applies to IUCN category, at least in my experience all items of a given national type have the same IUCN category as well. Extended this property to be heritage designation (P1435) for natural sites IMHO would be a can of worms, as it will make it even easier to declare a geographic feature being the same as a protected area, or putting together different protected areas in one item. Just look at the constraint violations for WDPA/CDDA/Natura2000-ID to see how many wrongly modeled protected areas we have in our database already. Ahoerstemeier (talk) 21:57, 15 August 2021 (UTC)
@Ahoerstemeier I agree it's a nightmare to describe protected areas in a systematic way in WD. The good thing of the WDPA/CDDA/Natura2000 id's is considering we can't faithfully describe the elements at least we can reduce the ambiguity a bit identifing each area with (more or less) international way. Plus, the CDDA type codes adds a bit of description (something more than IUCN code). The challenge would be to establish a worldwide ontology but it's absolutely out of my current goals. —Ismael Olea (talk) 08:30, 16 August 2021 (UTC)
I don't think that the use of heritage designation (P1435), or seprate "natural heritage designation" property, would make it easier to mix protected areas and other distinct geographical objects. In most cases where this has happened designations are currently given as P31 values anyway. Also please note that, as pointed out above, WDPA/CDDA include many individual protected objects that are *not* protected areas, and so many of these WDPA/CDDA property constraint violations are in fact false positives, e.g. in case of protected object Labidakivi (Q12368168). Considering this, as far as I can see and as previously explained e.g. here, the use of heritage designation (P1435) would rather help clear things up.
As for IUCN categories, it's true that protected objects of some designations fall into the same IUCN category, but there are also other designations for which it isn't true. For instance, per CDDA data, objects of designation code EE12 are divided between IUCN categories Ib, IV and V. 2001:7D0:81DA:F780:4CCD:3CA1:A616:3488 09:23, 16 August 2021 (UTC)
Maybe adding a restriction in WDPA/CDDA/Natura2000 id properties to be used in P1435 instead of P31 would help to reduce the mess? Or viceversa, whatever gets agreed. I can't have a preference for neither one approach. —Ismael Olea (talk) 10:00, 16 August 2021 (UTC)

  Support Thadguidry (talk) 12:37, 16 August 2021 (UTC)

I find it less confusing without CDDA associated label, and domain not being limited to protected areas makes sense as CDDA as a source includes also designations for individual natural objects that are not areas, as well as cultural heritage designations (references above). But now, with "designation type" label, it's pretty much the same as already existing heritage designation (P1435). 2001:7D0:81DA:F780:ED98:52B1:1627:75F2 07:52, 20 August 2021 (UTC)
Yeah, somehow the label should specify what the designations apply to and differentiate from P1435. --- Jura 13:15, 20 August 2021 (UTC)
Or, simply the existing P1435 property could be used instead of this proposed property. As pointed out above, it is already used for several natural heritage designations, and above I don't see a clear reason why it shouldn't be. 2001:7D0:81C5:A580:708F:5A45:F175:EC01 09:16, 7 April 2022 (UTC)

taxon synonym stringEdit

   Ready Create
Descriptionsynonym of the taxon name
Representssynonym (Q1040689)
Data typeString
Template parameter"synonyms" in en:template:speciesbox, en:template:taxobox, and en:template:automatic taxobox
Allowed valuesscientific names
Example 1Phidippus johnsoni (Q675345) → Attus johnsonii
Example 2Phidippus johnsoni (Q675345) → Phidippus bicolor
Example 3Phidippus johnsoni (Q675345) → Dendryphantes johnsoni
Planned useaddition of taxon synonyms for jumping spiders (99+% of which don't have items)
Robot and gadget jobsNothing currently planned, but there's a lot of potential here
See alsotaxon synonym (P1420)


The original proposal for taxon synonym (P1420) was to have it be a string property. However, the property was controversially created as an item property instead at the insistance of a single user. Fast forward six years and taxon synonym (P1420) is barely used (14,425 uses) despite the fact that almost every taxon on the planet has synonyms and many have dozens. This means that Wikidata still doesn't have useful data on taxon synonyms for 99.9% of taxons (even though Wikipedia, Wikispecies, and even Commons have this data). The fact is, no one is going to create Wikidata items for the millions of synonyms that exist (and it's debatable whether or not they even should in many cases, e.g. objective synonyms, taxonomic vandalism, etc.). These problems have been discussed ad nauseam on the property talk page without any solutions being reached, mainly because we keep letting the perfect be the enemy of the good. The only practical way forward, IMO, is to adopt Brya's compromise proposal to have separate item and string properties, similar to how author (P50) and author name string (P2093) work. This should allow us to finally move forward with adding more comprehensive synonym data to Wikidata while still allowing users to flesh out full items for taxon synonyms if they need to. Kaldari (talk) 16:01, 28 June 2020 (UTC)

How this property would be used in relation to taxon synonym (P1420)Edit

Use of "taxon synonym string" (with taxon author (P405) and year of taxon publication (P574) qualifiers) would be the default for most taxon synonyms. In cases where there are ...

  1. Competing taxon concepts in recent literature (e.g. Prasophyllum uroglossum (Q65946197) vs. Prasophyllum fuscum (Q15488111))
  2. Disagreements about taxon level in recent literature (e.g. Bos taurus (Q20747334) vs. Bos primigenius taurus (Q20747320))
  3. Deprecated taxon names that are notable in their own right (e.g. Attus (Q4818757))

... use of taxon synonym (P1420) would be encouraged. In other words, we should only use taxon synonym (P1420) where there is a concrete reason for a Wikidata item to exist for that synonym and the information can't be equally-well handled with just a string and qualifiers. Kaldari (talk) 20:32, 28 June 2020 (UTC)


  •   Oppose:
  1. The purpose of author name string (P2093) is "undifferentiated author", but taxon name is usually unique so it is possible to create items for individual names.
  2. This proposed solution assumes there is only one canonical name for each taxon, but the canonical name may differ between classification systems

--GZWDer (talk) 16:14, 28 June 2020 (UTC)

  1. That's not accurate. According to the description (and how the property is actually used), author name string (P2093) is for when the author is undifferentiated or doesn't have an item. Regardless, just because something is "possible" doesn't mean people are actually going to do it. For example, I really want to add synonyms to spider species, but I'm not about to create 100,000+ items in order to do it. Nor do I expect that anyone is going to create hundreds of thousands of Wikidata items for every author of a paper listed in Wikidata.
  2. True, in which case you can still use taxon synonym (P1420).
Kaldari (talk) 16:23, 28 June 2020 (UTC)
We need consistency, instead of different ways to achieve the same thing. --GZWDer (talk) 16:28, 28 June 2020 (UTC)
If there was a way to have properties that could be either strings or items, I would agree with you. Kaldari (talk) 16:30, 28 June 2020 (UTC)
  Comment There seems to be a classic conflict here, does Wikidata capture as much information as it can without trying to model everything in detail (in the hopes that it can be sorted out later) or does postpone adding data that hasn't (yet) been modelled? Individuals seem divided on this topic, the question is can both approaches exist side by side? The author name string (P2093) example works well because (a) it's clear that a huge amount of bibliographic data couldn't be added to Wikidata if we insisted on having authors as items, and (b) there are people and bots mapping author strings to author items. Having the string data in the first place makes this mapping possible, and doesn't seem to negatively impact this who would prefer to have authors as items. Perhaps this proposal could be strengthened by showing how we could move from synonyms as strings to synonyms as items? That way, those who prefer items could see a path to that goal, and hence we could develop bots to make that transition as and when we have information and/or time. I think most would agree that the modelling of taxonomic names and taxa in Wikidata is, at best, open to improvement, but how it is to be improved seems unclear. It is tempting to argue that we shouldn't mess with taxonomic properties until that model is clarified, but that will be enormously frustrating to those who "just want to get things done." --Rdmpage (talk) 17:10, 28 June 2020 (UTC)
  Comment I very much support Rod's pragmatic approach and, indeed, an expansion of Kaldari's original proposal to explain the mechanics of supporting a transition from string to item (when appropriate) would be a great addition. In my opinion, having followed the usage of author-related properties for a while, this incremental approach is solid. I'd be curious to hear from @Magnus Manske: the success of the author string vs item resolution depends to a large extent on the tools he created. --DarTar (talk) 18:22, 28 June 2020 (UTC)
@Rdmpage, DarTar: I don't think Wikidata claims always have to "progress" from strings to items. There are cases where it makes sense for an author to be a string forever (a minor author in a minor academic paper who has no other citations). Similarly, there are numerous cases (the majority, IMO) where it makes sense for a taxonomic synonym to be just a string (with qualifiers). The mussel species Anodonta cygnea has 568 synonyms. Creating separate items for each one (most of which only occur within a single paper), would be pointless and create a maintenance nightmare. I've now outlined above how I think this property should be used in relation to taxon synonym (P1420). Let me know if you think that makes sense. Kaldari (talk) 20:47, 28 June 2020 (UTC)
So adding 568 (qualified and referenced) synonym strings to Swan mussel (Q777865) will not „create a maintenance nightmare“? --Succu (talk) 21:12, 28 June 2020 (UTC)
Creating items for fake species does more than create "a maintenance nightmare": it makes Wikidata a serious threat to information on taxa, on a global scale. - Brya (talk) 03:53, 29 June 2020 (UTC)
@Succu: No more so than what Wikipedia already deals with. If, however, we had 568 items for all the synonyms (the current method), every time the accepted scientific name changed, we would have to update 568 items (rather than just updating one item). Anodonta cygnea may not be the best example, as there doesn't seem to be an item for the taxon name Anodonta cygnea specifically, but Phidippus audax (Q134277), for example, has several dozen synonyms. Most of them are listed in Wikipedia, but none are listed in Wikidata. Is there a downside to allowing string synonyms? I realize that it doesn't allow quite as much data to be associated with the synonym, but having name, author, and date is a lot better than having nothing, which is what we have now and it avoids the problems associated with having a proliferation of synonym items. I hope you will consider this idea with an open mind as your opinion carries a lot of weight here. Kaldari (talk) 14:15, 29 June 2020 (UTC)
I also am in agreement with Rod (@Rdmpage:) here. Particularly the point that I do not think comparison between authors and taxon names is appropriate. Large numbers of exisiting synonyms are important names and carry the potential of future usage, as such I think these should be items not strings. I accept there are some and objective synonyms is an example, that clearly will never be used. But I do think the aim should be to create items for these. I also agree that the entire struct of the taxonomic data needs a significant amount of scrutiny and redesign. It may be, as Rod says, better use of peoples time to first get the overall in the most useful form. Cheers Scott Thomson (Faendalimas) talk 01:50, 9 July 2020 (UTC)
  •   Question Is there a consensus that the current handling of synonyms in Wikidata should change to string-based solutions? Vojtěch Dostál (talk) 07:38, 29 June 2020 (UTC)
    • @Vojtěch Dostál: No, but there is also no consensus that the handling of synonyms should be item-based (see the original taxon synonym (P1420) proposal and various discussions on that property's talk page). By having both options we can flexibly accommodate either method when it makes sense to. I'm open to tweaking the guidelines about when to use either, but it's clear that the current item-only method isn't adequate. Kaldari (talk) 15:18, 29 June 2020 (UTC)
      • To me it's not that clear. I am afraid of breaking the status quo which has its merits, and creating two parallel taxonomic systems in Wikidata which will not communicate with each other. @Kaldari: I have one more question if you don't mind: How will a bot which imports from Wikispecies know when to use items and when strings? Clearly, some synonyms deserve an item of their own and classifying them as mere strings attached to a different taxon is an over-simplification of the taxonomic reality.Vojtěch Dostál (talk) 15:27, 29 June 2020 (UTC)
        • @Vojtěch Dostál: As suggested by Rod and Dario's discussion above, the default would be to initially bot-create the synonyms as strings under the item linked from Wikispecies. Any synonyms that merited their own items could then be changed into taxon synonym (P1420) claims as needed by humans. I expect that that would be the exception rather than the rule, however, and most synonyms would remain as strings with qualifiers. I see the two properties as being complimentary, not separate and parallel, in the same way that author (P50) and author name string (P2093) have allowed us to have more comprehensive author data than we would have with just author (P50) alone. Kaldari (talk) 15:40, 29 June 2020 (UTC)
  •   Question what happens if a name currently in "taxon name" becomes a synonym? Will you repurpose the item and change taxon name, apply the string? --- Jura 08:52, 29 June 2020 (UTC)
    • @Jura1: This should compliment the use of taxon name (P225) well (which is also a string property). In the event that the taxon name becomes a synonym, the values and qualifiers under taxon name would be moved to a "taxon synonym string" claim under the same item and a new taxon name (P225) claim would be created. As you suggest, the item would simply be repurposed (or merged with another item) and no new item would need to be created. This also saves us from having to move all the sitelinks (or split them up based on which ones move to the new name). It should be a much easier process and much more complimentary to our sister projects. Kaldari (talk) 15:04, 29 June 2020 (UTC)
      • It was a question, not a suggestion on my side. I don't think items should be repurposed in general. Your response suggests that you want to move from a taxon name based system. If you merely want to improve enwiki's handeling of siteslinks, you could opt for Commons' approach. --- Jura 15:10, 29 June 2020 (UTC)
        • @Jura1: By repurposed, I simply meant the same item would receive the new taxon name (if the name of that taxon was changed). The item itself would still represent the exact same taxon. In other words, taxon (Q16521) items would actually represent taxons, rather than our current awkward system of taxon items sometimes representing just taxon names and sometimes representing both taxons and taxon names. Does that make sense? Kaldari (talk) 15:23, 29 June 2020 (UTC)
          • I think I understand the two approaches. Maybe it's important to note that there is a key difference to "author name"/"author"-pair of properties you mentioned: "author name" is used for bulk imports because insufficient information is available to create an item for the author and large scale creations for these do happen once some identifier is available. For synonyms, I think one can't really create the string version without having sufficient information to create separate items as well. Also, the renaming you outlined illustrates the uncertaintity introduced by no longer providing a stable identifier (QID) for taxon names. --- Jura 07:23, 30 June 2020 (UTC)
            • There may be enough information to create an item, but 1) many synonyms are not notable enough to have an item and 2) in the current model creating an item would promote the synonym into a species (a taxon), even when it cannot be one, by definition. Another fake species will have been created. - Brya (talk) 05:23, 1 July 2020 (UTC)
              • I don't agree about the amalgmation you are doing, but the proposal doesn't change anything about (2). As for (1), it seems odd that that should depend on the existence of a sitelink. --- Jura 06:02, 1 July 2020 (UTC)
                • As for 2), with the proposed property it would be possible to add synonyms as strings, without implying in any way that they are, or represent, actual species, just like in any taxonomic paper. Creating an item for a synonym unambiguously states ("instance of: taxon") that they are species, even though it is possible to add a qualifier "this is a fake species" (there is a large variety of such qualifiers): the latter will confuse just about any user. - Brya (talk) 05:06, 2 July 2020 (UTC)
                  • @Jura1: I removed the sitelink criteria. To address your other concern, I think the uncertaintity introduced by no longer providing a stable identifier (QID) for taxon names is far less significant than the confusion currently caused by having to have a separate item for every taxon synonym (even synonyms which are simply misspellings or taxonomic vandalism). If you have any suggestions for improving the proposal, I'm open to ideas. Kaldari (talk) 00:55, 9 July 2020 (UTC)
  •   Support The proof of the pudding is in the eating. I don't see the apocalyptic scenario's described above. Wikidata is a linked-data store and core to linked data is the possibility to reroute links. SPARQL even has the CONSTRUCT query that enables this. So even if this proposal becomes obsolete because all taxa are perfectly defined in their proper wikidata items, there is really no long term risk in accepting this proposal, which would enable quite some use cases. Worst case scenario is that the need for this property becomes obsolete, in which case all we have to do is do a simple bot operation, that removes these deprecated statements, for which wikidata even has invented ranks. --Andrawaag (talk) 14:55, 29 June 2020 (UTC)
  •   Support Taxon syonyms refer to the same entity and thus modeling it this way is better then creating a new item. ChristianKl❫ 17:03, 29 June 2020 (UTC)
  •   Support With the understanding that (as proposed) this will exist besides P1420, and that most synonyms won't ever be transferred to P1420, although some may be (if notable enough). - Brya (talk) 04:18, 30 June 2020 (UTC)
  • For the moment   Oppose. Some reasons:
    1. taxon name (P225) is not intended to reflect the taxon concept currently in use. P225 should only be changed in very rare cases. A lot of others items and properties rely on it. In fact you'll get a warning if you try to change the value of P225
    2. I missed the word "reference" in your explaination. Subjective/heterotypic synonyms reflect a taxonomic opinion of someone. Wikmedia projects are not a reference at all. In your example Phidippus audax (Q134277) enWP has no reference for the listed synonyms. World Spider Catalog is a good reference for species etc. considered as synonyms. But you should allways cite the version or use retrieved (P813)
    3. Your The "synonym strings" are dumb. They show no relationship to each other (e.g. based on the same type). Should they ordered somehow (e.g. by date)?
    4. If you consider your "synonym strings" as an analogy to taxon name (P225) (including all allowed qualifiers) and you have all this information at hand, why not create an item? It's cheap and supported by tools like QS.
    5. In my opinion all synonyms provided by reliable sources are "notable enough" to get an item. Of course not all of this items are allowed to label a taxon concept
  • --Succu (talk)
    •   Comment Can we please refrain from calling others contributions "dumb" and be more convincing and less judgemental?
      • @ Andrawaag: I read "dumb" to mean the string was "dumb", not that the contribution was "dumb". In other words, the synonym string is just a set of text characters, not a thing (item) linked to other useful information.
    • Why is notability a criteria in selecting the value type of a property? In that case each InChI (P234) and InChIKey (P235) (just two random examples) should point to individual items too. Creating items is not as cheap as suggested, yes you can do that with QS or through the Wikidata API, but a lot of contributions are also coming from single users adding single statements. Then the workflow is suddenly frustrating. My approach in those cases (and I know how to write bots) is to open a second tab create the new wikidata item select the newly created and populated wikidata QID and paste that in the statements of which the property requires an item. This workflow is just not user-friendly and yet easier than achieving the same in QS. --Andrawaag (talk) 08:53, 1 July 2020 (UTC)
      • If you want to add a new monotypic species you'll have to add the new genus of course first. This is not a flaw in usability. In a database this a normal workflow such as adding a new customer before creating an invoice for the new customer. If you are creating the invoice with a text editor then this restriction will vanish at the cost of structure. BTW: here you can omit adding parent taxon (P171) and hope the constraint will be fixed by someone else. A common pattern... --Succu (talk)
  • It's not clear to me that the world fits any model we make of it in this regard. That, I suppose, is a support for the "mixed model" Kaldari proposes. It would be a good idea to work out what we do with synonyms if two species (say) become one, or one becomes two. Maybe this is an established concept in taxonomy. Also do we label synonyms with nomen erratum etc? How do we deal with updated or contradictory synonymy lists?
I hope your experience with author stings to authors is better than Wikipedia's. We have many citations where we would be so much better with a simple "authors=" parameter, rather than list of first and last names which doesn't handle all the oddities of human naming. All the best: Rich Farmbrough16:26, 7 July 2020 (UTC).
@User:Rich Farmbrough: lumpers and splitters (Q1662868) is an old taxonomic "problem". So what Wikipedias do if
  1. two species become one (lumped / merged)
  2. one becomes two (split; Crocodylus halli (Q68594258) is a recent example)
in regard of the related sitelinks? --Succu (talk) 19:06, 7 July 2020 (UTC)
We have a lesser problem, we can have an article about some or many species, we can have multiple articles about one species. We can have redirects where we need them, and change these things on a far more ad-hoc basis than Wikidata. that's not to say we always succeed, I'm not highly involve in that area. All the best: Rich Farmbrough00:23, 19 July 2020 (UTC).
  •   Oppose for the present. I have sympathy for Kaldari's frustration with the current system, which I share. But the problem is a deep one, and I'm not convinced that this patch is, overall, an improvement.
    1. The deep problem is that Wikidata does not model taxa as opposed to taxon names. Numerous discussions have resulted in the conclusion that we don't know how to model taxa and taxon names. (My summary, and it is only a summary, is here if you aren't familiar with these discussions.) Rich Farmbrough's comment It's not clear to me that the world fits any model we make of it seems very apposite to me.
    2. Wikidata taxon items are used to retrieve taxon identifiers, e.g. in the English Wikipedia's taxonbars. So any synonym that has an identifier in a taxonomic database needs to be an item, not a string. However, taxonomic databases have very different policies. The World Spider Catalog (WSC) does not have identifiers for taxon names, but for taxa. If the name it accepts for the taxon changes, the identifier remains the same. Treating synonyms as strings works well for data extracted from the WSC only if the taxon name of the item can be changed, i.e. the item really does represent a taxon, not a taxon name. GBIF has identifiers for all the taxon names it lists, including somewhat oddly both "Araneus diadematus Clerck, 1758" and "Araneus diadematus (Clerck, 1758)". So to retrieve GBIF's identifiers, the synonyms need to be treated as items.
I do take the point about the best being the enemy of the good, and we should strive to improve the modelling of taxa and taxon names in Wikidata regardless of the fact that there may not even be a way to do so properly. However, I'm not (yet) convinced this proposal alone is an improvement. The present system, which muddles taxa and taxon names, more-or-less works. Peter coxhead (talk) 06:42, 9 July 2020 (UTC)
@Peter coxhead: Regarding #2, that is why I am proposing a hybrid system rather than just changing taxon synonym (P1420) to a string property. In cases where there are legitimate reasons to have separate items (and separate Wikipedia taxonbars), we could accommodate that. Wikipedia, however, generally follows the 1 species = 1 article model, so this would actually make Wikidata more compatible with Wikipedia, not less, as it's more likely that relevant data for a species won't be split across multiple items. The downside of not including every database identifier for every synonym is a very minor downside, in my opinion, and I see very little practical impact from it. Kaldari (talk) 13:48, 9 July 2020 (UTC)
@Peter coxhead: Any thoughts regarding my response above? I would also like to mention that many database identifiers for synonyms just go to useless pages which have no more information than author and publication year, thus providing no additional information.[2] Are there specific cases you are thinking about where losing a database identifier for a synonym (that doesn't meet one of the criteria for creating a separate item) would actually result in some detriment to a Wikidata user or re-user? FWIW, I don't know of any Wikidata re-uses that are utilizing database identifiers for synonyms, so this seems like more of a theoretical concern than a practical problem. Kaldari (talk) 17:53, 16 July 2020 (UTC)
@Kaldari: sorry to be slow, I don't monitor Wikidata regularly. Databases differ significantly in what they do about synonyms, which complicates the issue.
  • The World Spider Catalog's identifier is for the taxon; if the name its compilers accept changes, the ID goes to the new name, and the old one is just listed as a synonym. So for this database, nothing is gained by having taxon names as items. Strings would be fine.
  • Tropicos (a plant taxonomic database) records names for those taxa it covers, listing for each any other sources that accepted those names. Its identifiers for synonymous taxon names are useful, because the entries contain useful information.
  • Many sources linked by taxon name IDs are not regularly updated, if at all; for example for plants the online Flora of China and the online Flora of North America. So they will often be using names no longer accepted in recent sources. Their entries can only be found under IDs for synonyms.
I don't know of any Wikidata re-uses that are utilizing database identifiers for synonyms – look at the taxonbar at the bottom of en:Reynoutria japonica. Calflora and FNA (Flora of North America) are useful sources, but they both use the synonym Fallopia japonica. If Fallopia japonica (Q899672) were not an item, we wouldn't have these IDs and hence links. Peter coxhead (talk) 06:35, 24 July 2020 (UTC)
The muddle between taxons and taxon names is one of the remaining places where names get confused with the concepts towards which the name points. Having less of those cases and only those cases which are needed for Wikipedia compatibility is desireable.
The present system also has the problem when linking a taxon from within Wikidata with properties such as instance of (P31) or found in taxon (P703). Whenever we have synonymous you would have to link to both the taxon and it's synonym if you want to log all the relevant relations. ChristianKl❫ 20:06, 9 July 2020 (UTC)
Shouldn't found in taxon (P703) better be linked to a circumscription (Q5121761)? --Succu (talk) 20:26, 9 July 2020 (UTC)
  •   Support in the absence of any major fixes to the struct here this is a needed solution for now. Cheers Scott Thomson (Faendalimas) talk 21:00, 10 July 2020 (UTC)
  • Comment

ok for the sake of somewhere to say this I have been thinking on what @Rdmpage: and @Peter coxhead: have said, both here and elsewhere. I am not meaning to hijack this and this is not so much an issue with this proposal but of how Wikidata does taxonomy in general. As I and others have said above the whole methodology here needs rebuilding, your struct. Its almost like your trying to be a hybrid of a database and an encyclopedia. Wikidata is a database you should treat it as one.

  1. change the name of Instance of Taxon to instance of taxon name, this removes this confusion. Both Rod and Peter have discussed this issue and I agree with them. Then it is clear you are databasing all the available names for life.
  2. all names must be items , start with the names in current usage but add in synonyms as you can.
  3. all names are listed under their original combinations as the mainspace name. your first statement will be the instance of taxon name, your second will be the original reference used in the circumscription of the name.
  4. have statements for the type data and the type locality.
  5. a statement declaring the current nomenclatural status of the name, eg available, valid, homonym, etc whatever is relevant
  6. then have a statement with the currently used combination, with the reference that made this change. Your parent identifier works for this.
  7. then a statement with a list of its known synonyms
  8. then put in the extra like images etc
  9. then a your various identifiers such as ITIS, and various checklists that use it, aggregators whatever.

There may be others that can be justified. but these are the ones you need. Then you are databasing the information that is absolutely needed, the data can then be used elsewhere throughout Wikimedia and possibly further afield. You must include all parents, so you need items for any proposed ranks, including subgenera, subspecies, subfamilies etc. This is very hit and miss at present. Now whether you put species in genera or species in subgenera and subgenera in genera I could not care. But you need to have a way of acknowledging the existence of the sub groups and having them queried in a way that the result places them in these ranks if thats what the user wants. Databases serve they provide information for other applications. Some of you may find this lecture on Wikiversity I created useful [3]. Cheers Scott Thomson (Faendalimas) talk 10:31, 10 July 2020 (UTC)

Does "all names are listed under their original combinations as the mainspace name." mean what I think it means? That is, have items only for original combinations, and add all subsequent combinations (as strings) to that item?
        Upon first glance this proposal seeems to maintain all current problems and add new ones; it would lose information on a grand scale. - Brya (talk) 11:00, 10 July 2020 (UTC)
        P.S. The Wikiversity page should make clear that it does not apply to Nomenclature and Taxonomy in general, but to Zoological Nomenclature and Zoological Taxonomy only. - Brya (talk) 11:00, 10 July 2020 (UTC)
Yes I do think your better off having all names under original combination, however, I also said all names should be items not strings. Stings would cost you a lot of data, I would not recommend that. I think this could be done without data loss, as I said I did not suggest strings, and I did say add everything else in you have eg images. I would not refer to this as a proposal it would need a lot of fleshing out and discussion first. At present I am just thinking out loud. What is here so far may not solve every problem, of course it adds work, restructuring a database always does so if thats the added problem sure. I do not for one minute think it would be easy, but to discuss it further it should be done elsewhere. Since both the title and subtitle state in the wikiversity article its using turtles as a case study I figured the zoology part was clear. Cheers Scott Thomson (Faendalimas) talk 11:47, 10 July 2020 (UTC)
I am not sure if I understand how that would be a change in this respect from the current situation. All names are already linked to the original combination (where this applies), so the most this would mean would be a property that is the reverse of "original combination" (like a property "subsequent combination")?
        From the above I got the impression you wanted to gather all information in the item on the original combination. Logically, this would mean adding names (subsequent combinations) as strings. - Brya (talk) 16:39, 10 July 2020 (UTC)
@Faendalimas: I proposed basically the same thing two years ago and it went nowhere. Your proposal retains many of the problems of the current system and would be a maintenance nightmare. Every time a species was renamed, all of its synonyms would have to be updated. I'm tired of us going around and around in circles on this. I just want an easy way to add more synonym data to Wikidata without causing any other problems. Nothing that I'm proposing makes other more comprehensive solutions impossible in the future. Can't we just take a small step towards improving the current situation rather than endlessly re-hashing the entire taxonomy system (which always leads nowhere)? Please consider the merits of this modest proposal and whether or not it would actually lead to more useful data in Wikidata (which I think it would). Sure it's not perfect, but it's an improvement, and it doesn't make the existing situation any worse. Kaldari (talk) 20:10, 10 July 2020 (UTC)
Sorry it was not my wish to hyjack this. I saw it as an opportunity to highlight some of the issues of what is clearly a hybrid database. Anyway above I have supported your proposal. Cheers Scott Thomson (Faendalimas) talk 21:00, 10 July 2020 (UTC)
Faendalimas, essentially, you proposed status quo. It's clear that it may appear difficulte to create new items for users who never did that, but I don't see how this new property would help users get started with Wikidata. That a few (automated) maintainance steps could (or should) be added isn't really argument in favor of this property proposal. --- Jura 21:17, 10 July 2020 (UTC)
Jura, essentially I agree with you, I do not think anything I commented was in favor of this. But in the absence of a full redesign this will allow data to be added. I think people should be encouraged to make items instead of strings. However in the absence of items at least something is there. I have supported it by concession, not because I think its perfect. Cheers Scott Thomson (Faendalimas) talk 22:03, 10 July 2020 (UTC)
@Faendalimas: what you don't seem to be taking into account is that Wikidata needs to be able to model its data sources, and in particular their IDs (especially for the English Wikipedia, whose taxonbar uses IDs as entries to those sources). Repeating what I wrote above, for some sources, like the World Spider Catalog, the ID is for the taxon: if the accepted name changes, the entry has a new name but the same ID. Strings will work fine. In other sources, like Tropicos, IDs are for names, and there is useful information under the name. For these cases, we need each synonym to have a link to an ID. Strings won't work for this. Peter coxhead (talk) 06:35, 24 July 2020 (UTC)
@Peter coxhead: Couldn't we just add the taxon name IDs as qualifiers to the synonym string property? We would just need to change their property scope constraint, but that's easy. Then no data would be lost. Kaldari (talk) 15:11, 21 August 2020 (UTC)

  Comment: As I see it, a prime problem is what is intended by "name". In the real world this is governed by the various Codes of nomenclature. These have ordered names into the following categories:

  1. not-formal names (not available, not validly published)
  2. formal names, that however may not ever be used as the correct name of a taxon (dead names, objectively invalid names, permanently invalid names) and
  3. formal names, that may be used as the correct name of a taxon, depending on taxonomy.

From the last category any taxonomist will select a subset that he accepts as correct names, but different taxonomists can select different subsets.

There are the following basic models that could be adopted:

  1. Single-Point-of-View: create a taxonomic point of view which adopts a set of correct names, and treats all other names as synonyms (without making a distinction between categories). Much of the taxonomic literature adopts this format, as does Wikispecies and, I guess, Commons. Pretty much by definition, it would only be compatible with itself, and not with different Wikipedias using different sets of correct names. A further problem with this SPoV would be that it would violate the NPoV and NOR policies of Wikipedias.
  2. Hybrid model: every name that potentially can be used as the correct name of a taxon can have its own item. By adding references it is possible to indicate which names are accepted by which taxonomist. Each of these items has information about the name (nomenclatural information) and the taxon (for which it has been used as the correct name). This is what happens in the real world, and to such an extent that many in the real world cannot distinguish between the correct name of a taxon and the taxon. This hybrid model can only work if a parallel structure is set up for names in category 2 (formal names that are dead, objectively invalid names, permanently invalid names) which interacts with the structure of potentially correct names.
  3. Names only. Items are for names only, containing nomenclatural information only (of all three categories). This will require setting up a parallel structure for taxa, with items on taxonomic information, and information about taxa. Only this parallel structure may serve as the interface between Wikipedia's and the name-only items.

The problem is that different users prefer different models but without accepting the consequences of their chosen model, and just import data which they alter by where they put it. - Brya (talk) 05:27, 11 July 2020 (UTC)

There is another option by using TNUs but it requires also a lot of good design. Happy to explain it but I think I have taken up enough of this proposal with what is an issue to the side, I feel I am being unfair to the proposal. Set up a place to discuss the Wikidata taxonomy model and I am happy to provide input. Cheers Scott Thomson (Faendalimas) talk 06:41, 11 July 2020 (UTC)
@Faendalimas: would be a good place to talk about the Wikidata taxnonomy model. ChristianKl❫ 09:01, 11 July 2020 (UTC)
  •   Comment Given that this discussion is rumbling on without obvious resolution, and you will find similar, seemingly endless discussions involving people paid to think about taxonomy, might a pragmatic (and hence admittedly unsatisfactory) solution be to (a) use "also known as" as the place for synonyms as strings, and (b) if you want to specify that a name is a synonym then create an item for that name and connect it to the taxon of interest using taxon synonym (P1420)  . For example, Anolis cristifer (Q5315308) has no taxon synonym (P1420)   but there are synonyms in "also known as" (Query). Now, "also known as" can include all manner of things, such as common names, etc., and so isn't as precise as taxon synonym (P1420)  , but if the goal is to help discoverability then having a set of alternative labels for something is all you need. One could argue that if you really want to distinguish something as taxonomic synonym (rather than just an alternative label), then you really should go to the trouble of spelling that out via taxon synonym (P1420)  . This seems a halfway approach that acknowledges that there is not universal agreement on the best way to model taxonomy in Wikidata, nor what the current model actually is, but still lets people do things without waiting for a resolution of the modelling issue. --Rdmpage (talk) 10:57, 16 July 2020 (UTC)
  •   Support Good opening arguments. If the community desires standing items for synonyms, IMHO, would better fit the Lexeme framework and get an L-id instead of a Q-id.@Rdmpage: suggestion also seems like a good compromise. --TiagoLubiana (talk) 16:31, 8 November 2020 (UTC)
  •   Oppose I don't think creating this is compatible with the current approach. --- Jura 09:14, 14 November 2020 (UTC)
  •   Support One of the causes of synonyms is spelling mistakes. For example, Opsariicjthys is a common spelling error in Opsariichthys (Q3768486)--Shizhao (talk) 07:34, 20 July 2021 (UTC)
  •   Oppose Strings are a nightmare to deal with. The example given is a good example why we should stick to the multi-items solution to srtucture the data adequately. Finally, the lazy people can still use aliases. Totodu74 (talk) 15:07, 16 September 2021 (UTC)

Nomenclature de tous les noms de roses connus IDEdit

   Under discussion
Descriptionidentifier of a rose cultivar in "Nomenclature de tous les noms de roses, connus, avec indication de leur race, obtenteur, année de production, couleur et synonymes", 2nd edition, by Léon Simon and Pierre Cochet
RepresentsNomenclature de tous les noms de roses (Q96643524)
Data typeExternal identifier
Domainrose cultivar (Q26817508)
Allowed values([1-9]\d{0,3}|1[01]\d\d\d)[a-z]
Example 1Rosa 'Belle Poitevine' (Q60965265) → 1409
Example 2Rosa 'Belle Biblis' (Q83673639) → 1226
Example 3Rosa 'Belle Herminie' (Q83673647) → 1340
Example 4Rosa 'Belle Isis' (Q60964253) → 1355
Example 5Rosa 'James Bougault' (Q64030579) → 4935
Example 6Rosa 'James Mitchell' (Q83668435) → 4938
Example 7Rosa 'James Veitch' (Q83672920) → 4941
Example 8Rosa 'Jeanne de Montfort' (Q83660038) → 5027
Example 9Rosa 'Jeanne Masson' (Q83673867) → 5044
Example 10Rosa 'Comte Adrien de Germiny' (Q60965024) → 2388
Example 11Rosa 'Comte de Chambord' (Q60964318) → 2401
Example 12Rosa 'Comte de Montalivet' (Q96277233) → 2415
Example 13Rosa 'Mademoiselle Claudine Perreau' (Q83672486) → 7181
Example 14Rosa 'Mademoiselle Christine de Nouë' (Q83671406) → 7174
Example 15Rosa 'Mademoiselle Blanche Lafitte' (Q60964631) → 7164
Example 16Rosa 'Princesse Louise' (Q83674468) → 9105
Example 17Rosa 'Adrienne de Cardoville' (Q83673585) → 288
SourceNomenclature de tous les noms de roses (Q96643524) pp. 1-170
Planned useadd to some existing ones [4], create new ones
Number of IDs in source>10000
Expected completenessalways incomplete (Q21873886)
See alsoLes Roses cultivées à L'Haÿ en 1902 ID (P8662)
Applicable "stated in"-valueNomenclature de tous les noms de roses (Q96643524)
Distinct-values constraintyes


Provides a simple way to cross-reference our items about cultivars with Nomenclature de tous les noms de roses (Q96643524) (Add your motivation for this property here.) --- Jura 12:08, 18 July 2020 (UTC)

The identifier used in the work is unique. It is generally numeric (<12000), sometimes followed by a letter (a-z). I added that to the regex above. A formatter url isn't available, but this isn't a requirement for external-id properties. --- Jura 14:32, 20 August 2020 (UTC)

  WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --- Jura 12:08, 18 July 2020 (UTC)

M.A.Miron Vincnet41 Tubezlob Prime Lemur Tris T7 TT me Infomuse TED Wkee4ager   Notified participants of WikiProject Botany --- Jura 08:52, 19 August 2020 (UTC)


  • this numbers? --Succu (talk) 20:15, 18 July 2020 (UTC)
  •   Support   Neutral Well founded. Nothing else to add. As Succu pointed out, Catalog and Catalog number might be enough for this need. M.A. Miron (📬) 00:20, 20 August 2020 (UTC)
    • Personally, I find a distinct property make checks on old roses easier. I'd try to do more than copy the same label to countless languages separately. --- Jura 09:04, 22 August 2020 (UTC)
  •   Oppose Use stated in (P248)=Nomenclature de tous les noms de roses (Q96643524) and catalog code (P528), page(s) (P304). --Succu (talk) 06:41, 20 August 2020 (UTC)
    • The primary use of this property would be for main statements (see domain/samples). stated in (P248) can't be used for that. (I don't think the page number is important once we have the id.) The idea is to include Nomenclature de tous les noms de roses (Q96643524) like a database, version 1906. --- Jura 12:41, 20 August 2020 (UTC)
      • Could you please give examples where this number is cited? --Succu (talk) 16:36, 20 August 2020 (UTC)
        • French Wikipedia uses the work as a reference, but cites with page numbers rather than the id. --- Jura 16:41, 20 August 2020 (UTC)
          • So I guess this number is not really notable. stated in (P248) for taxon name (P225) as suggested should work. --Succu (talk) 20:56, 20 August 2020 (UTC)
            • If the names were unique, one might do that. However they are not. I think French Wikipedia just didn't get to the the level where it matters.
              Also, we would have a harder time trying to figure out which ones are missing.
              In any case, while it could also be used as a reference, the primary use would be for main statements with a unique value constraint.
              BTW, As there are identifiers with a-z after the number, I suspect the identifiers are stable between the first and the second edition, but I haven't found a copy of the first edition. --- Jura 04:45, 21 August 2020 (UTC)
            • I see the point made by Succu; catalogue code does the trick (example done for Rosa 'Belle Poitevine' (Q60965265)) M.A. Miron (📬) 04:35, 21 August 2020 (UTC)
              • @Marc André Miron: yes, that could be another option. It would be exquivalent except for the unique value constraint. Also one would have to add slightly more (i.e. the qualifier). --- Jura 04:45, 21 August 2020 (UTC)
                • @Jura1: About the unique value constraint: I noticed that in the book, some species seem to have multiple entries, say for example Rose à coeur jaune that has id 18 and 19. Can't we create two catalogue codes pointing to the same catalogue for any Wikidata item? M.A. Miron (📬) 05:09, 21 August 2020 (UTC)
                  • @Marc André Miron: they might be two different cultivars (see "obtenteurs", also "année" on one), so I'd create two items. If they were same, yes, the two identifiers would be one the same item. The unique value constraint mainly avoids/detects that e.g. "18" appears on two separate items. --- Jura 05:23, 21 August 2020 (UTC)
                  • @Marc André Miron: Les Roses cultivées à L'Haÿ en 1902 ID (P8662) can show how it works out. --- Jura 07:28, 14 October 2020 (UTC)
                    • It didn't work at all. A random example: Rosa alba (Q478530) (=300) has two numbers 137 and 3300. --Succu (talk) 19:07, 22 October 2020 (UTC)
                      • Good pick. Fixed that one: there are indeed two for this: I think it means they planted the same at two places: once in the collection botanique and once in the collection horticole. Cultivars should have unique numbers in Hay's. --- Jura 19:22, 22 October 2020 (UTC)
                        • The point is that these numbers a not intended to be an ID (or a catalouge number). --Succu (talk) 19:56, 22 October 2020 (UTC)
                        • How would you qualify Hay's? --- Jura 21:02, 22 October 2020 (UTC)
                          • Qualify? It's simply a reference (mentioned in). --Succu (talk) 20:58, 23 October 2020 (UTC)
                            • I don't quite see the difference, but Hay's is probably better discussed elsewhere. --- Jura 09:43, 24 October 2020 (UTC)
  •   Support I find catalog codes less useful than dedicated properties. Mix'n'match is harder, constraints are harder, queries are harder.... So when there are enough items, I support making a property. --99of9 (talk) 01:22, 28 September 2020 (UTC)
  •   Support --Tinker Bell 17:59, 22 October 2020 (UTC)

Taxon holotype locationEdit

   Under discussion
DescriptionLocation where the holotype specimen of a taxon is stored.
Representsholotype (Q1061403)
Data typeItem
Domaintaxon (Q16521)
Example 1Pholcus phnombak (Q106573712)Senckenberg Museum (Q706441)
Example 2Nimiokoala greystanesi (Q42602605)Queensland Museum (Q1537684)
Example 3Giant koala (Q2340546)Queensland Museum (Q1537684)
Expected completenessalways incomplete (Q21873886)
See also
  • taxonomic type (P427): the type genus of this family (or subfamily, etc), or the type species of this genus (or subgenus, etc)


Capture information on the location of holotype specimens of taxa. Please be gentle, my first attempt at writing a property proposal and the requirements are far from clear. CanadianCodhead (talk) 15:14, 21 April 2021 (UTC)


  WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

  •   Support, an important property for biology.--Arbnos (talk) 15:33, 27 April 2021 (UTC)
  •   Question Why is this property restricted to holotypes? --Succu (talk) 16:11, 27 April 2021 (UTC)
    @Succu:My intention assuming this was approved was to then create proposals for paratype etc, but as this was my first attempt at creating a proposal, I wanted to ensure I understood the template etc first rather than making the same mistakes over and over in multiple proposals. Perhaps it is worth considering a single property, something liker 'Specimen location' where the type (holotype, paratype etc) is separated by a qualifier and perhaps even the specimen number and link to the relevant webpage should it exist be captured?CanadianCodhead (talk) 14:21, 28 April 2021 (UTC)
    @Succu: what else would you include? --- Jura 17:24, 13 May 2021 (UTC)
    In zoology there is an endless number of types. Types can have a description, a locality, a date, a collector, a collecting number, a herbarium code (here called location), a specimen identifier and so on. I don't think this information should be added as qualifieres to the value of proposed property. A type is not allways a specimen. It could be an illustration too. And we have taxonomic type (P427). I don't think the proposed property is the right way to make progress. --Succu (talk) 15:42, 14 May 2021 (UTC)
    • Ok. Thanks for your input. I guess if only minimal information is available, one could start out with qualifying an unknown value of P427. --- Jura 16:48, 14 May 2021 (UTC)
  •   Question Another modelling option that does not require extra properties is to have items for the holotypes themselves. They could have instance of (P31) holotype (Q1061403) (or paratype or any other types) and some relation to the taxon. It could be also instance of (P31) Giant koala (Q2340546) (considering taxons as classes) or use the qualifier. Or it could use the (rather broad) qualifier "of", as it is done here. There are 329 "types" on Wikidata, and the modelling varies: Anyways, great to see progress towards standardization! TiagoLubiana (talk) 04:28, 7 May 2021 (UTC)

@TiagoLubiana:I agree standardization is a great goal, it is kind of where I was going about the more general property. I do think there could be a couple of issues with making items themselves for specimens. It works well when you know the collection ID number. For example if you known the holotype of species X is Royal Ontario Museum specimen JX-77454-P2, it doesnt work so well in the likely many cases where all you know is the specimen is at the Royal Ontario Museum. You could of course create a generic 'species X holotype' item, but then if you want to do that for things like paratypes where there can be multiple, it gets messy in terms of naming etc.CanadianCodhead (talk) 13:51, 11 May 2021 (UTC)

@CanadianCodhead: I'd be okay with "species X paratype" in the name and a description of where it is in the "description". The greatest benefit is to be able to add extra metadata, like the ID number, but also images and, who collected it, and the like. If there is an article describing an holotype, than one can link the qid of the speciment directly. TiagoLubiana (talk) 20:39, 11 May 2021 (UTC)

@TiagoLubiana: just to restart the discussion, how would you propose capturing this data. Here are 3 real world examples: - Spiclypeus shipporum is a dinosaur known from a single specmen. It is held in the Canadian Museum of Nature as specimen CMN 57081 - Ectatosticta yukuni is a newly described spider species. I will be creating the item for it in a moment. It has a holotype specimen held in the Institute of Zoology at the Chinese Academy of Sciences in Beijing under the catalog # Ar42454 as well as 3 paratype specimens held at the same place using catalog #'s Ar42455, Ar42456 and Ar42457 - Augacephalus ezendami is another spider which has 1 holotype and 1 paratype held at the British Museum of Natural History. So far that is all I know, where they are held, no collection numbers. They dont appear to be available or digitized in the museum's online portal. So how could examples like the above be entered in a consistent manner? CanadianCodhead (talk) 13:48, 19 May 2021 (UTC)

@CanadianCodhead:Do you have the source articles/URLs for that information? I can create an item for each notable specimen and set up links to the institutions and the species. TiagoLubiana (talk) 16:38, 19 May 2021 (UTC)

@TiagoLubiana: The 2 spiders are here and here. The search portal on the Canadian Museum of Nature is offline for some reason as of when I write this. The original paper describing the species which also lists the specimen number is here CanadianCodhead (talk) 16:44, 19 May 2021 (UTC)\
@CanadianCodhead: That is one way to do it: holotype of Ectatosticta yukuni (Q106906682) ; holotype of Augacephalus ezendami (Q106906769). I've also used taxonomic type (P427) to link the species to the types (which is one of the uses on its examples). I believe the same can be done for the paratypes and so on. TiagoLubiana (talk) 17:10, 19 May 2021 (UTC)
@TiagoLubiana: not sure P427 is the right place for the link back on the taxon Q item, that's supposed to be for the type species/genus, not specimen according to its documentation. So for Ectatosticta, that should be Ectatosticta davidi in there. There needs to be a different place for the link back on the species item. CanadianCodhead
Not sure I get the examples in the P427 discussion page. The description for the item in there states ' This is used to indicate the type genus of this family (or subfamily, etc) or the type species of this genus (or subgenus, etc). It is not intended to indicate a type specimen, etc.'CanadianCodhead (talk) 17:31, 19 May 2021 (UTC)
@CanadianCodhead: I agree with you, the usage is not clear. That said, the descriptions here on Wikidata are often imprecise, and things that are semantically close sometimes are mashed up together. Take a look at the properties used for types, it is really a mix: It is reasonable to use P427 (close enough) and in the future the different uses (taxon-taxon and taxon-specimen) can be distilled into specific properties. TiagoLubiana (talk) 18:01, 19 May 2021 (UTC)
@CanadianCodhead: I mean, you can always propose a new property, but usually there is some overhead (as you can see :) ) TiagoLubiana (talk) 18:03, 19 May 2021 (UTC)
@TiagoLubiana: That's kind of the initial problem statement that prompted the proposal. There is no clear or defined way to document specimens. I really am indifferent if we have them done as separate Q items and a single link on the taxon page back to that, or a property with multiple qualifiers. I just see the need for something to do it that is as standardized as much as possible. I'm really not a fan of using properties for purposes that are explicitly stated in their documentation it is not for. That just creates a mess of data.CanadianCodhead (talk) 18:35, 19 May 2021 (UTC)
@CanadianCodhead: You have a good point, I agree with you in theory, but community processes are harder. Anyways, I'd definitely support a new property that takes this burden out of P427 and into a taxon-to-specimen property. Also, maybe you can start a data model page (i.e. the models on where work on sistematization can go beyond just one property. TiagoLubiana (talk) 18:53, 19 May 2021 (UTC)
Remark to holotype of Augacephalus ezendami (Q106906769): According to On some Southern African Harpactirinae, with notes on the eumenophorines Pelinobius muticus Karsch, 1885 and Monocentropella Strand, 1907 (Araneae, Theraphosidae) (Q90007362) the holotype of Ceratogyrus ezendami (Q106907504) is OUMNH-2009-043 from Oxford University Museum of Natural History (Q1760005). --Succu (talk) 19:27, 19 May 2021 (UTC)
Remark to „taxon-taxon and taxon-specimen“: Saying Aaa bbb is the type species (Q252730) of a genus Aaa refers to type specimen (Q51255340) of Aaa bbb. taxonomic type (P427) works fine for me for both types. --Succu (talk) 21:22, 19 May 2021 (UTC)
@TiagoLubiana: I'm not sure if you are proposing trying to create a data model for specimens or taxonomy on the whole. If it is taxonomy, I don't think that is a realistic goal. People have been arguing about how to model taxonomic data since probably the first week the site was launched. Seemingly simple issues like if the label for a Q item should be the scientific name or a common name or if 'Common Loon', 'Common loon' and 'common loon' should be 1 or 3 entries under the taxon common name property lead to vicious arguments.

I'm happy to close out this specific property proposal if the consensus it is better to add specimens as separate Q items and then do a linkback on the taxon Q item is a better approach. Frankly it likely is. But I really oppose using the P427 for the linkback. It's one thing to use a property for something it is somewhat related to, it is a separate really bad precedent and approach however in my mind to use it for something it specifically says it is not for. To my mind it is less an issue about entering data as it is about the mess and uncertainty it creates for querying and retrieving data. It just makes it very difficult to understand what data means in a query etc if a property is being used for multiple completely separate concepts. CanadianCodhead (talk) 15:05, 21 May 2021 (UTC)


   Ready Create
Descriptionidentifier for a plant in Chinese Plant Names Index database of Scientific Database of China Plant Species
RepresentsScientific Database of China Plant Species (Q28416737), Flora Reipublicae Popularis Sinicae (Q5862814)
Data typeExternal identifier
Domainplant (Q756), taxon (Q16521)
Allowed valuesCPNI-[0-9]{3,5}(-[0-9]+)?
Example 1Santalales (Q21851)CPNI-17899
Example 2Urticaceae (Q156332)CPNI-015
Example 3Hemerocallis citrina (Q4261552)CPNI-263-04287
Example 4Murraya koenigii (Q244731)CPNI-079-07878
Expected completenesseventually complete (Q21873974)
Formatter URL$1
See alsoIPNI plant ID (P961), APNI ID (P5984)
Single-value constraintyes
Wikidata projectWikiProject Taxonomy (Q8503033)


identifier for a plant in one database of Scientific Database of China Plant Species (Q28416737) and the databse is based on Flora Reipublicae Popularis Sinicae (Q5862814). This id can be used in zh-wikipedia template Template:CPNI (Q22772775). Kethyga (talk) 05:06, 17 March 2022 (UTC)


Encyclopedia of Cacti species IDEdit

   Under discussion
Descriptionidentifier for a species, subspecies, variety, form, or cultivar of cactus in the Encyclopedia of Cacti
RepresentsEncyclopedia of Cacti (Q111475261)
Data typeExternal identifier
Domainitem; taxon (Q16521)
Allowed values[1-9]\d{0,4}
Example 1Acanthocalycium chionanthum (Q109397105)1
Example 2Ferocactus gracilis (Q150203)11980
Example 3Wigginsia horstii var. juvenaliformis (Q109421079)20355
Example 4Turbinicarpus beguinii subsp. zaragosae (Q93185058)1950
Planned useadding to items edited or created
Number of IDs in source17776 (see
Expected completenesseventually complete (Q21873974)
Formatter URL$1/
Applicable "stated in"-valueEncyclopedia of Cacti (Q111475261)


The Encyclopedia of Cacti (Q111475261) aims to be a comprehensive encyclopaedia for all cacti species. It provides the accepted Latin name for most species, subspecies, variety, forms, and cultivars, with links to all synonyms by which the plant has been known. It contains 441 plant genera and includes 17776 scientific names and synonyms. 6810 taxa and cultivars have individual description sheets, 2237 of which are accepted scientific names, 419 cultivars names and 14934 synonyms. The encyclopedia is illustrated with 12217 plant photos (see UWashPrincipalCataloger (talk) 23:20, 3 April 2022 (UTC)


  Oppose - uncurated database full of errors. --Succu (talk) 18:49, 4 April 2022 (UTC)

Succu can you reference some of these errors? Does this database have more errors than most? Additionally, this database appears to be curated by volunteers...a lot like Wikidata... I see no problem with a crowdsourced database run by enthusiasts. --Crystal Clements, University of Washington Libraries (talk) 23:41, 20 April 2022 (UTC)

PlantFiles taxon IDEdit

   Under discussion
Descriptionidentifier for a taxon in the PlantFiles database
RepresentsPlantFiles (Q111693859)
Data typeExternal identifier
Domainitem; taxon (Q16521)
Allowed units[1-9][0-9]*
Example 1Eutrochium purpureum (Q19848832)11
Example 2Talinum paniculatum (Q7679537)777
Example 3Hosta ʽAbiqua Drinking Gourd’ (Q110765802)2911
Example 4Hemerocallis ʽKwanso’ (Q110767107)40824
Example 5Artocarpus altilis (Q14677)59617
Example 6Jasminum elongatum (Q11076238)250032
Planned useadding to new or existing items
Expected completenessalways incomplete (Q21873886)
Formatter URL$1
Applicable "stated in"-valuePlantFiles (Q111693859)


PlantFiles (Q111693859), part of the Dave's Garden (Q16834568) website, claims to be "the most complete plant database online, with information for new and expert gardeners alike." It includes information on plant species, varieties, and cultivars, including scientific and common names, pronunciation, synonyms, photographs and videos, and gardening information such as hardiness, water requirements, sun exposure, foliage, height, planting spacing, phenology, bloom color and size, propagation methods, seed collecting, and more. UWashPrincipalCataloger (talk) 05:55, 23 April 2022 (UTC)


  •   Support, an important property for botany.--Arbnos (talk) 14:42, 23 April 2022 (UTC) Plants Database IDEdit

   Under discussion
Descriptionidentifier for a taxon in the Plants Database
RepresentsThe Plants Database (Q111693970)
Data typeExternal identifier
Domainitem; taxon (Q16521)
Example 1Zombia antillarum (Q138584)118879
Example 2Rosa 'Crépuscule' (Q83666927)19
Example 3Dianthus acicularis (Q15225951)387647
Example 4Hemerocallis fulva (Q1424440)48484
Example 5Quercus durata var. durata (Q24692235)225952
Example 6Syringa oblata subsp. dilatata (Q24877911)222566
Planned useadding to new and existing items
Number of IDs in source775,360 plants (Cf.
Expected completenessalways incomplete (Q21873886)
Formatter URL$1/
Applicable "stated in"-valueThe Plants Database (Q111693970)


The Plants Database (Q111693970), from the National Gardening Association (Q43895468), includes 775,360 plants, and 721,142 images of plants, in a database that is collaboratively developed by over 4,000 members from around the globe. Entries may include general plant information (habit, sun requirements, water preferences, leaves, flowers, hardiness, size, pollination, etc.), common names, botanical names, and photographs submitted by members. UWashPrincipalCataloger (talk) 06:32, 23 April 2022 (UTC)


  •   Support, an important property for botany.--Arbnos (talk) 14:43, 23 April 2022 (UTC)

Woody Plants Database IDEdit

   Under discussion
Descriptionidentifier for a taxon in Cornell University's Woody Plants Database
RepresentsWoody Plants Database (Q111694088)
Data typeExternal identifier
Domainitem; taxon (Q16521)
Allowed values[1-9][0-9]*
Example 1Quercus rubra (Q147525)209
Example 2Abies nordmanniana (Q148920)299
Example 3Syringa meyeri ʽPalibin’ (Q110767585)313
Example 4Laburnum × watereri (Q12317600)133
Example 5Arctostaphylos uva-ursi (Q208032)26
Example 6Akebia quinata (Q1482093)20
Example 7Abies fraseri (Q1451343)3
Planned useadding to existing and newly created items
Expected completenessalways incomplete (Q21873886)
Formatter URL$1
Applicable "stated in"-valueWoody Plants Database (Q111694088)


Cornell University's Woody Plants Database (Q111694088) contains detailed descriptions of woody plant species, with a focus on woody plants used for landscaping in New York and the Northeast – particularly in challenging urban environments. The detailed information about each species is based on the experiences of Cornell instructors Nina Bassuk in the Horticulture Section of the School of Integrative Plant Science and Peter Trowbridge in the Department of Landscape Architecture. Entries include botanical and common names, ornamental and environmental characteristics, moisture tolerance, diseases, sound clips giving pronunciation and general information, photographs, range maps, and more. UWashPrincipalCataloger (talk) 07:39, 23 April 2022 (UTC)


  •   Support, an important property for botany.--Arbnos (talk) 14:43, 23 April 2022 (UTC)

Macaulay Library taxon IDEdit

   Under discussion
Descriptionidentifier for a bird, mammal, amphibian, or fish taxon in the Macaulay Library wildlife media archive
RepresentsMacaulay Library (Q111982999)
Data typeExternal identifier
Domainitem; taxon (Q16521)
Allowed values[a-z0-9\-]+
Example 1Black-capped Chickadee (Q282687)bkcchi
Example 2Aegolius funereus richardsoni (Q27610655)borowl2
Example 3Ursus americanus (Q122783)t-11036120
Example 4Odobenus rosmarus (Q40994)t-11030303
Example 5Equus burchellii boehmi (Q20908058)t-12030475
Example 6sergeant major (Q2070648)t-10950238
Example 7Aromobatidae (Q55310)t-12030654
Example 8Yosemite toad (Q302397)t-11050888
Planned useadding to existing or new items
Expected completenessalways incomplete (Q21873886)
Formatter URL$1
Applicable "stated in"-valueMacaulay Library (Q111982999)


The Macaulay Library (Q3332600) at the Cornell Lab of Ornithology (Q2997535) is the world's premier scientific archive of natural history audio, video, and photographs. Although the Macaulay Library's history is rooted in birds, the collection includes amphibians, fishes, and mammals, and the collection preserves recordings of each species' behavior and natural history. Access to audio and video recordings in the archive is available for research, educational, and commercial use. Including this property in Wikidata items will provide access to audio, video, and photographs for many species and other taxa. UWashPrincipalCataloger (talk) 08:29, 13 May 2022 (UTC)


has vectorEdit

   Under discussion
DescriptionThe biological group (often a taxon) which works as a vector for this pathogenic biological group . See Wilson et al 2017 (PMC5352812) for different valid perspectives on the concept of vector.
Representsvector (Q107994)
Data typeItem
Example 1Zika virus (Q202864)Aedes aegypti (Q1148004)
Example 2yellow fever virus (Q836749)Aedes aegypti (Q1148004)
Example 3Dengue virus (Q476209)Aedes aegypti (Q1148004)
Example 4Plasmodium (Q130948)Anopheles (Q158597)
Example 5hospital-acquired infection (Q215509)necktie (Q44416) reference Neckties on Physicians: Going the Way of Powdered Wigs (Q112074975)
Planned useConnect manually pathogens and their vectors. Create structure for future integration with databases (e.g. VEuPathDB: the eukaryotic pathogen, vector and host bioinformatics resource center (Q112066091)
See alsohost (P2975), disease transmission process (P1060), natural reservoir of (P1606), has natural reservoir (P1605)


While similar properties are available, there is no clear way to represent pathogen-vector relations on Wikidata.

The pathogen-vector relation is important for understanding all types of diseases, property would make the process of documenting the relation quite straightforward.

Although there are multiple definitions of a vector (see What is a vector? (Q30252972) for multiple perspectives), there is some degree of consensus and the concept is widely used.

TiagoLubiana (talk) 18:28, 18 May 2022 (UTC)


TiagoLubiana 01:35, 16 March 2020 (UTC)
Daniel Mietchen 01:42, 16 March 2020 (UTC)
Jodi.a.schneider 02:45, 16 March 2020 (UTC)
Chchowmein 02:45, 16 March 2020 (UTC)
Dhx1 03:38, 16 March 2020 (UTC)
Konrad Foerstner 06:02, 16 March 2020 (UTC)
Netha Hussain 06:19, 16 March 2020 (UTC)
Bodhisattwa 06:56, 16 March 2020 (UTC)
Neo-Jay 07:04, 16 March 2020 (UTC)
John Samuel 07:31, 16 March 2020 (UTC)
KlaudiuMihaila 07:53, 16 March 2020 (UTC)
Salgo60 09:11, 16 March 2020 (UTC)
Andrawaag 10:12, 16 March 2020 (UTC)
Whidou 10:16, 16 March 2020 (UTC)
Blue Rasberry 15:07, 16 March 2020 (UTC)
TJMSmith 16:15, 16 March 2020 (UTC)
Egon Willighagen 16:49, 16 March 2020 (UTC)
Nehaoua 20:32, 16 March 2020 (UTC)
Andy Mabbett (UTC)
Peter Murray-Rust 00:00, 17 March 2020 (UTC)
Kasyap 02:45, 17 March 2020 (UTC)
Denny 16:21, 17 March 2020 (UTC)
Kwj2772 16:56, 17 March 2020 (UTC)
Joalpe 22:47, 17 March 2020 (UTC)
Finn Årup Nielsen fnielsen) 10:59, 18 March 2020 (UTC)
Skim 11:45, 18 March 2020 (UTC)
SCIdude 15:15, 18 March 2020 (UTC)
Evolution and evolvability 01:23, 20 March 2020 (UTC)
Susanna Ånäs (Susannaanas) 07:05, 20 March 2020 (UTC)
Mlemusrojas 15:30, 20 March 2020 (UTC)
Yupik 20:23, 20 March 2020 (UTC)
Csisc 23:05, 20 March 2020 (UTC)
OAnick 10:26, 21 March 2020 (UTC)
Gnoeee 12:28, 21 March 2020 (UTC)
Jjkoehorst 14:27, 21 March 2020 (UTC)
So9q 08:58, 22 March 2020 (UTC)
Nandana 14:58, 23 March 2020 (UTC)
Addshore 15:56, 23 March 2020 (UTC)
Librarian lena 18:19, 24 March 2020 (UTC)
Jelabra 19:19, 24 March 2020 (UTC)
AlexanderPico 23:34, 27 March 2020 (UTC)
Higa4 02:51, 29 March 2020 (UTC)
JoranL 19:56, 29 March 2020 (UTC)
Alejgh 11:04, 1 April 2020 (UTC)
Will (Wiki Ed)) 17:36, 1 April 2020 (UTC)
Ranjithsiji 04:47, 2 April 2020 (UTC)
AntoineLogean 07:35, 2 April 2020 (UTC)
Hannolans 17:22, 2 April 2020 (UTC)
Farmbrough 21:15, 3 April 2020 (UTC)
Ecritures 21:26, 3 April 2020 (UTC)
  Notified participants of WikiProject COVID-19 - TiagoLubiana (talk) 18:30, 18 May 2022 (UTC)

Andrawaag (talk) 13:57, 25 May 2017 (UTC) DarTar (talk) 13:56, 25 May 2017 (UTC) Jodi.a.schneider Daniel Mietchen (talk) 15:04, 25 May 2017 (UTC) Mikima (talk) 08:21, 26 May 2017 (UTC)  Notified participants of WikiProject Zika Corpus - TiagoLubiana (talk) 18:30, 18 May 2022 (UTC)

Andrew Su
Dan Bolser
Daniel Mietchen
Andra Waagmeester
Elvira Mitraka
Konrad U. Förstner (talk)
Kristina Hettne
Jasper Koehorst
Muhammad Elhossary
Netha Hussain
Layla Michán
Tris T7 TT me
  Notified participants of WikiProject Microbiology - TiagoLubiana (talk) 18:30, 18 May 2022 (UTC)

Support if this does not exist I thought I saw this proposed or created since COVID, but I might be misremembering. It obviously needs to exist. The current description says that a vector needs to be a taxon, but I provided an example otherwise with the necktie example. Objects can be a vector for disease transmission also. Bluerasberry (talk) 17:10, 19 May 2022 (UTC)

Good point. If a necktie can be considered a vector or not depends on the definition, but I agree that it is the case under some definitions. I guess the description should be taken with a grain of salt in this case, but feel free to word it better. TiagoLubiana (talk) 21:12, 19 May 2022 (UTC)

Biochemistry/molecular biologyEdit

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


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

coordination numberEdit

   Ready Create
Descriptionnumber of atoms, molecules or ions bonded to in a molecule or crystal
Representscoordination number (Q397226)
Data typeQuantity
Allowed valuesnatural numbers
Allowed unitsnone
Example 1actinium (Q1121) with ionic radius (P10685)=112 pm and charge number=+3 → 6
Example 2silver (Q1090) with ionic radius (P10685)=100 pm and charge number=+1 → 4
Example 3silver (Q1090) with ionic radius (P10685)=94 pm and charge number=+2 → 6
Example 4oxygen (Q629) with ionic radius (P10685)=142 pm and charge number=-2 → 8
Planned useFill in Informations on ionic radii on the elements


The Property is needed as a Qualifier in combination with a Qualifier of the charge number to discribe the Property ionic radius (P10685) of an Element correctly. See also Wikidata:Property proposal/Ladungszahl. Meinichselbst (talk) 15:21, 25 April 2022 (UTC)


Jasper Deng
Egon Willighagen
Denise Slenter
Daniel Mietchen
Emily Temple-Wood
Pablo Busatto (Almondega)
Antony Williams (EPA)
Devon Fyson
Samuel Clark
Tris T7
Robert Giessmann
Cord Wiljes
Adriano Rutz
Jonathan Bisson
Charles Tapley Hoyt
Peter Murray-Rust
  Notified participants of WikiProject Chemistry

  •   Comment You are proposing these as qualifiers, so this is in the context of the element within a specific molecule or compound? Can you clarify with more complete examples of how you think this would be used? ArthurPSmith (talk) 17:59, 26 April 2022 (UTC)
Hi ArthurPSmith, the ionic radius depends on at least two factors: The charge of the ion and the coordination number. (Also, it depends on high or low spin in some cases, but I do not know how to introduce it.) Such, you have for Silver at least 6 values for the ionic radius:
  • Ag+1 with a coordination number of 4 has an ionic radius of 100 pm
  • Ag+1 with a coordination number of 6 has an ionic radius of 115 pm
  • Ag+1 with a coordination number of 8 has an ionic radius of 128 pm
  • Ag+2 with a coordination number of 4 has an ionic radius of 79 pm (in a square planar molecular geometry)
  • Ag+2 with a coordination number of 6 has an ionic radius of 94 pm
  • Ag+3 with a coordination number of 6 has an ionic radius of 75 pm
By that, the value of i.e. 100 pm for silver does not help anyone. The interestet person needs also the coordination number as well as the charge number. Only with them one can introduce the right value for an ionic radius into the data of an element. As a result, silver (Q1090) would have at least the above stated 6 values for the property ionic radius (P10685). You can find a more or less complete list of ionic radii here.
For further questions, please ask. --Meinichselbst (talk) 20:05, 26 April 2022 (UTC)
  Support Ok, I see the purpose now, thanks. We do have some items that are for the ions themselves (silver cation (Q75008432) I assume is meant to be Ag+1) where maybe the charge would already be specified, but those don't seem to be very plentiful or consistent here, so I guess it's fine to put these statements on the elements. ArthurPSmith (talk) 20:40, 26 April 2022 (UTC)
  Support meanwhile charge number (P10764) has been created. Pamputt (talk) 22:14, 15 May 2022 (UTC)


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


   Under discussion
Descriptionmedical condition for which the net benefit of a medical procedure is expected to be positive
Representscontraindication (Q1848900)
Data typeItem
Domainitems under medical procedure (Q796194)
Example 1liver transplantation (Q1368191)liver angiosarcoma (Q18555157), object has role (P3831)absolute contraindication (Q111771239), as stated in Hepatic hemangiosarcoma: an absolute contraindication to liver transplantation--the European Liver Transplant Registry experience (Q85963796)
Example 2magnetic resonance imaging of the brain (Q13400786)artificial pacemaker (Q372713), object has role (P3831)relative contraindication (Q111771260), as stated in Pacemakers in MRI for the Neuroradiologist. (Q39433692)
Example 3magnetic resonance imaging of the brain (Q13400786)claustrophobia (Q186892), object has role (P3831)relative contraindication (Q111771260), as stated in Pacemakers in MRI for the Neuroradiologist. (Q39433692)
Example 4hormonal contraception (Q7292449)breast cancer (Q128581), as stated in Hormonal contraception use before and after breast cancer diagnosis: A nationwide drug utilization study (Q111771479)
Example 5brimonidine (Q577377)lactation (Q719426), object has role (P3831)absolute contraindication (Q111771239), as stated in Glaucoma Management During Pregnancy and Lactation (Q111771472)
Planned usesystematic interlinking between common medical conditions and common medical procedures
Expected completenessalways incomplete (Q21873886)
Robot and gadget jobsEventually yes, though none are planned in the immediate future
See alsoMost relevant: medical indication (P10630), medical condition treated (P2175), has use (P366). Also related: medical examination (P923), possible treatment (P924), drug or therapy used for treatment (P2176), positive therapeutic predictor (P3354), negative therapeutic predictor (P3355), therapeutic area (P4044), may prevent (P4954)
Wikidata projectWikidata:WikiProject Medicine


Under certain conditions, the risks associated with a medical procedure (be it diagnostic or therapeutic) may outweigh the benefits, in which case the procedure should be avoided. Such conditions are called contraindication (Q1848900)      , i.e. the opposite of indication (Q496997)      . This proposed property would thus be a companion property to the recently created medical indication (P10630)    and was already partly discussed over there. In contrast to that property, I propose to define this one with the qualifier object has role (P3831)   , for which the values absolute contraindication (Q111771239)       and relative contraindication (Q111771260)       should cover most use cases. I think this qualifier should be optional, and I have thus included one example where it is not present. Daniel Mietchen (talk) 00:00, 30 April 2022 (UTC)


ligament insertionEdit

   Under discussion


Like muscle origin (P3490) and muscle insertion (P3491) for muscles Dbult (talk) 13:59, 4 May 2022 (UTC)



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

Computer scienceEdit

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


Please visit Wikidata:WikiProject Geology for more information.



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


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