Wikidata:Project chat/Archive/2023/03

From Wikidata
Jump to navigation Jump to search


Interwiki

Hi, I'm asking for help interwiki budget (Q56410323) to budget (Q41263) Bung Badak (☕)(kontribusi) 03:41, 5 March 2023 (UTC) Badak Jawa (talk) 03:41, 5 March 2023 (UTC)

→ ← Merged Estopedist1 (talk) 06:41, 5 March 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 17:27, 5 March 2023 (UTC)

Request for merge on Invidious.

Invidious (Q16868796) and Invidious(Q79343316) seem to describe the same thing, however I can't find the reason why both exist and why the former is defined as a "Wiktionary redirect", especially when it links to the English Wikipedia and not Wiktionary. I'd like to request a merge on both of these entries.

Money-lover-12345 (talk) 07:13, 5 March 2023 (UTC)

Hi @Money-lover-12345, I agree with you. → ← Merged. Michgrig (talk) 13:48, 5 March 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 17:27, 5 March 2023 (UTC)

question on 'also known as (aliases)'

Hi this Query finds a lot of architects together with their alias names. When looking at the results, I wonder about aliases containing the lastname only. While Michelangelo (Q5592) is primarily known by his first name, and the full name is mentioned as alias, I doubt that all these architects are known by their lastnames only. e.g. Rudolf Wondracek (Q2174150) Furthermore I feel that using the less unique lastnames as aliases will pollute the namespace. Search will find items by lastname only in any case. Is there a rule, when to put the bare lastname as an alias? And is it considered disruptive to remove such aliases? Help:Aliases says: you should include Surnames or nicknames of famous individuals ... Like Michelangelo or Shakespeare, but Wondracek? best --Herzi Pinki (talk) 20:07, 27 February 2023 (UTC)

I would consider it disruptive. It cannot be beyond possible that a user might search for Wondracek with a view to finding the architect. I do not recognise the concept of "polluting the namespace"; search expresses its result as Rudolf Wondracek (Wondracek), which seems cromulent. I think as a general rule, seeking the removal of aliases added by other in, presumably, good faith, is going down the wrong track. --Tagishsimon (talk) 20:18, 27 February 2023 (UTC)
I do wonder why the bot did it, but the operator doesn't seem to be around anymore to ask. Multichill (talk) 20:21, 27 February 2023 (UTC)
@Multichill: I would say because of this. Redirects were commonly used to seed aliases, and the bot adding it right after creating the element seems to make sense with it. -- Nono314 (talk) 19:39, 28 February 2023 (UTC)
removing the alias will not hinder searching for the surname, e.g. https://www.wikidata.org/w/index.php?search=Krawina for Josef Krawina (Q87563). --Herzi Pinki (talk) 21:28, 27 February 2023 (UTC)
It will hinder search: the quicksearch would now not find it; it'd require a full search. It's a way of degrading WD for no obvious benefit. --Tagishsimon (talk) 21:32, 27 February 2023 (UTC)
ok. So then the recommendation is to add the surname as an alias for all humans? To ease quicksearch? Help:Aliases then has to be fixed. Wouldn't it be an improvement, when quicksearch knows about this and implicitly does the expected thing? best --Herzi Pinki (talk) 22:51, 27 February 2023 (UTC)
Currently, Help:Aliases says "you should include Surnames or nicknames of famous individuals" but not "you should include Surnames or nicknames of individuals that aren't famous". If we would add it as alias for all humans, that would likely result in humans showing up in a lot of quicksearches where the user is not searching for them.
When it comes to both labels and aliases it's worth noting that they exist for ease of use. If you do queries and care about how the name gets displayed, there's a good chance that refering to name (P2561) and it's subproperties give you better results. Those properties also have the advantage that they have sources while labels and aliases do not. ChristianKl ❪✉❫ 14:36, 28 February 2023 (UTC)
To fix QuickSearch you could add:
  1. "Surname, Name"
  2. "Name Surname" for Japanese names
  3. "Surname XX" for people who publish papers with initials (this is needed for https://author-disambiguator.toolforge.org/ to work).
So a lot of options, not just adding the surname. Lockal (talk) 06:28, 1 March 2023 (UTC)
I was asking for a rule to follow, not for (even contradicting) options. "Surname, Name" is discouraged by Help:Aliases (You should not include: ... Alternative word order for people names (first name followed by last name vs. last name, comma, first name)). --Herzi Pinki (talk) 08:32, 1 March 2023 (UTC)

Facilities count

I'm interested in specifying the number of buildings in a complex. Is there a property I could use for that? {{u|Sdkb}} talk 03:09, 28 February 2023 (UTC)

@Sdkb: You could use has part(s) of the class (P2670) with "building" and the qualifier quantity (P1114). Amqui (talk) 16:13, 1 March 2023 (UTC)
Hmm, that seems pretty clunky. Is a new property needed for this? {{u|Sdkb}} talk 17:23, 1 March 2023 (UTC)
@Sdkb I'd say no, because we would then have hundreds of "number of..." properties. The proposed modelling seems just fine to me... Vojtěch Dostál (talk) 17:47, 1 March 2023 (UTC)
I think logically it should be a qualifier so you know what the quantity applies to. — Martin (MSGJ · talk) 17:48, 1 March 2023 (UTC)
@Sdkb I'd say no as well for the same reason mentioned by Vojtěch Dostál. Amqui (talk) 19:51, 1 March 2023 (UTC)

Reminder: Office hours about updating the Wikimedia Terms of Use

Hello everyone,

This a reminder that the Wikimedia Foundation Legal Department is hosting office hours with community members about updating the Wikimedia Terms of Use.

The office hours will be held on March 2, at 17:00 UTC to 18:30 UTC. See for more details here on Meta.

Another office hours will be held on April 4.

We hereby kindly invite you to participate in the discussion. Please note that this meeting will be held in English language and led by the members of the Wikimedia Foundation Legal Team, who will take and answer your questions. Facilitators from the Movement Strategy and Governance Team will provide the necessary assistance and other meeting-related services.

On behalf of the Wikimedia Foundation Legal Team,

JPBeland-WMF (talk) 16:11, 1 March 2023 (UTC)

Battles get warnings if given historic county locations

Battle of Hastings (Q83224) gets a warning for historic county (P7959) as its not a geographical location. I think historic county (P7959) constraints should be relaxed to allow either battle (Q178561) or even past occurrence (Q110227435), as occurrences often occur at places. Vicarage (talk) 17:11, 1 March 2023 (UTC)

Battle added as subject type constraint Vicarage (talk) 06:58, 9 March 2023 (UTC)

Add statement on the top of the page

Do we have any gadget to move "add statement" option and the consequent dialog to the top of the page? Juandev (talk) 08:04, 2 March 2023 (UTC)

ISBN to Wikidata

Do we have a SourceMD-like tool that will generate Qucikstatemnts commands, given an ISBN? Or is Zotero still my best bet? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:38, 2 March 2023 (UTC)

Use of 'participant in' for countries

United States of America (Q30) has about 20 arbitrary participant in (P1344) entries. Is is really appropriate to have these for such a multifaceted item when participant (P710) for the individual subjects seems a better approach. Could a constraint be applied to country (Q6256) or above to discourage this sort of thing? Vicarage (talk) 09:10, 1 March 2023 (UTC)

Languages

Until today, when I visited a Wikidata item, I was shown a description in four languages at the top left: in my case Dutch, English, French and German. That was fine with me. Today German had suddenly been replaced by 'American English'. Is there an American English Wikipedia nowadays? In any case: I never asked for this change and I need German much more than American English. How do I get my familiar German back? Sijtze Reurich (talk) 20:38, 1 March 2023 (UTC)

If you create a bable box on your user page, Wikidata takes the lanugages of that page as the languages it shows you. ChristianKl ❪✉❫ 22:43, 1 March 2023 (UTC)
I created bable boxes, but this does not help. But why do things like this happen at all? I never asked for American English, did I?

Agree wwith User Sijtze Reurich, this is really an unwanted action for all Wikidata users worldwide. If possible, somebody should find the reason for this unwanted major change and revert this. --Florentyna (talk) 06:18, 2 March 2023 (UTC)

Strange. When I log out, US English is suddenly replaced by German. When I log in anew, German is replaced by US English again. Sijtze Reurich (talk) 07:55, 2 March 2023 (UTC)
A colleague at the Dutch Wikipedia came up with a solution. The problem is not caused by Wikidata, but by Firefox! Hence, only Firefox users are affected. In Firefox go to "Settings", then to "Language" and delete "En-US". Sijtze Reurich (talk) 08:16, 2 March 2023 (UTC)
The other solution would be to create https://www.wikidata.org/w/index.php?title=User:Sijtze_Reurich&action=edit&redlink=1 and to add a bable box. ChristianKl ❪✉❫ 18:45, 2 March 2023 (UTC)

Full iso 639-3 support for title field

Is it possible to add additional languages as valid possibilities for the title field language? Many valid minority languages listed in (Property:P220) are not recognized. Nontoxicjon (talk) 17:52, 2 March 2023 (UTC)

https://www.wikidata.org/wiki/Help:Monolingual_text_languages describes the process in which languages get added. ChristianKl ❪✉❫ 18:42, 2 March 2023 (UTC)
Thanks for the reference! Nontoxicjon (talk) 21:28, 2 March 2023 (UTC)

Geographic administrative entities with multiples statuses

How are we supposed to deal with entities with overlapping or changing statuses?

e.g. East Ham (Q5177614) has held status county borough (Q1137272), municipal borough (Q518343) and urban district of Great Britain and Ireland (Q374614). Should each be a separate item? MRSC (talk) 08:58, 3 March 2023 (UTC)

The item already has start and end dates for its different roles. That seems fine to me. Multiple items would be a bad idea, even if there were minor boundary changes during its lifetime. Vicarage (talk) 09:39, 3 March 2023 (UTC)

Data comemorativa

Criei uma data comemorativa que não encontrei em nenhum outro lugar, posso acrescenta-la no wiki? 2804:18:849:FC67:F372:B330:7F78:9868 20:21, 3 March 2023 (UTC)

Google search engine

Dear community, could you please tell me why some Wikidata articles are not showing up in Google search engine? Is there a way to fix this? Thank you! 37.252.88.54 15:21, 4 March 2023 (UTC)

what articles? BrokenSegue (talk) 15:50, 4 March 2023 (UTC)

Please help me delete https://mix-n-match.toolforge.org/#/catalog/5789

I've messed up it by uploading a file not in UTF-8 encoding. I also find out mix-n-match can't pick up matches already on Wikidata if the ID contains a Chinese character, so it's difficult to sync it up. Midleading (talk) 02:52, 5 March 2023 (UTC)

@Midleading: did you try doing an import again at https://mix-n-match.toolforge.org/#/import/5789 to overwrite the entries? Multichill (talk) 11:25, 5 March 2023 (UTC)
Yes, I did it, and I just did it again now. But the garbled entries like https://mix-n-match.toolforge.org/#/entry/150037217 and https://mix-n-match.toolforge.org/#/entry/150037218 remain. Midleading (talk) 11:57, 5 March 2023 (UTC)
IIRC the documentation is very lacking when it comes to updating catalogs, so much so that I've refrained from doing this in the past. If anyone who knows how this is done, can do something about that, that would be nice. Infrastruktur (talk) 11:57, 5 March 2023 (UTC)

Belgian embassies and consulates

Hi, is there a way to export the data from this website to let's say openrefine? RVA2869 (talk) 14:03, 5 March 2023 (UTC)

Disambiguation and different from

There are some 30 WD entries called Fort George (Q240678). I could add different from (P1889) with 29 entries for each, or I could point to the disambiguation page Fort George (Q240678) which listed the 30 sites. The former might be better for casual enquiry, the latter better in query land. But I'm not sure how WP disambiguation pages are handled across the different WPs, and confusion can easily be language dependant, as the names could be clearly different in certain languages. We don't seem to have a common way of linking disambiguation pages to items (or vice versa), so I'm uncertain as how to proceed. Vicarage (talk) 11:55, 5 March 2023 (UTC)

I use different from mainly as a means to prevent similar items from being merged erroneously. It's not useful to label all things with the same label as different. But if two are especially prone to confusion and you are sure they are different it's good to mark them. BrokenSegue (talk) 20:39, 5 March 2023 (UTC)

Transcluding lexemes

Hello. How is it possible (if at all) to transclude grammar forms of lexemes in Wikipedia? For example, I would like to use a genitive and sometimes a dative form of a noun (language: Slovene) in various templates. Can I insert them by calling them from Wikidata? Or should I go about this differently? --TadejM (talk) 02:21, 10 February 2023 (UTC)

I guess this is not yet possible. I've filed a feature request (phab:T329344). --TadejM (talk) 03:08, 10 February 2023 (UTC)
@TadejM: This little demonstration in the English Wikipedia might be of interest. ―BlaueBlüte (talk) 09:34, 10 February 2023 (UTC)
BlaueBlüte, it seems great. I will check it out to see if it suits my needs. Thank you! --TadejM (talk) 09:36, 10 February 2023 (UTC)
BlaueBlüte, it just works perfect. I've implemented it in sl:Predloga:Mesec kategorija. There are perhaps other things that need to be taken into account (vandalism, load etc.), but it does solve a major problem. Thank you again. --TadejM (talk) 10:29, 10 February 2023 (UTC)
BlaueBlüte, what I don't see able to do is to call forms defined with two or more grammatical features; see e.g. L1013827. I guess these forms should always be defined with more than two grammatical features. The module's usability would be greatly expanded if it was possible to link directly to lexeme forms. Which I guess should be possible to implement.[1] --TadejM (talk) 14:28, 10 February 2023 (UTC)
@TadejM: What I've generally done in this case--albeit somewhat inefficiently--is to iterate through the forms, concatenate the sorted QIDs of all features, and then check whether the result matches a particular ordered set I've previously defined. See bn:wikt:মডিউল:বাংলা_আভিধানিক_উপাত্ত for what I mean regarding concatenation (lines 235-238) and the particular ordered sets (lines 130-229). Mahir256 (talk) 14:45, 10 February 2023 (UTC)
@TadejM: What would be the benefit of transcluding a specific lexeme form, say writing {{transcLexF|L1013827-F2}} in a page (invoking some fictitious lexeme-form-transcluding template Template:transcLexF), over just writing out the form in the page as meseca (cf. meseca (L1013827-F2))? ―BlaueBlüte (talk) 08:06, 17 February 2023 (UTC)
Hello, BlaueBlüte. Transclusion would be mutually beneficial. On the one hand, it would possible to change the form in one place if required, provide additional information on the word/phrase, and reduce the number of spelling mistakes. On the other hand, Wikidata would put the forms to practical use and could also gather additional information on their use and the context where they are used. Finally, I guess it could be further upgraded, for example by creating sets of related forms that are displayed depending on the user preferences or something. It could also be used in various parser functions, such as {{#ifeq}}. Thank you. for the question. --TadejM (talk) 08:48, 17 February 2023 (UTC)
BlaueBlüte, what I would in particular appreciate is to be able to define lists of various case forms for names of individual languages that may be reused at various places in various cases and without duplication. These are tiresome to translate again and again and variants easily occur if the name is not centralized as much as possible. It should be possible to translate them at one place, preferably in a central repository.
For example, in English the same word is used for lang-de to show a German term in the article text, to indicate a language name in the infobox or to name the category Articles with sources in German. In Slovene, one has to use the word nemško (adjective) for the article text, the word nemščina for the infobox and the word v nemščini (locative) for the category name. As said, the management of these forms should be centralized to avoid redundancy and variants.
The same applies for other such lists, e.g. of artistic media etc. --TadejM (talk) 19:51, 19 February 2023 (UTC)
All those arguments and use-cases clearly make sense, but it would seem to me that any solution (maybe except for the grammatically simplest languages) has to go beyond what one might call ‘transcluding lexemes’—rather, a mechanism for dynamically selecting forms (or even lexemes) based on some feature (or even part-of-speech) requests seems necessary.
As to your example, which lexemes have the required Slovene forms
nemško
,
nemščina
, and
(v) nemščini
, repsectively (or the ones denoting any other language)? (If they aren’t in Wikidata yet, could you create them so we have an example to work from?) Also, is the preposition/particle
v
always the same with all language nouns? Or might it be a different preposition/particle like
po fantaščini
for some language nouns (making one up here)? BlaueBlüte (talk) 23:40, 19 February 2023 (UTC)
Hello, BlaueBlüte. I would be very inclined to develop this option further when it is available in its basic form. Please note that the developer at the linked ticket in Phabricator said the transclusion should work via the form IDs, so I guess any selector should be implemented downstream via a module. I've created three lexemes for German yesterday with various forms that may be used to further illustrate the development: L1029357 (noun), L1029405 (adjective), and L1029479 (adverb). Yes, the locative and instrumental may use different prepositions, so I've omitted them in the forms. What I also found out was that a) the work was very tedious, b) the presentation of forms is non-transparent (they should be presented in a table instead), and c) many such forms are available on Wiktionary, so they could be reused. What's your opinion about how we should proceed? --TadejM (talk) 11:23, 20 February 2023 (UTC)
@TadejM: Just briefly replying on one of your points, regarding nemščina (L1029357), nemški (L1029405), and nemško (L1029479): I added one sense each, and related those to German (Q188) via item for this sense (P5137). Could you have a look and check if those senses and statements are correct? Also, nemško (L1029479) currently has no forms. We need at least one form on any lexeme we want to transclude. Could you add one (even if the spelling might be exactly the same as in the lemma)? Thanks, BlaueBlüte (talk) 22:07, 22 February 2023 (UTC)
@BlaueBlüte:, I have checked this and confirm that the meanings and senses are correct. I have also added a form for nemško (which may refer to German language, Germans or Germany). --TadejM (talk) 19:35, 28 February 2023 (UTC)
Hi @TadejM, looks like this can be put to work in a SPARQL query. (Play with the VALUES to test other parts of speech and other grammatical features—examples are given in comments for each line.) Do you know if the project you want to employ this in (Slovene Wikipedia?) supports SPARQL queries via Lua modules? ―BlaueBlüte (talk) 00:19, 7 March 2023 (UTC)
Hi, BlaueBlüte. That's interesting, thanks. The Slovene Wikipedia does not contain SPARQL-supported modules at the moment but a module can always be built or imported from elsewhere. I'll test it. --TadejM (talk) 00:27, 7 March 2023 (UTC)
Hi, Mahir256. Thank you for providing this. I'll try around a bit and see what works best. --TadejM (talk) 14:59, 10 February 2023 (UTC)
One of the ideas of Wikifunctions is to provide an enviroment that can provide functions that do task like this. I don't think it would make much sense to invest into providing another API for this. ChristianKl ❪✉❫ 15:40, 10 February 2023 (UTC)

Here is the code to call a form by its ID provided by a developer at Phabricator. If anyone will use it to construct a module, please link it here for others to reuse. --TadejM (talk) 03:04, 15 February 2023 (UTC)

Adding a label in a language I don't normally use

Some time many years ago I must have configured my account to show me labels & aliases in the 8 languages I at all often use, but I can't for the life of me see how to add a label in a language other than one of these if I have a reason to. Is there something to click on the usual editing screen for an item to do this? Or do you have to do it some other way? Trying to fix a warning at Atelier Boissonnas (Q116985342), where I fixed RKDartists ID (P650) and it is now telling me that there should be a Dutch-language label if that is used. Please ping me if responding, I don't maintain a watchlist on Wikidata. - Jmabel (talk) 00:38, 6 March 2023 (UTC)

