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

Wikidata:Project chat

From Wikidata
(Redirected from Wikidata:Project Chat)
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

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/06.

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

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]
How many Scottish people have you talked to? Many of my Scottish friends would be happy, for instance to cook with en:Scotch bonnet peppers, or eat a en:Scotch egg, and none of them have ever written "Scot*h" in anything I've read. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 12 June 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]
@Tengwar: - Thanks! No idea how to do that, though :'( Any ideas how to go about it? As mentioned above, I find wikidata processes impenetrable - MPF (talk) 21:44, 1 June 2022 (UTC)[reply]
I also have no idea about Wikidata processes and structures. I can't help you there, sorry. I guess the only way is to read help pages and google stuff.
All that I know is that Wikibase is the software Wikidata runs. (Just like MediaWiki is the software Wikipedia runs.) And since Wikibase is open-source, it should have an issue tracker (aka bugtracker). Where is it located? How to file an issue there? I have no idea. --Tengwar (talk) 16:55, 2 June 2022 (UTC)[reply]
Thanks! Can anyone else suggest, please? - MPF (talk) 22:06, 8 June 2022 (UTC)[reply]
There's a ticket I created a while ago asking for a new rank - phab:T210961. You could add your usecase there. - Nikki (talk) 20:56, 9 June 2022 (UTC)[reply]
@Nikki: Thanks! I'll take a look there. Not sure what a 'usecase' is, but I'll add a comment - MPF (talk) 06:16, 19 June 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.

Cheers, Ls1g (talk)

spouse (P26) end cause (P1534) his death (Q105080687) or her death (Q105080700)[edit]

Just noticed a number of spouse statements with these end cause qualifiers (for heterosexual marriages). Is there a specific reason for this? Usually I would add either death (Q4) or death of spouse (Q24037741) on the spouse items depending on who died first. What's the recommended way to model deaths in marriages? Piecesofuk (talk) 09:11, 3 June 2022 (UTC)[reply]

It seems unnecessary and unhelpful to model marriage in a way that requires us identify the male and female participants. CC @Richard Arthur Norton (1958- ) as creator. Bovlb (talk) 14:57, 3 June 2022 (UTC)[reply]
  • When you see end_cause=death, you have to do a search to see who's death ended the marriage. His_death and her_death, answers the question, without the reader having to look at the death dates for the two people involved in the marriage to figure out who died first. Most Wikidata naïve readers will not be aware that death_of_spouse exists, and is the converse of "death". --RAN (talk) 16:41, 3 June 2022 (UTC)[reply]
    • @Richard Arthur Norton (1958- ): I don't think you're addressing the key point here. The model you propose requires checking the gender of the marriage participants and assumes, not only that both genders are known, but also that one is male and the other female. The check is an unnecessary indirection, and the assumptions, while commonly true, are not valid in the general case. Bovlb (talk) 16:50, 3 June 2022 (UTC)[reply]
  • Same sex marriages make up a very tiny proportion of marriages, and can be handled any way you want. Same for any other nonconforming relationship. We require gender identification when we have instance_of=human, so gender is not unknown. In your model end_cause=death, we are always left wondering: who's death?, one died, but which one? When we have end_cause=divorce, it is clear both parties divorced. --RAN (talk) 17:00, 3 June 2022 (UTC)[reply]
    • @Richard Arthur Norton (1958- ): "Same sex marriages make up a very tiny proportion of marriages". While it is true that same sex (and non-binary) marriages are rare, we're on dangerous ground if we choose to design an ontological model that crucially depends on the assumption that they don't exist at all. Why would we want to do that? This is especially the case when the model in question is also inferior for other reasons (compared to Q4/Q24037741). Bovlb (talk) 17:39, 3 June 2022 (UTC)[reply]
Calling it "dangerous ground" is hyperbole, we already have a half dozen reasons for marriage:end_cause, finding one that fits unambiguously and tersely for non binary marriages is a challenge, but not "dangerous ground". --RAN (talk) 21:40, 3 June 2022 (UTC)[reply]
    • Wouldn't neutral qualifiers "their death" or "spouse death" be better? Vicarage (talk) 19:12, 3 June 2022 (UTC)[reply]
Note that death of spouse (Q24037741) does exist, and should be used where applicable. An item "death of subject" might be appropriate, if it is indeed the subject of the item who has died. Jheald (talk) 21:43, 3 June 2022 (UTC)[reply]
  • We already have massive confusion surrounding "object has role" versus "subject has role" and it will be the same for "death of subject" and "death of object". "Death of subject", I assume would be the person with the Q-number at the top of the page, and the object would be the person listed as spouse? --RAN (talk) 12:37, 8 June 2022 (UTC)[reply]
Jura1 created that entry in an attempt to clarify the issue. The problem with death of spouse (Q24037741) is the placement, since it appears with information on the spouse, some were interpreting it as the death of the spouse's spouse. --RAN (talk) 21:50, 3 June 2022 (UTC)[reply]
  • "Their death" unfortunately is also ambiguous, it was suggested at one point in English Wikipedia for infoboxes, but even in that debate people were unsure which of the two parties was "their", the person with the Wikipedia entry, or the person listed as "spouse". The problem was that the information appears next to the spouse name, where we store the marriage information and people were thinking "their" was the spouse. The problem is the balance between being terse and being unambiguous. The best would be "death of the person who is listed at the top of this Wikidata entry and not the person that they are married to". I don't see why we can't have a different set of parameters for same sex marriages. We have multiple options to choose from for "gender=", we can have multiple options for marriage:end_cause. --RAN (talk) 21:14, 3 June 2022 (UTC)[reply]
    • You make a good point about infoboxes. It is tricky to see how to communicate that information tersely yet clearly. I was considering it from the perspective of crafting queries. It makes no sense that one would have to write one query for male-female marriages, and a different query for same-sex or non-binary marriages. That just leads to having them excluded from query results. It also makes no sense to encode the data in a way that requires the query to also check the genders of the participants. Wikidata's ontological model isn't just for infoboxes. We can't have a different data representation for a minority group. It's not at all the same thing as having multiple options for gender, because it is exclusive rather than inclusive. Bovlb (talk) 23:01, 3 June 2022 (UTC)[reply]
  • I am sure we will come up with a terse and unambiguous version that satisfies all types of marriages, but we have not found it yet. --RAN (talk) 02:29, 6 June 2022 (UTC)[reply]
    • It's going to be a heavy lift to satisfy "all types of marriage" – none of our proposals or existing representations handle plural marriage (well) – but it's not clear to me that same-sex or non-binary marriages should be regarded as different types of marriage. I'm only distinguishing them here because you've managed to construct an ontological model that doesn't represent them. Piecesofuk's model does not distinguish them. Bovlb (talk) 16:32, 6 June 2022 (UTC)[reply]
