Wikidata:Project chat

(Redirected from Wikidata:PC)

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

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

Template:Motoarchive resolved section


UCI code of cycling team (P1998)Edit

UCI code of cycling team (P1998) 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)

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)
@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)
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)
@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)
@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)

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)

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)
@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)

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)
  • 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)
  • 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)
  • "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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
@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)
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)
@Tengwar: thanks; is this the best route to follow with other offensive names? - MPF (talk) 22:30, 4 May 2022 (UTC)
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)
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)
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)
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)
@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)
@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)
@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)
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)
@Tengwar: - reference here. I'm not sure how best to add it to the statement. - MPF (talk) 22:32, 12 May 2022 (UTC)
@MPF, @ChristianKl: Source added. Please improve if needed. --Tengwar (talk) 13:54, 14 May 2022 (UTC)
@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)
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)
@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)
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)
@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)
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)

Amir Temurning oʻzidan oldingi shajarasiEdit

<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).

Q91313507Edit

user:Benedifan has edited Karolina Protsenko (Q91313507) replacing Ukrainian to Russian on name in native language (P1559), native language (P103) and languages spoken, written or signed (P1412). I have checked some other people from Ukraina and there is Ukrainian instead of Russian, for example Andriy Shevchenko (Q41244). Why? --Gatto bianco (talk) 17:36, 8 May 2022 (UTC)

I have found no source for name in native language (P1559) and native language (P103), so I deprecated the values; for languages spoken, written or signed (P1412) I found one source. --Epìdosis 20:19, 8 May 2022 (UTC)
@Gatto bianco, @Epìdosis The history of this item shows that a lot of statements were removed from it. I think we should restore them and, if they have no source, mark as deprecated with not been able to confirm this claim (Q21655367) as the reason. We should also contact the users who removed statements and ask them to use deprecation in the future. What do you think about it? --Tengwar (talk) 22:58, 9 May 2022 (UTC)
Time-consuming, but probably best solution. --Epìdosis 07:41, 10 May 2022 (UTC)
I would prefer to completely remove disputed unsourced statements, especially for living persons. Otherwise anything stated without source by anybody could stay forever even if completely false. See also Wikidata:Living people. --Dipsacus fullonum (talk) 12:54, 10 May 2022 (UTC)
@Dipsacus fullonum: Parts of that linked policy are surprising. I was told that incorrect statements should not be removed, but deprecated instead, as marking statements as deprecated has meaning. For example having a deprecated statement that someone speaks language X (with a reason for deprecated rank (P2241) incorrect value (Q41755623)) means that this person does not speak language X. This is both informative and prevents readding of the incorrect statement by someone thinking it's correct. Yes, it stays forever, but it stays explicitly marked as false, so everyone knows it's false.
That policy says that challenged unsourced statements "may be subject to removal", so I guess there is some leeway. But I still find that policy surprising. I can understand that some statements could be used to slander a person, so I understand their removal instead of deprecation - they are vandalisms and unlikely to be readded by well-meaning users. But normal statements like language spoken? I see no negatives (and few aforementioned positives) of leaving them deprecated.
BTW since she speaks Russian and English, it's very likely that her native language is Russian, unlikely that it's English and impossible that it's Ukrainian. --Tengwar (talk) 21:38, 15 May 2022 (UTC)
@Tengwar: I agree that sourced incorrect statements should be retained, but deprecated. That is useful if someone else intend to use the same source. But I see no point in retaining unsourced and challenged statements. Without a source it has no value and can possibly be vandalism, opinions from any user, true, false or anything else. If a user want to retain the statement, they should provide an available source. If you deprecate it with reason for deprecated rank (P2241) incorrect value (Q41755623), that is again a claim without source. I think that claiming something to be false without source is just as bad as claiming it to be true without source. --Dipsacus fullonum (talk)
@Dipsacus fullonum: Yes, I agree that reason for deprecated rank (P2241) incorrect value (Q41755623) needs a source confirming the incorrectness. But according to aforementioned policy, known incorrect data should be removed (because there is no source confirming they are correct) instead of marked as incorrect with a source confirming it's incorrect. This goes against what I heard before, and such mixed signals leave me confused. --Tengwar (talk) 15:08, 22 May 2022 (UTC)

Call for papers: Wikidata workshop at ISWC 2022Edit

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)