@Jmabel: You can add something like this to your common.js: (Preferences/Appearance/all skins)
mw.loader.load('//www.wikidata.org/w/index.php?title=User:Nikki/AddTermboxLanguage.js&action=raw&ctype=text/javascript');
Infrastruktur (talk) 13:13, 6 March 2023 (UTC)
There is also the labelLister gadget at Special:Preferences#mw-prefsection-gadgets. It provides a custom term editing dialog via the "tools" menu. —MisterSynergy (talk) 13:36, 6 March 2023 (UTC)
@MisterSynergy: could you tell me the name of that option? Searching on that page, neither "custom" nor "term" nor "editing" turns up anything that appears to be relevant. - Jmabel (talk) 16:29, 6 March 2023 (UTC)
@Jmabel: "Labels list" in English. Within the "tools" menu in the upper right corner (Vector/Vector-2022). —MisterSynergy (talk) 16:39, 6 March 2023 (UTC)
@MisterSynergy: I don't see anything by that name. I see "LabelLister", which I already have checked. It is allowing me to edit in (as I said above) the 8 languages I at all often use, but it does not seem to provide any way to access any additional languages. In any case, Peter James gave me a usable workaround below. - Jmabel (talk) 19:37, 6 March 2023 (UTC)
I tend to use quickstatements: QID TAB Lcy TAB "foo" for a Welsh label, for instance. --Tagishsimon (talk) 13:40, 6 March 2023 (UTC)
All of this seems terribly complicated, and makes it unduly difficult for someone who is not using Wikidata day-to-day to do this. - Jmabel (talk) 16:26, 6 March 2023 (UTC)

Wikidata weekly summary #562

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • wikidata-todo is a tool that helps you find Commons categories with files, where none of the files are used on Wikidata.
  • Other Noteworthy Stuff
  • Development
    • Wikibase REST API:
      • The statements endpoint now supports filtering by Property ID like ?property=P123 (phab:T309021)
      • We started working on GET /entities/items/{item_id}/aliases (phab:T327882)
      • We started working on including sitelink URLs in GET /entities/items/{item_id} (phab:T330252)
    • Community Wishlist Survey: We reviewed the results and what we can do to address some of the wishes.
    • Query Builder:
      • We continued work on the language selector to make it possible to switch the UI language (phab:T328764)
      • We have added support for the datatypes for Form (phab:T329205) and Property (phab:T329207)
    • Search: We are looking deeper into how we can make it possible to search for Properties, Lexemes and EntitySchemas in the search box, not just Items (phab:T321543)

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


Reverse

Can someone reverse my 3 contributions on Q37860142 (wrong author) Thank you Io Herodotus (talk) 20:16, 6 March 2023 (UTC)

Done. - dcljr (talk) 23:04, 6 March 2023 (UTC)

WD:RFD error

Hello, there is an error in the current version of WD:RFD. Can someone help to fix the problem? Thank you. 132.234.228.148 23:56, 12 March 2023 (UTC)

This seems to have been fixed.[2] From Hill To Shore (talk) 00:20, 13 March 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. From Hill To Shore (talk) 00:20, 13 March 2023 (UTC)

Merging branch and branch office

I want to merge these 2 items, Q1880737, and Q1410110. They seem to be the same thing or very similar, but can anyone let me know if there is a difference or if they should stay seperate. PalauanReich (talk) PalauanReich (talk) 13:29, 6 March 2023 (UTC)

Sitelinks to language wikipedia will frustrate a merge right now; either e.g. AZ & DE wikis are drawing a distinction between the two concepts, or else have duplicate articles. You'd need to get to the bottom of the lang wikis handling of the concept. --Tagishsimon (talk) 13:33, 6 March 2023 (UTC)
The dewiki writes about the difference: "Filialen unterscheiden sich von Niederlassungen oder Zweigniederlassungen vor allem dadurch, dass letztere von der Unternehmenszentrale eigene Kompetenzen etwa bei Beschaffung oder Vertrieb eingeräumt werden." which translates roughly into "branch office (Q1880737) differ from branch (Q1410110) or branch (Q232846) primarily in that the latter are granted their own competences by the company headquarters, for example in procurement or sales" ChristianKl ❪✉❫ 17:26, 6 March 2023 (UTC)

Merge request

Could someone please merge Ladies Musical Club of Seattle (Q117000963) into Ladies Musical Club of Seattle (Q106216254)? Thanks. - Jmabel (talk) 05:01, 7 March 2023 (UTC)

→ ← Merged. You can use this gadget for merging WD items.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 05:25, 7 March 2023 (UTC)

Notice for Friday bringing in students

On March 10, 2023, the Faculty of Humanities and Social Sciences (FHSS - https://inf.ffzg.unizg.hr) at the University of Zagreb (Croatia) will host a presentation and hands-on workshop for the students of Information and Communication Science inside of Virtual Museum course, on the topic of Wikimedia and few of its projects, including Wikipedia, Wikimedia Commons, Wikidata.org and most recent experiments on Wikispore.org. The program will be facilitated by informed and experienced Wikimedia contributors, open content/data advocates and educators who are actively involved in the (Open) GLAM wiki Croatia initiative.

During the event, students will be able to gain insight into some of the possibilities offered by these platforms, including those beyond Wikipedia, that are publicly less known. They will learn the significance of these platforms for the open knowledge ecosystem, as well as how to contribute and improve upon existing data. Furthermore, in partnership with the Department, students will have the opportunity to complete a portion of their course obligations by contributing data and improving content on selected topics on Wikimedia platforms, as well as to optionally join Wikimedia campaigns and initiatives.

We kindly ask you all for patience and understanding with new users on the day.

Thank you very much. --Zblace (talk) 08:50, 7 March 2023 (UTC)

What can be done with broken references ?

By chance I have come across this item Marcin Ambroziak (Q114863013) with statements referenced with the Polish Wikipedia. The problem is that the WP article that had been used as the reference was later deleted per the Polish Wikipedia notability guidelines. Thus these references are broken. I assume that the person's item is notable enough to warrant existing in WD. I think this shows that this kind of referencing seems to be vulnerable and at all not helpful for Wikidata. Would it be a good idea to deprecate this kind of referencing and mark these references so ? Kpjas (talk) 09:57, 7 March 2023 (UTC)

These references are useful in that they have told you the information has come from a deleted Wikipedia page. Without them, the statements would be just more unreferenced information. The fact that the information is sourced to a deleted Wikipedia page flags up that the information is suspect. It is best to replace "imported from" references with more specific references where possible. For the item: as there are multiple identifiers and the item is linked from 8 different items, it is definitely notable for Wikidata. From Hill To Shore (talk) 11:41, 7 March 2023 (UTC)

Spanish alias malformed

One of the es aliases on Q134254 is: 

 Cíclidos africanos

I can't remove it with LabelLister; can anyone else do so with some other tool? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 7 March 2023 (UTC)

✓ Done, Wikibase-cli worked in this case. Vojtěch Dostál (talk) 21:02, 7 March 2023 (UTC)

How to crowdsource specialized directories using Wikidata?

I believe it should be relatively easy to crowdsource the creation and maintenance of specialized directories using Wikidata. I have two examples in mind:

1. PeaceWorks Kansas City has a list of Peace, justice, environment, and human rights groups in the Kansas City Metro area on their website. Sadly, it has not been updated since 2018, because it's too much work for the limited staff of PeaceWorks. However, it seems to me that it should be fairly easy to train people in how to create and maintain Wikidata items for all the organizations on that list and update it automatically with a SPARQL query. Before I start, I feel a need to get help from someone who understands what Wikidata properties to use to make this happen.
2. People with Friends of Community Media and Community of Reason Kansas City want to create a directory of local news outlets in the Kansas City metropolitan area.

If I could figure out how to do one of these things, I think I could figure out how to do the other -- AND the same methodology would likely have many other applications. I'd want to document the methodology in a tutorial on Wikiversity and offer to make presentation(s) on it at a future Wikimedia:Wikimania.

Suggestions? Thanks, DavidMCEddy (talk) 18:51, 4 March 2023 (UTC)

I think you might start by reading and contemplating on Wikidata:Notability and Wikidata:What Wikidata is not before moving on to identifying methods and tools. --William Graham (talk) 03:08, 6 March 2023 (UTC)
@William Graham: Thanks.
Wikidata:Notability says "An item is acceptable if and only if ... it meets at least one of the three criteria":
  1. "It contains at least one valid sitelink to a page on" a Wikimedia project.
  2. "It refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references."
  3. "It fulfills a structural need, for example: it is needed to make statements made in other items more useful."
I think all the items I would want to consider would meet the second and third of these criteria, though maybe not the first.
Wikidata:What Wikidata is not could exclude applications like what I want, as "Wikidata is not ... [a] collection of external links, internal links [nor] White or Yellow Pages".
However, I also looked at Wikidata:Notability/Exclusion criteria: I think we could make sure that all the "Peace, justice, environment, and human rights groups in the Kansas City Metro area" that would be included in such would be more than "meetup pages when meetup is only for users in one wiki" or any of the other "Exclusion criteria" listed there.
That would be particularly true for the second application, being "a directory of local news outlets".
Beyond that, if Wikipedia and other Wikimedia Foundation projects had more volunteers, it could be much more effective in pursuing the Wikipedia:Wikipedia:Prime objective to make it easier for "every single person on the planet [to] access to the sum of all human knowledge."
I want to recruit and train a small army of volunteers in how to create and maintain Wikidata items for organizations that meet the Wikidata:Notability criteria. Then I want to train others in how to create specialized directories suited to their needs. If this works like I believe it will, the new volunteers trained to create and maintain Wikidata items for organizations will likely find other uses for those skills and branch out into making important contributions in other Wikimedia Foundation projects.
However, I could still use help in identifying the properties to use for something like this, etc.
DavidMCEddy (talk) 21:33, 7 March 2023 (UTC)
I feel we are somewhat in "if we had ham we could have ham and eggs, if we had eggs" territory here. You want to recruit and train a cadre of volunteers for all good reasons, but are asking for advice on some very basic concepts, giving rise to a concern that you may not, at the moment, be the person best placed to (at least) train such volunteers, nor deliver lists based on volunteers' work.
It is easily possible to conceive of maintaining KC metro area lists via WD items and reports extracted from WD. I don't by any means wish to discourage you.
Items can be created & embellished. The properties used in such items would be what you'd expect - instance of (P31), country (P17), located in the administrative territorial entity (P131), perhaps field of work (P101) with appropriate values, at a minumum. What other properties could be used can be found by looking at existing items of the type which you're proposing here: so PeaceWorks Kansas City (Q64287449), for instance, but more generally, think of the subjects in your proposal, go and find items for things like your subject in WD, look at the properties and values being used in these items, and take inspiration for your use case.
Guidelines for items can be written - see an example at Wikidata:WikiProject Books#Bibliographic properties
Lists can be put together via SPARQL, probably largely based on items having an appropriate located in the administrative territorial entity (P131) value. That's great for people who like WDQS, but that probably does not include your volunteers? You will, at least, need to be able to put together some SPARQL. You may have to wrange SPARQL via an API to get results onto an external website? Doable, but not trivial; probably not all that complex, but will need a reasonable input of work calling for diverse skills and experience.
PeaceWorks Kansas City, when they compiled their list, had wide freedom to classify listed organisations as this or that to fit the way they decided to arrange their list. WD should, ideally, describe subjects based on reliable sources, and so does not have the freedom & latitude enjoyed by PeaceWorks. I've not looked at their decomposition, but merely note that it may not be possible to replicate it on WD in the absence of sources.
I note that WD aggregates data from reliable sources. Supposing PeaceWorks Kansas City to be a reliable source, moving the locus of its list from its website into WD means that its list can no longer be used as an RS for WD. That's probably of no great moment, but is a small cost of folding the locus into WD. --Tagishsimon (talk) 11:15, 8 March 2023 (UTC)

A property for inference

I couldn't find something like this, and I also wonder if this is a property you'd like before formally proposing it. Some times you can infer the value of a claim by getting it either directly or indirectly from a different claim. Rarely values can be directly inferred, but more often an ID points to an information resource where a value can be obtained for another Wikidata identifier. This might be useful to formally document, so that people running bots can easily spot potential jobs.

So first, what do we call such a property? "Property can be used to infer value for other property"? And two or three qualifiers for how strong the connection is: Direct inference, indirect inference, Inferred value that can be manually obtained. Is there existing qualifier that is suitable for this? Also is there an existing qualifier suitable for explanations? Domain and range is obviously properties. As an example you can directly infer the value of child claims from one of the parent claims since they are biological relations, and vice versa.

Is this a good model for such a property, or is there anything you would have done differently? Infrastruktur (talk) 13:53, 7 March 2023 (UTC)

When it comes to thinking about whether a certain property would be good in a specific form, it's important to think through actual examples. If you take your example, in >99.9% we don't want a parent claim on Wikidata on the item of the parent if there's a child claim. If someone would run a bot to add that claim, they would add bad claims to Wikidata. ChristianKl ❪✉❫ 14:49, 7 March 2023 (UTC)
A more typical example would be something like using the DOI value to obtain the PMID value. To be more clear, what I am proposing is that the item for the DOI property would have a statement saying that you can derive a value for the PMID property from it, and a qualifier briefly explaining how. Infrastruktur (talk) 15:29, 7 March 2023 (UTC)
Only a part of items with DOI has PMID; most don't. The proper place to notify bot operators about work to do is Wikidata:Bot requests. A simple statement cannot cover enough detail required to actually get a bot running. Midleading (talk) 12:55, 8 March 2023 (UTC)
supported metadata (P8203) is a somewhat related property. Stevenliuyi (talk) 18:27, 8 March 2023 (UTC)
Thanks. This is very helpful. A goldmine for anyone looking for bot-able tasks. Is there a way to qualify the statement to say that a DOI value might optionally point to a PMID value? Infrastruktur (talk) 18:52, 8 March 2023 (UTC)
Perhaps using the qualifier nature of statement (P5102) with values like sometimes (Q110143752) or optional (Q59864995)? Stevenliuyi (talk) 21:32, 8 March 2023 (UTC)

Unicode characters

At William Adriense Bennet (Q96305762) I am getting Unicode characters in the WeRelate identifier from the WeRelate website. Can Anyone figure out why? RAN (talk) 21:00, 7 March 2023 (UTC)

@Richard Arthur Norton (1958- ): it seems that corrected by user:Tagishsimon Estopedist1 (talk) 06:05, 8 March 2023 (UTC)

stream, natural watercourse

Just want to surface a concern arising from Q55659167 (previously 'natural watercourse') being merged into Q47521 'stream' (and now renamed in EN as stream (Q47521)). @Машъал, Alloykcks:. The reasons for the merge are fairly clear on examination - Q47521 'stream' does seem to describe any natural watercourse, not just the EN 'watercourse that is smaller than a river' and so covered the same concept as Q55659167 'natural watercourse'.

The concern is that after the merge and for the next six days a report on watercourses I regularly run produced erroneous results. The errors seem to arise from items previously coded as P31=Q55659167 not having been updated to P31=Q47521.

There do seem to be very many items still linked at WhatLinksHere/Q55659167. I think my expectations are that after 6 days these would have been updated to point to Q47521?

Full disclosure: I reverted the merges, and then reverted my reverts, on Q55659167 and Q47521, as well as amending the EN label of Q47521 from 'stream' to 'natural watercourse' because of the ambiguity about the word stream (any natural watercourse cf. w:en:Stream versus watercourse smaller than a river).

Is there cause for concern about the many items still linked at WhatLinksHere/Q55659167? --Tagishsimon (talk) 10:24, 8 March 2023 (UTC)

The problem is that links (statement values in items) to a now redirected item have not been updated & so items have fallen out of the class tree. The ontology may or may not be good, sitelinks may or may not be appropriate to the item they live on, but that's not the focus of concern. 66109 items need to be updated - https://w.wiki/6RNm - 7 days after the change. --Tagishsimon (talk) 16:55, 9 March 2023 (UTC)

Broken property

At some point in the past few years, the National Cartoonists Society completely remade their website, and every instance of National Cartoonists Society member ID (P5622) is now broken (except for the few I fixed by hand). Is there a way to rapidly correct the ~350 others, given that they've gone from being "surname.jpg" (or sometimes "memorium/surname.jpg" to "firstname-lastname"? DS (talk) 19:04, 10 March 2023 (UTC)

... ugh, it's more complicated than that: for one thing, the address still depends on whether the individual is alive. We may have to adjust the property itself, not just the instances thereof. DS (talk) 19:14, 10 March 2023 (UTC)

Tchotchke vs. Tand

In January 2022, two formerly separate items Q7690674 for "tchotchke", a Jewish-American expression that is described specifically with its etymology etc. in en:Tchotchke, and Q2392218 for the German "Tand", which is described in de:Tand as a word for things of little value (again, specifically with the etymology for "Tand"), were merged by User:Loominade. This has led to the English Wikipedia article about "tchotchke" being now interwiki-linked with the German article about Tand. Though the two expressions describe similar concepts, I think they are too different for merging. After all, en:Tchotchke deals specifically with the term "tchotchke", so one would expect, clicking on the German Wikipedia link "in other languages", to get a German article about the word "tchotchke"; but de:Tand doesn't even mention it. I would suggest splitting this into two items again, but I'm not active enough on Wikidata to feel comfortable doing so. Gestumblindi (talk) 19:24, 6 March 2023 (UTC)

@Gestumblindi: I've undone the merge with tand (Q2392218) and added more context to it. -- William Graham (talk) 15:51, 11 March 2023 (UTC)
@William Graham: Thank you! Gestumblindi (talk) 16:06, 11 March 2023 (UTC)

Can we scape Findagrave for all cemeteries that we do not have entries for yet?

We have most USA cemeteries because at one time we imported them from the GNIS database, but they are now deleted from GNIS. Findagrave appears to have at one time imported the gps data from GNIS. We only need 4 properties to identify a cemetery, See for example: Belcrest Memorial Park (Q116997076). We have most USA cemeteries, but I occasionally find one that we have not loaded. We would not take any proprietary data, just the name, gps, findgrave_id, and "located in the administrative territorial entity". We would exclude the ones where we already have a Findagrave_ID. This can be USA only or worldwide. RAN (talk) 20:22, 6 March 2023 (UTC)

To the extent existing cemetery items are not marked up with findagrave_id, your proposal would create duplicate items. --Tagishsimon (talk) 21:21, 6 March 2023 (UTC)
  • That happens with every data import. I am still merging people imported from Genealogics that are duplicates of The_Peerage because one database used "Sir John Doe" and the other was "John Doe". The trick is always to minimalize duplication, but if we have zero tolerance for duplications, we would never be able to import any new data. As always, the first step is to look for instances_of=cemetery with no Findagrave_ID and see if we can find pre-existing matches. --RAN (talk) 23:08, 6 March 2023 (UTC)
It does not happen with every import. So far as cemeteries from FaG are concerned, there is name, local government area and coordinate data which should be used to dedupe prior to the upload. You don't seem to be proposing to make any real effort here, just rack up the unnecessary dupes. --Tagishsimon (talk) 23:14, 6 March 2023 (UTC)
I think the best first step would be to try to add Findagrave identifiers to all existing cemetery WD items in the United States and Canada without them. Then after that is done, do a mass import from Findagrave. -- William Graham (talk) 00:55, 7 March 2023 (UTC)
Yes, could be useful to upload the list of all cemeteries of Findagrave in Mix'n'Match first. Ayack (talk) 08:38, 7 March 2023 (UTC)

What item was deleted -- and a need for "usage on other wikis"

@Ameisenigel: I received an email stamped 2023-03-11T08:07 UTC saying you deleted Q115776939, saying "Not notable, item about a single page on Ballotpedia".

What was this item?

I ask, because I'm fairly confident that I used it somewhere, which means that when you deleted that item, you also turned all reference(s) to that time into broken links. Worse, because I don't know what it was, it's not easy for me to find and fix it.

I vaguely remember having created that item a few weeks ago, but I don't remember where I used it.

This raises other questions in my mind:

Usage on other wikis

I'd really like to see in Wikidata a facility giving "usage on other wikis", similar to what appears on each item in Wikimedia Commons. This could perhaps be under "What links here", which currently only lists other Wikidata items. The absence of that facility means that you probably did not know when you deleted Q115776939 that it was being used anyplace.

It also makes it difficult for me to find where I used it.

Notice when someone links to a single page on Ballotpedia

It would help a great deal with things like that if Wikidata included a bot so each time someone links to a single page on Ballotpedia, they get an error message saying, "Not notable". If I had gotten a notice like that when I created it, I could have considered alternative ways of making that reference. However, when I get a notice like this weeks later, it means that it is very difficult and perhaps infeasible to find what it was and where I used it, so I can fix the problem created by this deletion.

How to reference a single page on Ballotpedia?

What do you suggest I do to reference a single page on Ballotpedia if I cannot create a Wikidata item for it?

I've come to using Wikidata for most of my references, e.g., {{cite Q|...}}, because if it's used more than once, it's easier to maintain. For example, if I get a broken link for one of the reference, fixing it in Wikidata fixes it for all items. Also, I may find a link for full text for a Wikidata item that does not currently have such a link. Adding that link to the Wikidata item makes the link instantly available for all references to that item. AND I routinely create new Wikdata items for authors for which Wikidata items currently seem not to exist. In bibliographic references, readers may not always care to know, e.g., which John Smith wrote a particular item, but some do. Using "author" rather than "author name string" makes each author reference unique.

Thanks, DavidMCEddy (talk) 11:44, 11 March 2023 (UTC) DavidMCEddy (talk) 11:44, 11 March 2023 (UTC)

@DavidMCEddy: Why, noting WD:N, would a single page on a website be notable enough to have a WD item? It's one thing for WD to have items on books or academic papers, another entirely to act as a repository of any webpage a person wishes to use as a reference for something or other. --Tagishsimon (talk) 11:51, 11 March 2023 (UTC)
I too have noticed that you cannot see where an item is used outside this wiki, and also consider it a shortcoming. A source search for Q115776939 on enwiki reveals that the affected Wikipedia page in this case is w:Judy Morgan. William Avery (talk) 12:32, 11 March 2023 (UTC)
  • The data item Q115776939 claims to be: "Judy Morgan on Ballotpedia" (en-label), "Ballotpedia article on Judy Morgan" (en-description). There are also a few claims, but the item by itself (i.e. not considering backlinks etc.) does not fulfill notability criteria.
  • There are no backlinks via Special:WhatLinksHere/Q115776939
  • There is no usage in Wikimedia Commons (SDC)
  • However, the item is in use at enwiki: en:Judy Morgan, thus being notable under the "structural need" criterion; I am thus restoring it now.
  • Item use can be tracked via "page information" on item pages [6], and with a special page on client wikis (as in en:Special:EntityUsage/Q115776939).
—MisterSynergy (talk) 12:35, 11 March 2023 (UTC)
Thanks for the discussion and for restoring the item.
Many pages like that on Ballotpedia (Q4851899) are the single best references I know for certain information on many political candidates. They are comparable to newspaper articles, in my opinion, and I want to continue citing them as such ;-)
Might it be feasible to modify the code for Special:WhatLinksHere/Q115776939 so it includes the "Usage on other Wikis" from en:Special:EntityUsage/Q115776939? Pages on Wikimedia Commons have that information, e.g., File:JudyMorgan at KKFI Radio-2023-01-03.jpg; it shouldn't be hard for Wikidata to do it.
Thanks to User:William Avery for confessing that, like me, he didn't know how to find that information. Thanks to User:MisterSynergy for explaining that I could get that information from en:Special:EntityUsage/Q115776939. However, I don't think that one should have to know that secret w:abracadabra to get that information.
FYI, prior to this comment, my "Global contributions"} reported 15,559 edits on Wikidata. I've been a Wikimedian since 2010, and wanted to use Wikecite for years before learning how: I sat next to [https://lydiapintscher.de/ Lydia Pintscher, OL 9106374A, Wikidata Q18016466View profile on Scholia on a flight to Capetown for Wikimania 2018, and she showed me how. But, of course, she didn't show me en:Special:EntityUsage/Q115776939 ;-)
Thanks for your contributions to w:Wikipedia:Prime objective, to give "every single person on the planet .... free access to the sum of all human knowledge." DavidMCEddy (talk) 15:35, 11 March 2023 (UTC)
Sorry for the late answer, but I have not received your ping and just discovered this discussion by chance. Unfortunately I have not noticed the usage of this item in enwiki. I think we should try to make it more obvious if an item is used somewhere or not (just like it is the case for backlinks on items). Sorry for the inconvenience. --Ameisenigel (talk) 20:41, 11 March 2023 (UTC)