I thought "death of spouse" solved the problem, but if you search for the debate, you will find the objections where at least one person thinks that it means the "death of the spouse's spouse" because it appears under the name of the spouse. The debate about terse vs. ambiguous is still found with "object has role" and "subject has role" which still confounds me. --RAN (talk) 15:32, 7 June 2022 (UTC)[reply]
We're talking about two different issues here, and I think it's important to distinguish them. The first is: Do we have a data representation that is efficient, unambiguous, and expressive enough to cover all cases? Death (of self)/death of spouse satisfies that, whereas his death/her death fails all three arms. The second is: Is the information clearly conveyed via some interface, such as an infobox? Your concern is that death (of self)/death of spouse is widely misinterpreted, whereas his death/her death is understood by all, at least in most cases. Your concern is valid, and I take this issue seriously, but I don't think we can resolve it at the expense of the first issue. Our mission at Wikidata is not (just) to generate text for humans can understand. Perhaps it would help if you shared this infobox with us and pointed us to the debate; presumably both can be found on one of our many client projects. Bovlb (talk) 18:18, 7 June 2022 (UTC)[reply]
It only appears clear because you are looking at the paired terms. When you see death of person (Q99521170) in isolation, you ask: "which person?" The person at the top of the page, or the person where the label has been attached, the spouse, where the actual start and stop dates for the marriage appear. Less so with death of spouse (Q24037741), but at the debate we had people assuming it was referring to the spouse's spouse, because of where it appears. --RAN (talk) 06:09, 11 June 2022 (UTC)[reply]
@Richard Arthur Norton (1958- ): It appears that five users (me, Piecesofuk, Infovarius, Vicarage, Jheald) broadly agree on the appropriate data representation here, with only you in disagreement. You appear to be primarily concerned with the effect this data representation has on some infobox. Do you intend to provide any information about this? Setting aside the infobox, do you intend to engage with the more important data representation issue? Bovlb (talk) 17:50, 11 June 2022 (UTC)[reply]
  • I don't see that other users "broadly agree", I see them asking questions, and suggesting various schemes, none of which are sufficiently "terse and unambiguous". You said you were worried about "crafting queries" and that "his death" and "her death" might cause errors, do have a query in mind, so we can see what damage is being caused, and how to remedy it? --RAN (talk) 18:10, 11 June 2022 (UTC)[reply]
    A problem with his death (Q105080687) and her death (Q105080700) is that they are identical. Unless you know English or the handful of other languages stated in the label/description fields how would someone know which one to use? See Piecesofuk (talk) 06:48, 12 June 2022 (UTC)[reply]
    Your question is oddly-phrased, but here is a query I threw together: Who had multiple marriages ended by their spouse's death? - How would you represent that query in your data model? Bovlb (talk) 19:37, 12 June 2022 (UTC)[reply]
  • Remember, not every human Wikidata entry that was married has an entry for a spouse, even those that do have an entry for spouse, they do not have a start and end date, and even fewer of them have and end_cause listed. When we get all those other elements in place, then we can harmonize end_cause= . --RAN (talk) 00:21, 13 June 2022 (UTC)[reply]
    • @Richard Arthur Norton (1958- ): It's true that our data are incomplete, and likely to remain so, but that doesn't actually seem like a good reason to select an inferior data representation, so I'm not sure why you bring it up. Do you plan to address any of the points raised above? Bovlb (talk) 01:37, 13 June 2022 (UTC)[reply]