Sofron - male given nameEdit

SOFRON and SOFRON I think there is no reason for two values. Sofron has no other pronunciation in the Ukrainian language. --Микола Василечко (talk) 16:37, 19 May 2022 (UTC)

Those links are invalid. You will need to provide the number like this {{Q|1234}}. From Hill To Shore (talk) 23:16, 19 May 2022 (UTC)
Seems to be Sofron (Q20088032) and Sofron (Q112053604) — Martin (MSGJ · talk) 12:34, 20 May 2022 (UTC)
I have merged them for you — Martin (MSGJ · talk) 12:41, 20 May 2022 (UTC)
I don't think that merge was correct. "Софрон" is not necessarily the same as "Sofron". Names in different scripts/alphabets generally need separate items for the name in its original script, as well as for the transliterations in other scripts (like Latin script). That's because a name in e.g. Cyrillic script could be transliterated in different ways depending on language, country and transliteration system. But if a person born and living in e.g. a Latin script country has one of the transliterated versions of the name as their name, the name wouldn't get transliterated in other latin script countries. See Yury (Q30465251), Yuri (Q18585594) and Juri (Q18932166) for example.
For an Ukrainian person with the name "Софрон", the item for the Cyrillic version is the correct one, which would also show the different transliterations in other languages. But for persons with the Latin script name "Sofron", we need the other item, too.
So Sofron (Q20088032) should be restored to the previous version where it was still about the Latin script "Sofron" and Sofron (Q112053604) used as the Cyrillic name. --2A02:810B:580:11D4:E98E:BA80:42BE:4F93 13:01, 21 May 2022 (UTC)

kidney (Q111907436) and kidney (Q9377)Edit

Somebody made this wikidata items weird. This should be returned but I have no idea how to do it. I think somebody made new item for ruwiki: Почка человека. --LR0725 (talk) 06:38, 20 May 2022 (UTC)

What is weird about them? Infovarius has been working on these items — Martin (MSGJ · talk) 12:26, 20 May 2022 (UTC)
Okay I've looked into this a bit more and I agree something is not right. Q9377 was relabelled (in English) from kidney to human kidney and a new item was created for kidney. It would have been better to create the new item for human kidney. Now there are a lot of duplicated identifiers — Martin (MSGJ · talk) 12:33, 20 May 2022 (UTC)
@MSGJ: Thanks for understanding. I think I didn't write so well to understand. --LR0725 (talk) 18:21, 23 May 2022 (UTC)

@D6194c-1cc, Infovarius: I am intending to revert the changes to kidney (Q9377). Until 8 May this item was a general item for kidney - English description "internal organ in most animals, including vertebrates and some invertebrates" but you have repurposed it to "human kidney". This is inappropriate - items should never be repurposed. If an item for "human kidney" is missing, then you should have created a new item for it rather than repurposing an existing item. — Martin (MSGJ · talk) 06:27, 21 May 2022 (UTC)