Gangs Of Old Ladies

Gangs Of Old Ladies is an Australian extreme metal band that was the side project of world renowned Swedish guitarist David Andersson until his tragic death in September 2022. The band are attempting to support his memory and continue their legacy with the release of their upcoming 3P that features the last music David wrote before his death. Formed by Jekyll Jones and Simon Unknowne in 2019 after a meeting with Dani Filth from Cradle of Filth. The band have worked with a plethora of well known metal celebrities including, Gene Hoglan from Testament/Dark Angel, Phil Rind from Sacred Reich, Paulo Xisto from Sepultura, Chuck Billy from Testament, Rick Rozz from Left to Die/Death/Massacre, George Kollias from Nile. Karl Willets from Bolt Thrower, Francesco Paoli from Fleshgod Apocalypse, Squiz from King Parrot, Travis Ryan from Cattle Decapitation, Gary Holt from Slayer/ Exodus, Bjorn Strid from Soilwork and Dani Filth from Cradle of Filth. The band has been played on multiple stations in multiple countries and are currently working on breaking into the next level.GOOL666 (talk) 11:52, 11 March 2023 (UTC)

In the interest of helping this Australian extreme metal band attain the correct Google and SEO options.
I would like to have this band entered into Wikidata GOOL666 (talk) 11:54, 11 March 2023 (UTC)
Wikidata does not exist to help people with SEO. Thanks, for alerting us so that we can make sure we delete any items that would be created for it. ChristianKl ❪✉❫ 16:46, 11 March 2023 (UTC)
Wikidata does help people with SEO. So long as the subject is notable, all is good. There are plenty of RS for Gangs Of Old Ladies, and so it seems to pass WD:N. --Tagishsimon (talk) 18:16, 11 March 2023 (UTC)
At Wikidata we have rules against undisclosed conflict of interest edits and https://www.wikidata.org/wiki/Wikidata:What_Wikidata_is_not says "Wikidata:What Wikidata is not ... place for self-promotion, or advertising/marketing" ChristianKl ❪✉❫ 19:06, 11 March 2023 (UTC)
This is an attempt to create factual information without paying hundreds of dollars to a Wikipedia commons license. I find your comment and your attitude unsatisfactory GOOL666 (talk) 19:08, 11 March 2023 (UTC)
Thank you GOOL666 (talk) 19:07, 11 March 2023 (UTC)
Can you please help me with the data creation as I don't understand how this works GOOL666 (talk) 19:17, 11 March 2023 (UTC)
Where are factual databases supposed to exist them? Facebook? I find your dismissal and misunderstanding of the point of the entry to Wikidata disappointing GOOL666 (talk) 19:10, 11 March 2023 (UTC)
Note above it says deliver correct SEO - as in correct factual data - it has nothing to do with advertising. As the other user states this is satisfactory GOOL666 (talk) 19:16, 11 March 2023 (UTC)

Use of Wikidata for programming language and library information?

Apologia, introduction, etc.

I've been interested in mechanized documentation and topics such as graph databases, RDF, and SPARQL for some time, but I've only recently started looking into Wikidata. So, please excuse (and correct!) any confusion shown below.

Overview

I've been speculating about the use of graph databases to store, organize, and present information on software projects. My current use case has to do with projects that use Elixir and related technologies (e.g., Erlang, Livebook, Nerves, Nx, Phoenix), but the general approach is clearly not specific to that domain.

Details

I'd like to collect a variety of information about software projects, in order to assist in their development, debugging, maintenance, and operation. This information falls into three rough categories, based on its origins and temporal nature:

  • generic information: archive data, definitions, etc.

This is the part where I see a role for Wikidata. It would provide overall context, based on information found in the Elixir documentation, archive documentation and index pages, etc.

So, for example, it might tell us that attributes, functions, and macros are all defined within modules. It could also tell us about the dependencies of various libraries, where their "official" code bases are located, etc.

  • static (i.e., compile-time) information: code base, configuration files, etc.

I would store this information in a local instance of a graph database (eg, Neo4j), pre-loaded from Wikidata. It would provide information on static, structural aspects of a given Elixir code base.

The information could be harvested from code analysis, calls to ElixirLS (the Elixir language server), compile-time checks, etc. So, for example, it might tell us which attributes, functions, and macros are defined (and used) within which modules, (what parts of) which libraries we're using, etc.

  • dynamic (i.e., run-time) information: runtime monitoring, tracing, etc.

I would store this information in a separate instance, also pre-loaded from Wikidata. It would provide information on dynamic and possibly ephemeral aspects of a running Elixir code base.

This would provide information on dynamic aspects of Elixir-based sessions: inter-process links, message traffic patterns, process spawning, etc. So, for example, it might tell us that the Foo.bar/2 function started a given set of processes, using a "one_for_one" restart strategy, etc.

Questions

Q: Would there be any problem with my using Wikidata for the context information?

Q: Does anyone find this project interesting and/or plausible?

Q: Any other advice, comments, clues, or suggestions?

-r RichMorin (talk) 07:53, 12 March 2023 (UTC)

This feels like the wrong sort of thing to use WD for. WD is better at storing the metadata for a project than a project itself. So a for a scientific paper it would record title, author, references, point to a PDF and the data sources used, but not attempt to record what the paper said beyond a summary line. WD really isn't set up to record software development beyond version history, and it would be a stretch of its ontology to do so.
I think its an interesting idea, but I'd first consider setting up your own wikibase instance to develop the idea before trying to introduce it here. Vicarage (talk) 09:44, 12 March 2023 (UTC)

Wikidata advocacy at the university

How to advocate data at the university. I have a feeling, that Wikidata will one day play an important role in the area of databases, like a database of bibliografic metainformation, but I am not able to advocate it at the university to contribute with their scientific articles? Any idea how to do so? Juandev (talk) 10:38, 12 March 2023 (UTC)

IMO it would be more useful to convince them to release their papers as Open Access if they aren't already doing so. A lot of universities are doing research for taxpayer money which ends up behind a paywall. This is far from ideal. Infrastruktur (talk) 19:31, 13 March 2023 (UTC)

New Wwwyzzerdd 1.0.0 Release

If anyone is interested I recently launched the 1.0.0 version of Wwwyzzerdd this includes a number of visible/invisible improvements. Here's a video that goes over some of the features in the browser extension.

Feedback, bug reports and functionality requests appreciated. BrokenSegue (talk) 04:24, 13 March 2023 (UTC)

Wiki Data on Google

Dear editors, could you tell me why this article is not showing up in google search engine? I can also show a number of other articles that don't show up on Google. Help me figure out the reason. Thank you! 141.136.88.204 07:36, 13 March 2023 (UTC)

First of all, the link you provide is not an article. It is a Wikidata item. In fact, the item you link has no corresponding Wikipedia article in any language, and I daresay it's a good candidate for WD:N-based deletion. It appears to have been created as a vanity project for the editor of the same name.
Furthermore, I have never known any Wikidata item to appear on Google. Why do you want it to appear there; what interest do you have in Googling it? Is this another attempt at self-promotion? Can you point at any common Wikidata item that appears on Google rather than something on Commons or enwiki? Elizium23 (talk) 07:49, 13 March 2023 (UTC)
It's not important enough for google to decide to show it or for that matter for us to have it as an item (so I have deleted it). ChristianKl ❪✉❫ 17:12, 13 March 2023 (UTC)

Adding 200 items for emoji sequences

Hello all,

I am ready to add 200 emoji ZWJ sequence items, like this one 🧔‍♂️ (Q116985810), using a QuickStatements batch.

I believe they are notable, being " described using serious and publicly available references", the widely used Unicode Standard, and present on practically every modern operating system.

If no objections here I will be adding them like the item above. -wd-Ryan (Talk/Edits) 03:14, 6 March 2023 (UTC)

+1, looks good to me EpicPupper (talk) 03:38, 6 March 2023 (UTC)
Could you also add Emojipedia ID (P8711) to track uniqueness? Thanks! Lockal (talk) 04:52, 6 March 2023 (UTC)
I've been able to include Emojipedia ID (P8711) for most of them, thanks! -wd-Ryan (Talk/Edits) 14:17, 6 March 2023 (UTC)
Interesting stuff. Will you be adding just the ones covered by Recommended For General Interchange (RGI)? An example of one that is not is hacker cat? Infrastruktur (talk) 14:08, 7 March 2023 (UTC)
Yes. More specifically, all of the ones on here, except for the skin tone variants, because I thought it was redundant but open to having them included: https://unicode.org/emoji/charts/emoji-zwj-sequences.html -wd-Ryan (Talk/Edits) 20:00, 7 March 2023 (UTC)
✓ Done -wd-Ryan (Talk/Edits) 00:56, 15 March 2023 (UTC)

Trying to create factual information

I am trying to create a correct factual page for this topic. Some users agree it passed as it's notable. Another user keeps trying to destroy the topic due to conflict of interest. How is the collect collation of true data a conflict of interest? GOOL666 (talk) 19:22, 11 March 2023 (UTC)

Is Wikidata not a place for correct information? Since the death of David Andersson there has been notable incorrect data applied to this topic in places like Rolling Stone Magazine, Metal Injection and various other news outlets. I was under the impression this is where true and factual data can be banked. Can anyone please help? GOOL666 (talk) 19:25, 11 March 2023 (UTC)
@GOOL666: The item you created was deleted at Q117066644. Please do not recreate deleted items. Instead if you would like to appeal this decision bring the discussion to WD:AN. There you should make reference to the notability policy (WD:N). Particularly valuable would be references to this subject in serious news outlets. I see you recreated the item as Gangs Of Old Ladies (Q117071607). Recreating deleted items is frowned upon here. But looking at it I do not see any references to serious source. So another thing you can do is add more serious references to that item. BrokenSegue (talk) 05:28, 13 March 2023 (UTC)
If you go to the source now someone has started filling in the data from pages and citations from the internet. I do not understand why it's obvious that something exists and then you refute or delete it and say that it doesn't. What criteria does something have to meet to be real ? The links to Spotify, the Bandcamp data encyclopaedia metallum were all there? Wikidata was recommended to me by a large organisation to avoid paying Wikipedia article writers money - is this a money thing too? GOOL666 (talk) 06:05, 13 March 2023 (UTC)
Also serious news outlets- if you Google the subject in the first page of responses is an article from The Courier Mail. A Rupert Murdoch owned newspaper that has been the largest newspaper in my home state for over 40 years.  GOOL666 (talk) 06:07, 13 March 2023 (UTC)
I can't find an appeals process or anything other than a bunch of people trying to help and a bunch of people telling me the data isn't real ? GOOL666 (talk) 06:09, 13 March 2023 (UTC)
And thank you to the person who added all the Apple music, Deezer Bandcamp and other links it is really appreciated, we can't figure out how to right this thing and your help in validating the subject is greatly appreciated. GOOL666 (talk) 06:30, 13 March 2023 (UTC)
@GOOL666, why are you speaking about paying money for creating an article in Wikipedia? Everyone can edit Wikipedia or another Wikimedia project for free. If someone is asking for money, most probably it is scam.
> What criteria does something have to meet to be real ? - You were given a link to the notability policy. Please read it. This policy describes what can and what cannot be added to Wikidata. Michgrig (talk) 19:10, 14 March 2023 (UTC)
I did read the link and as the kind user who populated all the data agreed it met criteria. As for the money. After attempting to create a Wikipedia page our manager was continually contacted by an American firm that wanted $700USD to create and publish the Wikipedia page, the company was called Wikiwriters. If you Google Soilwork you will see that ours and theirs ( shared guitarist) who passed away was replaced today and it's in major news articles across the web. David Andersson was our guitarist for 3 years and we hold the last music he ever wrote, releasing later this year. We were trying to create a factual page of reference for the band and our time - work together etc. Not all of us understand these data collection pages as well as others.
If the attempt is wrong just delete it all. I honestly give up GOOL666 (talk) 19:23, 14 March 2023 (UTC)

Wikimedia disambiguation page with main category

Does it make sense for a Wikimedia disambiguation page (Q4167410) to have a topic's main category (P910), as is the case with Limburg (Q1161)? --2A02:8108:50BF:C694:F952:F97C:CD5A:EAD0 13:42, 13 March 2023 (UTC)

no sense for me, but it is created by the bot, maintained by user:JAn Dudík Estopedist1 (talk) 06:38, 14 March 2023 (UTC)
IN this case is it false positive (same name of disambiguation and category - but category was already in source - srn disambiguation since 2008). And there are also Wikimedia disambiguation category (Q15407973) which are valid for disambiguations. JAn Dudík (talk) 07:38, 14 March 2023 (UTC)
I cannot tell whether Q9703623, linked by Limburg (Q1161), should actually have instance of (P31)Wikimedia disambiguation category (Q15407973). --2A02:8108:50BF:C694:E091:62B2:1FFD:EA0F 09:57, 14 March 2023 (UTC)

Princess Elisabeth Zone

The Princess Elisabeth Zone is a zone where multiple offshore wind farms will be located, how should I tag this? It's not a wind farm as it is made out of smaller wind farms. There is a similar thing with Hollandse Kust Zuid, Windenergiegebied Borssele (it is tagged as a wind park but the wiki is saying it is a collection of wind parks) etc. How would you tag this? There should probably be a new wikidata lade for this. Jhowie Nitnek 08:10, 14 March 2023 (UTC)

A separate item for each power plant and an additional item for "cluster" (if needed) is the best practice. Wikis often tend to cover cluster only, but wikidata is more granular. Individual power plants have their own installed capacity, inception, and sometimes even different owners (even if they are within the same cluster). It is not a bad idea to consider creating a new item for the "cluster" power plants, you can discuss that at Wikidata talk:WikiProject Energy. Jklamo (talk) 10:56, 14 March 2023 (UTC)
Here you go: windfarm cluster (Q117156709) — Martin (MSGJ · talk) 14:10, 15 March 2023 (UTC)

Help with Notability

Should an item always have at least one identifier in order to be 'notable' (having looked around, every page I can find has at least one)? And if so, how would I use a - let's say Super Mario Wiki - page to that end (or if there's an alternate method of proving an item's notability) if the page in question is not specifically about the item, but contains information about it?

I'll try not to be vague - the item in question I'm considering creating is the Dango from Super Mario Sunshine, using this page.

Alternately, of course, there's a chance this isn't notable in Wikidata terms at all, in which case I just won't make the item. LilWaddleDee (talk) 10:56, 15 March 2023 (UTC)

The thing that matters are sources. Those don't have to be necessarily from an identifer. ChristianKl ❪✉❫ 11:38, 15 March 2023 (UTC)
So I'd use 'described at URL', then? LilWaddleDee (talk) 11:43, 15 March 2023 (UTC)
Just using reference URL (P854) for the claims you make about the item is enough especially if there are good sources you don't need described at URL (P973). ChristianKl ❪✉❫ 11:55, 15 March 2023 (UTC)

How to merge two items?

I found two items about the same entity, how can I merge them? GeoGQL (talk) 14:07, 15 March 2023 (UTC)