At this point we are just repeating our talking points. Enough information is here for third parties to make up their own minds. "Address any of the points": You can look at an infobox yourself, I don't need to link to one, and I don't need to show you a query, we both agree that there is only a small portion of marriages listing spouses, and an even smaller subset with end_date, and an even smaller subset with end_date that actually use end_cause. No query will give any meaningful information because of the inherent incompleteness of the data. My final summary: there is no good end_cause=death that is both terse and unambiguous. I was happy with "death of spouse", but one person was very vocal that it was ambiguous to them as referring to the "spouse's spouse", look for the guy that objected to it in the previous debate over the issue, and convince them. --RAN (talk) 01:43, 13 June 2022 (UTC)[reply]
Bovlb (talk) 16:36, 13 June 2022 (UTC)[reply]
I agree that this is a possible solution but I think there are problems with both death of person (Q99521170) and death of spouse (Q24037741) that need fixing beforehand. Death of Person seems to be defined by its description and not its statements, also its description seems to contradict its purpose as it refers to the Q-object and not the subject which I believe is what it is supposed to refer to. Also death in office (Q5247364) is currently sub-classing Death of Person which I think is wrong if Death of Person is the opposite of Death of Spouse. Also Death of spouse needs fixing and it is not currently a subclass of death (Q4).
Would it help if Death of Person is renamed as Death of Subject and Death of Spouse is renamed as Death of Subject's Spouse. Piecesofuk (talk) 18:13, 13 June 2022 (UTC)[reply]
All good points.
"Would it help if Death of Person is renamed as Death of Subject and Death of Spouse is renamed as Death of Subject's Spouse" - Not opposed to that renaming. The intent is the important thing for me.
It makes sense for death in office (Q5247364) to be a subclass of Death of Person, because they are both end causes associated with the subject dying; we need to have Q5247364 because it has a sitelink, but it doesn't need to be an end cause. This feels like it is a separable issue.
"Death of Person seems to be defined by its description and not its statements" - Agreed, but an ongoing problem in any ontology, and arguably separable.
"its description seems to contradict its purpose as it refers to the Q-object and not the subject which I believe is what it is supposed to refer to - Strictly speaking, given that this is used as a qualifier value, it is the subject (Q-item) of the subject (a full statement) or the qualifier, but I'm happy to refer to it as the subject, as that works both ontologically and colloquially. I agree that referring to it as "object", while true in another sense, is confusing in this context.
Do we ever have a need for subject/object end causes for other properties representing human relationships, e.g. doctoral advisor (P184)? Bovlb (talk) 18:57, 13 June 2022 (UTC)[reply]
  • Death of subject is as inherently confusing as "Subject has role" and "Object has role", even when shown as a pair, are confusing. I thought subjects were for people and objects for places and things, and so did others based on the usage. You also keep saying we have reached consensus, when we clearly have not. I understand you are eager to end the debate, but I do not think consensus has been reached. Several people have offered their opinions, but they are still offering tentative and diverse solutions. --RAN (talk) 19:08, 15 June 2022 (UTC)[reply]
    The subject is always the Q-item that you are viewing, the objects are the values of each of the properties of that item. The subject will become the object when viewed from another Q-item that uses it as a property value. If I'm viewing the spouse statement of Douglas Adams from within Q42 then Douglas Adams is the subject and his wife Jane Belson is the object. If I view the spouse statement of Jane Belson Q14623681 then she is the subject and Douglas Adams is the object. So since Douglas Adams died first the end cause on Q42 is Death of Person (Subject) and on Q14623681 the end cause will be Death of (Subject's) Spouse (or we could state it as Death of Object). Piecesofuk (talk) 15:06, 18 June 2022 (UTC)[reply]
  • Perhaps death of spouse (Q24037741) could be paired with "named as" so we know which partner in the marriage pair. Also perhaps a way to mark same sex marriages without having to click on the spouse to look at their gender. --RAN (talk) 19:16, 15 June 2022 (UTC)[reply]
    • "Perhaps death of spouse (Q24037741) could be paired with "named as" so we know which partner in the marriage pair." This is a confusing suggestion for two reasons. You seem to be suggesting that when a marriage ends through death, this fact is documented somehow and the dead partner is named in a way we should record. Secondly, the purpose of this is to identify which participant is the spouse of the subject, which makes no sense as it is recorded already. "Also perhaps a way to mark same sex marriages without having to click on the spouse to look at their gender." This seems an orthogonal suggestion. Same sex marriages can already be queried (to some extent), and there are somewhat more than two types of marriage (with respect to the sexes of the participants). Some marriages change category. What problem is this trying to solve? Do you want to mark same sex marriages differently in infoboxes? Are there any other contexts in which we regularly annotate people with their sex? Bovlb (talk) 07:09, 25 June 2022 (UTC)[reply]

Please help with popes[edit]

At Talk:Q19546 we have the official list of popes, but with 266 it is exhausting to fix all the errors. Some are duplicated because of bots, and some early popes have inconsistent start and end dates. I have started with the newest and am working down. You have to edit the entry for the pope to have it fixed in the list. RAN (talk) 23:18, 15 June 2022 (UTC)[reply]

@Richard Arthur Norton (1958- ): for the early popes, be wary that for some of them the historical informations we have is meagre at best. I wouldn't be too suprised if they dates effectively overlap or if their are multiple contenders for the same period of time: it will all depends on the source used. --Jahl de Vautban (talk) 19:15, 17 June 2022 (UTC)[reply]
@Jahl de Vautban @Richard Arthur Norton (1958- ) I'd also note that the list on the talkpage is going to seem a little weird before the 1500s: WDQS converts all its dates into "proleptic Gregorian" and doesn't know if they're Gregorian or Julian. It then reports that, via the bot, so eg if you look at John XXI (Q172916), his item reports 1276-09-27 to 1277-05-20, both Julian dates as they should be, but the talkpage list gives 1276-09-27 to 1277-05-27 - seven days difference. The "proleptic Gregorian" date isn't shown anywhere on WD for older Julian dates, just in the query service, so it can get very confusing figuring out what's going on.
There isn't any easy way to correct for this without either manual calculations or some quite substantial changes to WDQS, unfortunately... Andrew Gray (talk) 08:38, 22 June 2022 (UTC)[reply]
  • So sad to see the date problem is difficult to fix, but thanks for figuring it out! --RAN (talk) 01:55, 24 June 2022 (UTC)[reply]
  • This is a nasty gotcha, of which I was completely previously unaware. So there is no way in a query to display the Julian date that is entered on the item-page; and no warning that a conversion has been done. (cf and then compare to the dates of death as shown on the items). That's a recipe for considerable confusion, not least when Wikidata content is reused. And a bug on this has been opened (by users) since March 2020 (thanks @Tagishsimon:), but still no official take or plan from the project team as to what to do about it?
At the very least the documentation at mw:Wikibase/Indexing/RDF_Dump_Format#Value_representation and mw:Wikibase/Indexing/RDF_Dump_Format#Time ought to give a very clear warning about this. But it really ought to be possible to get the Julian-format date, as used on sources and entered on wikidata, out of WDQS. Paging @Lydia Pintscher (WMDE):. -- Jheald (talk) 09:07, 24 June 2022 (UTC)[reply]
  • Have you noticed that the first pope is not displaying in the list? --RAN (talk) 02:08, 25 June 2022 (UTC)[reply]
Someone who doesn't understand rank had dicked around with a P31 rank for Peter. Now fixed. --Tagishsimon (talk) 02:15, 25 June 2022 (UTC)[reply]

Creation of a new class item for instances of a "performance hall"[edit]

The performing arts community is considering the creation of new class item for the concept of a "performance hall", which would be defined as room within a building that includes the stage and the audience space. This class would be a subclass of event venue (Q18674739). This idea is further described in this document.

