Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

Start a new discussion
Edit
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2022/05.


taxon common name (P1843)[edit]

taxon common name (P1843) is currently very vague and imprecise, just giving lists devoid of any contextual information other than a language and an optional source reference. Names for animals and plants are frequently highly emotive issues, and the system here needs refinement to accomodate this. Names also vary considerably in whether they are in extensive widespread use, or are only very rarely used; no distinction is currently possible. Some ideas for progress:

  • names derived from demonyms or ethnic slurs considered offensive to some or many people (e.g. n*gger, k*ffir, m*ngol, g*psy, sc*tch, squ*w, p*ki, etc.) need a statement to be used as a reason for deprecated rank (P2241).
  • names commemorating persons not, or no longer, considered worthy of commemoration (e.g. slave holders; see Thick-billed Longspur) also need a statement to be used as a reason for deprecated rank (P2241).
  • names with official status (particularly in the native region of a taxon) need an option for setting as a reason for preferred rank (P7452).
  • names in the USA frequently differ from those in the rest of the English-speaking world (not just '-colored' rather than '-coloured', but also numerous others). It would be helpful if these (notably names sourced from USDA PLANTS ID (P1772)) could be entered as language code en-us rather than en, to indicate they are American usage that may not be used elsewhere. This will need a bot task to convert entries already added.
  • rarely used names (particularly archaic names, e.g. sourced from copyright-expired texts) need some form of tagging to indicate they are no longer in widespread use; some sort of "semi-deprecation" (not necessarily pink background, but will not be picked up by e.g. the VN lists at Commons).
  • factually inaccurate or misleading names also need a similar option for tagging, so that those who wish to strive for accuracy can know those names are not accurate.

MPF (talk) 11:41, 7 April 2022 (UTC)[reply]

I agree about inaccurate names. There should be a general-purpose "incorrect name" property, not limited to taxons. Though modelling the explanations for why is something incorrect might be challenging.
And I need to ask: by "m*ngol", do you mean "Mongol"? I don't see how that's offensive. It's an endonym. --Tengwar (talk) 20:21, 23 April 2022 (UTC)[reply]
@Tengwar: sorry, missed this one - because the term was widely used in the past as a pejorative term for people with Down syndrome (Q47715) - MPF (talk) 22:33, 4 May 2022 (UTC)[reply]
Oh. TIL. But do you believe some taxons were named after the offensive meaning as opposed to the more widespread meaning? --Tengwar (talk) 00:05, 5 May 2022 (UTC)[reply]
@Tengwar: - very unlikely, I'd think; it's just that this particular spelling is toxic for many people. The more usual endonym spelling 'Mongolian' is widely used (as in e.g. Mongolian Lark (Q2522924) or Quercus mongolica (Q1367359)) and is not considered offensive anywhere (as far as I know!) - MPF (talk) 14:29, 5 May 2022 (UTC)[reply]
@MPF: I might be mistaken due to my lacking knowledge of English, but isn't "Mongolian something" named after Mongolia and "Mongol something" named after Mongols? I did a quick search and found some uses of the latter, e.g., Mongol epic poetry (Q107473501) or Mongol campaign against the Nizaris (Q92987578). --Tengwar (talk) 20:54, 5 May 2022 (UTC)[reply]