See https://www.wikidata.org/wiki/Help:Merge ChristianKl ❪✉❫ 14:10, 15 March 2023 (UTC)
Thank you. Done https://www.wikidata.org/w/index.php?title=Q29937&diff=prev&oldid=1852737545 GeoGQL (talk) 14:17, 15 March 2023 (UTC)

Best Practices for Ensuring Data Quality?

Hello, I'm working with the Scottish Witchcraft Survey Data, checking for anomalies between the data in an Access database that was the original data source, and the current data available from Wikidata.

So far I've been downloading wikidata queries as csv files and comparing them to csv files exported from Access in R, but I'm looking for a better method.

I would like to create a simple protocol or query which compared the wikidata properties to the details in the original database in order to find any anomalies, like import errors or changes made by different editors over time, that might be present. This way, individual items can be manually checked to ensure data quality. If possible I'd like to find a method of periodically checking and monitoring the data (model queries, adding constraints) that doesn't require a lot of technical expertise and that this method should use only open source software, so it can be periodically repeated by anyone else doing future data quality checks/assessing to see how the Wikidata version of the original data evolves.

If anyone has any advice, or could let me know what techniques or data processing tools you use to compare between Wikidata datasets and other data sources, I would really appreciate it! Witchcraftintern2022 (talk) 16:34, 8 March 2023 (UTC)

@Witchcraftintern2022 Not sure if this is of any help to you, but there are a couple of R packages that might at least help you avoid the CSV export. I haven't really worked with any of them, so I can't give advice. But there's a somewhat older overview available for connecting to Wikidata here. Similarly, RODBC allows you to access Access databases from R using SQL queries: Connect to Microsoft Access Database in R using RODBC El Grafo (talk) 13:38, 9 March 2023 (UTC)
Thank you! I'll check these out. Witchcraftintern2022 (talk) 17:28, 15 March 2023 (UTC)
@Witchcraftintern2022: Sounds a bit like (my understanding of) Wikidata:Mismatch Finder? And more generally Wikidata:Data round-tripping (although there’s not much there)? Jean-Fred (talk) 19:50, 15 March 2023 (UTC)

Wikidata weekly summary #563

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • Open Etymology Map - is an interactive map that shows the etymology of names of streets and points of interest. (blogpost in Polish)
  • Development
    • Query Builder: We continued the work on making it possible to switch the language of the UI (phab:T328764)
    • EntitySchemas: We started the development of version 2 with some underlying cleanup and technical improvements.
    • REST API:
      • We worked on getting full URLs for sitelink data in the responses (phab:T330252)
      • We worked on a dedicated way to get the aliases of an Item (phab:T327882)

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

@Lydia Pintscher: RE: Abstract Wikipedia. I agree that it should be a community decision where it's located. Currently, Wikidata has very different notability rules than the Wikipedia's I would expect that it would be better for Abstract Wikipedia to have notability rules that are more like the notability rules for the Wikipedia's than the notability rules for Wikidata. ChristianKl ❪✉❫ 16:45, 16 March 2023 (UTC)
That might very well be, yeah. I don't have a set opinion yet either really. Denny published the different options that we have so far in the latest Abstract Wikipedia newsletter. Lydia Pintscher (WMDE) (talk) 17:29, 16 March 2023 (UTC)

A bot for notifying Wikiprojects

Currently, a lot of discussions about how to structure data are not happening because it's hard to draw attention of people to the discussions. For Wikiprojects <50 people it's possible to get some discussions by pinging the project but unfortunately it isn't for larger projects. One way to solve this issue and have more discussions would be to have a bot that does multiple edits to stay within the 50 pings per edit limit. ChristianKl ❪✉❫ 16:49, 16 March 2023 (UTC)

See phab.
Tracked in Phabricator
Task T200350
Tracked in Phabricator
Task T148154
Unfortunately according to developers "limit is there for good reasons" and "workarounds that exist seem to do a good job", but in fact, nobody's working on a proper workaround. --Jklamo (talk) 09:37, 17 March 2023 (UTC)
Wikiprojects like Wikiproject Ontology suffer a lot because it's impossible to ping everyone to get input and move discussions further. When it comes to data quality this single change might do more than specific data quality features that WMDE is working on, given that data quality seems very bottlenecked by discussions around how we want to model and not about technical ways to express the model. ChristianKl ❪✉❫ 14:18, 17 March 2023 (UTC)
In one of the tickets they wrote "For the specific "ping project" use-case, we recommend that the bot behind the template be modified to ping people in batches of 50." This means that someone could run a bot that pings people in batches and would solve the problem within Wikidata. ChristianKl ❪✉❫ 15:07, 17 March 2023 (UTC)

Please merge 2x Diego Sebastián Velázquez

Diego Sebastián Velázquez (Q55719758) = Diego Velázquez (Q117197980) ; sorry, I made a mistake. 77.191.57.186 15:13, 18 March 2023 (UTC)

✓ Done - Valentina.Anitnelav (talk) 15:35, 18 March 2023 (UTC)

Interwiki template

Hello I'm asking for help to wiki template Template:The AfC Barnstar (Q26067064) to Template:The AfC Barnstar (Q6664019) Badak Jawa (talk) 09:24, 18 March 2023 (UTC)

@Badak Jawa, these are → ← Merged. In future, you can do a merge yourself by using the Merge gadget. Michgrig (talk) 11:49, 18 March 2023 (UTC)
@Michgrig thank you 116.206.37.243 13:59, 19 March 2023 (UTC)

Category:Men (Q9507857) vs. Category:Man (Q1410641)

What is the difference? I think both categories are the same just Category:Men (Q9507857) has some incorrect labels. Eurohunter (talk) 10:23, 19 March 2023 (UTC)

Setting aside any complicated modern issues of gender identification, "men" in English refers to adult male humans. "Male humans" can also include children. From Hill To Shore (talk) 10:33, 19 March 2023 (UTC)
It looks like for (at least) many European languages Category:Men (Q9507857) is used to list all men/male humans and Category:Man (Q1410641) covers topics about men in one way or another. Gunnar Larsson (talk) 10:59, 19 March 2023 (UTC)
If you want to know whether two Wikidata items have a difference, looking at Wikilinks is often a good step. If there are multiple Wikilinks in a single language that suggests that the Wikipedia makes a difference. ChristianKl ❪✉❫ 14:02, 19 March 2023 (UTC)

Hoax with Wikilink

The Persian language Wikipedia has an article for Princess Sura of Parthia (Q7645263) which has been deleted from English Wikipedia for being a hoax. If anyone knows how to write Farsi and is willing to help get this deleted that would be greatly appreciated. StarTrekker (talk) 19:32, 19 March 2023 (UTC)

Implementing a warning when switching an item's basic superclasses

The subclass hierarchy in Wikidata is ... not that reliable (many examples can be seen here). This is due to a lot of reasons, but one cause is that editors are not given any warning when changing an item from being, for example, a subclass of temporal entity (Q26907166) to being a subclass of spatial entity (Q58416391). This is a big change, and nearly always an error (although the error may be somewhere further up in the hierarchy). If editors were warned about this (and some other basic superclasses pairs like material entity (Q112276019) / abstract entity (Q7048977) and artificial object (Q16686448) / natural object (Q29651224)) I think it would considerably reduce the number of new errors being introduced by mistake, and would make more visible the many errors already present. I'm not sure how much creative coding it would take to implement this, but I wanted to bring it up as an idea at least. JesseW (talk) 02:51, 8 March 2023 (UTC)

I think this would have to be implemented via constraints on subclass of (P279) - a new constraint type of "superclass that should not change" or something like that? Not sure how that could be done. ArthurPSmith (talk) 18:47, 9 March 2023 (UTC)
Sadly, constraints (even a new one) aren't quite right, as one really wants this as a warning before an edit is saved, rather than a visual icon that appears until it's resolved. Maybe implementing it as a (default-enabled) Gadget would be the right way? JesseW (talk) 02:43, 10 March 2023 (UTC)

@Mateusz Konieczny: I am now working on implementing this as a Gadget; so far I've got the tree logic working, next I'll work on having it load the before and after during an edit; then identify the conflicting pairs, and provide a UI warning. Help/encouragement/etc welcomed! JesseW (talk) 00:36, 17 March 2023 (UTC)

Thanks! I am quite curious how well it will work - I am a bit worried about false positives Mateusz Konieczny (talk) 07:13, 18 March 2023 (UTC)
I've now got a (very rough, hacky but working) version up on https://www.wikidata.org/w/index.php?title=User:JesseW/common.js&oldid=1855581854 . While there are LOTS of improvements I'm already intending, I'd be glad for comments/suggestions about what to work on first, or bug reports, etc. JesseW (talk) 15:59, 19 March 2023 (UTC)

Now got it warning when an item is selected, not just when it is saved (which is a big UI improvement). Still need to handle more than just edits to subclass of (P279), and improve the warning messages, and performance, and add a bunch more conflicting properties. Oh, and package it up so it can be easily installed by other people (and hopefully eventually be a default Gadget, which is where it will really start being useful). JesseW (talk) 01:52, 21 March 2023 (UTC)

Warring

The user Tm insits on including a Galician and a Portuguese name in the section of Spanish names for the article Q3375350. The same with a Portuguese name in the section of English names for the article Q3375706. I told him on his discussion that it doesn’t make sense beucause users already can find these items with those names since they are already in their respective section. This user always insists on warring on stupid things. Lojwe (talk) 01:26, 12 March 2023 (UTC)

Wikidata:Administrators'_noticeboard/Archive/2023/02#Tm and Wikidata:Project_chat/Archive/2021/05#Tm are pretty clear that native names are permissible in english (as other users told in those two discussions) and to be clear for the second time "to be clear it was not me added those spanish labels in barragem do bemposta but another user", a spanish one to boot.
As the other times it is you that is edit warring, not me, to again , after trying to deturpe what others say, going against of what was discussed and impose your will by edit warring. And the previous is exactly the answer i gave this user in my talkpage, after this same user, for the fourth of fifth time removed those names, even after the previous discussions that did not go the way he wanted, i.e. he starts edit warring, even after being explained, as does not like it, opens several sections like this one, he is proven completly wrong, he repeats the same edits and edit warring even after after discussions and opinions of several users to the contrary, waits a time, starts again with the edit warring, like he did this march 2023, February 2023 and November 2021, i.e. he has insisted three times since the riginal discussion to subvert the results of the same. Tm (talk) 05:38, 12 March 2023 (UTC)
@Lojwe Neither Bemposta Dam (Q3375350) nor Picote Dam (Q3375706) are articles. They are items or if you want to use a more general term pages. Names not only exist for searching but also so that Wikidata can display labels instead of Q-numbers. If there's no English name for an item having the native Portuguese name as the label is desirable.
This might change in the future with the adoption of mul, but currently there's nothing wrong with this way Tm did things here. ChristianKl ❪✉❫ 12:12, 12 March 2023 (UTC)
English name exists in both cases. What about inserting a Galician name in the Spanish section? It doesn’t make sense. Lojwe (talk) 12:17, 12 March 2023 (UTC)
Two previous discussions already closed, a third open just a few hours ago and now you open a fourth one in Wikidata:Administrators' noticeboard#Warring. Nice forum shopping, to have again said the same things for a third time, like the fact of you called "inserting a Galician name in the Spanish section" as i already told you before, but you seem bent in ignoring what others say, it was a spanish user that added that labels. Tm (talk) 13:26, 12 March 2023 (UTC)
It's would be a lot easier to follow what you are saying if you would learn the basic terms of Wikidata, being labels, aliases etc and not speak about terms like "Spanish section" that don't have any meaning in Wikidata. ChristianKl ❪✉❫ 22:41, 12 March 2023 (UTC)
If there's no English name for an item having the native Portuguese name as the label is desirable.
@ChristianKl, would you apply that equally to placing Portuguese names as Spanish labels, because that's what's going on here? Does English have some sort of special-casing in Wikidata as the primary interface language? Do English labels have a special default case?
What if there's no German name for an item? Can a Dutch-language label be placed as German? And so on and so forth. What is the utility of mixing up languages that do not particularly belong in those slots? It would seem that if it has Portuguese names, just put them as Portuguese labels and be done. If names are translated in RS, put translated names as appropriate labels.
I'm honestly not really sure why you'd cram a non-Spanish label into the blanks where users are expecting Spanish. In fact it's very confusing to someone who may speak neither language because Portuguese can look very similar indeed to Spanish. If someone came along to put a Spanish translation as a label, would they be discouraged by the fact that a non-Spanish placeholder is already there? Kind of weird to clog up labels with non-native translations. That seems antithetical to the system of having all languages represented separately. Elizium23 (talk) 06:46, 13 March 2023 (UTC)
I think it’s just a stupid discussion. Why should we put a Galician name into the section of Spanish names when this Galician name is already in the Galician section? Please, someone should stop this. I just can’t believe why a so erratic user like Tm is allowed to do things like these. Lojwe (talk) 18:56, 13 March 2023 (UTC)
I agree with @Lojwe. Why pollute another language label with a language that is not the one indicated? It is fundamentally misinformation. Likewise, don't pollute English labels with foreign-language names unless you can prove that English-speakers use the foreign-language term. Elizium23 (talk) 19:05, 13 March 2023 (UTC)
Lojwe's first post does sound like he's talking about labels. If you read the discussion, you see that he's not talking about labels but aliases. To the extend that there's a policy question about those aliases, https://www.wikidata.org/wiki/Help_talk:Aliases is the place to have the policy discussion. We could have rules that forbid putting in labels of other languages into the alias field. You are free to propose such a rule on the talk page and see whether it finds consensus.
By design neither Wikidata labels nor aliases have references and as a result it makes little sense to require any proof for them. ChristianKl ❪✉❫ 13:39, 14 March 2023 (UTC)
@ChristianKl, that seems like a bad design, if we are fundamentally unable to require or provide any proof for a data point somewhere.
We recently had a discussion on enwiki whereby it was apparently decided by some admins that any editor who speaks a given language is a reliable source for foreign-language names and terms, including translations and transliterations into and out of that language into English. This troubled me greatly, because if editors are a reliable source, how do we cite a Wiki editor? How do we query an editor as a source, especially if that editor has been dormant 5+ years?
If we don't need to require proof for any labels or aliases in any language, I think that's just a bad design. How do you resolve disputes and edit wars in that case? Who has a definitive say? Where do you turn for authoritative answers? Can of worms! Elizium23 (talk) 16:45, 14 March 2023 (UTC)
You are confusing different things with each other. You can give a source for a name. name (P2561) works well for that purpose. What you can't do is have source for labels and aliases. Decisions about how to chose the label are about Wikidata internal labeling rules and not directly about how outside sources name an entity. They are about what label is useful for Wikidata. ChristianKl ❪✉❫ 17:31, 14 March 2023 (UTC)
@ChristianKl, I didn't confuse anything: I wrote If we don't need to require proof for any labels or aliases in any language and you wrote: What you can't do is have source for labels and aliases, so what is my confusion, pray tell? Elizium23 (talk) 17:33, 14 March 2023 (UTC)
I don’t know what an alias is. I just think this discussion is simplier. It makes no sense to put a Portuguese or a Galician name in the section of Spanish names/aliases/whatever. In Spanish we don’t use those Galician and Portuguese words. Please, check Q3375350. Encoro de Bemposta (Galician) is twice. Barragem de Bemposta (Portuguese). I don’t understand why we have to make this more complex and let an user do stupid reversions. Lojwe (talk) 18:25, 14 March 2023 (UTC)
@Lojwe Calling the actions of other people stupid does not help your cause. ChristianKl ❪✉❫ 21:24, 14 March 2023 (UTC)
You spoke about there being an inability to source names. That's not true. We have sources for that. We however don't have sources for labels/aliases. ChristianKl ❪✉❫ 21:27, 14 March 2023 (UTC)
No I didn't. You've misinterpreted me. Please do not patronize me. Please reread what I wrote and try to understand it. Elizium23 (talk) 00:14, 15 March 2023 (UTC)
Tm insists on repeating other language’s aliases as different languages aliases. Could please someone revert him? He’s not gonna stop it until someone else, apart from me, stops him. He always do these nonsense things. Lojwe (talk) 11:39, 18 March 2023 (UTC)
How ironic that you said that, when it is you, against the results of all discussions, that started this again by edit warring for the third time. Tm (talk) 11:52, 18 March 2023 (UTC)
Labels and aliases serve one purpose: help human users of Wikidata find the right item when they are looking for a concept/class, an instance of a class, or a property. It doesn't really matter if a given alias appears only once or is repeated across languages. What really matters are the statements describing the item. Fjjulien (talk) 01:48, 21 March 2023 (UTC)

Birth References

Would someone be kind enough to offer the means by which a birth certificate image can be imported to a WD page as a confirmed reference? This is a simple effort to confirm a fact of birth, nothing more. Thanks in advanceDonMassey832020 (talk) 19:03, 16 March 2023 (UTC)

@DonMassey832020: Images or other audiovisual media without copyright restrictions can be added to Wikimedia Commons. Generally facts like those on a birth certificate are not copyrightable, but I am not an expert on how different countries treat birth certificates in regards to copyright. However, I would not encourage any user to upload personal identifiable information for a living person to a Wikimedia/Wikipedia project. And indeed it may not be necessary if the image is hosted elsewhere on the internet by linking out with reference URL (P854).
It looks like you're attempting to add references for the Wikidata item about yourself Q117072135. I will note that you do meet the Wikidata:Notability guidelines (serious and publicly available references about yourself exist in your entry in the Library of Congress name authority records), but I would encourage you to not use Wikidata as a means for self-promotion of works that may not be notable. -- William Graham (talk) 19:43, 16 March 2023 (UTC)
Many thanks for your response. Under no circumstances will any self-promotion of any kind be done here. The only fair way to use WikiData...as an objective portal and repository for data. Citation of birth, as in place and date, are factual as I am using them here. The page seeks a reference for confirmation, which can only be done through an element from the public record. I know who I am and when I was born, but the Wiki repository doesn't. I'm only seeking to provide the reference sought. [There is an example of such citation in the record of Marilyn Monroe, an Item that shows an image of her birth certificate. My assumption was that Wiki needs such confirmation...hence my effort to provide it.]DonMassey832020 (talk) 19:51, 16 March 2023 (UTC)
If you browse items on other human beings, you'll find that many if not most don't have references for date of birth. It would be nice if every statement in Wikidata had a reference, but that is not always reasonable or needed. Reading Help:Sources and Wikidata:Tours/References and looking at a bunch of other items about human beings who are not celebrities will help you understand how references are commonly used. -- William Graham (talk) 20:04, 16 March 2023 (UTC)
A concise and appreciated response...thank you. FYI...my concern was that I would not be seen as viable without such a reference. I guess I can assume my existence is assured! Thanks againDonMassey832020 (talk) 20:12, 16 March 2023 (UTC)
I'm just a humble country editor, but English Wikipedia has a policy against using birth certificates or other types of public records (such as you might find in genealogical searches or courthouse records) for supporting information about living people. One of the many reasons they don't accept them is because you will have difficulty proving that a particular record corresponds to the person you are attempting to document.
Now, Wikidata may not have such strictures on public records per se, but I would say that if you cannot find a reliable secondary source that documents such a vital statistic, it would be questionable whether that item in question is notable at all. Elizium23 (talk) 14:20, 19 March 2023 (UTC)
Why would you say that about a subject for whom there are four external IDs - VIAF, ISNI, LoC and WorldCat? Seems an odd hill to die on. --Tagishsimon (talk) 15:52, 19 March 2023 (UTC)
@Tagishsimon saying it's "questionable" is dying on a hill? You're surely exaggerating. Calm down. Elizium23 (talk) 15:54, 19 March 2023 (UTC)
@Elizium23: Please try to focus on what people are trying to say rather than how it is phrased. This an international and multilingual project and many people here are not communicating in their native language. I think Tagishsimon has a valid point: Having multiple non-user generated external IDs generally does mean that someone is notable in Wikidata and there are plenty of situations where we don't know the birth date of someone who is notable, so not being able to find a reliable source for someone's birth date would not make me question the notability of the entire item. - Nikki (talk) 05:28, 20 March 2023 (UTC)
"Seems like an odd hill to die on" is a common English idiom which I recognise well, and I am calling out that as an exaggeration because I am certainly not standing in anyone's way regarding this issue. Furthermore I completely agree with Tagishsimon's point about notability; I am not sure whether you picked that up in my subtle English phrasing. Elizium23 (talk) 18:13, 20 March 2023 (UTC)