We will be meeting on June 23 at 13:00 - 15:00 UTC to discuss these and other venue-related questions. Everyone is welcome to attend (Zoom information). You may also share your thoughts in this discussion thread. Beat Estermann
Vladimir Alexiev
Birk Weiberg
Daniel Mietchen
Klaus Illmayer
Vero Marino
Anju A Singh
Simon Villeneuve
Gregory Saumier-Finch
Gabriel De Santis-Caron
Raffaela Siniscalchi
Aishik Rehman
SAPA bdc
Pictogram voting comment.svg Notified participants of WikiProject Performing arts Fjjulien (talk) 21:27, 17 June 2022 (UTC)[reply]

Certainly sounds like an item which is missing - good idea to create — Martin (MSGJ · talk) 20:56, 18 June 2022 (UTC)[reply]
@MSGJ Thank you for your input. Fjjulien (talk) 17:01, 23 June 2022 (UTC)[reply]
The WikiProject Performing arts community met today meeting to discuss this question (see the minutes). There was consensus that a new class item describing a "performance hall" is needed to meet the information needs of the performing arts sector. I will for example for example, make it possible to associating a maximum capacity (P1083) with a specific room as opposed to an entire building. It was deliver cleaner query results and will therefore enable more efficient data reuse.
The suggested description for the concept is:
  • (en) performance hall: "room intended for the presentation of live performances before an audience, generally comprising an audience space and a stage space"
  • (fr) salle de spectacle: « salle destinée à des représentations de spectacles devant public qui comporte généralement une scène et un espace pour les spectateurs »
This concept will be the same as Grand dictionnaire terminologique ID (P9900): 17061281. The Getty Art and Architecture Thesaurus was contacted in advance of the meeting and decided to create a record for the concept: AAT_300449028. The class item will be maintained by WikiProject (P6104): WikiProject Cultural venues (Q107031691).
This discussion and the minutes of the meeting will be documented in the discussion page of the WikiProject Cultural venues. Beat Estermann (talk) 22:21, 31 March 2017 (UTC) Romaine (talk) 10:33, 20 April 2017 (UTC) - working on the cultural venues from a Belgian performing arts database. I am importing this database in a collaboration with this institution. Beireke1 (talk) Beireke1 (talk) 12:07, 2 May 2017 (UTC) - collaborating with Romaine on Belgian data on performing arts venues. Affom (talk) 15:26, 12 May 2017 (UTC) Anvilaquarius (talk) 11:41, 15 September 2017 (UTC) PEAk99(talk) PEAK99 (talk) 20:32, 29 January 2019 (UTC) Boxomi (talk) 22:21, 24 September 2019 (UTC) Antoine2711 (talk) 00:19, 5 December 2019 (UTC) Fjjulien (talk) 21:15, 13 February 2020 (UTC) Vero Marino (talk) 21:15, 13 February 2020 (UTC) Bello Na'im (talk) 08:34, 24 September 2021 (UTC)Pictogram voting comment.svg Notified participants of WikiProject Cultural venues[reply]
I will wait until tomorrow to create the new class item. If you have any thoughts or suggestions about the labels, the descriptions, the alias or the statements for this class item, please share them here. Fjjulien (talk) 17:22, 23 June 2022 (UTC)[reply]

"Salle de spectacle" as well as "performance hall" are widely used in their languages for the whole building as well. There will be lots of confusion. --Anvilaquarius (talk) 09:50, 24 June 2022 (UTC)[reply]

There are lots of buildings which contain more than one performance hall, so I think the distinction is important. — Martin (MSGJ · talk) 12:03, 24 June 2022 (UTC)[reply]
@Anvilaquarius I am too well aware of the confusion that exists with the French expression « salle de spectacle ». Similar confusion is experienced with many terms associated with event buildings and rooms (for example "theatre"). However, as @MSGJ pointed out, many performing arts buildings contain more than one performance space (see National Arts Centre (Q105547738)). Moreover, the performing arts community identified several rationales supporting the creation of this class:
  • Performance halls often have a distinct name from the building.
  • Places announced as locations for live performances are very often performance halls rather than the whole building.
  • Technical information such as room capacity and stage dimensions are specific to each performance hall, not to the building as whole.
  • Many industry datasets hold records of entities that are instances of performance halls.
  • And event venue (Q18674739) is too broad and messy to be used by the industry as an alternative to conceptually clear "performance hall" class.
Altogether, this class will item will serve many structural needs within Wikidata and it will enable better data reuse by the performing arts industry. Fjjulien (talk) 16:50, 24 June 2022 (UTC)[reply]
✓ Done: performance hall (Q112688641) created. Fjjulien (talk) 18:42, 24 June 2022 (UTC)[reply]
After originally supporting this idea, I now find that we have auditorium (Q230752) which I think is the same concept? Can they be merged or is there a distinction? — Martin (MSGJ · talk) 21:55, 24 June 2022 (UTC)[reply]

Award presentation[edit]

Hoi, often an award recipient gives an acceptance speech. These are often recorded like this one. How can I document this as a qualifier to the award? Thanks, GerardM (talk) 09:52, 19 June 2022 (UTC)[reply]

video (P10) perhaps — Martin (MSGJ · talk) 14:51, 20 June 2022 (UTC)[reply]

Admin activity[edit]

It seems that User:Cyberpower678/ActiveStats has not been updated since February 22nd. I dropped a note to Cyberpower678 at enwiki, but no response. I think admin activity should be monitored, to see if acitivity criteria are met. I know of at least one former admin who withdrew themselves, but I don't think that is how it is supposed to be. Any thoughts? Lymantria (talk) 13:54, 19 June 2022 (UTC)[reply]

How about Admin Stats? It seems to work. --Epìdosis 14:00, 19 June 2022 (UTC)[reply]
Indeed. Lymantria (talk) 15:53, 19 June 2022 (UTC)[reply]
In the past I have developed a similar report, but it has never been deployed to any onwiki presence yet. User:MisterSynergy/activity/Administrator (and other pages) should now provide similar results. There are a couple of other inactivity policies which can be monitored as well.
  • Would this be useful to have regularly updated? If so, what is a good interval? It would be easy to set this up.
  • Any flaws observed? Please let me know.