Sorry, wikidata items for the Human kidney and the Vertebrate kidney (or just Kidney) are not the same. The new wikidata item was created for the kidney of vertebrates. All verkebrates have kidneys, not only human or mammalians (even the primitive fish). Human kidney is item a deriviative of Kidney item. A kidney can one of three major forms: pronephros, mesonephros and metanephros. The human kidney is the metanephros, which is the most complex kidney type. And human kidney belongs to the mammalian kidney type, which is only one of the three kidney types in amniotes and it evolutioned in parallel with the bird kidney type. Previously the kidney item was about the metanephros kidney form of mammalians, not about the vertebrate kidney, which can be different types and forms. You cannot merge them again. And the Kidney article from English wikipedia must be transformed to the human kidney, because it describes only human/mammalian kidney (and it makes confusion because it doesn't says about it). Separate article was made for the vertebrate kidney to describe all kidney forms and types. And separate article would be made for the mammalian kidney too, since there are a lot of information about it in open access. Please do not do any hasty actions before you'll understand the problem. --D6194c-1cc (talk) 06:50, 21 May 2022 (UTC)
I think it is you who is not understanding. Yes, I fully agree we should have separate items for "kidney" and "human kidney". The existing item Q9377 was about "kidney". It is incorrect to change the purpose of this item to "human kidney". I hope that is clear now! — Martin (MSGJ · talk) 07:11, 21 May 2022 (UTC)
I'm just stepping in here to confirm that MSGJ's interpretation is correct. We never repurpose an existing iten as that confuses every internal or external page that was relying on the original meaning. Instead we create a new item to describe the new purpose/concept. From Hill To Shore (talk) 08:41, 21 May 2022 (UTC)
Well, the previous kidney Wikidata item had features of human/mammalian kidney. Division into cotrex/medulla, for example, which is absent in reptilians and lower vertebrates. Do you suggest that to fix that we should have created a new item and move all from one item to another just to preserve wikidata item number? In fact many other wikipedia languages describe the same kidney as english do, so the problem was not only in Russian and English wikipedias (most of articles would be translations from English language). We just revealed the problem. The easiest way was to transform item to human kidney and create the new one. --D6194c-1cc (talk) 11:03, 21 May 2022 (UTC)
What you are describing is a conflation. We fix conflations by creating new items for all of the different concepts in the original item. We remove statements from the original item that have been moved to the correct location but leave any statements that can't be moved. If all statements have been moved, the original item is empty and we delete it, with a deletion summary pointing to the replacement items. If some statements remain on the original, we mark it as instance of (P31) conflation (Q14946528) and set different from (P1889) statements to point to the replacement items. That way we don't change the meaning of statements made be internal and external pages through repurposing an existing item. The internal and external pages are pointed to the replacement items either through the deletion summary (if the original is deleted) or through the different from (P1889) statements if the original remains. The internal and external pages can then choose which of the different topics they were meant to link to. From Hill To Shore (talk) 11:23, 21 May 2022 (UTC)

I have reverted the changes to Q9377 and also created human kidney (Q112107043). Feel free to move any statements or sitelinks that relate solely to the human organ — Martin (MSGJ · talk) 21:07, 21 May 2022 (UTC)

  • Do you understand that now we need to delete all wrong statements (like corticomedullary organ, it's mostly related to metanephros form of kidneys of mammalians and birds) from the kidney (Q9377) (kidney) item and move them to human kidney (Q112107043)? Why did you create all that additional work? Only to preserve numbers? It contradicts common sense. You've just made A as B and B as A. Next stage we'll just need to move English Kidney page to human kidney (Q112107043) after discussion will be completed. And throught time other Wikipedias may follow this pattern. --D6194c-1cc (talk) 07:21, 22 May 2022 (UTC)
    I moved all the human/mammalian kidney properties back to human kidney item as it should be. --D6194c-1cc (talk) 09:12, 22 May 2022 (UTC)
    Unless it relates solely to human kidneys it should not be moved — Martin (MSGJ · talk) 17:21, 22 May 2022 (UTC)
    Multiple editors have tried to explain it to you ... — Martin (MSGJ · talk) 17:21, 22 May 2022 (UTC)

Morocco (Q1028) - moved from "Request a query"Edit

Hello,

Could you please remove the last two modifications to this page? This contributor https://m.wikidata.org/w/index.php?title=User:%D8%A7%D9%84_%D8%B3%D8%A8%D8%A7%D8%B9&redlink=1 makes an Arabist POVP by adding "Arab-Islamic" while the country defines itself as "Arab-Berber". Thank you.  – The preceding unsigned comment was added by YusAtlas (talk • contribs) at 12:39, 20 May 2022‎ (UTC).

This does not seem problematic so I won't revert. But you are welcome to undo that edit and explain why in the summary — Martin (MSGJ · talk) 12:23, 20 May 2022 (UTC)
I believe the complaint may be right. Checking this edit, the user removed berber as the person's language, even though that language is noted as their native language in arwiki (Chrome manages to translate as much). The user has done little else but changing peoples' language from berber to arabic. Do we have any arabic-language admins that could look into this? Karl Oblique (talk) 11:55, 21 May 2022 (UTC)
@علاء, باسم: could either of you help with this please? — Martin (MSGJ · talk) 18:02, 22 May 2022 (UTC)
@MSGJ: I found nothing (on ar.wiki and a couple of other websites) that suggests that this person is of Berber origin or speaks Berber as his first language. I also didn't find anything that suggests Arabic being his native tongue as well. All Moroccans, especially academics like this person, speak Arabic. They might know a Berber delicate if they are of Berber origins or if one of their parents is. I removed the 1st language as I found nothing to support it. Please note that on ar.wiki we always suffer from such complains, many of which tend to be false and racially motivated. I already told the user (آل سباع) that changed this info to base his edits on reliable sources, and I wish anyone who claims otherwise to add their sources as well on Wikidata. Best-- باسم (talk) 18:22, 22 May 2022 (UTC)
Many thanks — Martin (MSGJ · talk) 18:38, 22 May 2022 (UTC)

What is best: no information, or wrong information?Edit

Hi to all, I've been contributing to Wikidata from time to time, usually tidying up items that I stumble on while working on the Italian Wikipedia. But I would say I'm still quite a newbie here.

This recent discussion that left me puzzled. I had found out that the information "state of use = in use" had been automatically added to lots of Italian railway stations, without anyone actually checking if they're actually in use or not. (It has been added to stations which are still only at a planning stage, to stations which are actually in use, and to stations which have been closed a long time ago.)

Is this right? The other user seems to defend such an approach.

I would personally prefer no information to be added in such a way, because it actually degrades the quality of Wikidata - from items with missing information, to items with wrong information (which is clearly worse, to me.)

As I've never been involved in massive editing, maybe I'm missing something. What do you think? --Fabio Bettani (talk) 13:25, 20 May 2022 (UTC)

I agree that we should not be adding a statement unless there is some evidence that it is true. This is so obvious that I'm surprised to find myself typing this. — Martin (MSGJ · talk) 14:21, 20 May 2022 (UTC)
Same. @Bouzinac:, "I prefer to fill up and clean down rather than to add one per one as it is impossible to check one by one and hopefully it's a collaborative database" is really not good. You knowingly adding junk data, and hoping that someone will clear up your mess, is thoroughly objectionable. --Tagishsimon (talk) 15:10, 20 May 2022 (UTC)
I find your remarks a bit rude. There are plenty of mass edits of different sources of different editors and they can come with some typos or errors, of course! One that always awe me is that harvest templates can add false date of official closure (P3999) eg that edit https://www.wikidata.org/w/index.php?title=Q698837&oldid=734677624#P3999 which hadn't been noticed for some years, which made suppositions that station was out of service.
Edit a database always need to cross data, and check inconsistencies, query and refine data. Query and refine data, again. And we are not alone, hopefully.
Otherwise, we should ban mass edit and permit only manual edits... Bouzinac💬✒️💛 15:32, 20 May 2022 (UTC)
Poor edits by other tools or editors does not excuse poor edits by yourself. Please do not add any statements that you are not able to verify. Thank you — Martin (MSGJ · talk) 06:30, 21 May 2022 (UTC)

Gadget-DragNDropEdit

I tried the tool and it's very useful. But noticed that there is no attribution (in the edit summary), at least, from which wikipedia the info taken and which reversion. Geagea (talk) 13:40, 20 May 2022 (UTC)

FAQ for synonymsEdit

At the risk of opening a major discussion (e.g. see https://www.wikidata.org/wiki/Wikidata:Property_proposal/taxon_synonym_string), I was wondering what to do about synonyms like Manis gigantea vs Smutsia gigantea. In particular, I noticed that the Manis gigantea item contains information about the NCBI identifier for Smutsia gigantea, but the Smutsia gigantea item does not contain any NCBI identifier. Should Q20085878 duplicate properties such as the NCBI identifier? Or (more controversially), should there be only a single item for the taxon? Either way, this seems like if would be a good FAQ for this project, if there is anywhere to put such a thing? HYanWong (talk) 16:03, 20 May 2022 (UTC)

I accidentally posted this to the general chat rather than https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Taxonomy. Apologies. I will repost there. HYanWong (talk) 10:33, 21 May 2022 (UTC)

Linking definitions, not recreating themEdit

Sorry, I am a newbie. But I noticed a very flawed description of "cartoon" Q1416517 where in the record there is a link to the Getty AAT. When there is a link to a controlled vocabulary, why isn't that definition automatically linked/displayed/used?  – The preceding unsigned comment was added by Sjpw99 (talk • contribs) at 18:54, May 20, 2022‎ (UTC).

Well, fundamentally, nothing happens unless someone does it. Feel free to improve the description. One issue with the Getty description is, however, that they claim copyright for them, as far as I can tell. I also don't quite see the difference in the definitions: "Refers to full-size preparatory drawings made for the purpose of transferring a design to the working surface of a painting, tapestry, or other large work." (Getty) vs "life-size drawing on cardboard, used as a design for an artwork". I would even guess that the latter already is an attempt to rephrase the text from Getty. Karl Oblique (talk) 03:40, 21 May 2022 (UTC)

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)

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)

Bad mergeEdit

Can someone undo the bad merge at Charles Martel, Duke of Calabria (Q1499236), two people with the same title were merged improperly. --RAN (talk) 17:30, 22 May 2022 (UTC)

  Done. According to en:Charles Martel, Duke of Calabria, Charles Martel, Duke of Calabria (Q5080691) is about two different people, one of whom is Charles Martel, Duke of Calabria (Q1499236) ... — Martin (MSGJ · talk) 18:00, 22 May 2022 (UTC)

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)

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)
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)
  • 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)