Wikidata weekly summary #564

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • EntitySchemas: We are preparing for adding a new datatype and other changes by improving tests, documentation, etc.
    • Date input: We did a bug triage hour around issues with date parsing and improved it for Japanese dates (phab:T214002)
    • Ontology issues: We started evaluating the survey responses for the survey about different types of ontology issues reusers are facing. More work is needed before we have results.
    • REST API: We finished work on including the URL of an article in sitelink data (phab:T330252) as well as providing all aliases of an Item (phab:T327882)

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

Wikidata:Property proposal/Generic

Hello! This page has the largest number of properties in the discussion - there are 48 in total. Due to the growth of the page, some properties are no longer displayed. I have a question - do I need to create a new page with the Wikidata:Property proposal/ prefix or move some of the property discussions to other sections? —MasterRus21thCentury (talk) 21:35, 18 March 2023 (UTC)

I think creating a new prefix should not be done without seeking consensus for a specific proposal first. In general the way to progress the existing proposal. Is to read them and think about what they need to either be accepted and rejected. ChristianKl ❪✉❫ 12:34, 19 March 2023 (UTC)
@ChristianKl In your opinion, is there a shortage of contributors with the property creator flag, or is the current number sufficient to close the gaps? MasterRus21thCentury (talk) 07:12, 21 March 2023 (UTC)
@MasterRus21thCentury I don't think the problem is a shortage of contributors with the property creator flag. I think it's more that there's a shortage of people who read property proposals and actually engage with them by thinking about how they can be improved. ChristianKl ❪✉❫ 12:54, 21 March 2023 (UTC)

New performing arts class items

The Linked Open Data Ecosystem for the Performing Arts (LODEPA) Wikidata Working Group declared two new classes describing performing arts concepts:

The rationale for each class is documented in each item's discussion page.

In addition, members of the Working Group documented the class hierarchy for performing arts places in a diagram and in a class table.

Beat Estermann (talk) 22:21, 31 March 2017 (UTC) 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) Titanboo (talk) 17:23, 8 July 2022 (UTC) dlh28 (talk)18:21, 22 September 2022 (UTC)

Notified participants of WikiProject Cultural venues

Beat Estermann
Affom
Vladimir Alexiev
Birk Weiberg
Smallison
Daniel Mietchen
Buccalon
Jneubert
Klaus Illmayer
Katikei
GiFontenelle
Antoine2711
Fjjulien
Youyouca
Vero Marino
Celloheidi
Beireke1
Anju A Singh
msoderi
Simon Villeneuve
VisbyStar
Gregory Saumier-Finch
Rhudson
DrThneed
Pakoire
Gabriel De Santis-Caron
Raffaela Siniscalchi
Aishik Rehman
YaniePorlier
SAPA bdc
Joalpe
bridgetannmac
Nehaoua dlh28
LiseHatt
Zblace
Bianca de Waal
MichifDorian

Notified participants of WikiProject Performing arts Fjjulien (talk) 01:35, 21 March 2023 (UTC)

Merge or disambiguate?

Can someone have a look at oil and gas field (Q4291415) and oil and gas field (Q12132769) and fix them? At first glance they look similar, one seems to be classified as a mineral deposit and the other as a geographic area. The first item is wonky being an instance of something that is not a class. Edit: The ukranian wiki seems to think deposits and fields are two different things, they also have pages for oil and gas regions and oil and gas provinces. This makes zero sense to me. Infrastruktur (talk) 18:29, 19 March 2023 (UTC)

@Infrastruktur you can read https://www.wikidata.org/wiki/Help:Merge Badak Jawa (talk) 15:12, 20 March 2023 (UTC)
@Badak Jawa Help:Merge is for items that are supposed to be merged. When one Wiki has items for both, we don't merge the items. ChristianKl ❪✉❫ 20:20, 22 March 2023 (UTC)

WDQS March 2023 scaling update is out

Dear all,

A new Wikidata Query Service scaling update has been published. It outlines the WDQS current state and summarizes the suggestions with the most impact we’re exploring now, with a few in-progress.

You can read the full update here: Wikidata:SPARQL query service/WDQS backend update/March 2023 scaling update