MisterSynergy (talk) 21:56, 20 June 2022 (UTC)[reply]
This is neat, MisterSynergy! It would be great if it updated is daily? --Lymantria (talk) 05:14, 21 June 2022 (UTC)[reply]
This should be set up right now. I am going to monitor it within the next days in order to make sure that nothing goes wrong here. —MisterSynergy (talk) 08:10, 21 June 2022 (UTC)[reply]

When an event can occur[edit]

How can I relate pre-order (Q4376555) and pre-order period (Q112628344) to say that pre-orders can occur during the pre-order period?

An analogous relationship would be vote (Q42904171) can occur during voting period. Lectrician1 (talk) 14:57, 19 June 2022 (UTC)[reply]

We have something close with valid in period (P1264) View with SQID. author  TomT0m / talk page 18:48, 21 June 2022 (UTC)[reply]

Today's WDQS backend update meeting is cancelled[edit]

Dear all, sorry for the short notice, but we are forced to cancel today's meeting about WDQS backend update due to several staff members being out for illness (including me, unfortunately). The meeting will be rescheduled to a new date as soon as possible. Sannita (WMF) (talk) 08:48, 20 June 2022 (UTC)[reply]

You can now reuse Wikidata Lexemes on all wikis[edit]

Hello all,

In 2018, the Wikidata development team enabled Lexemes, Forms and Senses on Wikidata, allowing everyone across the Wikimedia projects to gather structured data about words and languages. Lexicographical data has been growing, thanks to the effort of the community who added, up to this point, more than 661K Lexemes in 846 different languages on Wikidata (13 languages having more than 1500 Lexemes - see statistics here.

In order to make this data usable and useful, one missing feature was the ability to access and use the data from Wikidata’s Lexicographical Data on the other Wikimedia projects via Lua modules. This feature has been requested for a long time by editors, and after a test phase on a few Wiktionaries, we are happy to announce that Lua access to Wikidata Lexeme will be enabled on June 21st on all Wikimedia projects.

Practically, Lua access means that we created some new Lua functions that will allow you to integrate Lexemes, Forms and Senses from Wikidata on any of the pages of any Wikimedia wiki. Among many possibilities that this feature offers, you will be able to create for example: conjugation or declination tables, stubs of Wiktionary entries, tools displaying the meaning of a word on Wikisource, and many other things, depending on what your project needs. Until someone on your project writes a Lua module that makes use of these new functions and then uses this module on a page, nothing changes for your project.

In order to use it, people with experience with Lua modules and templates can look at the documentation listing the available functions. You can also have a look at simple example showing the singular and plural forms of an English noun: the template, the module, the result.

Following the deployment of this feature, we are confident that several editors will start creating their own modules for Wikisource or Wiktionary - we invite you to share your experiments on this talk page, so other people can discover what you have been doing and get inspired.

If you’re involved on a Wiktionary or Wikisource, feel free to share this announcement around and to try the feature with your community.

If you have any questions or feedback, or if you want to discuss with other editors, feel free to use the talk page of the lexicographical data project or the related Telegram group. To report a technical issue, feel free to use this Phabricator ticket.

Thanks for your attention and have fun with Lexemes! Lea Lacroix (WMDE) (talk) 12:19, 20 June 2022 (UTC)[reply]

Occupation: actor ?[edit]

I suggest that we only use actor and not divide it into television actor, film actor, voice actor, stage actor etc. I think they are too specific. Most notable actors have a carriere that includes several (in many cases all) of these fields. Ezzex (talk) 13:34, 20 June 2022 (UTC)[reply]

The more specific the better I think! If they have done various types of acting, you can add multiple values to the property — Martin (MSGJ · talk) 14:49, 20 June 2022 (UTC)[reply]
I agree that using the property actor and adding qualifiers for tv/stage/film is best. Easier to write queries that way, and extra modes, like video game don't require new properties. Vicarage (talk) 18:57, 20 June 2022 (UTC)[reply]
No it is not. Voice actor is unsurprisingly a subclass of actor. The voice actor specialization is notable, meaning that it has to have its own Q-item, meaning you gain nothing from using a qualifier. I'm with MSGJ on this, I don't know what is the reason for the suggestion, but if has to do with too many items in the infobox, this is better solved on the local wiki. If you don't feel like adding many statements to the occupation, then it should be fine just adding 'actor' assuming you don't remove any more specific statements. Infrastruktur (talk) 12:45, 23 June 2022 (UTC)[reply]
On Commons and Wikipedia we love intersecting concepts. In Wikidata we have the option to use other properties to go deeper. So for example instance of (P31) is always set to human (Q5) for humans and not man (Q8441) or actor (Q33999), we use sex or gender (P21) and sex or gender (P21) for that. I would continue on that path and use field of work (P101).
Take for example Tom Hanks who has actor (Q33999) and a whole bunch of subclasses: film actor (Q10800557), voice actor (Q2405480), character actor (Q948329), television actor (Q10798782) & stage actor (Q2259451). Shouldn't we just have actor and put the relevant classes ("film acting", "voice acting" etc.) in field of work (P101)? Multichill (talk) 10:14, 25 June 2022 (UTC)[reply]

Wikidata weekly summary #425[edit]

Choose qualifier when multiple values[edit]

Here is my answer to the archived question Wikidata:Project_chat/Archive/2022/06#How_to_access_a_chosen_qualifier_when_a_given_property_has_multiple_preferred_values:


The example uses en:Template:Wikidata in Wikipedia to fetch the latest software version using the following:

This leads to multiple results:

  • {{wikidata|property|edit|reference|Q55671|P348}} gives: 5.1.2[1] Edit this on Wikidata
  • {{wikidata|qualifier|Q55671|P348|P577}} gives: 16 February 2018; 9 February 2019


To reduce the result from multiple results to one, you could for example choose stable version (Q2804309) or beta version (Q3295609) with version type (P548), e.g. P548=Q2804309 according to the syntax and options in en:Template:Wikidata.

  • stable version (Q2804309)
    • {{wikidata|property|edit|reference|Q55671|P348|P548=Q2804309}} gives: 5.0.6[2] Edit this on Wikidata
    • {{wikidata|qualifier|Q55671|P348|P577|P548=Q2804309}} gives: 9 February 2019
  • beta version (Q3295609)
    • {{wikidata|property|edit|reference|Q55671|P348|P548=Q3295609}} gives: 5.1.2[1] Edit this on Wikidata
    • {{wikidata|qualifier|Q55671|P348|P577|P548=Q3295609}} gives: 16 February 2018

References from examples[edit]

  1. 1.0 1.1
  2. "Bugzilla 5.0.6 Release Notes". 9 February 2019. Retrieved 18 January 2021.

Robertsilen (talk) 06:58, 21 June 2022 (UTC)[reply]

Copyright question[edit]

So I have a couple scenarios that I would like to know the answer to, if they're able to be added to wikidata (not as a url but actual data)

1) For ex a phone manufacturer publishes a datasheet for their phone. The specifications on that document (what types of ports, version of bluetooth, screen resolution etc) (I'm guessing that's allowed?)