Difference between football teams and football clubs, and difference between football teams and men's football teams.Edit

(I apologize if there exists a policy document regarding the categorization of sports teams. If so, please feel free to point me to it rather than answering my questions in detail. Also feel free to move this if my post is in the wrong place.)

I am trying to understand Wikidata, so as to use it to find lists of alternate names for (association) football teams (soccer teams).

My first instinct was to query for anything with league (P118) of a association football league (Q15991303). However, this gave me stuff like Pierre Bengtsson (Q1620680) as a member of Allsvenskan (Q202243), which isn't what I want.

My second attempt was to query for anything with instance of (P31) == association football club (Q476028). This included teams ("clubs") like FC Barcelona (Q7156) and IF Brommapojkarna (Q754339). However, it failed to include teams like FC Barcelona B (Q10467) and IF Brommapojkarna (Q85768040) ("IF Brommapojkarna (Women)").

So, my first thought was that the football club was an entity, it was synonymous to its strongest team (i.e. non-youth male first team), and all other teams (reserve team, women team, etc) were merely "clubs".

However, I found exceptions to this. For example, Manchester United F.C. (Q18656)'s women's football team Manchester United W.F.C. (Q54818167) is considered as a separate club, and Borussia Dortmund (Q41420)'s reserve team Borussia Dortmund II (Q865720) is also.