We will also be hosting two office hour sessions on Jitsi (https://meet.jit.si/WDQSOfficeHour) to directly address your comments and questions with the team.

The first session will take place on March 27, 2023, at 17:00 UTC. Additionally, to accommodate those in the ESEAP area, we have scheduled a second office hour on March 28, 2023, at 8:00 UTC.

We hope you will be able to join us during one of these sessions to discuss this important topic further. Sannita (WMF) (talk) 10:06, 20 March 2023 (UTC)

Thanks! Just a little comment on the point "Reduce Redundant Data" in the update: I would propose to consider, alongside with the very much important addition of "mul" labels, the 5 Phab tickets I listed in meta:Community Wishlist Survey 2023/Wikidata/Prevent data duplication. Thanks again! I hope to manage to participate to one of the sessions on Jitsi. --Epìdosis 10:28, 20 March 2023 (UTC)
@Epìdosis Duly noted, and I personally bumped the tickets with the team. :) Hope to see you at the office hour! Sannita (WMF) (talk) 17:49, 20 March 2023 (UTC)
@Sannita (WMF): great, thanks! I've just added another small one here, also reported in WD:RATP. See you at the second office hour! --Epìdosis 21:16, 21 March 2023 (UTC)
Section Data management is mentioning "We estimate that approximately 40% of the data in Wikidata would be moved to a different Wikibase instance". Any details on that? Jklamo (talk) 11:00, 20 March 2023 (UTC)
@Jklamo The "40% of the data" part was under the hypothetical assumption that a part of our data, i.e. scientific papers, could be moved to a dedicated Wikibase instance, but this is all theoretical at the moment -- we need to first have a discussion on whether doing it or not, community consensus should be formed first, so all of this has to be figured out. I hope I answered your question. Sannita (WMF) (talk) 17:57, 20 March 2023 (UTC)
The point about an external label service (Decouple SERVICES from SPARQL) sounds very interesting, especially since this is very inefficient to do in SPARQL. (See: Wikidata:Project_chat/Archive/2023/01#The_problem_with_monolinguals) A document database/MapReduce backend would probably be perfect for a microservice, and will scale horizontally. Infrastruktur (talk) 08:28, 22 March 2023 (UTC)

Help with proposal

I can't really follow the guidelines and I'm unable to sketch the proposal, but I think it would be interesting to have a property for «https://wpbsa.com/player/». It provides nice and updated information about snooker players: ronnie-o'sullivan for this or john-higgins for this, for example. Thanks in advance. Alavense (talk) 09:26, 22 March 2023 (UTC)

There are only 130 items there, I think it will be faster just to add such urls with described at URL (P973) (mix&match should also work) than proposing a new property. Lockal (talk) 10:08, 22 March 2023 (UTC)
I would use described by source (P1343) of World Professional Billiards and Snooker Association (Q2030665) with qualifier URL (P2699), as it makes it easier to gather write a report for all the entries present. Vicarage (talk) 17:22, 22 March 2023 (UTC)

Backlog of Properties ready for creation

Hello, in Category:Properties ready for creation there are currently 67 Properties ready for creation.

Especially, I would like to be able to use property Wikidata:Property proposal/Deutsche Synchronkartei Person-ID and fill it with the new values.

Thanks a lot! M2k~dewiki (talk) 19:00, 15 March 2023 (UTC)

WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. for information. --M2k~dewiki (talk) 19:12, 15 March 2023 (UTC)

@M2k~dewiki ✓ Done as Deutsche Synchronkartei person ID (P11646) by Stevenliuyi. --Emu (talk) 20:23, 15 March 2023 (UTC)
I would be quite happy to support your application as a property creator, but for some reason I could not find the application. Infrastruktur (talk) 21:35, 15 March 2023 (UTC)
Thanks a lot @Stevenliuyi, Emu, Infrastruktur: currently the new IDs are inserted using QuickStatemens, a list of old and new IDs can be found with this query:
M2k~dewiki (talk) 22:52, 15 March 2023 (UTC)

@M2k~dewiki: on 8 March you created the proposal and the next day it had six support votes. How did you manage to achieve this? I created Wikidata:Property proposal/OpenStreetMap node ID and the proposal got no single feedback yet, not even speaking of support votes.

I would like to improve the OpenStreetMap data in Wikidata.

WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. for information. GeoGQL (talk) 07:31, 16 March 2023 (UTC)

@GeoGQL: with a ping to the groups WikiProject Movies and WikiProject Germany, where the members of this projects might be interested in this property.
With Wikidata:Property_proposal/ESPN.com_tennis_player_ID I experienced the same, without a ping no response for months, with a ping to WikiProject Tennis there was immediate support of the proposal.
Relevant projects might be found at Wikidata:WikiProjects. For example Wikidata:OpenStreetMap, Wikidata:Map data, Category:Wikidata_users_who_contribute_to_OpenStreetMap M2k~dewiki (talk) 08:56, 16 March 2023 (UTC)

Sometimes properties are unused after being created. I'm trying to avoid that when the property is ready for creation but the proposer is either inactive or doesn't seem to want to use it immediately. Midleading (talk) 11:38, 23 March 2023 (UTC)

Following the suggestions by user:M2k~dewiki I notified some users and got more feedback. @Midleading: can you have a look at Wikidata:Property proposal/OpenStreetMap node ID? Certainly that one will not stay unused. The count for the values that can be immediately copied is now 9000, and more values will probably be added as shows the +100 in the recent 7 days. GeoGQL (talk) 14:05, 23 March 2023 (UTC)

Wikidata:Property proposal/mastodon URL

Please have a look at Wikidata:Property proposal/mastodon URL. A Mastodon instance Q72705885 can be described using several of the properties that already exist. URL (P2699) is one such property. It is proposed to create a dedicated property only for URLs of Mastodon servers. And one user already suggested to add additional data describing the Mastodon instance using qualifiers. Then individual statements cannot be referenced. If implemented problems and possibly bad data will follow. Individual organisations can manage several instances, so any such entity is not the best place to describe the Mastodon instance. The instances can also change from one organisation to another. The instance can be descibed by owner, operator, URL, start time, end time, number of users, software version, technical features, maybe some policies they apply, location. I suggest to do it right from the start and create an item for each instance and use URL (P2699) for the URL and all the other exsisting properties. 89.14.237.54 19:32, 23 March 2023 (UTC)

A dataset of 481 000 SPARQL queries

Following a first attempt to collect a dataset of SPARQL queries (see https://observablehq.com/@pac02/hello-sparql-queries-dataset?collection=@pac02/wikidata-tools), I've collected a much larger dataset of 481 000 queries (notebook, csv file and parquet file). I think it would be very useful to deploy a search engine on this dataset. I'm not a specialist. If anyone knows how to use and deploy search engine softwares such as tantivy, sonic or meilisearch, help would be greatly appreciated. PAC2 (talk) 21:16, 23 March 2023 (UTC)

where did these queries come from? just scraping wikidata or from query logs? if the latter are there privacy concerns about sharing these? BrokenSegue (talk) 21:38, 23 March 2023 (UTC)
All queries are external links to query.wikidata.org published in Wikidata. I've collected them using the following query https://quarry.wmcloud.org/query/67454 PAC2 (talk) 21:58, 23 March 2023 (UTC)
if we could somehow get the context of the query e.g. a short summary of what it's trying to do then we could try to train an AI to generate them BrokenSegue (talk) 22:16, 23 March 2023 (UTC)
It's not possible to have the context. However we can look at queries with a title (#title:). PAC2 (talk) 06:07, 24 March 2023 (UTC)
Interesting. Can you add page_namespace to your dumps? page_title alone is not so useful.
A quick finding is that apparently ~68k (14%) of queries seem to be using "named subqueries", a feature that is at risk of becoming unavailable if the query service was migrated away from the no longer maintained Blazegraph backend some day in the future. —MisterSynergy (talk) 22:19, 23 March 2023 (UTC)
OK, I'll add page_namespace in the next version.
Of course, this dataset can be very useful if we move from blazegraph to another engine such as qlever. PAC2 (talk) 06:15, 24 March 2023 (UTC)

merge Q25625616 with Q486839

Q486839 is protected. Please merge with Q25625616. రుద్రుడు (talk) 13:53, 24 March 2023 (UTC)

Done ChristianKl ❪✉❫ 15:19, 24 March 2023 (UTC)

Mix'n'match new catalog

Hello,

Gerwoman has been helping me with the creation of two Mix'n'match catalogs but it seems she is not that active recently. I would like to create a new catalog to be associated with Africultures structure ID (P11462). The lists of URLs to capture is found on http://www.spla.pro/list.organization.html. Is there a way a catalog can be extracted from this? Moumou82 (talk) 21:06, 24 March 2023 (UTC)

Board of Trustees have ratified the UCoC Enforcement Guidelines

Hello all, an important update on the Universal Code of Conduct (UCoC) Enforcement Guidelines:

The vote on the Enforcement Guidelines in January 2023 showed a majority approval of the Enforcement Guidelines. There were 369 comments received and a detailed summary of the comments will be published shortly. Just over three-thousand (3097) voters voted and 76% approved of the Enforcement Guidelines. You can view the vote statistics on Meta-wiki.

As the support increased, this signifies to the Board that the current version has addressed some of the issues indicated during the last review in 2022. The Board of Trustees voted to ratify the Enforcement Guidelines. The resolution can be found on Foundation wiki and you can read more about the process behind the 2023 Enforcement Guidelines review on Diff.

There are some next steps to take with the important recommendations provided by the Enforcement Guidelines. More details will come soon about timelines. Thank you for your interest and participation.

On behalf of the UCoC Project Team, JPBeland-WMF (talk) 21:13, 24 March 2023 (UTC)

P2561

Greetings,

I am in conversation with @Markraf6969 about his use of the property name (P2561). I am curious, in general, how this property is prescribed for use, above and beyond the standard names, aliases, and labels we use on Wikidata. I can see that obviously it can carry references, unlike names, aliases, or labels. That is an advantage. I would assume it carries disadvantages as well; certainly it is not quite a standard usage. Is it widespread? Are there guidelines for implementing it? Would it be discouraged in certain cases? Elizium23 (talk) 16:00, 23 March 2023 (UTC)

Good morning, I am participating in a university project (University of Florence) for the 'Lessico dei Beni culturali', which involves collecting the names of people and artworks mentioned in the original editions and their translations of Vasari's Lives. The names of the people mentioned in Vasari's books and translations are listed under the item name (P2561) because my Professors told me to do in this way. All names will then be taken, thus indicated, to be used for a dictionary on cultural heritage. I am simply following the indications of my Professors.
Thanks for you message. Markraf6969 (talk) 16:15, 23 March 2023 (UTC)
'name': name the subject is known by. If a more specific property is available, use that.
Markraf6969's use of 'name' on Stephen (Q161775) seemed entirely reasonable & well referenced - diff. Stephen is known by the name saint Étienne. Nowhere else is that name string used as the object of a triple, nor referenced. You have removed Markraf6969's edit, but I do not see to what advantage. What exactly do you see as the disadvantage of saint Étienne on that record, when from first principles one would expect to find it as an object for a property such as 'name'? --Tagishsimon (talk) 16:18, 23 March 2023 (UTC)
Hello. Thank you for your message. Markraf6969 (talk) 16:25, 23 March 2023 (UTC)
@Markraf6969 is working on artwork, not historical persons. The references that are being included refer to the artworks in question which, in turn, depict the historical people concerned in these items. I do not see why "point in time, 1903" would refer to a historical person's name if that person lived in the 1st century? Has that not been John the Baptist's name for as long as French has existed? Elizium23 (talk) 17:22, 23 March 2023 (UTC)
Hello. The date 1903 is the one of publication of the edition in translation, as can also be read by clicking on the work (because there are several translations of Vasari's work). Markraf6969 (talk) 17:26, 23 March 2023 (UTC)
So in 1903, that was John the Baptist's french name? What was his French name in 1902? What was it in 1904? What was his French name in AD 20? Elizium23 (talk) 17:27, 23 March 2023 (UTC)
I'm working only with the translation published in 1903. There may be several variants of the name in various translations. There may be several references/variants, as Linguistics and translanguaging studies show. I must record the 'anthroponyms' specifically mentioned in that translation. This is the task I have. Markraf6969 (talk) 17:31, 23 March 2023 (UTC)
Why must you record them in the items about the historical persons and not the paintings which are documented in this reference? Why is this your reference for a name of a historical biblical figure? Why is your source not the Bible in French, or a Scriptural commentary? Elizium23 (talk) 17:33, 23 March 2023 (UTC)
@Markraf6969, your edit to Q117280276 makes perfect sense, as it is a 16th-century tableau which is adequately documented in your chosen reference work, which is perfectly suited to describe such a work of art. This IMHO is a perfectly normal use of the "name" property in question. The item is not a historical person, but a work of art. Why must you extend the scope creep to historical person items as well? That's just what I don't get. There are thousands of works of art you could be working on, just stick to those first? Elizium23 (talk) 17:35, 23 March 2023 (UTC)
Okay, I see. Thanks for your message. Markraf6969 (talk) 17:38, 23 March 2023 (UTC)
Vies des peintres, sculpteurs et architectes (Q110548580) is an encyclopedic work on the lives of "painters, sculptors, and architects". Saint Stephen was none of these. Why is this reference work being used to reference the name of a Christian saint who predates the French language by hundreds of years? Elizium23 (talk) 17:24, 23 March 2023 (UTC)
@Elizium23: it doesn't matter what the encyclopedic work is about. if is provides a reference for the person's name then it is valid as a reference. point in time is basically always a valid qualifier even if it is redundant or unnecessary. While it is not usual to provide a name (P2561) statement it isn't necessarily a problem especially if it's well referenced. please stop reverting their edits while this discussion is ongoing. @Polidori Eleonora : If we're going to have the same name at different points in time with different references we should fold them into a single statement with two points in time and two references. Is your professor who gave the project familiar with wikidata? BrokenSegue (talk) 18:33, 23 March 2023 (UTC)
Agree with BrokenSegue. Elizium23 doesn't show why that statement would be wrong. It doesn't matter what the professor requires, but s/he is suggesting a correct usage. Regarding merging two statements - the reference must refer to the point in time, how would that be possible if the two are merged? 89.14.237.54 19:43, 23 March 2023 (UTC)
There would be two points in time and each reference would refer to one of those. BrokenSegue (talk) 21:39, 23 March 2023 (UTC)
But why... why? Why have a "name" property when the French (and other) names are adequately filled in already in the built-in names, aliases, and labels?
Furthermore, these editors are adding honorifics and extraneous modifiers to these names. Honorifics are not names. They are not parts of names. They are honorifics, and we can have ourselves yet another debate about which honorifics belong with the names, which do not, and which should be clearly separated. The main point about honorifics is that they are bestowed by certain groups who use them and not used by other groups who do not. So adding honorifics to a name is to lose our neutral point of view.
Honorifics can be adequately handled via other mechanisms in Wikidata and other projects, and do not need to be prepended/appended to a P2561 value. Elizium23 (talk) 02:30, 24 March 2023 (UTC)
Labels and aliases exist for Wikidata internal purposes. In this case, there's scholarship where someone wants to store the name that was used in sources and that's what name (P2561) is for. It's a valid scholarship project to investigate how the name of a historical figure evolved over time. ChristianKl ❪✉❫ 13:06, 24 March 2023 (UTC)
@BrokenSegue, it is customary to maintain the status quo while consensus is achieved to make a change, not the other way around. @Markraf6969 has ceased editing for now and that is the right thing to do until he can muster consensus to add this P2561 property to everything. Elizium23 (talk) 02:33, 24 March 2023 (UTC)
@BrokenSegue, P2561's instructions are explicit: If a more specific property is available, use that. These editors have brazenly ignored these instructions and added this property even when such fields as "given name" and "surname" and others already exist. It is on these grounds of misuse that I continue to protest and oppose the widespread addition, of this property, in this manner, and with this reference.
Thank you. Elizium23 (talk) 02:35, 24 March 2023 (UTC)
Good morning. Please don't say that I 'brazenly' ignored the instructions because it's not true: I'm new to Wikidata and to this project and it's normal to make mistakes. That's why this chat exists.
1. Regarding honorifics, I'm looking into it. In case I made a mistake, I apologise. They are certainly not fields that I will add back, as far as these saints are concerned. They are not really relevant to this project.
2. Regarding variants of a name: there will often be cases in translations where the name is different from the original and this is crucial not only for contextual use in editions but for linguistic use in general.
3. Regarding putting first names and surnames: you are right. If the full anthroponym is given in the same edition I use that, without repeating it several times.
Thank you. Markraf6969 (talk) 08:00, 24 March 2023 (UTC)
@Elizium23 The instruction says "If a more specific property is available, use that.". If a person is named "John Smith" than neither the given name nor the surname property is a more specific property to store the name. If you have a source that says "The name of this person is 'John Smith'" than name (P2561) does the job. If it however says "The official name of this person is 'John Smith'" than official name (P1448) would be better.
Wikidata's neutral point of view is that we look at sources when it comes to what someone's name is. If a source includes the honorific in the name, a name (P2561) that references that source should include it. ChristianKl ❪✉❫ 13:04, 24 March 2023 (UTC)
I'm not sure if you speak English natively, but I interpret that sentence as meaning "If at least one more specific property is available, use that." Since P2561 is a superclass, there is almost always at least one more-specific property. It's like someone is adding "year of birth" properties to items that already have more-specific "date of birth" property. I can't wrap my head around it.
Nevertheless, nobody else in this discussion opposes the addition of these properties, so it appears that you have consensus to add them. Enjoy. Elizium23 (talk) 02:25, 25 March 2023 (UTC)
Lawyers study a lot to learn how to read laws to actually understand what the laws mean. Being a native English speaker alone is not sufficient to understand what's meant by every law. You actually need to understand the purpose of laws to interpret their meaning correctly.
In this case, the usage instruction does not exist to stop the usecase of an academic storing the names that sources used to refer to a person. For some people honorifics are part of the name that's used to refer to the person. For others they aren't. ChristianKl ❪✉❫ 19:28, 25 March 2023 (UTC)

User:DeltaBot not marking done requests on WD:RFD

Hello, I have found that User:DeltaBot stopped marking done requests on WD:RFD. The last edit by the bot on WD:RFD was in 20:50 UTC on 23rd March. It caused me to mark done requests manually. Is there are any problems on the bot causing it not marking those requests? 211.30.32.67 07:21, 25 March 2023 (UTC)

@Pasleim, MisterSynergy: FYI --Ameisenigel (talk) 07:41, 25 March 2023 (UTC)
It got stuck somehow and needed a restart. Hope it's fine again. —MisterSynergy (talk) 08:39, 25 March 2023 (UTC)

issues with new property OpenStreetMap node ID

OpenStreetMap node ID (P11693) was created this afternoon.

1) sorting: after moving a claim to the new property it is no longer sorted next to the other OpenStreetMap ID. Can it be made so, that on an item page they sort in this order:

  1. OpenStreetMap relation ID (P402)
  2. OpenStreetMap way ID (P10689)
  3. OpenStreetMap node ID (P11693)

?

2) linking: formatter URL (Property:P11693#P1630) exists, but new claims using the property only show the value and don't link to OpenStreetMap

3) moving: Autofix has been added by the property creator, is it known when this will be carried out? Can it be triggered? ~9000 values would be moved. GeoGQL (talk) 16:34, 24 March 2023 (UTC)

For #1, if you leave a note at MediaWiki talk:Wikibase-SortedProperties an admin will be able to get this into the right position.
For #2, formatter URL changes usually take about a day to show up due to caching delays, and I would assume this is the same for a newly created property. So it should be working smoothly by tomorrow, I think. Andrew Gray (talk) 17:41, 24 March 2023 (UTC)
Looks like the autofix bot has now kicked in as well (which is useful to know, didn't realise it would work retrospectively). Andrew Gray (talk) 16:14, 26 March 2023 (UTC)
2023-03-25 08:15 it still worked on it and the next edit 9:15 was something else. [7] . Still 10108 wrong https://w.wiki/6Vne Of these as main statement, 2023-03-15 [8] -> now 2023-03-26:
GeoGQL (talk) 21:20, 26 March 2023 (UTC)
Progress of conversion after 2023-03-24 implementation of autofix
Time Regex fail
"^([1-9][0-9]{1,10})$"
https://w.wiki/6Vne		 main "way"
https://w.wiki/6Sh8		 main "node"
https://w.wiki/6Sgy
2023-03-15 - 16359 8946
2023-03-26 10108 8369 4413
2023-03-29 11:51 10098 8261 3859
2023-03-30 15:37 10108 8260 3840
2023-03-31 00:54 406 0 0
2023-03-31 14:21 0 0 0

GeoGQL (talk) 11:51, 29 March 2023 (UTC), GeoGQL (talk) 15:37, 30 March 2023 (UTC), GeoGQL (talk) 00:54, 31 March 2023 (UTC), GeoGQL (talk) 14:21, 31 March 2023 (UTC)

@Andrew Gray: after the first run it slowed down a lot. Thanks for your offer of a batch operation [9]. If you could do the move of the ~3840 "node" values in main statements via a batch that would be very helpful. This one is more important since the values belong to another property and there is a risk that some user removes the "node/" part. The others are more but can maybe wait a bit longer. The move of the node values to the new property also may fix other constraint violations, e.g. two values in "OSM way ID". So, the most benefit and the least work seems to lie in that part. GeoGQL (talk) 15:52, 30 March 2023 (UTC)

So just to confirm:
  1. any value of OpenStreetMap way ID (P10689) : node/12345 should be moved to a new claim with OpenStreetMap node ID (P11693) : 12345
  2. the new OpenStreetMap node ID (P11693) statement should have any reference/qualifier which was on the OpenStreetMap way ID (P10689) statement
  3. the old OpenStreetMap way ID (P10689) statement can then be deleted
I think I can see how to do this but #2 might turn out to be a little tricky to make sure I do it right. Will see what I can work out. On the other hand, 2941x have neither qualifiers nor references, so that should be straightforward. Andrew Gray (talk) 17:18, 30 March 2023 (UTC)
Confirmed. Suggest to first do only those without qualifiers or references. If done I will try to have a look at the remaining ones. Or maybe you have a SPARQL so I could already now have a look what is in the qualifiers and references. GeoGQL (talk) 17:22, 30 March 2023 (UTC)
@GeoGQL Turns out wikibase-cli manages to cope with all three cases without any trouble - this is a test edit for the simple case (no qualifiers/references); this is one with a reference, and this is one with qualifiers. Looks like they all work OK? I'll set that batch up tonight. Andrew Gray (talk) 17:41, 30 March 2023 (UTC)
...no they don't, I am an idiot and forgot to remove the node/ element! Back to square one. Andrew Gray (talk) 17:43, 30 March 2023 (UTC)
At least it would be already in the right property. Autofix exists for the new property too. GeoGQL (talk) 17:54, 30 March 2023 (UTC)
Yes, that's definitely *something*!
I think the best way to make sure we conserve the references/qualifiers is to do this move (so P11693:node/12345) and then update the new statement to have the 12345 value. Two edits per page and a little clunky, but it will work and not lose any data.
Looks like that's working, thankfully. Andrew Gray (talk) 17:56, 30 March 2023 (UTC)
Just saw the fixes. Great. Yes, two steps but safe. No idea if KrBot preserves q and r. Oh, and that means you can also fix the way/. :-) GeoGQL (talk) 17:58, 30 March 2023 (UTC)
I am pretty sure it does (it is run by someone a lot more competent than me!). First stage now running. Andrew Gray (talk) 18:14, 30 March 2023 (UTC)
First stage done, second stage now running! Andrew Gray (talk) 19:09, 30 March 2023 (UTC)
Confirmed, query of third column in table above has zero results. Probably the third stage would be to remove the "way/" from the main statements, then the query of the second column in the table would have zero results. Then there should be only the non-main statements, 397x reference and 22x qualifier, which can be found via the query in the first column https://w.wiki/6Vne . I will do q manually now. GeoGQL (talk) 19:21, 30 March 2023 (UTC)
https://w.wiki/6Vne - 22 qualifier done, some moved to references. GeoGQL (talk) 19:34, 30 March 2023 (UTC)
To confirm for way/ - it's a straightforward OpenStreetMap way ID (P10689) : way/12345 becomes OpenStreetMap way ID (P10689) : 12345, no need to change the property, just strip off the prefix? That one should be easy to do. Andrew Gray (talk) 22:02, 30 March 2023 (UTC)
Confirmed. Just saw the bot finished, happy to see way/ fixed. GeoGQL (talk) 22:08, 30 March 2023 (UTC)
Set the /way run going now (example) - 8k items so should take a little while but will be done sometime tonight, if all goes well. (If not I'll restart it tomorrow.) Andrew Gray (talk) 22:51, 30 March 2023 (UTC)
At the current rate of >85 it would mean done in less than 8260/85 ~ 100 min. GeoGQL (talk) 22:58, 30 March 2023 (UTC)
Bot has finished. Now only 406 references remain https://w.wiki/6Vne GeoGQL (talk) 00:56, 31 March 2023 (UTC)
@Andrew Gray: The remaining 406 reference errors have been resolved manually by me. It seemed to me as if there were more result rows than actual errors, i.e. sometimes I fixed one error on an item and two error rows for that item disappeared. GeoGQL (talk) 14:24, 31 March 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. GeoGQL (talk) 14:24, 31 March 2023 (UTC)

MediaWiki / Wikibase bug leading to hundreds or thousands of broken links

Some links for OpenStreetMap way ID (P10689) are broken. E.g. on Mount Olivet Cemetery (Q21586308) the claim at Q21586308#P10689 shows a value of 60928528 the formatter for the property is https://www.openstreetmap.org/way/$1 but the link goes to https://www.openstreetmap.org/60928528 and not to https://www.openstreetmap.org/way/60928528.

The value has been changed 2023-03-25 02:35 but the old URL formatter is still applied, it was changed to the new pattern 2023-03-25 19:44. A bug in the MediaWiki / Wikibase (Q16354758) software. GeoGQL (talk) 12:13, 29 March 2023 (UTC)

@GeoGQL Formatter URLs are cached, and get updated when the page is next edited/purged. (I've just manually purged the page now and it's showing up with the correct URL). This is logged as phab:T112081 - it's a little complicated because there are two effects at play - as we discussed earlier, there's also one where the initial change is cached for 24 hours before being applied to items at all. But after that, you still need to wait for the cache to be cleared by editing/refreshing for existing items to show the change.
In this case, because the edit was made to the page before the formatter URL was changed, it didn't trigger the change. I have a short script I can run to fix these (by triggering a purge on each affected item); will get it running later today. Andrew Gray (talk) 12:29, 29 March 2023 (UTC)
...although, hmm, having said that it looks like a lot of the existing properties have the old-style node/ or /way prefixes - about 12k of 20k. Presumably these will all be updated in the near future? In which case the only ones needing updated are the ones that were already changed, which simplifies the problem a bit - there's no need to purge the old-style ones. Andrew Gray (talk) 12:35, 29 March 2023 (UTC)
Autofix is not carried swiftly, see section #issues with new property OpenStreetMap node ID, and caches not refreshed. Thanks for the pointer to phab:T112081 - created 2015-09-10 'When we start using the "formatter URL" statements on properties to generate HTML links to authority vocabularies, we need a way to purge such cached renderings when the respective statement in the property definition changes.'
Maybe they did 'start using the "formatter URL" statements on properties to generate HTML links to authority vocabularies' before having 'a way to purge such cached renderings when the respective statement in the property definition changes'.
Can you run your script only for those that are already changed? Or maybe the Autofix can be applied faster and you could run it on all items. GeoGQL (talk) 16:21, 29 March 2023 (UTC)
From now on (unless the property is changed again) any edit to update the property will also produce the correct link - and since those all need updated anyway, there doesn't seem any point in purging them just now. The only ones where it will be useful are the ones with new-style values - these items. I've set the script running on them - past experience says it'll plug through them all over the next 24h.
In terms of the autofix, I'm not sure how that's structured (it may do things in batches rather than convert all the values for a single property at once), but if it's not up and running with the new values by the weekend I can try setting up a batch job for it as well. Andrew Gray (talk) 21:37, 29 March 2023 (UTC)
Run on all was only meant for the case that running couldn't be split. Thanks for your help. GeoGQL (talk) 15:42, 30 March 2023 (UTC)
@Andrew Gray: confirmed probably fixed. https://www.wikidata.org/w/index.php?title=Q4198&diff=prev&oldid=1860356307 was last changed 2023-03-24 i.e. before the formatter change, but displays the correct URL, tested even logged out. GeoGQL (talk) 17:26, 31 March 2023 (UTC)

Fixed for the OSM properties, but still can occur at any time a formatter is changed. GeoGQL (talk) 17:29, 31 March 2023 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. GeoGQL (talk) 17:29, 31 March 2023 (UTC)

Lama versus Lama

Should we split occupations and honorifics like Lama (Q191421), I added that it was also an honorific. I had asked once before, but there was no consensus. If we had Lama as an honorific, a bot could tell that Lama Namkha Tashi (Q106794692) "Lama" was not a given name. We do something similar for entries with "Sir" and "Reverend" and "Judge". RAN (talk) 19:28, 24 March 2023 (UTC)

Yes, the honorific and the occupation are two different concepts. ChristianKl ❪✉❫ 11:37, 27 March 2023 (UTC)

duplicate : Héctor Barceló (Q55067389) = "Héctor Barceló" (Q55458582)

Héctor Barceló (Q55067389) = "Héctor Barceló" (Q55458582) 89.14.40.68 23:22, 26 March 2023 (UTC)

→ ← Merged Estopedist1 (talk) 06:28, 27 March 2023 (UTC)

Clean up official website (P856) duplicates, one with trailing / and another without

I come across many official website (P856) duplicate statements, one with trailing / and another without. But there are too many official website (P856) claims that I can't use SPARQL to generate a list of them. Can somebody clean up it? Midleading (talk) 13:31, 27 March 2023 (UTC)

This SPARQL query appears to be working for me. Stevenliuyi (talk) 14:30, 27 March 2023 (UTC)

Siblings

Do we have a sibling bot, that would populate sibling=, if people had the same parents? The number of permutations is exhausting and error prone, when done by hand. RAN (talk) 22:36, 13 March 2023 (UTC)

I thought I read somewhere (possibly a couple of years ago now) that use of sibling (P3373) is generally discouraged when it is a simple biological relationship and the parents are already mapped. The various relationship tools and even normal queries can construct the family tree in most cases from the item links between parent and child. It is only where parent information is missing or there is a more complex relationship such as adoption of a child that sibling (P3373) is needed. We don't necessarily need to cross match every relationship in the database to make the information retrievable. As you say, the number of permutations from the millions of existing human items is extremely high; is there better use of our resources when the parent relationship can already construct the information you are trying to model? From Hill To Shore (talk) 01:01, 14 March 2023 (UTC)
That is a bit difficult as I am talking about not using sibling (P3373). Showing you where sibling (P3373) is not used is the same as trying to prove a negative. My point is that it is possible to retrieve sibling relationships from queries simply from mapping the parent child relationships when sibling (P3373) is absent. Now, I am no expert on Wikidata queries, so it may be that the effort to map a family tree from query results when sibling (P3373) is absent is inordinately time consuming and wasteful of server resources. Just because something is theoretically possible, doesn't make it practical. I am certain I read somewhere that I shouldn't use sibling (P3373) but I am unable to locate it in any official guidance; it may be that such guidance was removed or I am just remembering some advice from the Project Chat page (such advice may or may not have reflected consensus at the time). From Hill To Shore (talk) 22:09, 14 March 2023 (UTC)
From a SPARQL perspective, querying for <all items that have the same 'father' and 'mother' values as this item> is very considerably more expensive than querying for <the value of 'sibling' in this item'> and, given the existence of sibling, considerably less intuitive. Although there are garbage in, garbage out (Q1569381) and edge-case concerns in deriving sibling data from extant parent data, I beg to doubt FHTS's discourgers. --Tagishsimon (talk) 08:09, 15 March 2023 (UTC)
I don't think that sibling (P3373) usage will be discouraged due to redundancy in any time soon, because it is used almost in every person infobox in every language in Wikipedia and call to getEntity(parent) is expensive. Lockal (talk) 10:21, 15 March 2023 (UTC)
If it's any help, I have a distant recollection that at some point the advice was "don't worry about including sibling because a bot will infer it from same father/mother and add the claims"... but it looks like that never happened. And maybe I was just confused anyway.
At the moment we have about 820,000 pairs of children with the same parents, but only about 75,000 of those have sibling links (report). It should be straightforward to write up a batch of those and just have a bot churn through it, marking everything as eg "inferred from: same mother and father", if that's something people would feel is valuable. It would take a while to process 1.5m edits, though! Andrew Gray (talk) 17:42, 21 March 2023 (UTC)
 Support for User:Andrew Grays proposal, albeit always with a list of problems and errors that can be looked through by a human. --Tolanor (talk) 00:47, 28 March 2023 (UTC)

How to merge Anterior Cruciate Ligament Injury (Q18912826) and Cruciate Ligament Injury (Q34623048)

I was surprised that the German wiki article Kreuzbandriss didn't link to the English equivalent Anterior Cruciate Ligament Injury.

They each use a different Wikidata entity. The English one Q18912826 is associated with 14 languages, the German one Q34623048 with 4.

I don't know how to merge since unfortunately the Swedish Wikipedia has stub articles for each of the entities: https://sv.wikipedia.org/wiki/Korsbandsskada and https://sv.wikipedia.org/wiki/Fr%C3%A4mre_korsbandsskada.

There is a small fundamental difference between the German and English wikidata entries: the English talks specifically about the "Anterior" ligament, whereas the German talks about the general class of all cruciate ligament injuries.

While this may seem a substantial difference, in practice, injury is almost always to the anterior ligament, so the German article could well link to the English "anterior". Germans just talk about the specific injury in more general terms in practice - whereas English speakers use the more precise medical terminology.

I think the German editor should have linked to the English article that was already in existence. The current situation is not good - in that each language has usually just one article, picking arbitrarily between the more specific or general - there's no point to have an article for the general case and the specific. So it would be good to merge the wikidata entity to the larger English one. Or the other way round if merging in the general direction is preferred.

I've never merged anything, just noticed this so thought I ask here for help. Micronor (talk) 13:23, 20 March 2023 (UTC)

Wikidata items not only exist for Wikipedia links. Wikidata items often are very specific both items for example have different ICD-11 values and a user might want to look up the Wikidata item for a given ICD-11 value. The way you get Wikipedia interlinks in cases like this is through Wikilinks to Redirects. Redirects also allow more directly to link to the actual sections. ChristianKl ❪✉❫ 13:42, 20 March 2023 (UTC)
Thanks @ChristianKl! After some more reading I came to the same conclusion, that this is a classic case of Bonnie and Clyde (Help:Handling sitelinks overlapping multiple items) and that the workaround is to use redirects - which are a pain to generate. There was once a RFC but that stalled. Micronor (talk) 15:37, 20 March 2023 (UTC)
@Micronor The RFC is through. They aren't as painful to create as they used to be in the past. You just need to add the badge.
DeWiki might need it's own RFC to allow some redirects to be created but in this case the relevant redirects seem to be within the rules of DeWiki. ChristianKl ❪✉❫ 21:06, 20 March 2023 (UTC)
"almost always" is not "always"; a merge would remove the possibility to cater for the minority of cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:27, 27 March 2023 (UTC)

Bandcamp ID Issue

Attempting to place a Bandcamp ID into our band Item, and issues abound. Does anyone have experience with such ID placement, and would they be willing to suggest a bit of guidance? Thanks in advance.DonMassey832020 (talk) 15:58, 24 March 2023 (UTC)

@DonMassey832020: can you be more detailed? What item is your band? What is the bandcamp id? Is it Q117071897? I believe I fixed it for you but your band may not meet our notability guidelines and so may be deleted. BrokenSegue (talk) 20:57, 24 March 2023 (UTC)
I thank you very much for your assistance. As for our band, the band is comprised of performers who have toured the world with major artists such as Sting and Aretha Franklin, as well as having performed for presidents Clinton and Obama at the White House. We are continuing to update our achievements, adding them into our data blocks.DonMassey832020 (talk) 23:04, 24 March 2023 (UTC)
Just add in some urls for any press coverage you received. --RAN (talk) 23:23, 24 March 2023 (UTC)
Many thanks. Where would those URL's be placed on our Item page? Also...may we create a new Item for Category: Bogus Troll Band members, separate and distinct from our primary Item? Creating and incorporating such a supporting and relevant Item could allow noted band members to be entered and cited. Am I correct about that? Thanks once again...your kindness very much appreciated.DonMassey832020 (talk) 23:37, 24 March 2023 (UTC)
Wikidata is not the platform to promote your own band. Deleted. Multichill (talk) 12:22, 25 March 2023 (UTC)
What is interpreted as promotion is the simple fact of existence when those who established this musical entity are themselves NOTABLE by virtue of their separate and verified achievements. No active promotion was sought or intended, let alone enacted. The decision to delete other Items that are substantiated by the achievements and citations listed in our respective Identifiers appears to be inherently punitive, a decision that also appears to have willfully ignored Darryl Tookes, as one example, and his longstanding musical achievements, including having appeared on the Billboard charts, performed at the White House, recorded on West Side Story under Leonard Bernstein himself, toured the world with major artists and, on top of all that, already being shown within the listed rankings of accepted data repositories used by other musical entities. Was any examination of his credentials and Identifiers (at least 11 sites that are used by artists listed on Wikidata, including the Eagles) before his deletion? In my own case, deletion was done despite my having been recognized as a published author on an important historical event in American history--forget about my musical achievements--as a punitive action, despite my being listed in 9 accepted repositories used routinely by Wikidata. There seems to have been negative underlying assumptions, if not animus, at the heart of this deletion action. I believe the evidence would lead an objective party to that conclusion. There should be an objective means of seeking to overturn seemingly arbitrary deletions, and such an effort should be undertaken, especially since "promotion" cannot in any reasonable way be asserted or substantiated. No one waved the Wiki flag to the world in order to prove our validity or our existence. We should not have to "lobby" our way onto the Wikidata listings, since our achievements should be sufficient. Those achievements seem to have been ignored in order to fulfill deletion.DonMassey832020 (talk) 13:28, 25 March 2023 (UTC)
You did nothing to indicate your conflict of interest in your edits on the page, so engaging in punitive actions for violating rules requiring conflict of interest disclosure is completely sensible. If you are a notable musician someone else is going to create an item for you. If nobody besides you considers you notable enough to create an item for you that's a good sign that you aren't notable. ChristianKl ❪✉❫ 20:08, 25 March 2023 (UTC)
Sensible enough. While it is unlikely that you can still review the ITEMS created for individuals other than myself (Darryl Tookes, as one example) since we were summarily deleted along with the band item (you cannot read them for analysis now) you and others might find that a) those items were created about individuals and NOT the band, b) those individuals were NOT myself (except in one case), c) those individuals had more than enough credentials to meet the Notability standard, and d) those Items (while notable in and of themselves) were deleted ALONG WITH the Bogus Troll Band item. What say you or others about the Wikidata deletion rules? If I had declared an asserted "conflict of interest" or if someone other than myself had submitted the very same data on my, would I still have been deleted? My background stands, no matter who enters the data. Was there a valid reason to delete OTHER ITEMS that were NOT Bogus Troll Band, simply because the items were created by me, as a founder of Bogus Troll Band? Arbitrary and unfounded are words that come to mind, given that deletion rules seem pretty clear: there seems NOT to have been a foundation for deletions beyond Bogus Troll. That, as I view it, was punitive and beyond the scope: Simply deleting because of an association with the BAND should not be justifiable. Is that what Wiki Deletion Rules state, guilty BY ASSOCIATION? I rather think not. There was no fraud or deception perpetrated. Perhaps a case could be made that other notable Items should not be deleted because of any one editor's extrapolated assumptions. Specifically, I see no case for the deletion of Darryl Tookes, as he was described, or myself (a published author with Identifiers in multiple acceptable repositories around the world). Did we earn deletion as a punitive action? Rest assured, there are objective third parties (NONE OF THEM PAID, ESPECIALLY NOT BY US) who stand ready to create new Items for many of the men formerly listed here as Items but who were deleted last night. MY QUESTION: Will any such new Items be summarily deleted a) just because they were deleted before, or b) because an editor chooses to arbitrarily deny creation of such Items, even when created by objective third parties, based on our name? If that were to happen, would it not be discriminatory? I submit this last question: HOW IS ANYONE WITHIN THE WIKI EDITORIAL UNIVERSE to know whether an individual editor who creates an official Wiki account is sufficiently objective? No one knows anyone directly, but accounts are created routinely, and the editing process begins. All well and good, as it should be. My hope is that we will not be summarily dismissed if or when a future editor (unknown to us) chooses to create Items on our behalf. If such summary deletion were to occur, it could seem that the entire editing process could be called into question, especially in the absence of a requirement that any proposed editor submit THEIR OWN CREDENTIALS prior to being allowed to become an editor in the first place. That's something that no editor is required to do now, correct? Such is the nature of Open Source: nothing can be truly open without admitting the possibility of at least one flaw in its creation. [Rather long, but the commentary included here is inherently logical, as I see it.] Thank you.DonMassey832020 (talk) 21:11, 25 March 2023 (UTC)
Our rules don't exist to satisfy people who come here with their own commercial interests. ChristianKl ❪✉❫ 15:16, 26 March 2023 (UTC)
Assumptions...again...absurd.DonMassey832020 (talk) 17:00, 27 March 2023 (UTC)