2) A website like Gsmarena that's already indexed data from datasheets like mentioned above (I'm guessing this is not allowed, as it's data owned by gsmarena, so only a link to gsmarena would be allowed, not actual data copy)

3) Data about a business (Opening hours, adres, phone number, etc..) on their own website (I'm guessing that's allowed)

4) Data about a business (..) on their Facebook/twitter/ig/.. page (I'm used to that being allowed to a certain degree on Openstreetmap, but that obv doesn't have an actual cc0 license like wikidata does. So I don't know about this one)

5) Let's say there is a photo of product box, that photo is on Commons with a CC by SA license. Taking information from that box photo, can that be used in Wikidata?

Thibaultmol (talk) 08:25, 21 June 2022 (UTC)[reply]

  • Factual information can't be copyrighted, to meet the threshold of originality you need some sort of commentary. --RAN (talk) 18:38, 24 June 2022 (UTC)[reply]

Desktop Improvements update[edit]

Making this the new default

Hello. I wanted to give you an update about the Desktop Improvements project, which the Wikimedia Foundation Web team has been working on for the past few years. Our work is almost finished! 🎉

We would love to see these improvements become the default for readers and editors across all wikis. In the coming weeks, we will begin conversations on more wikis, including yours. 🗓️ We will gladly read your suggestions!

The goals of the project are to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use article tabs and the user menu, and more. The improvements are already visible by default for readers and editors on more than 30 wikis, including Wikipedias in French, Portuguese, and Persian.

The changes apply to the Vector skin only, although it will always be possible to revert to the previous version on an individual basis. Monobook or Timeless users will not notice any changes.

The newest features
  • Table of contents - our version is easier to reach, gain context of the page, and navigate throughout the page without needing to scroll. It is currently tested across our pilot wikis. It is also available for editors who have opted into the Vector 2022 skin.
  • Page tools - now, there are two types of links in the sidebar. There are actions and tools for individual pages (like Related changes) and links of the wiki-wide nature (like Recent changes). We are going to separate these into two intuitive menus.
How to enable/disable the improvements
  • It is possible to opt-in individually in the appearance tab within the preferences by selecting "Vector (2022)". Also, it is possible to opt-in on all wikis using the global preferences.
  • On wikis where the changes are visible by default for all, logged-in users can always opt-out to the Legacy Vector. There is an easily accessible link in the sidebar of the new Vector.
Learn more and join our events

If you would like to follow the progress of our project, you can subscribe to our newsletter. You can read the pages of the project, check our FAQ, write on the project talk page, and join an online meeting with us.

Thank you! SGrabarczuk (WMF) (talk) 16:59, 21 June 2022 (UTC)[reply]

Join us on Tuesday

Join an online meeting with the team working on the Desktop Improvements! It will take place on 28 June 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location. The following events will take place on 12 July and 26 July.

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file and copied to Etherpad. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English. At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We can answer questions asked in English and a number of other languages. If you would like to ask questions in advance, add them on the talk page or send them to We hope to see you! SGrabarczuk (WMF) (talk) 21:42, 23 June 2022 (UTC)[reply]

Implicating/mentioning another in formal trial setting[edit]

Hi, looking at modelling how accused witches were named in a formal trial process. So the accused witch is defendant (P1591) but during their trial they mention/name/implicate/denounce other people who are subsequently investigated and then brought to trial themselves. And the cycle continues. From historical and legal point of view the nature of modelling this McCarthy-esque witch hunt of ""naming names"" is important and I'm wondering how to do this correctly given the current properties on legal terms and naming don't seem to cover this. Allegation or Denunciation or Mentioning or Implication comes closet I believe. In the Survey of Scottish Witchcraft we have 7 types of mention indicated during the trials:

  • Accomplice
  • Denounced
  • Consulted
  • Hired
  • Known witch
  • Witchcraft precedent
  • Previously tried

The vast majority are either indicated as accomplice or denounced. The property perpetrator (P8031) includes accomplice as an alias but perpetrator doesn't sit right with what is actually being alleged. One thought was to include the property of significant person (P3342) on a trial item to indicate people implicated during the trial process. And using qualifiers object has role (P3831) to link to the type of mention - accomplice (Q706884) or denunciation denunciation (Q1189956) etc. - and extra qualifier of sourcing circumstances (P1480) indicating this is allegedly (Q32188232). An example of what I mean is here trial of Mawsie Aslownae (Q43404889)
This would not help me add mentions of consulted, hired, known witch or witchcraft precedent but it goes some way to get the vast majority of mentions included. From legal/historical point of view of modelling, just wondering if anyone has thoughts on whether there is a better way and whether a property proposal of (1) alleges/allegation or (2) implicates or (3) mentions or (4) names might be appropriate... or misused. Implicates seems the most appropriate and least liable to misuse in my view but let me know what you think. Stinglehammer (talk) 10:25, 22 June 2022 (UTC)[reply]

Qualified significant person (P3342) is IMO a good way to go. I'd be inclined to create a set of qualifier items for the project, so in trial of Mawsie Aslownae (Q43404889), 'denunciator':'person listed as denouncing a witch" ... and in the 'denunciator' item, part of (P361) Scottish Witchcraft Project dataset. No reason why consulted, hired, known witch &c cannot be covered in this way. --Tagishsimon (talk) 11:19, 22 June 2022 (UTC)[reply]