I think that there could be utility in defining some qualifiers that indicate if, in a given source, one common name is preferred over another. For example, the Database of Vascular Plants of Canada (Q19544711) lists accepted names in English and French along with other synonyms in English and French (for an example, see http://data.canadensys.net/vascan/taxon/7174).

I think using language codes for specific varieties of a language will be fraught with problems. Just because a name is found in an American reference source does not necessarily mean that the usage is restricted to the U.S. For English, there are only Wikimedia codes en-ca, en-gb, and en-us. What about Australian English, New Zealand English, South African English, Singaporean English, etc.? We would need codes for all countries where English is spoken. French only has a specific code for Canadian French and Louisiana French, but not Swiss French, Belgian French, Guinean French, Senegalese French, etc. I think labeling something with a code such as en-ca should only be acceptable if the source specifically states that it is providing a specific language variety of the information (for example, terms found in Dictionary of American Slang (Q48813215) can assuredly be labeled as American English). The U.S. is not the only place in the world that uses "color" vs. "colour." According to this article, "around the world, the American way of spelling is now far more popular."

I also disagree with some of MPF's assumptions about certain words being pejorative, particularly the word "Scotch." The Oxford Lexico website says about this word: "The use of Scotch to mean ‘of or relating to Scotland or its people’ is disliked by many Scottish people and is now uncommon in modern English. It survives in a number of fixed expressions, such as Scotch broth and Scotch whisky. For more details, see Scottish." Under "Scottish" it says "The word Scotch, meaning either ‘of or relating to Scotland’ or ‘a person/the people from Scotland,’ was widely used in the past by Scottish writers such as Robert Burns and Sir Walter Scott. In the 20th century, it became less common. It is disliked by many Scottish people (as being an ‘English’ invention) and is now regarded as old-fashioned in most contexts." There's nothing that says the word is pejorative, just disliked by many Scots. The Collins English Dictionary does indicate that "Scotch" is American English and that its use as an adjective is "sometimes offensive." But its use for a plant name just doesn't seem to me to possibly be offensive. It's not putting down Scottish people. Collins notes "The natives of Scotland refer to themselves as Scots or, in the singular, Scot, Scotsman, or Scotswoman. The related adjectives are Scottish or, less commonly, Scots. Scotch as a noun or adjective is objected to except when used of whisky and in established phrases like Scotch egg and Scotch pine. In the United States, Scotch is often used where the Scots themselves, or some Americans of Scottish descent, would prefer Scottish or Scots." I would suggest that "Scotch elm", like "Scotch egg" and "Scotch pine," falls under the category of established phrases that are not objectionable. UWashPrincipalCataloger (talk) 01:09, 11 April 2022 (UTC)[reply]

MPF's suggestion that name statements should be marked as deprecated because of actual/supposed/conceivable offence is to propose a misuse of deprecation. Deprecation is for statements that were never true. WD does not deprecate data based on "highly emotional" reactions. --Tagishsimon (talk) 01:44, 11 April 2022 (UTC)[reply]
@UWashPrincipalCataloger, Tagishsimon: thanks for your replies. I would certainly support creation of en-au, en-in, en-nz, en-sg, en-za, etc. language codes; I find it strange that they have not been long ago.
Of usage of 'Scot*h', I suggest you visit Scotland and ask people there, how they feel about Americans telling them they must accept American renaming of their native plants for them (and that goes for any other European species where the US naming authorities like USDA and ITIS have changed the native name to something different): it is regarded as [cultural] imperialism, and greatly detested as an insult to their intelligence, the treatment of native rights with contempt. The term may not be pejorative, but it most certainly causes offence when it is suggested (as wikidata sadly now does) to be correct usage. This is a fact, and needs to be recorded in wikidata, for the data to be accurate. If deprecation is not appropriate, then some other form of notation is needed, to indicate that what may be acceptable in some areas, is not in others. Consider for example a German author writing an article in English about Ulmus glabra for a scientific paper, and wanting to mention the English name: how will he know that Wych Elm is the correct name to use, and that 'Scot*h elm' is considered offensive by many, if wikidata provides no clues when he turns to it? This sort of information is very important, and needs to be recorded.
Of the Daily Mail article cited above, a reminder that en:wp banned use of the Daily Mail several years ago as being an unreliable source. This article fits exactly into the sort of "sensationalism and flat-out fabrication" that they were banned for. I certainly would not rate their claim above as trustworthy. - MPF (talk) 15:15, 11 April 2022 (UTC)[reply]

I think several of the reasons suggested for deprecation (or it's opposite) are a matter of opinion, not fact, and that can sometimes be inferred from the source itself.

Notes inserted below each point; @Plantdrew, UWashPrincipalCataloger: - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • Whether a name is archaic is an opinion (when is the cutoff? an arbitrary date is an opinion), and archaicness can be inferred if the source for a common name was published long ago.
  • It may be visible on wikidata if the source is cited with a publication date long ago, but it is not visible (a) if the source is secondary, and more importantly, (b) in details exported from wikidata to other wiki projects - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • That McCown's longspur is deprecated can be inferred from it only being sourced to older versions of IOC, not the most recent (and there is a movement to rename all birds with eponyms, regardless of whether the namesake is worth of commemoration; if that succeeds do we really need to flag some eponymous names as having an unworthy (opinion again) namesake?
  • From which, I conclude that it is reasonable to tag names generally as deprecated, if they are only used in an older version of a source? - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • "Official" status? Who decides that? A government or language academy? A international learned society? A regional learned society? What if a government and international learned society disagree on an "official" common name; will multiple names be flagged as "official"? Picking just one is an opinion. If somebody knows that certain governments or learned societies are in the habit of designating "offical" common names, that can be inferred by having that entity as a source for the common name (admittedly, many people don't know which entities are in the habit of designating "official" common names)
  • It 'just is'; disagreement like you clearly want, just doesn't happen. You're quibbling to try to discredit the near-universal UK concept of one English name being correct, and others incorrect. It's how we do things here. Much the same as formal scientific names, one correct, others invalid synonyms. Many/most other countries in Europe are the same; see e.g. the French wiki page nom normalisé; read it, understand it, and stop trying to apply American concepts of naming ("every vernacular name is of equal status, regardless of its source") to everyone. Wikidata is international, and not the sole preserve of US ideas and concepts. To exclude UK concepts of naming, is contrary to the wiki community ideals of inclusiveness; I, like at least some other UK editors I know, have felt very unwelcome at times on wiki projects for not wishing to submit to US supremacy in ideas and concepts. That should not be happening. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • I will qualify the above, by adding that not everyone in UK holds with these ideas; some prefer the US styles. But equally, the converse is also true, many in US (e.g. American Ornithological Society (Q465985)) adhere to more European concepts of right and wrong in vernacular names. Ditto, CNN (Q48340), in their famous 'Facts First' tweet pointing out that correct naming matters. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • Even in America, you must surely accept that not all vernacular names are of equal validity or status; the policy at en:wp of treating them so is ludicrous. For one example, see white spruce, listing it as "a common name for several species of spruce" without any qualification at all, despite it being the de facto universal standard name for Picea glauca, and virtually never used for either of the other two (likely only as misidentifications). Wikidata should not follow this sort of nonsense; we very badly need some form of distinguishing between widespread, and very minor, uses of names. Without it, lists of names used become worthless, as they become without meaning if the same name is given to multiple taxa. It needs some way of tagging rarely-used names as 'low importance', so that while they can still be found by wikidata's search, they are not automatically exported to other wikimedia projects where they are likely to cause confusion. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • Factually inaccurate? Again, a matter of opinion in deciding what a name accurately refers to in the first place. Is it inaccurate to use the name "lily" for plants formerly, but not currently classified in the family Liliaceae (or should "lily" be restricted only to members of the genus Lilium, let alone any other former/current members of the Liliaceae). The "official" name for plants in the genus Phormium, according to MPF's favorite source, the BSBI, is "New Zealand flax". Phormium isn't at all closely related to "true flax". MPF, get the BSBI to change that before you start complaining about: "Wollemi pine", "prairie dog", "jellyfish", or "water lily" (none of the people that common names are supposed to serve have any clue why the last is sometimes written as "water-lily"; pedants sticking hyphens into common names is not actually helpful). Plantdrew (talk) 05:07, 15 April 2022 (UTC)[reply]
  • Granted that BSBI are not perfect in all of their choices, but overall, their list is widely (close to universally) accepted in UK, and should be followed at least for English names of European native species. Since Phormium is not a European species anyway, BSBI's name is of low relevance; better to follow New Zealand usage, where (as with other NZ endemic plants), the strong trend is to adopt native Maori names into English (in the case of Phormium, 'Harakeke') to remove the misleading names imported by settlers. As for your remark "pedants sticking hyphens into common names is not actually helpful" - that is your opinion, which I find demeaning and offensive, and many (including leading US authorities like American Ornithological Society (Q465985), United States Forest Service (Q1891156), and others) would disagree very strongly with. Sorry, but your turn for not being helpful. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
  • If we have a discussion about whether to record important information, we should look at the sources you could cite for that important information. Having discussions about who's worthy of commemoration within Wikidata should be avoided as much as possible.
To the extend that there is one English name that's better than others, "best rank" is the way we would label that name and not deprecation. ChristianKl
@ChristianKl: - that is certainly a good idea, but as mentioned above, we also need the means to 'half-hide' names that are worse than others. Otherwise, exports from wikidata to other wikimedia projects become excessively cumbersome and increasingly worthless with huge long lists of very rarely used vernacular names that only serve to confuse and mislead users. - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
@MPF: I don't consider names to be worthless, even if they are not in widespread use anymore. Such names were in use at some point. When I find some weird name in an older book (or new book using stylized language), it's useful to be able to find the e.g. plant by that older name. I do see some value in marking names as outdated or offensive, but I wouldn't "half-hide" them. Other projects can either not import/process outdated/offensive names at all or import them with the "outdated" or "offensive" qualifiers.
@Tengwar: - I agree it would be useful to be able to find a plant by an older name; what's at issue, is some way of indicating to users that it is an older name (or in any other way inappropriate), that is unlikely to be understood, if they used it elsewhere outside of wikidata. How would you suggest doing that? - MPF (talk) 22:30, 4 May 2022 (UTC)[reply]
But of course "outdated" is an opinion. It might even be outdated in one region, but not in another region. "Offensive" can be even more of an opinion, depending on the name. Is "wild ass" offensive? Offensiveness can also increase or decrease over time as words shift meanings. There will be arguments and edit wars about all that. It might be better to try to derive some of it programmatically. For example if a name was marked as named after (P138) instance of (P31) human (Q5) and the human in question is marked as someone you consider evil (e.g. slave owner, Confederate soldier, Z (Q111103866) supporter), you can consider the name to be offensive. Same if the name contains a word that you consider offensive.
And I see that you marked "McCown's Longspur" as deprecated. I don't think deprecation is the correct way of modelling offensiveness. Instead, I marked the name as has quality (P1552) offensive (Q76500861). --Tengwar (talk) 19:51, 23 April 2022 (UTC)[reply]
@Tengwar: thanks; is this the best route to follow with other offensive names? - MPF (talk) 22:30, 4 May 2022 (UTC)[reply]
I think yes, until a better solution appears. It's not perfect, but better than deprecation. Marking names in this way should make it possible to find them in the future and mark them in a better way. --Tengwar (talk) 00:09, 5 May 2022 (UTC)[reply]
Thanks! What would be the best ways to mark other names, such as archaic, or inaccurate / misleading, vernacular names please? Presumably 'has quality' again, with what qualities? - MPF (talk) 22:24, 10 May 2022 (UTC)[reply]
I'm also doubtful about whether this is the best place for the discussion. Wikiproject Taxonomy would likely be better. ❪✉❫ 10:58, 15 April 2022 (UTC)[reply]
I've no objection to its being moved there, if that is generally felt to be the best place - MPF (talk) 22:30, 21 April 2022 (UTC)[reply]
@Tengwar: I don't think you should add has quality (P1552) offensive (Q76500861) without any source. Doing original research about what's offensive and what isn't on Wikidata is a recipe for drama. ChristianKl ❪✉❫ 14:57, 7 May 2022 (UTC)[reply]
@ChristianKl Previously that entire statement was marked as deprecated by @MPF. Un-deprecating it and marking as offensive was an improvement. I agree that the current state still needs to be improved. For example, currently a source for the offensiveness cannot be added, as Wikidata does not support adding sources to qualifiers. If you can improve the current state further, please do so. --Tengwar (talk) 19:21, 7 May 2022 (UTC)[reply]
@Tengwar: Sources apply to the full statement. You can apply the source to the statement. Without a source I would suggest to simply remove it. If MPF wants to do something with it, that process should start with a source.
Adding ways to model to replace deprecation isn't an improvement because there's a chance that the bad way to model it will be copied by people to other parts of Wikidata. ChristianKl ❪✉❫ 00:36, 11 May 2022 (UTC)[reply]
I have to ask for clarification. Do you want to:
  1. temporarily keep this way of modelling offensiveness (but with added source) and devise a better way of modelling it later, or
  2. immediately get rid of this way of modelling offensiveness and devise a better way of modelling it later?
Because the first part of your post suggests the former, but the second part of your post suggests the latter.
@MPF: If you have sources for the offensiveness of "McCown's Longspur" name of Thick-billed Longspur (Q263740), please add them to the statement about that name. --Tengwar (talk) 21:32, 12 May 2022 (UTC)[reply]
@Tengwar: - reference here. I'm not sure how best to add it to the statement. - MPF (talk) 22:32, 12 May 2022 (UTC)[reply]
@MPF, @ChristianKl: Source added. Please improve if needed. --Tengwar (talk) 13:54, 14 May 2022 (UTC)[reply]
@Tengwar: Thanks! Any suggestions for suitable tagging for other rarely-used 'uncommon' names? The whole system here remains a mess with so many names added as "common" names which are not in common use at all, but included because they have been used once, somewhere, maybe a long time ago, in a citeable source. The result is, wikidata users can't know easily which name is the right one to use. MPF (talk) 09:06, 20 May 2022 (UTC)[reply]
If there is one common name that is better than the others, perhaps its rank should be set to preferred? (With an appropriate reason for preferred rank (P7452) value to make it clear what makes it the preferred name.) --Tengwar (talk) 14:56, 22 May 2022 (UTC)[reply]
@Tengwar: Thanks! For someone who struggles with wikidata's complex formulations, how do I record that appropriate reason for preferred rank (P7452), please? Out of curiosity, why should 'Deprecated' not be used (as stated above!), if 'Preferred' can be used? I had assumed the two were counterpoise to each other (they list each other as complementary property (P8882)!); if a particular name can be set as 'Preferred' for reason of being a good name (e.g. standard use), then why can't a name be set as 'Deprecated' for reason of being a bad name (e.g. offensive, or misapplied)? - MPF (talk) 11:46, 25 May 2022 (UTC)[reply]
AFAIK preferred means "best value" (most recent, most accurate, HTTPS link as opposed to a HTTP link, etc.), while deprecated means "not true". There's no "true but discouraged" rank other than not being preferred while some other value is preferred.
Just add reason for preferred rank (P7452) as a qualifier to a preferred statement with an appropriate reason. list of Wikidata reasons for preferred rank (Q76637123) has some reasons for preferred rank, but I'm not sure if the list is exhaustive. --Tengwar (talk) 18:56, 25 May 2022 (UTC)[reply]
@Tengwar: Many thanks! Although this disparity in application sounds odd, I'll try to follow it. But we really do need (and badly) a "true but discouraged" rank, to deal with a variety of 'bad' names (most importantly offensive ones, but also names liable to cause confusion for any definable reason, such as a name misapplied to a second species when it is usually used for a different species, or geographically or taxonomically misleading names, or archaic names no longer widely used). Any chance this could be instituted? - MPF (talk) 21:58, 25 May 2022 (UTC)[reply]
Well, you could propose such a new rank, but I have no idea what is the best place to propose it. Perhaps Wikibase's issue tracker? --Tengwar (talk) 21:31, 26 May 2022 (UTC)[reply]

Amir Temurning oʻzidan oldingi shajarasi[edit]

<Amir Temurning oʻzidan oldingi shajarasi. (Q111870802)>

Tarix  – The preceding unsigned comment was added by Ravshanbek Tohirov (talk • contribs) at 06:55, 8 May 2022 (UTC).[reply]

Call for papers: Wikidata workshop at ISWC 2022[edit]

Dear colleagues,

Please find here the link to the Call for Papers for the scientific Wikidata workshop at ISWC 2022. Papers are due on July 29, and the workshop takes place on October 24, online. We look forward to your submissions. https://wikidataworkshop.github.io/2022/

Cheers, Ls1g (talk)

YouTube channel ID (P2397)[edit]

How to add user account url (youtube.com/user/) if there is no channel? Sometime ago it was possible to get url of channel from video page but it doesn't works now. Eurohunter (talk) 10:45, 22 May 2022 (UTC)[reply]

is it possible to have a user link but not a channel? can you give an example? you could use website account on (P553) with website username (P554). BrokenSegue (talk) 16:51, 22 May 2022 (UTC)[reply]
yes I have come across this before. for example: https://www.youtube.com/c/ (enter the channel name here).
useful website:https://tools.codeofaninja.com/find-youtube-channel-id RVA2869 (talk) 08:36, 29 May 2022 (UTC)[reply]

Conflation or typo?[edit]

Michał Rogoziński (Q111359588) I can't figure out if this is a conflation or a typographical error, any guesses? --RAN (talk) 18:09, 22 May 2022 (UTC)[reply]

As we have one source giving a date of birth a century after another source gives a date of death, I'd normally suggest separating them into separate items. However, what is the claim to notability here? The item has no incoming links other than error reports and no information besides the name and status as human. I'd be tempted just to delete if it wasn't generated from mix'n'match (it will just get recreated later). From Hill To Shore (talk) 20:01, 22 May 2022 (UTC)[reply]
If the only thing we know about a person is in doubt, then better just to delete the item — Martin (MSGJ · talk) 11:26, 23 May 2022 (UTC)[reply]
  • It looks like User:Palotabarát has split them into two entries, resolving the problem of dying before he was born. --RAN (talk) 01:33, 23 May 2022 (UTC)[reply]
Its not typo, it's my wrong match on MnM (it is repaired now). Per Nukat IDs they are two persons. Matlin (talk) 12:12, 28 May 2022 (UTC)[reply]

When/how do you expect to start replacing wikipedia facts with wikidata ones, and then maintaining them.[edit]

At the moment it seems you are still populating Wikidata with Wikipedia facts, but there seems little move to replace the tables, infoboxes etc in Wikipedia with templated SPARQL queries. If for a fact Wikipedia has 90% coverage, and Wikidata 80% coverage, with 70% overlap, how do you envisage getting Wikidata to 95% coverage with complete overlap, replacing Wikipedia information with templates and getting the Wikipedia editor community, both dedicated and casual, to add facts here rather than there. Historical facts could have clear completeness targets (given the vagaries of knowing the past), but ongoing facts need a constant update cycle.

I bet Wikipedians rapidly updated all the Football stats at the end of the English Premier League yesterday, but how long will it be until wikidata catches up, and will it be done by the same fannish editors? Vicarage (talk) 09:21, 23 May 2022 (UTC)[reply]

How language wikipedias use wikidata is up to them; wikidata is not in a position to force language wikis to use its data, and so has no particular plans in this regard. EN wikipedia is well known for having many Luddite editors fighting an ill-conceived battle against the use of wikidata on EN W, which is why WD gets used, sometimes, for infoboxes, sometimes for CiteQ, and rarely if ever for data tables.
WD does take a lot of data from WPs, but far, far, far, far more from non-WP sources. WP and WD move at different speeds; it's excellent if WP has completed its data intake for the the English Premier League's most recent season, but the reality is that both WP and WD are vastly incomplete and have patchy coverage; one will excell at one thing, the other at another thing. --Tagishsimon (talk) 09:49, 23 May 2022 (UTC)[reply]
Even if WD were complete and more data-reliable than any WP language on any topic, often WP-editors would likely refuse to publish data from a templated linked WD query. WP-editors would prefer typing a table with raw values rather than pick structured data (and sometimes more fresh data !). I've experienced that with airport statistics graphs refused on German wikipedia and with subways neighbour stations often refused on french wikipedia for some people prefer to type rather than rely on automatic templated tables from WD.
Other example is the coordinates in infobox where WP-people would prefer to type raw coordinates rather than rely on coordinate location (P625). Etc....... Bouzinac 💬●✒️●💛 10:41, 23 May 2022 (UTC)[reply]
NIH is rearing its head here. Wikidata really needs a good showcase of its possibilities, as the raw data is clumsy, and Reasonator, while better, would still not be your first choice to find anything. If Wikipedians can't be persuaded to use wikidata, who can, as the SPARQL system is as difficult to use as it is powerful. If wikidata is the glue that binds the information world together, as I guess we all hope, you need to make it attractive enough so all factual sites want to have an infobox using it, and the promise that local administrators don't need to maintain changing common data, as others will. But they will need a roadmap to replace their parochial data with yours. Are there Wikipedia pilot projects that have devolved their data to Wikidata? If not this does not bode well for the project. Vicarage (talk) 11:33, 23 May 2022 (UTC)[reply]
Wikidata is used to a different extent by various projects but there is also substantial difference between subject areas (I have seen some positive comments on some of our biology data). I don't think we need to invoke the words, "this does not bode well for the project" as there are many uses for Wikidata and we will continue to serve a purpose even if some projects don't use our data as well as it could be used. Some of the concerns raised by English Wikipedia are valid as most of their manually inserted data is referenced but much of our equivalent data is unreferenced. From their perspective, why should they replace their high quality data with our lower quality data? As our data quality/referencing improves over time and new tools or demonstrations show how our data can be used effectively, there will be greater adoption. If you want to campaign now for greater adoption of Wikidata by other Wikimedia projects, there is nothing to stop you. However I for one am focused on improving data quality and will leave improving adoption to others. From Hill To Shore (talk) 12:06, 23 May 2022 (UTC)[reply]
In Russian Wikipedia, the Wikidata module is quite elaborate and takes much data from WD (for example, dates of birth and death for people, neighboring stations for railway and metro stations, coordinates, etc.) This module is used quite extensively.
Still, there are many users who are stongly against taking data from WD and who never fail to mention this (which resembles "Carthago delenda est (Q611895)"). Michgrig (talk) 13:07, 29 May 2022 (UTC)[reply]

Places of Worship in Scotland[edit]

Scottish Churches Heritage Research are in the initial stages of adding data from their existing database to Wikidata. This is a place to discuss any issues with the uploaded data, or suggestions for improvements  – The preceding unsigned comment was added by PeterK147 (talk • contribs).

For starters, it would be nice to explain what the data are, where they are stored, what is their license, and if you have experience with reconciliation and mass import. Or consider creating a project page dedicated to your initiative. Thanks.--Vojtěch Dostál (talk) 17:42, 23 May 2022 (UTC)[reply]
It's mainly an ID afaics - POWiS ID (P7659) & https://w.wiki/5CLg - ... all of the reconciliations that I've checked so far - only a small handful - check out and are well done - e.g. Q56622277#P7659; nice & useful qualifiers. --Tagishsimon (talk) 18:06, 23 May 2022 (UTC)[reply]
Thank you for this, and apologies for the lack of clarity in the original posting. I am a newcomer to Wikidata, and in truth I thought I was creating a Project page! More work is obviously needed. PeterK147 (talk) 11:37, 24 May 2022 (UTC)[reply]

Airth Old Parish Church - merge suggestion[edit]

Q17571498 and Q15106331 both seem to refer to the same historic site. I suggest that they are merged.

PeterK147 (talk) 17:16, 23 May 2022 (UTC) Peter Kershaw (Scottish Churches Heritage Research)[reply]

These were merged 20 days ago. Vojtěch Dostál (talk) 17:40, 23 May 2022 (UTC)[reply]
Thank you PeterK147 (talk) 11:34, 24 May 2022 (UTC)[reply]

Please merge[edit]

Dundas Church (Q15109941) and Grangemouth, Bo'ness Road, Dundas Church And Hall (Q17571276) are the same location. Please merge: Q17571276 is the better entry.

PeterK147 (talk) 11:33, 24 May 2022 (UTC)[reply]

Strictly speaking Dundas Church and Hall (Q17571276) is about the church and the hall, so Dundas Church (Q15109941) is part of that — Martin (MSGJ · talk) 14:09, 25 May 2022 (UTC)[reply]

2-way syncing with Zotero?[edit]

Zotero reference manager is spreading and it makes easy to share references to Wikidata through Quickstatement. I contributed over 11,000 references and I'm glad to see editors and bots improve them.

So, I have 2 questions:

1) how to sync my Zotero library with Wikidata items seamlessly (it would help Wikidata greatly if Zotero users' constant curation of their libraries updates Wikidata items constanly)

2) how to automatically import updates to Wikidata items into my Zotero library (this would incentivize Zotero users to link up)

Thanks //() (talk) 14:59, 24 May 2022 (UTC)[reply]

Help please: Female genitalia WD item[edit]

I am looking for a WD item to add q:Female genitalia to the list of wikis, but I don't seem to be able to locate such a WD item. Thanks in advance, Ottawahitech (talk) 12:37, 25 May 2022 (UTC)[reply]

Created female genitalia (Q112127847) — Martin (MSGJ · talk) 13:59, 25 May 2022 (UTC)[reply]

Merge: Amalek (Q372091) and Amalek (Q16010675)[edit]

These two can be merged, but I am not experienced enough to execute it (following https://www.wikidata.org/wiki/Help:Merge) -- there are errors during merge process. Could you help?

One appears to be a tribe or ethnic group. The other a biblical figure (who, I speculate, gave rise to the 'ethnic group'). So they are not the same concept and they should not be merged. --Tagishsimon (talk) 08:32, 26 May 2022 (UTC)[reply]

subterranean river[edit]

subterranean river (Q1140845) is currently in the subclass tree of food (Q2095), inheriting via

subterranean river (Q1140845) subclass of (P279) groundwater (Q161598).

What's the best way to fix this? Subterranean rivers are a kind of groundwater, but should not be in the general subclass tree of drinking water (Q7892) and therefore food (Q2095) -- given that we don't classify rivers that way.

Thanks in advance for your suggestions. Jheald (talk) 21:30, 26 May 2022 (UTC)[reply]

Pretty much everything I read on en:Groundwater suggests to me that a subterranean river is distinct from and excluded by the definition of the characteristics of groundwater. en:Subterranean_river explicitly distinguishes subterranean river from waterflow associated with aquifiers. --Tagishsimon (talk) 21:48, 26 May 2022 (UTC)[reply]
OK thanks. I've removed the subclass of (P279) statement (diff). Jheald (talk) 09:36, 27 May 2022 (UTC)[reply]
@Tagishsimon: So now any thoughts on Barrow Blow Wells (Q96782643) -> artesian aquifer (Q177734) -> groundwater (Q161598) -> ... -> food (Q2095) ? Jheald (talk) 09:47, 27 May 2022 (UTC)[reply]
@Jheald: I've removed groundwater (Q161598) -> fresh water (Q102192), again on definitional grounds; groundwater is not exclusively "naturally occurring water with low concentrations of dissolved salts". --Tagishsimon (talk) 09:57, 27 May 2022 (UTC)[reply]

Revisions to the Universal Code of Conduct (UCoC) Enforcement Guidelines[edit]

More languages • Please help translate to your language

Hello all,

We'd like to provide an update on the work on the Enforcement Guidelines for the Universal Code of Conduct. After the conclusion of the community vote on the guidelines in March, the Community Affairs committee (CAC) of the Board asked that several areas of the guidelines be reviewed for improvements before the Board does its final review. These areas were identified based on community discussions and comments provided during the vote. The CAC also requested review of the controversial Note in 3.1 of the UCoC itself.

Once more, a big thank you to all who voted, especially to all who left constructive feedback and comments! The project team is working with the Board to establish a timeline for this work, and will communicate this next month.

Members of the two prior UCoC Drafting Committees have generously offered their time to help shape improvements to the Guidelines. You can read more about them and their work here, as well as read summaries of their weekly meetings in 2022.

Wikimedians have provided many valuable comments together with the vote and in other conversations. Given the size and diversity of the Wikimedia community, there are even more voices out there who can give ideas on how to improve the enforcement guidelines and add even more valuable ideas to the process. To help the Revisions committee identify improvements, input on several questions for the committee’s review is requested. Visit the Meta-wiki pages (Enforcement Guidelines revision discussions, Policy text revision discussions) to get your ideas to the Committee - it is very important that viewpoints are heard from different communities before the Committee begins drafting revision proposals.

On behalf of the UCoC project team
--YKo (WMF) (talk) 06:26, 27 May 2022 (UTC)[reply]

2022 Board of Trustees Call for Candidates is now closed[edit]

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

The 2022 Board of Trustees election Call for Candidates has now closed. This Call led 12 candidates from the community to submit their applications. Learn more about the 2022 Board of Trustees candidates.

The Analysis Committee will now consider the candidates’ applications with the skills and criteria provided by the Board. The trustees seek certain skills and competencies to improve the capacity of the Board. After the Analysis Committee completes their review, the ratings of each candidate will be published. These ratings are for informational purposes only.

For more information about the 2022 Board election, you may find the timeline, voting information and other ways to get involved on Meta-wiki.

Thank you for your support,

Movement Strategy and Governance on behalf of the Elections Committee and the Board of Trustees--YKo (WMF) (talk) 06:31, 27 May 2022 (UTC)[reply]

Property aliases[edit]

Does anyone else feel that the number of aliases on inception (P571) is excessive? — Martin (MSGJ · talk) 08:06, 27 May 2022 (UTC)[reply]

No. See also Postel's law. They're predicated on the robustness principle ('be liberal in what you accept') such that users searching for inception will find it. They're not constrained by a principle of concern about "excess", which is at best a cranky subjective thing. --Tagishsimon (talk) 08:14, 27 May 2022 (UTC)[reply]
Two questions: What harm do you think having that number of aliases does; and which of them do you think are not valid? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 27 May 2022 (UTC)[reply]
Even if the aliases are valid, this still indicates that we might be conflating too many things into one property. See Property talk:P571#1 word inception for 58 different Words and the related property proposals for "construction start" and "incorporated" for some recent discussion about this. Vahurzpu (talk) 21:15, 27 May 2022 (UTC)[reply]
Well, no, it doesn't indicate that at all; rather, the discussion & proposals seem to be an admixture of idontlikeit and ihavennotreallythoughtaboutitverydeeply. I don't see any real problem analysis nor any options analysis, just a supposed bright idea which some people are mistaking for a magic wand. Briefly, there are a couple of ways WD's RDF can go so as to convey meaning: 1) more & more specific properties, such that there's a silo for everything. 2) general properties used in conjunction with qualifiers that impart specificity. Option 1 is really just an expression of the narcissism of small differences, introduces all manner of complexity and additional layers of ambiguity (e.g. in reporting; in users hunting for the most appropriate of a deck of date properties) and that way madness and a degraded wikidata lies. Option 2 works very well and lends itself to reporting b/c the core data uses a single predicate rather than one of a growing set of similar predicates. And under option 2 - which is the way WD mainly operates - one should expect, welcome and add to long lists of aliases. --Tagishsimon (talk) 23:26, 27 May 2022 (UTC)[reply]
Amusingly, the thread below - member_of vs. part_of - exactly illustrates the pitfall of the 'more specific property' panacea. 'Member of' does not add anything that was missing from 'part of', but now we have two properties and users will use one or the other, with little prospect of consistency. The new property proposer's answer to RAN's question would be to coin a new property for 'member of a comedy team'. --Tagishsimon (talk) 00:00, 28 May 2022 (UTC)[reply]
The distinction between inception and start_time was never made clear, adding more properties is likely to have more confusion. Inception for a project that needs to win support already has multiple values (idea, proposal made, win, construction start, opening) but these are best dealt with by qualifiers to significant_event than new properties. Keep timelines within one property. Vicarage (talk) 06:17, 28 May 2022 (UTC)[reply]

Illogical constraint warning[edit]

Screenshot of constraint warning: "official website = no value"; "required qualifier constraint = This official website statement is missing a qualifier language of work or name."

Can we set constraints in a way that they don't apply to "no value" statements? Or is this a software bug? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:17, 27 May 2022 (UTC)[reply]

Kestrel/Common kestrel[edit]

I'm tri-lingual (with limitations) and just now I wanted to find the Dutch word for en:Kestrel. For some reason I didn't use google translate but went to the English language WP. To my surprise there wasn't a Dutch link under languages but there was a German 1 de:Turmfalke. However I stumbled on a Dutch link under languages there. I clicked nl:Torenvalk and there I found a English language link under languages to en:Common kestrel! My experience on Wikidata is limited but I thought something was wrong here and wanted to let you guys know. --Dutchy45 (talk) 15:36, 27 May 2022 (UTC)[reply]

@Dutchy45: Thanks for posting the above. The English wikipedia article en:Kestrel is about the group of birds known as Kestrals - cf. en:Kestrel#Groups. The DE and NL articles you point to are for Falco tinnunculus, the Common Kestral - i.e. a subset of the Kestral group. DE and NL do not seem to have a counterpart to the EN Kestral article; EN does have a counterpart for DE and NL's Falco tinnunculus, in en:Common_kestrel. So interwiki links are working as expected, but the result can provoke the sort of puzzlement you've experienced. Perhaps one part UI limitation, one part caveat lector. --Tagishsimon (talk) 19:23, 27 May 2022 (UTC)[reply]

ISOCAT[edit]

ISOCAT id (P2263) somewhy appear on item pages in «Statements» section but not in «Identifiers» section. 217.117.125.83 17:01, 27 May 2022 (UTC)[reply]

member_of vs. part_of[edit]

When people are members of a group of performers, should we be using member_of=Three_Stooges or part_of=Three_Stooges. Initially we only had part_of, but now we have the more precise member_of, should we switch them all? --RAN (talk) 23:52, 27 May 2022 (UTC)[reply]

  • Unlike Tagishsimon I'm a fan of "member of", mainly because it doesn't require or encourage the inverse "has part". It's pain maintaining both sides of the relationship with roles, start/end dates, etc. At least for musicians, that are members of musical groups, I think the "member of" property is a great choice. Moebeus (talk) 00:50, 31 May 2022 (UTC)[reply]

How to find all my contributions except automated works?[edit]

I made too many contributions about linkng authors from scholary articles by author-disambiguator. So I want to all my contributions except automated works. ChoKukSuho (talk) 05:59, 28 May 2022 (UTC)[reply]

@ChoKukSuho: If you expand the "Search for contributions" icon there is a "Tag filter" - you probably want "wikidata-ui" (or "Wikidata User Interface"). ArthurPSmith (talk) 01:13, 29 May 2022 (UTC)[reply]

Vandalism not being detected[edit]

Twice in recent days I have found vandalism that has not been detected, nor repaired, for some time. this lasted for nine days (and is particularly egregious, changing the name of a district to its adjacent neighbour), while this was done in February. Both items are linked from several others, and used in Commons' infoboxes.

Is this symptomatic of a wider issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:05, 28 May 2022 (UTC)[reply]

  • I'm sure the problem is worse than any one person can notice, with hundreds of millions of items and a very limited volunteer pool. This personal attack on a living politician was in place for more than a month. This destructive edit was in place for three weeks. This childish edit was in place for 23 days. Label or description vandalism might get overlooked if it's in a language unknown to the reviewer, and while vandalism in popular items (celebrities, countries, major planets, etc.) is likely to be quickly detected and reverted, who knows how many obscure items (minor battles, insect species, unmarried offspring of noble families, etc.) have longstanding intentional errors just waiting to contaminate the information ecosystem. -Animalparty (talk) 18:31, 30 May 2022 (UTC)[reply]

Wikidata[edit]

How do you import data

Fighting with a bot[edit]

At Category:Christian Kabbalah (Q9179029) I find myself at risk of edit war with a bot that keeps connecting Commons-category disambiguation page commons:Category:Cabalism to this item. I don't know how to stop the bot from repeating this error. - Jmabel (talk) 20:14, 28 May 2022 (UTC)[reply]

@Mike Peel — Martin (MSGJ · talk) 20:38, 28 May 2022 (UTC)[reply]
@Jmabel, MSGJ: Should be fixed now? Removing the link from enwiki was good, but you also needed to remove the P373 value from here, now done. Thanks. Mike Peel (talk) 21:11, 28 May 2022 (UTC)[reply]
I made this further edit. Let's see if it finally sticks. I presume I will not be considered to be edit-warring here. - Jmabel (talk) 21:46, 28 May 2022 (UTC)[reply]

Bot adding wrong description to items[edit]

Hi, I'm an administrator on pi.wikipedia. Whenever I connect a page to an item, a bot will come and add descriptions which make no grammatical sense at all. How & where do you fix that so bots add the sensible description? Thanks! CX Zoom (talk) 11:00, 30 May 2022 (UTC)[reply]

@CX Zoom Please contact the bot owner - or if you cannot find out who the owner is, please state the bot's username here and we will try to help you. Vojtěch Dostál (talk) 11:39, 30 May 2022 (UTC)[reply]
Currently it's just User:MatSuBot so far, but in the past several bots were involved in this. In fact, same bad descriptions were added manually way back in 2013, when Wikidata just started. (please see below)CX Zoom (talk) 18:08, 30 May 2022 (UTC)[reply]
@CX Zoom: Can you link to a few examples, please? Bovlb (talk) 19:39, 30 May 2022 (UTC)[reply]
Please see Special:Diff/1650286920 & Special:Diff/1650365142 as examples. CX Zoom (talk) 21:00, 30 May 2022 (UTC)[reply]
In both of those examples, the bot is copying the name of the piwiki pages into the label for the item. As the piwiki page names include a mixture of native script and latin script, these two scripts are then shown in the label. I am not familiar with the native language of piwiki. What would you suggest as the correct label for the bot to insert in these cases? If there is a consistent method of choosing the correct label, the bot owner may be able to automate it. From Hill To Shore (talk) 21:41, 30 May 2022 (UTC)[reply]
I'm sorry, I misinterpreted the bot's edits, but the point is that pi & sa descriptions across every Wikidata item on a Template is wrong. They just don't make any sense at all. Thanks! CX Zoom (talk) 22:27, 30 May 2022 (UTC)[reply]

Wikidata weekly summary #522[edit]

Wikidata-logo-en.svg
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Other Noteworthy Stuff
    • Want to know more about Abstract Wikipedia & Wikifunctions? You can now subscribe to the weekly newsletter and get a friendly reminder every time a new issue is published!
    • Radioactivity map: Mind map about radioactive radiation built by importing from Wikidata with InfoRapid KnowledgeBase Builder
  • Development
    • Wikibase REST API: Expanding statement reading routes (a single statement specified by ID (phab:T307087), all statements of an item (phab:T305988), a single statement for a specific item (phab:T307088))
    • Fetch revision metadata and entity data separately in all use cases (phab:T307915, decision)
    • Update installation instructions in WikibaseLexeme.git readme file (phab:T306008)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 15:21, 30 May 2022 (UTC)[reply]

Featured queries?[edit]

In Wikipedia, we have featured articles and good articles labels. In Wikidata, we have showcase items. Writing a good query in Wikidata is also difficult. Why not creating a label for a featured query? It could be useful. What do you think? PAC2 (talk) 20:51, 30 May 2022 (UTC)[reply]

WD does not store queries, in the way that it stored items, and language wikipedias store items. So there isn't a need for a label for featured queries. The weekly wikidata newsletter (above) has a section for reports this week; and there is the Wikidata:SPARQL query service/queries/examples page - albeit that's not much maintained. Beyond that users write and sometimes share better or worse reports. --Tagishsimon (talk) 21:46, 30 May 2022 (UTC)[reply]
@PAC2 Do you mean something like Wikidata:Showcase Queries? Ainali (talk) 22:18, 30 May 2022 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1650989091"