Wikidata property for an identifier that does not imply notability (Q62589320)

Is this item for identifiers that does not automatically makes a subject notable? Or is it for identifiers that does not count towards notability in the slightest? I feel like these are two very different things. --Trade (talk) 22:36, 24 March 2023 (UTC)

  • I have always had a problem with it, and it has been used in many deletion arguments. Several identifiers have been exploited by SEOs for living people, such as IMDB, where anyone can start a production company and add a movie that only appears on YouTube, then VIAF creates an entry based on the IMDB reference. A better name would be "exploitable identifiers". Recently there were several nominations for human entries where only a Findagrave and Familysearch identifier were entered. --RAN (talk) 23:17, 24 March 2023 (UTC)
Our notability policy doesn't directly care about Wikidata property for an identifier that does not imply notability (Q62589320) or Wikidata property for an identifier that suggests notability (Q62589316) at all. Both can something be a help but notability decisions are always made in a case-by-case basis. ChristianKl ❪✉❫ 15:22, 25 March 2023 (UTC)
notability decisions are always made in a case-by-case basis
Well, no, they are not. A case-by-case basis implies that every item is brought before the community for examination and consensus, but not every item is treated like this; only the edge cases are. Administrators frequently delete items that clearly do not meet the notability policies, and this is not case-by-case but simply a generalized application of policy when the "case" is clear-cut. Conversely, many items are kept, not on a case-by-case basis, but because any reasonable person can recognize that they pass the notability policy. See Jesus (Q302), for example; was it decided to keep Jesus on a case-by-case basis? Nope. Elizium23 (talk) 17:03, 25 March 2023 (UTC)
Case-by-case no way implies that it has to be a community decision and not a decision made by one admin.
The main point is that, when we used to have discussion about whether we should delete Wikidata property for an identifier that does not imply notability (Q62589320)/Wikidata property for an identifier that suggests notability (Q62589316) years back, we said that we don't delete them even if they have no direct influence on our notability policy. We never made a decision to change our notability policy in a way that makes Wikidata property for an identifier that does not imply notability (Q62589320)/Wikidata property for an identifier that suggests notability (Q62589316) matter to whether or not items are notable.
Wikidata has a notability policy that's written down. Based on the existing policy and decisions we make to delete and undelete items there's a rough consensus among admins of how to apply this policy. Unfortunately, it's not written in a way where an outside can easily see whether or not an item is notable like Wikipedia policies that are very explicit about what criteria an item might fulfill. There would be some advantage to having a policy that's more explicit and easy to understand, but nobody has created such a proposal. ChristianKl ❪✉❫ 19:48, 25 March 2023 (UTC)
I created both properties, with the intention of differentiating identifiers which may be either self-generated (ORCID, IMDb) or generated by a non-authoritative cataloguers; and those which are part of a set where we definitely should have an item; such as identifiers for Fellows of the Royal Society. The waters were muddied when the description of Wikidata property for an identifier that suggests notability (Q62589316) was foolishly changed from "a Wikidata property where a legitimate value indicates that the subject is notable" to read "...that the subject is probably notable". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:19, 27 March 2023 (UTC)

Wikidata weekly summary #565

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming:
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group Working Hour March 27, 2023: We will be creating items related to notable book podcasts. You are, as always, welcome to bring your own project to work on.Event page
      • WikiCite Monthly Meeting, online on 28 March 2023 at 16:00 UTC. Information and notes
      • Wikidata Query Service backend update office hours will be held on Jitsi on 27 March 2023 at 17:00 UTC (link to the Etherpad) and 28 March 2023 at 10:00 UTC (link to the Etherpad)
      • Weekly Lexemes Challenge #86, Clothes
  • Development
    • EntitySchemas: We started working on the new datatype to link to EntitySchemas in statements (phab:T214884)
    • Query Builder: We finished the work on the language selector so you can swithc the interface language of the tool (phab:T328148) It will be available on the site in the next days.
    • Wikibase REST API: We implemented the functionality to provide an Item's label, description or aliases in a specific language (phab:T323173)

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

ChatGPT-Wikidata plugin

Recently OpenAI has implemented initial support for plugins in ChatGPT, these plugins allow ChatGPT to access up-to-date information, run computations, or use third-party services. I believe that it would be nice if someone with technical knowledge could evaluate the feasability of creating a Wikidata plugin (to access items information), or a Wikidata Query Service plugin (to perform queries). MathTexLearner (talk) 22:35, 23 March 2023 (UTC)

I was literally about to post the same thing over at Wikidata talk:WikiProject Large Language Models. I would do it but I don't have much free time right now. I think we would also need to create a toolforge API to proxy in front of the official Wikidata API to make it amenable to use by chatgpt. BrokenSegue (talk) 04:04, 24 March 2023 (UTC)
Anyone interested in this topic might be interested in https://golden.com/ai which is a text-based interface to querying information from Golden (Q71016606) (a competitor to Wikidata). it's not great but it points in an interesting direction. BrokenSegue (talk) 05:14, 28 March 2023 (UTC)

Gender controversy redux

Should the heuristic assignment of genders based on given names be reversed as done here Special:Contributions/Clements.UWLib. I believe the formula is when we have a given_name assigned to only one gender, the bot/editor assigns the gender, and attributes it to the heuristic formula. Rather than have an edit war, a decision is better made here. Asking here first would have been better than reversing the gender assignment. RAN (talk) 17:53, 24 March 2023 (UTC)