Edit Statistics and Analytics and metrics[edit]

I am wondering if there is a way to see edit statistics similar to Wikipedia's edit summary for a page. ScientistBuilder (talk) 02:10, 23 June 2022 (UTC)[reply]

@ScientistBuilder: this? --Tagishsimon (talk) 02:27, 23 June 2022 (UTC)[reply]

Describing membership benefits[edit]

For British house museums I'm noting when they are member of (P463) Historic Houses Association (Q5773523). Half the houses offer free access to members of the public who also join the association, half do not, and its a strong split on their website. Any suggestions on how I qualify each statement, some form of reward (P4444) perhaps? Would a new item gratis_entry_for_members be sensible, or use existing terms? Vicarage (talk) 04:55, 23 June 2022 (UTC)[reply]

I ended up only adding sites who offered free access to members. Vicarage (talk) 09:45, 25 June 2022 (UTC)[reply]
Not sure if we already have a good model for that. I tried using fee and that seems to be a better option than using payment types accepted. Multichill (talk) 09:56, 25 June 2022 (UTC)[reply]
@Multichill: applies to people (P6001) looks like a useful relevant qualifier here, to use with a fee (P2555) statement. Jheald (talk) 11:43, 25 June 2022 (UTC)[reply]

WDQS backend update meeting rescheduled[edit]

Hi all! The online community meeting for the Wikidata Query Service backend update has been rescheduled for Monday June 27, 2022 at 18:00 UTC (link to the meeting).

The topic of the call will be the testing of the backend alternatives and the Blazegraph migration, and this will be also an opportunity to discuss the approach and the details, and to ask other questions about the Blazegraph alternatives work - such as how the Blazegraph-specific features and capabilities will (or will not) be supported. This will also be the last chance to talk to Andrea Westerinen, our Graph Consultant, before her contract expires! You can find more info about the latest WDQS backend updates here.

My sincere apologies for those who showed up last time, only to find the meeting to be canceled. As you know we were forced to cancel last-minute because of several people (me included) being ill, this time we hope it will go better. :)

See you there! Sannita (WMF) (talk) 11:18, 23 June 2022 (UTC)[reply]

Named after[edit]

When an item 1 is named after an item 2, the field "named after" is filled in.

With regard to item 2, can we know if it is eponymous, i.e. if it is used to name an item ?

For example: 470 Kilia is named after Kiel.

Is Kiel used to name an asteroid? Nothing says it. Io Herodotus (talk) 11:56, 25 June 2022 (UTC)[reply]

Well yes, something does say it, but for the most part only via a SPARQL report. The thing about WD is that it is linked data, and the full picture only emerges when the content of links to an item are considered alongside links within the item. There are good reasons why there is no reciprocal property for 'named after' ... consider Queen Victoria, after whom a huge number of things are called ... there's nothing to be gained by adding all of them to her WD item. Much better to point each instance of a thing named after her, at her item. WD is very much not wikipedia; one should not expect all information about an item to be within the item. --Tagishsimon (talk) 12:20, 25 June 2022 (UTC)[reply]
Thank you.
That could be a good reason. However I think an item could be added, in the style of "award received", it could be "honour received". In many cases it could be useful (Kilia for instance).
What is a SPARQL report ?
--Io Herodotus (talk) 14:22, 25 June 2022 (UTC)[reply]
It is, for sure, easy to imagine the new property which could point from the source (person, thing) which gave its name to whatever it gave its name to. But as I say a) it's not necessary and b) it invites the compilation of long lists of property values within an item record, which for all sorts of UI and technical reasons is a bad thing. So - with some dishonourable exceptions (cough tributary (P974) and inflows (P200)) - WD does not encourage reciprocal properties in situations in which there are very-many to one ratios within the datasets to be linked.
SPARQL is the query language used to produce reports from wikidata; a SPARQL report interface for wikidata is at
Here, by way is example, is a report showing all main-belt asteroids whch are named after someone or something, together with a link to and identification of the thing they're named after (press the 'play' button).
If you're serious about wikidata, then knowing how to write SPARQL reports is fairly necessary. There's an excellent tutorial here - - and a helpdesk here - Wikidata:Request_a_query. --Tagishsimon (talk) 14:52, 25 June 2022 (UTC)[reply]

Using Youtube videos for described at URL (P973)[edit]

Youtube channels like and produce detailed videos on particular ships or tanks which are well regarded and curated and as good an introduction to their subjects as a Wikipedia page. Is their any reason I should not add them to the relevant articles using described at URL (P973) as I have at Marcílio Dias-class destroyer (Q110895911) and Churchill (Q696182). Are there notability/quality thresholds I should be aware of? Vicarage (talk) 11:57, 25 June 2022 (UTC)[reply]

IMO use of P973 is fairly subjective; if you think a video warrants a link b/c it is encyclopaedic & you regard the source as trusted, then all's good; do it. Consider whether it would be better to create or use an item for the source - 'TheTankMuseum youtube channel' - as a value for a described by source (P1343) statement, qualified with URL (P2699) pointing to the video (and perhaps media legend (P2096) & any other useful qualifiers). Arguably that would provide a better base for curating the set of links to the youtube channel. --Tagishsimon (talk) 12:14, 25 June 2022 (UTC)[reply]
Thanks. I'm trying that for Churchill (Q696182), but I had to make The Tank Museum (Q112706730) a video recording (Q34508) to allow it to be a described by source (P1343), because YouTube channel (Q17558136) wasn't considered a valid source. Allowing group of works (Q17489659) to be a valid source would fix that, and I've flagged it. Vicarage (talk) 12:54, 25 June 2022 (UTC)[reply]

Please migrate this property[edit]

Statistics Indonesia area code (P1588) should be migrated as identifier because the code is unique, published by Statistics Indonesia (Q3449895), a government department responsible for statistics. I've asked this at Wikidata:Identifier migration/1 but no response there. Hddty (talk) 13:22, 25 June 2022 (UTC)[reply]