I also found the category men's association football club (Q103231176) (which appears unused) and men's association football team (Q103229495) (which is not). What's going on here? In particular, what is the difference between a "men's association football team", such as RB Leipzig (Q97905954), and an association football team (Q15944511), such as SC Freiburg (Q106394)?

Q1: Is there some systematic rule for when a team is a team and when it is a club? Does it depend on the internal governance structure of the team/club, or are just some of these temporary errors?

Q2: Is there a way to find all association football teams (including women's teams and reserve teams), without manually specifying "women's team OR women's club OR team OR club OR men's team" (but not men's club, no such thing!)), in the event that I am missing yet further categories?

Q3: Would it make sense to introduce a standardized designation for "a team that may be a member (qua having league (P118)) of a football league, and which all members of football leagues must have" (with the effect of making Pierre Bengtsson (Q1620680) and 2015 Örebro SK season (Q23044722) ineligible as members of Allsvenskan (Q202243))?

Q4: What's the purpose of men's association football club (Q103231176) anyway?

Q5: What's the policy on women's football? Personally, I think it would make the most sense to remove competition class (Q22936940) from women's association football (Q606060) and make it into a "full" sport, like how basketball (Q5372) is ontologically different from cricket (Q5375). However, it would also make more sense to decide something like the following:

  1. Only football teams can play in football leagues.
  2. If a club only fields one team, it should either be both a club and a team, or it should have a dummy club entry.
  3. Football teams must be exclusively male, exclusively female, or (explicitly) "other" (non-binary/mixed-sex teams etc, if such exist). A team should not be able to be an "association football team" (alternatively, it should only be able to be so if it is not a male association football team, i.e. "football team" is the non-binary category)

If these questions are already answered in some FAQ or document, feel free to point me to it. I would like to apologize if this is the wrong place to ask, since this is my first post on here.

Many thanks for information!

98.128.180.201 20:07, 22 May 2022 (UTC)

Well it's a mess, basically. For several reasons:
  • It has to some extent historically evolved due to lack of coordination in the early phases. Migration to another model is difficult.
  • Connected Wikipedia articles often mix this up as well, and editors from different Wikipedia editions may have a different idea what these items are be about.
  • It is pretty complicated to come up with a generic model that really fits most of the situations encountered in association football. If you want to make it generic enough for all/most types of sport, it's even more complicated.
  • An ontologically clean solution seems bloated sometimes, so it is difficult to make editors adapt it properly. Many are not particularly well trained and use a simpler, yet inferior model instead just because they work with what they find.
Your grasp of a somewhat ideal and desirable situation is in fact already pretty good:
  • We should have a structurally symmetrical solution for women's and men's association football and all other types of sport. Particularly, women's sport should bot be some subtype of the men's version, or somehow separated out of the "main" event, which is how the men's sport often is perceived by the general public unfortunately.
  • We should also make individual items for teams (women's, men's, junior/age class, second teams, etc.) that are in whatever form operating within clubs that may have very different legal forms. "club" needs a proper definition here as these entities are organized differently everywhere on the world; maybe we should rather talk about brands of something similar instead.
MisterSynergy (talk) 21:16, 22 May 2022 (UTC)
I think that there's obvious things that can be done, even if they are not 100%.
For example:
  • It should be a no-brainer to require that all league members must be teams or clubs - players etc can't be direct members. (If they can, then we should maybe have some distinction between "leagues with teams" and "leagues with players")
  • It's also theoretically correct to require them to be teams, but there's a lot more constraint violations that would have to be cleaned up if so.
  • It should be a no-brainer to require that, should an association football league (Q15991303) (or maybe a sports league (Q623109)) have for example competition class (P2094) == men's association football (Q31930761), then it's a constraint violation if a team with league (P118) == <that league> doesn't have the same competition class. (Alternatively, it could only be valid for leagues not teams, but I really don't like that approach.)
  • Likewise, there should probably be some kind of check that competition classes are consistent across league level above (P2499) and league level below (P2500), at least on the way down, but this isn't 100% obvious.
  • Either the concept of "men's / women's team" should be abolished in lieu of association football team (Q15944511) + competition class, or the notion of non-gendered teams should be abolished, at least except for mixed-sex teams. (In association football at least it seems fine in such case to make that a constraint violation, since mixed-sex teams aren't really a thing)
  • At least it should be a no-brainer to require that members in men's association football team (Q103229495) class lack competition class (P2094), since else they should go in the subclass of men's association football team (Q103229495) with such prop.
  • All teams should either be instances or subclasses of sports clubs.
  • It should be a constraint violation for an association football club (Q476028) to also be an instance of a association football team (Q15944511), IF there exist other teams having parent club (P831) of that club, except perhaps if it's a reserve team.
  • I don't think that a proper definition of club is needed for the moment; the low hanging fruit is to clean up the obvious violations and then to merge together the reserves team with their main teams.
My key point here is that there's a lot of clean-up that can be done more or less automatically, without having to make any terribly difficult decisions. As for my own problem, I solved it with ?teamID wdt:P31 / wdt:P279* wd:Q4438121., which covers all the types of clubs and teams but not other stuff.
98.128.180.201 01:08, 23 May 2022 (UTC)
There is certainly a lot of work to be done in football, where you have a mass of well documented data people care about and want to analyse. Tottenham Hotspur F.C. (Q18741) for example is a mess of partial and incorrect information, and plenty of people care about them. "The Spurs" eh! Vicarage (talk) 09:02, 23 May 2022 (UTC)

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)

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

Wikidata weekly summary #521Edit

Places of Worship in ScotlandEdit

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

Airth Old Parish Church - merge suggestionEdit

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)

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

Please mergeEdit

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)

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)

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)

Help please: Female genitalia WD itemEdit

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)

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

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)

subterranean riverEdit

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)

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)
OK thanks. I've removed the subclass of (P279) statement (diff). Jheald (talk) 09:36, 27 May 2022 (UTC)
@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)
@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)

Revisions to the Universal Code of Conduct (UCoC) Enforcement GuidelinesEdit

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)

2022 Board of Trustees Call for Candidates is now closedEdit

You can find this message translated into additional languages on Meta-wiki.

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)

Property aliasesEdit

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

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

Illogical constraint warningEdit

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)

Kestrel/Common kestrelEdit

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)

@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)

ISOCATEdit

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)

member_of vs. part_ofEdit

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)

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)