Courtesy ping to @Clements.UWLib:. From Hill To Shore (talk) 18:45, 24 March 2023 (UTC)
It looks like a consensus to revert was arrived at: User talk:Dsp13#Quickstatements Activity Using P21. ArthurPSmith (talk) 19:01, 24 March 2023 (UTC)
  • Which is being reverted, the assignment of gender, or reverting the deletion of gender? It isn't clear in the thread. Wait, it now looks like there is consensus on removing gender. We should probably look at error rates before making a decision, the error rate is most likely less than 1 in 1,000 based on the heuristic. --RAN (talk) 19:06, 24 March 2023 (UTC)
    The consensus was to revert the assignment of gender. --Crystal Yragui, University of Washington Libraries (talk) 22:54, 25 March 2023 (UTC)
    I apologize if I jumped the gun on reversing these quickstatements batches. I thought edits needed to be reviewed before they were made, but didn't realize reverting problematic batches needed to be discussed. I will bring it up here in the future. I think it would be very unethical to wait on removing these until an error rate can be determined, given the potential for harm by misgendering people. I think that is what people were saying on the user talk page for Dsp13. How would error rates be determined? How long would that take? How much harm will be done in the meantime? Assigning sensitive personal demographic information to living people in this way and leaving it up on the web until it can be disproven will cause harm to people. One such person spoke up in the thread mentioned above. The people harmed will be disproportionately gender non-conforming folks. That is not okay. --Crystal Yragui, University of Washington Libraries (talk) 23:04, 25 March 2023 (UTC)
    To be honest, I don’t see any consensus, I just see (a) a mediocre batch and (b) some American activist librarians with similar opinions. --Emu (talk) 08:40, 26 March 2023 (UTCI was
    People who don't agree with me = activist. Good to know. Gamaliel, American activist librarian (talk) 15:13, 26 March 2023 (UTC)
    Please don’t put words in my mouth. --Emu (talk) 06:54, 27 March 2023 (UTC)
    Then don't cast such aspersions on the motives of other editors. Gamaliel (talk) 14:10, 27 March 2023 (UTC)
    What exactly are you denying? American? Librarian? Activist? None of those epithets are dishonorable in any way. --Emu (talk) 16:55, 27 March 2023 (UTC)
    You are clearly dismissing differing opinions as "activist". Did you instead mean that as a compliment? If so could you clarify why you labeled these opinions as activist and not others? Gamaliel (talk) 17:03, 27 March 2023 (UTC)
    English isn’t my native language but I’m pretty sure that there is a third possibility beyond dismissive and as a compliment. If I understand your intentions correctly, you want to delete most sex or gender (P21) statements for living people. Sounds like activism to me. --Emu (talk) 22:49, 27 March 2023 (UTC)
    Now who is putting words in people's mouths? I never actually expressed an opinion one way or the other on gender statements on items for living people. I merely object to dismissing as "activism" someone raising valid concerns about living individuals. Please try discussing the concerns instead of labeling other editors. Gamaliel (talk) 02:02, 28 March 2023 (UTC)
    It follows e contrario from your statement on 02:48, 27 March 2023. But I’m glad that you aren’t actually trying to get rid of all unsourced sex or gender (P21) statements of living people. I’m still not quite sure what’s wrong with activism and why it’s wrong to label activism as such, but it might be a cultural thing, so I’ll try once again: Calling somebody an American activist librarian wasn’t meant to be an attack. I would also be very hesitant to call something consensus, if it’s mostly based on the opinions, say, Indian conservative lawyers or Spanish conformist teachers. --Emu (talk) 10:40, 28 March 2023 (UTC)
    I'm glad it wasn't an attack, but I don't understand what the point of your comment was if it wasn't. Can you explain the purpose of your labeling it activism and how this "activist" proposal is different from other suggestions on this page? Gamaliel (talk) 12:50, 28 March 2023 (UTC)
    could we find consensus to allow this kind of editing for the dead? that way BLP concerns are resolved? All bulk edits have some error rate so that there are errors at all isn't a great argument. BrokenSegue (talk) 02:40, 27 March 2023 (UTC)
    This seems reasonable. Nobody is going to find and add sources for the gender of thousands of dead politicians and sportspeople, but it's very useful to have this data remain. Gamaliel (talk) 02:48, 27 March 2023 (UTC)
  • I would be more offended of being stripped of my ethnicity, religion, and gender, than the very small risk of having it misattributed. I offered a solution, to not use the given_name heuristic for humans where they are part of the Wikiproject:LGBTQ, that would eliminate the source of most of the errors. We went through this is in the past and started a temporary purge of religion and ethnicity, based on good intentions, but with a bad outcome, where even rabbis and reverends were stripped of their religion, if there was no reference. --RAN (talk) 00:44, 27 March 2023 (UTC)

Let's clean up privacy violations

Criminal convictions and medical diagnosis are both highly sensible and thus we have them at protection class property that may violate privacy (Q44601380) for convicted of (P1399) and medical condition (P1050). Currently, we have a lot of unsourced claims for those and such potentially highly evasive wrong statements on items for living people. I propose we delete all unsourced statements for the two. Does anyone have any objections? ChristianKl ❪✉❫ 20:16, 25 March 2023 (UTC)

You're conflating the concept of a 'privacy violation' with the concept of an unreferenced claim. The two are not the same. An unreferenced claim may not be a privacy violation. A referenced claim may be a privacy violation. So on that basis, I don't think blanket removal is a very good plan & so suggest that you do not do that. --Tagishsimon (talk) 21:07, 25 March 2023 (UTC)
@Tagishsimon property that may violate privacy (Q44601380) has a specific meaning according to our policy. It's not just that there's something with privacy going on:
The meaning of the class is: "Living individuals with records in Wikidata are for the most part not famous or celebrities; their privacy should be respected. Values for living individuals should generally not be supplied unless they can be considered widespread public knowledge or are openly supplied by the individual themselves (otherwise hidden supporting references are not sufficient). As an example, the fact that someone's address is accessible by looking at a domain name registration doesn't imply that it's considered widespread public knowledge for the sake of this policy."
I don't think unsourced statements meet this bar. ChristianKl ❪✉❫ 00:27, 26 March 2023 (UTC)
AIUI, "generally" is not synonymous with "always". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:04, 27 March 2023 (UTC)
Generally, means taht there are possible exceptions. But the nature of something being an expection means that there have to specific reasons why an individual statement is an expection. I see no reason why the claims we are talking about here would be exceptions to the general policy. ChristianKl ❪✉❫ 16:30, 27 March 2023 (UTC)
Please explain how your proposal that "we delete all unsourced statements for the two" (my emphasis) allows for the exceptions which you acknowledge may exist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 27 March 2023 (UTC)
I am just a humble country editor, but if these properties apply to living people and cannot be immediately sourced, they can, and should, definitely be removed, without question.
In terms of celebrities and the like, it seems that the most common source of medical conditions is the celebrity's own claims in interviews and such. This is actually a highly-unreliable way to gather medical information about someone. Just because the star of a film claims they have ADHD is not a good reason to shove it into wiki, even if it is allegedly sourced. Celebs often claim medical/psychological conditions for self-serving reasons, such as to become an activist raising money for research.
Politicians, being public figures, often have medical conditions published, to keep voters and constituents advised of their fitness to serve in public office, at least in these United States.
In terms of criminal convictions, again, being just a humble country editor, I know best of enwiki policy, which says public records can never be used to support statements about living people. So we cannot use court records, transcripts, proceedings, mugshots, etc. Of course, if it hits the news, then that would seem adequate for inclusion. Elizium23 (talk) 21:50, 25 March 2023 (UTC)
Generally speaking, I agree that unsourced claims of this nature should be removed, especially in the case of living people, as per WD:BLP; I support the original proposal. I think that @Tagishsimon may be right in the sense that ‘privacy violation’ might not be the best umbrella term to use in these instances, but I don’t necessarily see how that leads to the whole idea of the cleanup not being valid.
As for what @Elizium23 said regarding public records used on items of living people, enwiki policy is not Wikidata policy; I would strongly discourage anyone from removing sources just because they happen to be public records. There is a reason – or rather, a good amount of reasons – why this project has different policies from enwiki. --Blua lago(let's have a chat y'all) 22:35, 25 March 2023 (UTC)
what if we only do this for people we are sure are still alive (or plausibly alive)? I'm not aware of Wikidata having a particular "living person's policy" but maybe we should? BrokenSegue (talk) 02:21, 26 March 2023 (UTC)
oh also in the past people have removed referenced statements whose references was to Wikipedia. Generally I'm more skeptical of such removals. BrokenSegue (talk) 02:22, 26 March 2023 (UTC)
Wikipedia is most certainly not a reliable source for these kind of sensitive topics. You are supposed to use the references at the bottom for a reason Trade (talk) 13:39, 27 March 2023 (UTC)
I'm surprised that you are not aware of our living people policy, but we do have it. And it was referenced earlier in this topic. The unclarity suggests that we might make that policy clearer, but we do have it. ChristianKl ❪✉❫ 15:21, 26 March 2023 (UTC)
Previously we had cases when people removed statements imported from Wikipedia just because such statements were imported from Wikipedia. However, there removals did not take into account the fact that almost every Wikipedia edition has its own BLP policies (often more strict than in Wikidata). So the original proposal so far is equivalent to you writing a bot that will edit articles in all Wikipedia languages and unconditionally delete all information, whether or not it is backed up by references there. Instead of rushing to extremes, I suggest a safer way: 1) you open the article 2) you make sure the statement has sources (they should, according to local BLP policies) 3) you add a better source to the Wikidata element. At the same time you get a great opportunity to correct errors in Wikipedia, if you find them (which, of course, is unlikely). --Lockal (talk) 17:00, 26 March 2023 (UTC)
I agree with Lockal, we stripped people of their ethnicity and religion in previous purges if they lacked a reference, instead of the proper looking for, and importing a reference. We had reverends and rabbis have their religion removed, because they had no reference, or were imported from Wikipedia. There is also an ongoing debate about stripping gender completely from Wikidata. Gender based on our heuristic given_name model was just reverted over the weekend, which I also think was wrong. I would be more offended of being stripped of my ethnicity, religion, and gender, than the very small risk of having it misattributed. --RAN (talk) 00:44, 27 March 2023 (UTC)
@Richard Arthur Norton (1958- ), I have found it extraordinarily difficult to find references to support the assertion that African-American people are African-American. The popular press treats it as a "sky is blue" given fact and generally does not explicitly say that African-Americans are thus (or Black or whatever the appropriately-deemed adjective should be.) Indeed, many thousands more are poised to be 'stripped of ethnicity' unless reliable sources can be found for that ethnicity. And it's a sensitive subject. People often retort "just look at the picture!" as if race is judged on appearance in these cases. 🤷🏻‍♂️ Elizium23 (talk) 00:57, 27 March 2023 (UTC)
I don't believe that criminal convictions are treated by the press as as a "sky is blue" given facts. These two cases seems for me to be quite different Trade (talk) 13:51, 27 March 2023 (UTC)
There's the question of notablity of private information. If the press consider it not important to write about whether or not someone is African-American, maybe it's not considered a notable fact about the given individual. While I generally like being inclusive of information on Wikidata that doesn't go for private information of living people. Private information that's not notable doesn't have to be on Wikidata. ChristianKl ❪✉❫ 17:13, 27 March 2023 (UTC)
"There is also an ongoing debate about stripping gender completely from Wikidata"? Where? BrokenSegue (talk) 02:27, 27 March 2023 (UTC)
@Richard Arthur Norton (1958- ) The Living People policy lays out exactly what you are supposed to do when you think that a protection status should not exist at a given property in Wikidata:Living people#Adding and removing Q44597997 and Q44601380 from properties. If you read the policy I think it's obvious that the bot job for inferring gender did not validate that the values are "widespread public knowledge or are openly supplied by the individual themselves" as is necessary for that protection class. If you don't want that standard, follow the guidance of how to remove that standard for the gender property. ChristianKl ❪✉❫ 11:03, 27 March 2023 (UTC)
The reversal involved all humans, both living and dead, that is how it showed up in my watchlist. If you have a block of people you want to remain genderless, such as living people, you can add gender=unknown, and the bot will not use the heuristic. We can mark every record under the auspices of Wikiproject:LGBTQ as gender=unknown, to solve the problem. It is also clear that the data was filled by a bot, they get marked as filled in by a heuristic. If would be more offended by being stripped of my gender than the very, very small chance that I may be misgendered. --RAN (talk) 16:19, 27 March 2023 (UTC)
@Richard Arthur Norton (1958- ) That's an argument for why property that may violate privacy (Q44601380) is not appropriate for the gender property. As I said, if you think so, the policy lays out the step to do something about that. ChristianKl ❪✉❫ 16:41, 27 March 2023 (UTC)
Again, the reversal involved both living and dead. Dead people are not covered by the policy, and have no protections of their privacy, except the wooden box that contains their decaying remains. I am repeating myself multiple times here, the bot can be run and exclude living people, where there is no death date and they are less than 120 years old. We can also mark living people as gender=unknown, as a more extreme measure to ensure no one feels the need to add gender without a reference. Maybe we should just hear from other contributors, we are just repeating our opinions over and over. --RAN (talk) 16:56, 27 March 2023 (UTC)
It's very unclear to me, why you don't want to use the channels that exist to deal with the issue and instead want to ignore the policy. If you want to argue for a bot doing a task, there's the bot approval process for that. ChristianKl ❪✉❫ 12:15, 28 March 2023 (UTC)
@ChristianKl, there is already a whole set of open topics seeking for consensus (this one, [2], [3], [4]) if not for excluding P21 from this rule, then at least agree for specific exceptions. For example, it is linguistically impossible to write a meaningful article in ruwiki without mentioning gender (or mentioning that gender is unknown). It is hardcoded in the language to the point that you can set up a constraint that gender must be specified (maybe to somevalue) for every ruwiki-Q5 item. Mass-deletion of unsourced (or Wikipedia-sourced) gender statements should be considered as vandalism as it corrupts infoboxes there (as occupations and categorization system there uses gender-specific forms). Inferring gender from ruwiki pages will always be the part of reality, it is not even "IAR", it is common sense.
Anyway, if you have any opinion regarding the topic - please share. Your previous comment does not add anything substantial. Lockal (talk) 13:00, 28 March 2023 (UTC)
@Lockal our living people policy describes a specific process for removing property that may violate privacy (Q44601380) from properties. Neither of those discussions you link to follow the process that could remove it. They all take as a given that sex or gender (P21) has property that may violate privacy (Q44601380).
The living people policy have the consensus of having gone through an RFC. If you have a discussion somewhere that every ruwiki-Q5 item has to have a gender statement and that discussion didn't go through an RFC it does not overrule our living people policy. ChristianKl ❪✉❫ 13:48, 28 March 2023 (UTC)

thepeerage.com

At Talk:Q75926183 I have requested of User:Nikkimaria a link to a discussion where "consensus was reached that thepeerage.com is not to be used as a source on Wikidata". She has been unable (or unwilling) to provide one, but nonetheless insists on repeatedly removing the site as a source from that item (which I created, and where her only involvement appears to be the removal or replacement of that source). She does not appear to dispute the statement for which the site is a source. Her only response on that point was to refer to a proposed guideline on en.Wikipedia. My own searches also find no such agreement.

Am I right in thinking that:

  1. there is no prohibition on Wikidata, preventing us from citing thepeerage.com
  2. this project is not bound by proposed en.Wikipedia guidelines ?

I note that there is no edit filter in place preventing the use of thepeerage.com as a source on this project.

Naturally, I shall be quite happy to cease using the site as a source here, if it can be shown that such consensus has been reached. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:25, 27 March 2023 (UTC)

@Nikkimaria: where do you think such a consensus was reached? ChristianKl ❪✉❫ 12:29, 27 March 2023 (UTC)
For the purposes of identifying what sources are or are not considered reliable, Help:Sources directs us to Wikidata:Verifiability which in turn directs us to en:Wikipedia:Reliable_sources#Questionable_and_self-published_sources. That page indicates that self-published sources (like this one) are generally unreliable. I note that the absence of an edit filter preventing an action does not mean that action is the best choice. In this case, given that there are multiple more reliable sources available for the datapoint in question, replacing the unreliable source with one of them improves the quality of the item. I have yet to see a rationale for reverting that. Nikkimaria (talk) 21:41, 27 March 2023 (UTC)
Help:Sources never went through a consensus finding process like an RFC. We have plenty of discussions that find consensus on whether or not certain claims should be added and removed and that consensus does often not tend to be in line with the standard writting down in those pages. ChristianKl ❪✉❫ 15:31, 28 March 2023 (UTC)
The RfC on references and sources closed with the conclusion that Help:Sources is an official site guideline. I'm not aware of any RfC since then that found consensus to change that? Nikkimaria (talk) 02:53, 29 March 2023 (UTC)
  • If you want to make an objective determination of reliability, you have to measure error rates and use the same measurement on the database in question and the gold standard like VIAF and LCCN and Wikidata itself. You can look at rate of duplicate entries, rate of conflation, the number of people who lived more than 120 years, and number of people who died before they were born. We use the same queries to look for errors in Wikidata. Just because something is crowdsourced or is the product of a single person, does not make it inherently unreliable. You can also look internally at Wikidata to see which sources have the most deprecated values. We recently imported data from an external database that had multiple transposed numbers in birth dates and death dates, caused by the typist. Many numbers meant to be 1800 or 1900 were typed in as the wrong century. --RAN (talk) 19:55, 28 March 2023 (UTC)

Merge request.

Could someone do a proper merge of Lobo River (Q35336444) and mouth of Lobo River (Q31807509)? Thanks. Abductive (talk) 23:45, 27 March 2023 (UTC)

 Not done: @Abductive: cebwiki has two standalone articles Estopedist1 (talk) 06:39, 28 March 2023 (UTC)
That's unlikely to reflect reality. Coordinates (before I improved them) on one pointed upstream of the other. Abductive (talk) 06:44, 28 March 2023 (UTC)
@Abductive: That doesn't matter. It is impossible to merge two wikidata items while the same wiki has two different articles. The "problem" (assuming this is an error) needs to be fixed at cebwiki before we can merge here. From Hill To Shore (talk) 07:45, 28 March 2023 (UTC)
This is a typical case of erroneous data from GeoNames imported to cebwiki by w:Lsjbot, cf. [11], [12]. Do we have a workflow for this with people who have sysop rights in ceb.wikipedia? --Tolanor (talk) 08:07, 28 March 2023 (UTC)
One item is about the whole river and the other item is about the mouth of the river. CebWiki has items for both. While you can argue that we don't really need an item for the mouth if we already have one for the whole river it's not a clear case of doublicated data.
I created https://www.wikidata.org/wiki/Wikidata:WikiProject_Territorial_Entities/Geonames_and_CebWiki a while ago to document the current state and we don't have an established workflow to deal with it. ChristianKl ❪✉❫ 12:30, 28 March 2023 (UTC)
Interesting. This solves my small problem of where to add the interwiki link. Abductive (talk) 18:56, 28 March 2023 (UTC)

We need a comment field

Hello, I’m sure this has been discussed 100 times already – I don't really know where these discussions take place. But still, the absence of a comment section in which I can add a quick source or comment on why I chose to make certain decisions in data sorting is a big problem for a variety of reasons. For example, where do I now state my reasons for separating Q107166203 from Q117317055? The reason is that Margarete Stargardt was a resident of Breslau in 1931, while Margarete Stephan was a resident of Rüdersdorf-Hennickendorf. I have sources for both, but they don't know anything about each other. So I have no direct source for stating that they are not the same, it's just my current conclusion. Where do I explain my reasoning and doubts? Best, Tolanor (talk) 04:39, 28 March 2023 (UTC)

@Tolanor: This information, if you wish to add it, should go on an item's talk page (e.g. Talk:Q117317055 or Talk:Q107166203). Mahir256 (talk) 04:41, 28 March 2023 (UTC)
Okay, thanks, that’s a workaround. But unfortunately it doesn't solve the general issue I bring up: the missing comment function makes it near impossible for casual users of Wikidata to add sources and comments that could increase data quality. I've been on Wikidata for some time, but even I cannot know all the absurd ways in which to construct data in absence of a field (even if I know the names of all the qualifiers, "speaking in qualifiers" is still often less precise than explaining something in language). How would casual users handle this – say, an author of a Wikipedia article who knows all the sources and intricacies of his subject but not of Wikidata? This person's info could be really important, but they will give up after 1 minute. This surely has been discussed at some point? --Tolanor (talk) 05:06, 28 March 2023 (UTC)
There is comment (DEPRECATED) (P2315) in case you didn't find it. Midleading (talk) 17:04, 28 March 2023 (UTC)
Wikidata is a multilangual project where it's not a given that users that edit an item share a common language. Expressing data in terms of structured data allows users of different languages to read it. For those cases where you want to express something in natural language there's still the talk page.
We do have based on heuristic (P887) to express common reasons and you could make up new items for heuristics you use. ChristianKl ❪✉❫ 12:26, 28 March 2023 (UTC)
Just echoing the above - use the Talk page or qualifiers, we do not want an unstructured "comment" field, this has indeed been discussed many times in the past. ArthurPSmith (talk) 13:28, 28 March 2023 (UTC)

All caps name on Game Freak (Q782028)

The English label was in normal name case "Game Freak" before a user changed it to all-caps, likely it's the official name. Should I revert to normal name case ("Game Freak") as I think its more commonly used? This can be comparable to the all-caps name on the ASUS (Q152864), as I think its probably 50/50 usage between all-caps and normal case. Stylez995 (talk) 15:00, 27 March 2023 (UTC)

The linked Wikipedia article is about Game Freak Co., Ltd. If we go at the homepage we find GAME FREAK inc as the name. Is the Wikipedia article here just wrong about the "Co., Ltd"? Or are they two distinct legal entities here? ChristianKl ❪✉❫ 12:39, 28 March 2023 (UTC)
It's quite common for Japanese entities to use idiosyncratic capitalization; this particular company isn't very consistent with their own name, never mind their titles, but I've always read it as uppercase + "inc." in all game credits/manuals I recall; Japanese Wikipedia says it's a Kabushiki Kaisha which is conventionally translated as "Co. Ltd." but immediately follows it with their international name which matches what ChristianKL found! --5.94.43.78 22:03, 29 March 2023 (UTC)

Problem on Reasonator

On reasonator, under Christian Bourdeille, (Q79975393), I read "created by Q115253832" (Uranoscope de l'Ile de France). In fact Christian Bourdeille created the Uranoscope, (not the opposite!).

. Io Herodotus (talk) 17:46, 22 March 2023 (UTC)

Anachronistic place of residence

Georg Eppenstein (Q28871955) lived 1867-1933, user:MB-one uses batch editing and adds "Treptow-Köpenick" and qualifier "end time 20. century" [13]. But Treptow-Köpenick (Q158089) has inception = 1 January 2001.

I think this should not be done. If one adds places that didn't exist at time when the subject existed, where would one stop? Add residence=Roman Empire to current members of the French national assembly? GeoGQL (talk) 20:33, 29 March 2023 (UTC)

You are right, this statement is a bit misleading. You are welcome to correct it. MB-one (talk) 06:54, 30 March 2023 (UTC)
Can you elaborate on "this statement is a bit misleading."? I didn't say that, did I? Following common English language it is wrong. On your user page it says residence = Berlin (Q64). Would you say residence = Holy Roman Empire "is a bit misleading"? GeoGQL (talk) 15:34, 30 March 2023 (UTC)

Are properties symmetrical?

Hello everyone! Coming from MusicBrainz, where creating a "relation" between two entities always leaves a backlink (e.g. "song X's composer is A" → A's page now fully automatically mentions X), I'm having trouble understanding if this is the case on Wikidata: for instance I just added "named after/yoke" to deflection yoke (Q322355) but if I follow the link there's nothing suggesting the inverse relationship. Is this normal and, if yes, should it manually be created? Thanks in advance! --5.94.43.78 22:34, 29 March 2023 (UTC)

Its generally discouraged to introduce symmetrical relationships, because the SPARQL query language can extract the information both ways. There are a few exceptions for ease of human reading, but generally saying "A named after B" is sufficient as a query can tell you what B's have things named after them. Vicarage (talk) 22:58, 29 March 2023 (UTC)
For most one-to-many relations, inverse relations are virtual and represented by inverse label item (P7087) statements (example). You can see such "virtual" relations using external script and tools like relateditems gadget, SQID or Reasonator. Lockal (talk) 06:40, 31 March 2023 (UTC)
Thank you both! --5.94.43.78 13:22, 31 March 2023 (UTC)

Merge defense industry and arms industry?

Looks the same to me, but certainly worth a second opinion. There are different articles in fa: and pt: wikipedias, all other entries are unique (thus mergeable). Retired electrician (talk) 15:00, 30 March 2023 (UTC)

It can't be merged because there are conflicting articles in pt. Right? BrokenSegue (talk) 15:26, 30 March 2023 (UTC)
Defence industry seems to include providers of goods or services other than military equipment, or that are not manufacturers. I think it could also include private military companies/contractors (Q1057214). Peter James (talk) 11:58, 31 March 2023 (UTC)

MediaWiki:Wikibase-SortedProperties not updated since 2023-03-05

[14] - can someone do that? New IDs are currently sorted at the end instead of being sorted alphabetically. That is bad for editing since e.g.

  1. OpenStreetMap relation ID (P402)
  2. OpenStreetMap way ID (P10689)
  3. OpenStreetMap node ID (P11693) - created 2023-03-24

are not sorted next to each other. Requests at MediaWiki talk and User talk without reply or resulting implementation. GeoGQL (talk) 12:21, 29 March 2023 (UTC)

I have run the script but not yet worked on the edit requests. --Ameisenigel (talk) 21:56, 29 March 2023 (UTC)
That way good engough, edit request on talk withdrawn [15]. GeoGQL (talk) 15:28, 30 March 2023 (UTC)
Can you have a look at the following two, which are maybe easy and not controversial?
  1. MediaWiki_talk:Wikibase-SortedProperties#Move_Inequality-adjusted_Human_Development_Index_(P11593)_to_just_below_Human_Development_Index_(P1081)
  2. MediaWiki_talk:Wikibase-SortedProperties#VIAF-related_IDs_-_sort_alphabetically_and_use_numbered/HTML_ordered_list
GeoGQL (talk) 15:27, 31 March 2023 (UTC)

Wikimania 2023 Welcoming Program Submissions

Do you want to host an in-person or virtual session at Wikimania 2023? Maybe a hands-on workshop, a lively discussion, a fun performance, a catchy poster, or a memorable lightning talk? Submissions are open until March 28. The event will have dedicated hybrid blocks, so virtual submissions and pre-recorded content are also welcome. If you have any questions, please join us at an upcoming conversation on March 12 or 19, or reach out by email at wikimania@wikimedia.org or on Telegram. More information on-wiki.

 – The preceding unsigned comment was added by MediaWiki message delivery (talk • contribs) at 15:44, 13 March 2023 (UTC).

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2023/03&oldid=1937432795"