Unfortunately there are 1335 non-distinct values as shown in this report — Martin (MSGJ · talk) 19:54, 26 June 2022 (UTC)[reply]
@MSGJ By migrating, hope that it will motivate editors to fix it so it would be like administrative code of Indonesia (P2588) (already an identifier) with few violations. Hddty (talk) 00:22, 27 June 2022 (UTC)[reply]

Merge request[edit]

Could somebody please merge Cotoneaster nan-shan (Q96201349) and Cotoneaster nanshan (Q70866244) for me? I have never been able to get the merge to work. Thanks! Abductive (talk) 09:04, 26 June 2022 (UTC)[reply]

You've made just short of 10k wikidata edits. Probably time to work out what's going wrong with merge. What's going wrong with merge? See also help:merge. (And w.r.t. the instance issue, there does seem to be an issue of the two items having different taxon authors ... ideally that should be checked lest it indicate the merge is unsafe (although I see someone has already merged it, as if these things don't matter ... @Maculosae tegmine lyncis: does it not matter?)). --Tagishsimon (talk) 11:22, 26 June 2022 (UTC)[reply]
@Abductive @Tagishsimon I think it does matter. Also the taxon names have different spellings. I am reverting the merge for now. Vojtěch Dostál (talk) 20:08, 26 June 2022 (UTC)[reply]
@Vojtěch Dostál, @Tagishsimon, Plants of the World Online (Q47542613) lists the authors as "M.Vilm. ex Mottet", which constitutes good evidence that the two items are talking about the same entity. Auguste Louis Maurice Levêque de Vilmorin (Q4111351) is given as the author in Cotoneaster nanshan and Séraphin Joseph Mottet (Q21340334) is given as the author in Cotoneaster nan-shan. A hyphen is not considered something that makes a difference in biological nomenclature. Abductive (talk) 20:17, 26 June 2022 (UTC)[reply]
That all sounds excellent. But here's the thing: merge is the ideal time to fix issues like this. Farming out your merge, having your merge done by someone who doesn't seem to have apprehended that there was an issue here to address, is suboptimal. --Tagishsimon (talk) 20:30, 26 June 2022 (UTC)[reply]

Club was formed after a merger of two others club[edit]

Hello. Example, AEK Larnaca F.C. (Q291447) was formed after a merger of EPA Larnaca FC (Q2317850) and Pezoporikos Larnaca FC (Q2277220). I can show in EPA Larnaca FC (Q2317850) and Pezoporikos Larnaca FC (Q2277220) that they merged together to form AEK Larnaca F.C. (Q291447). See Q2317850#P576. But how can I show in AEK Larnaca F.C. (Q291447) that was created after the merger of the two other teams? Philocypros (talk) 15:31, 26 June 2022 (UTC)[reply]

You can also use merged into (P7888) but I'm not aware of an inverse property to this — Martin (MSGJ · talk) 20:00, 26 June 2022 (UTC)[reply]
merged into (P7888) is about a subject that was dissolved and merged into the other object, that existed previously. It's not the same case. In my example A and B merged together and created C. Both A and B were dissolved. Philocypros (talk) 00:51, 27 June 2022 (UTC)[reply]

Towards documented SPARQL queries[edit]

SPARQL queries are essential to explore the Wikidata graph. Right now, each wikiproject has some specific queries in the project pages. Users share their queries in the weekly newsletter and many user stores queries in their own user page. That's great but there is a lack of documentation for queries.

In Documented queries, I propose an approach to create wiki pages to document queries. I provide a first example : User:PAC2/Query/Gender and labels for properties whose values are instances or subclasses of human in French.

I think that the documented queries approach is complimentary to existing initiatives such as {{Query page}} and Wikidata:Showcase Queries.

Of course, there are many open question. If relevant, we could move User:PAC2/Documented queries to something such as Wikidata:Documented queries. Maybe it would be also relevant to have a specific namespace for documented queries such as Wikidata:Queries:.

I would be happy to have feedback about this proposition. PAC2 (talk) 18:34, 26 June 2022 (UTC)[reply]

I'm not really seeing it. And it's not clear what the need is that you're trying to fill. My experience of writing and using reports for my own purposes, and my experience on Request a Query meeting the wants of users there, suggests that, in general, report specifications are fairly highly specific and nuanced, making it vanishingly unlikely that a library of reports will be of much use. It's very unlikely the report I want will be in the library; or if it is, because there is such comprehensive coverage of reporting needs, it's unlikely I'm going to be able to find it. So "library in which you can find the report you want" is just not a happening prospect.
If instead the purpose is exemplar reports, we have Wikidata:SPARQL query service/queries/examples, which is very well linked from the WDQS UI - has a very high profile - but is very very little maintained, suggesting there's not much user interest in collecting and collating reports. Were effort to be put into exemplar reports, improving that page might be more worthwhile. --Tagishsimon (talk) 19:07, 26 June 2022 (UTC)[reply]

Use of the terms 'pro-life' and 'pro-choice' on WD[edit]

I have noticed there are several items that uses both words in description or label. Do you others think this is something that should be avoided? Or are the terms within the scope of our policy of NPOV? --Trade (talk) 18:59, 26 June 2022 (UTC)[reply]

Does WD have an NPOV policy? If so, not easy to find. Whether or not, WD data should be NPOV. On this issue, the BBC style guide says "Avoid pro-abortion, and use pro-choice instead. Campaigners favour a woman's right to choose, rather than abortion itself. And use anti-abortion rather than pro-life, except where it is part of the title of a group's name."[1] That seems to be a sensible approach. --Tagishsimon (talk) 19:46, 26 June 2022 (UTC)[reply]
I assume there is a policy? People have definitely been banned for it before here. --Trade (talk) 20:18, 26 June 2022 (UTC)[reply]
Help:Description has related content, but it's not a formal policy. —MisterSynergy (talk) 20:39, 26 June 2022 (UTC)[reply]
I think this is actually an unreasonable policy, because it's predicated on "use the language that one group uses for itself and then not the language that another group uses for itself". Why is this NPOV? —Justin (koavf)TCM 01:39, 27 June 2022 (UTC)[reply]