On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/09.
SpBotarchives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days.
Hi, please have a look at [1]. The values for the two coordinate location (P625) are almost the same (+- 4 meters), but the value displayed in D/M/S format differs a lot (by ~40"N and ~20"E). The real difference is the different precision. It is strange when we add the same decimal value but get quite different values in D/M/S format. I consider this to be a flaw. --Herzi Pinki (talk) 16:44, 21 August 2024 (UTC)[reply]
That's because of the precisions. In Wikibase, the precision determines how precisely the coordinates should be displayed. Without it, it doesn't know whether a value of "1" is intended to be to the nearest degree (i.e. 1°), the nearest minute (i.e. 1° 0'), or even the nearest 0.001 seconds (i.e. 1° 0' 0.000"). A precision of 0.013482119238374° means to the nearest 48.5 seconds, approximately, so that's what it rounds it to. The result is strange because the data itself is strange.
Here's your quick overview of what has been happening around Wikidata over the last week. This is the Wikidata summary of the week before 2024-08-26. Please help Translate.
Discussions
Open request for adminship:
Gwanki - RfP scheduled to end after 26 August 2024 05:54 (UTC)
Putnik 2 - RfP scheduled to end after 27 August 2024 23:17 (UTC)
Audio Transcription (P9533) from Author: Yug. P9533 is described as transcription of the word/text being spoken in this file. Does this exclude other communications modalities?
Wikidata's 12th Birthday is fast approaching. Do you need financial support to organize a birthday event? Here is some useful information about how to get funding: Wikidata:Twelfth Birthday/Run an event/Funding. The deadline to apply is September 1st.
WikiLibCon25 The Wikimedia+Libraries International Convention 2025 takes place in Mexico City, Mexico between 15 - 17 January 2025 - Call for Scholarships (ends 31 August0 and Proposals (ends 15 September) are open. WikiLibCon25 brings together Wikimedians, Wikibrarians, information professionals, library workers and mission-aligned partners from around the globe to create a vivid community and promote cooperative projects in the Library & Wikimedia sphere.
Slides: Giving metabolites (and lipids) a chemical and biological context with open science. This talk discusses the role of open science in providing chemical and biological context for metabolites and lipids, highlighting open-source cheminformatics, open standards, and open data to facilitate linking knowledge across databases and publications, as well as describing chemical interactions in biological pathway databases. By Egon Willighagen.
Wikidata distributed/#game=94 - Help adding missing information related to artists on BNU's catalog (Select the option that fits best).
Other Noteworthy Stuff
New AI Project Manager to join Wikimedia Deutschland: We’re pleased to announce that a new AI project manager will be joining our team next week. Lydia and Jonathan (Director of Engineering) have been prototyping in this area and recently presented their work at the AI_dev summit (YouTube link). Our goal is to bring knowledge graphs and generative AI closer together, making AI more equitable, truthful, participatory, and open. More updates to come soon!
Googles Dictonary suggests that acting the in the pursuit of political aims is part of the definition of what makes someone a terrorist. ChristianKl ❪✉❫ 15:29, 2 September 2024 (UTC)[reply]
Ambazonia (Q2842000) has quite a ton of missing info.
The presidents for example, need to have things identifying that they are "The President of the Interim Government". Remember, there are many factions. Also, you gotta have two new presidents in the "head of state" section; Marianta Njomia and Chris Anu.
And also, you need to add the vice presidents of the four. Dabney Yerima for Ayuk Tabe, Eric Ateh for Sako, Hariscine Abongwa for Marianta, and Rev Njini for Chris.
Since we're assuming that that page is just for the Interim Government and nobody else, there are three sites you need to put in there: "statehousebuea.org" for Sako, "federalrepublicofambazoniagov.org" for Marianta, and "ambazoniagov.org" for Chris Anu. Make it so that the link to ambagov.org leads to an archive of the page too.
People also seem to sometimes erroneously call the Interim Government's state not as the Federal Republic of Ambazonia, but as the Republic of Ambazonia. Not to be confused with the faction "Republic of Ambazonia". Gotta add that to the "also known as" part of the page.
The emblem of Ambazonia shouldn't be here too. I've read the constitution and I can provide an exerpt from it, Article 4, Section 4: "The national coat of arms shall be an escutcheon supported by two crossed fasces with the motto 'JUSTICE-UNITY-DEMORACY'. The escutcheon shall be composed of two gold stars and triangle gules, charged with the geographical outline of Ambazonia in azure and surcharged with the scales of Justice." (hold on, did copy-pasting this exerpt from the constitution break the rules?) And guess what, Sako changed the coat of arms of the interim government at the start of 2024, and the constitution Sako made isn't even ON the web.
So since the two coat of arms of the IG haven't been uploaded to Wikicommons yet, let's just use the seals of the Interim Government.
Ambazonia also left the UNPO in 2021, it seems.
But everything else seems fine. Please try to edit the things described in this post into the Ambazonia Wikidata page. Thanks. Kxeon (talk) 13:36, 10 August 2024 (UTC)[reply]
@Wüstenspringmaus: Wikidata operates under the Open-world assumption - "lack of knowledge does not imply falsity", or in other words, every item in Wikidata is missing info. But it's also a wiki. Editing should be done by people who are knowledgeable on the subject. Is there some reason why you are unable to add this information yourself? ArthurPSmith (talk) 17:28, 28 August 2024 (UTC) @Kxeon: sorry, I pinged the wrong person there. ArthurPSmith (talk) 17:29, 28 August 2024 (UTC)[reply]
The usage of this property differs from language to language. Looking at USA and UK, some write their form of "USA", while others write "United States" (hence UK and United Kingdom). I'm looking for a more or less reliable field to retrieve a short name (not an abbreviation!) and I'm asking myself if this would be the one, I could use for that. UK I would rather expect at international license plate code or something. I changed it for English and German in the UK and the US, but now I start to worry, that this might cause problems elsewhere. I would also like to change the value at Holy Roman Empire to Holy Roman Empire instead of HRE. Any advice on the topic? Flominator (talk) 05:10, 29 August 2024 (UTC)[reply]
Also states, like Kentucky, use it as KY, where I would have expected just "Kentucky" as opposed to the official name "State of Kentucky". Of course, I could also use the label, but that would be another API call. The claims I already have at hand at that point. --Flominator (talk) 05:35, 29 August 2024 (UTC)[reply]
Its aliases "acronym" and "initialism" do make it ambiguous. Splitting off an "acronym" property might be best. Mind you, that wouldn't help the OP who naturally refers to USA and US in their post, as we all do, UK/GB are a muddle, and you'd code UK as both a short form and an acronym, and no-one has attempted to unravel Foreign, Commonwealth and Development Office (Q358834) !! Vicarage (talk) 08:22, 29 August 2024 (UTC)[reply]
Actually, it would help him a lot, because he could go then and set "United States" and "United Kingdom" as value for this property without getting his butt kicked (or at least to defend himself with a line of argumentation, in case it happens anyway). Flominator (talk) 09:01, 29 August 2024 (UTC)[reply]
That proposal was very confused. What we'd want is 'initialism' ('acronym' is a a pronounceable word), but as Michael Caine would say, not a lot of people know that. But its not something that impacts me. Vicarage (talk) 16:52, 29 August 2024 (UTC)[reply]
OMG, that's bad. I can't believe they did this. It works, but it goes against Wikidata's philosophy and creates a boatload of items which have no other function than to "hold" the value. At least they didn't create a new one for each census, just for each settlement-ethnic group combination :). And I see no point whatsoever in modelling it this way, compared to the solution above. I might write to the North Macedonia Wikidata community and propose to harmonize the representation and free up several hundred thousand precious triples in the graph. --Nikola Tulechki (talk) 17:50, 29 August 2024 (UTC)[reply]
@So9q: 100 items over what time span? But I agree there should be some numeric cutoff to item creation (or edits) over a short time period (day, week?) that triggers requiring a bot approval at least. ArthurPSmith (talk) 00:32, 1 September 2024 (UTC)[reply]
QuickStatements sometimes returns the error message Cannot automatically assign ID: As part of an anti-abuse measure, this action can only be carried out a limited number of times within a short period of time. You have exceeded this limit. Please try again in a few minutes.
Let me give you an example: I recently imported less than 100 banks when I added Net-Zero Banking Alliance (Q129633684). I added them during 1 day using OpenRefine.
Thats ok. It's a very limited scope, we already had most of the banks. It can be discussed if the new banks which are perhaps not notable should have been created or just left out, but I did not do that as we have no policy or culture nor space to talk about imports before they are done. We need to change that.
Other examples:
Importing all papers in a university database or similar totaling 1 million items over half a year using automated tools is not ok without prior discussion no matter if QS or a bot account was used.
Importing thousands of books/monuments/whatever as part of a GLAM project over half a year is not ok without prior discussion.
Importing all the bridges in the Czech Republic e.g. Q130213201 during whatever time span would not be ok without prior discussion. @ŠJů:
Importing all hiking paths of Sweden e.g. Bohusleden (Q890989) over several years would not be ok.
etc.
The intention to import many object without prior community approval is what matters. The community is your boss, be bold when editing but check with your boss before mass-imports. I'm pretty sure most users would quickly get the gist of this policy. A good principle could be: If in doubt, ask first. So9q (talk) 05:16, 1 September 2024 (UTC)[reply]
@So9q: I'm not sure that the mention of individually created items for bridges belongs to this mass import discussion. There exist Wikidata:Notability policy and so far no one has questioned the creation of entries for physically existing objects that are registered, charted, and have or may/should have photos or/and categories in Wikimedia Commons. If a community has been working on covering and processing any topic for twenty years, it is probably not appropriate to suddenly start questioning it. I understand that what is on the agenda in one country may appear unnecessarily detailed in another one. However, numbered roads, registered bridges or officially marked hiking paths are not a suitable example to question; their relevance is quite unquestionable.
The question of actual mass importation would be moot if the road administration (or another authority) published the database in an importable form. Such a discussion is usually led by the local community - for example, Czech named streets were all imported, but registered addresses and buildings were not imported generally (but individual items can be created as needed). Similarly, the import of authority records of the National Library, registers of legal entities, etc. is assessed by the local community; usually the import is limited by some criteria.. It is advisable to coordinate and inspire such imports internationally, however, the decision is usually based on practical reasons, i.e. the needs of those who use the database. It is true that such discussions could be more transparent, not just separate discussions of some working group, and it would be appropriate to create some formal framework for presenting and documenting individual import projects. For example, creating a project page that will contain discussion, principles of the given import, contact for the given working group, etc., and the project page should be linked from edit summaries. --ŠJů (talk) 06:03, 1 September 2024 (UTC)[reply]
Thanks for chipping in. I do not question the notability of the items in themselves. The community in telegram has voiced the opinion that this whole project has to consider what we want to include and not and when and what to give priority.
Millions of our current items are in a quite sad state as it is. We might not have the man-power to keep the level of quality at an acceptable level as is.
To give you one example Wikidata currently does not know what Swedish banks are still in operation. Nobody worked on the items in question, see Wikidata:WikiProject_Sweden/Banks, despite them being imported many years ago (some are from 2014) from svwp.
There are many examples to draw from where we only have scratched the surface. @Nikki mentioned in Telegram that there are a ton of items with information in descriptions not being reflected by statements.
A focus on improving what we have, rather than inflating the total number of items, is a desire by the telegram community.
To do that we need to discuss imports whether already ongoing or not, whether very notable or not that notable.
Just as a side note, with no implications for the discussion here, but "The community in telegram has voiced" is irrelevant, I understood. Policies are decided here on the wiki, not on Telegram. Or? --Egon Willighagen (talk) 07:58, 1 September 2024 (UTC)[reply]
It is correct that policies are created on-wiki. However, it may also be fair to use that as a prompt to start a discussion here and transparent to explain if that is the case. It won't really carry weight unless the same people also voice their opinions here, but there is also no reason to belittle it just because people talked somewhere else. Ainali (talk) 08:13, 1 September 2024 (UTC)[reply]
+1. I'll add that the Wikidata channel is still rather small compared to the total number of active Wikidata editors (1% or less is my guess). Also the frequency of editors to chat is very uneven. A few very active editors/chatmembers contribute most of the messages (I'm probably one of them BTW). So9q (talk) 08:40, 1 September 2024 (UTC)[reply]
Terminology matters, and the original bot policies are probably not clear anymore to the current generation Wikidata editors. With tools like OpenRefine and QuickStatements), I have the impression it is no longer clear what is "bot" and what is not. You can now easily create hundreds of items with either of these tools (and possibly others) in a editor-driven manner. I agree it is time to update the Wikidata policies around important. One thing to make clear is the distinction mass creation of items and mass import (the latter can also be mass importing annotations and external identifiers, or links between items, without creating items). -- Egon Willighagen (talk) 08:04, 1 September 2024 (UTC)[reply]
I totally agree. Since I joined around 2019 I have really struggled to understand what is okay and not when it comes to mass-edits and mass-imports. I have had a few bot requests declined. Interestingly very few of my edits have ever been questioned. We should make it simple and straightforward for users to learn what is okay and what is not. So9q (talk) 08:43, 1 September 2024 (UTC)[reply]
I agree that we need an updated policy that is simple to understand. I also really like the idea of raising the quality of existing items. Therefore, I would like the policy to recommend that, or to even make an exception for preapproval if, there is a documented plan to weave the imported data into the existing data in a meaningful way. I don't know exactly how it could be formulated, but creating inbound links and improving the data beyond the source should be behavior we want to see, whereas just duplicated data on orphaned items is what we don't want to see. And obviously, these plans need to be completed before new imports can be made, gaming the system will, as usual, not be allowed. Ainali (talk) 08:49, 1 September 2024 (UTC)[reply]
@ainali: I really like your idea of "a documented plan to weave the imported data into the existing data in a meaningful way". This is very similar to the OSM policy.
They phrase it like so:
"Imports are planned and executed with more care and sensitivity than other edits, because poor imports have significant impacts on both existing data and local mapping communities." source
A similar phrasing for Wikidata might be:
"Imports are planned and executed with more care and sensitivity than other edits, because poor imports have significant impacts on existing data and could rapidly inflate the number of items beyond what the community is able or willing to maintain."
In general, any proposal that adds bureaucracy that makes it harder for people to contribute should start wtih explaining what problem it wants to solve. This proposal contains no such analysis and I do consider that problematic. If there's a rule 10,000 items / year seems to me more reasonable than 100. ChristianKl ❪✉❫ 15:37, 2 September 2024 (UTC)[reply]
Thanks for pointing that out. I agree. That is the reason for me to raise the discussion here first instead of diving right into a writing a RfC.
The community in Telegram seems to agree that a change is needed and has pointed to some problems. One of them mentioned by @Nikki: was: most of the manpower and time in WMDE for the last couple of years seem to be spent on trying to avoid a catastrophic failure of the infrastructure rather than improving the UI, etc. At the same time a handful of users have imported mountains of half-ass quality data (poor quality import) and show little or no sign of willingness to fix the issues pointed out by others in the community. So9q (talk) 08:49, 5 September 2024 (UTC)[reply]
There are many different discussions going on here on Wikidata. Anyone can open a discussion about anything if they feel the need. External discussions outside of Wikidata can evaluate or reflect Wikidata project, but should not be used to make decisions about Wikidata.
This discussion scope is a bit confusing. By mass import I mean a one-time machine conversion of an existing database into wikidata. However, the examples given relate to items created manually and occasionally over a long period of time. In relation to this activity, they do not make sense. If 99 items of a certain type are made in a few years, everything is fine, and as soon as the hundredth item have to be made, we suddenly start treating the topic as "mass import" and start demanding a previous discussion? That makes absolutely no sense. For this, we have the rules of notability, and they apply already for the first such item, they have no connection with "mass imports".
As I mentioned above, I would like to each (really) mass import have its own documentation project page, from which it would be clear who did the import, according to what policies, and whether someone is taking care of the continuous updating of the imported data. It is possible to appeal to mass importers to start applying such standards in their activities. It is also possible to mark existing items with some flags that indicate which specific workgroup (subproject) takes care of maintaining and updating the item. --ŠJů (talk) 18:06, 1 September 2024 (UTC)[reply]
Maybe using the existing "bot requests" process is overkill for this (applying for a bot flag shouldn't be necessary if you are just doing QS or Openrefine work), but it does seem like there should be either some sort of "mass import requests" community approval process, or as ŠJů suggests, a structural prerequisite (documentation on a Wikiproject or something of that sort). And I do agree if we are not talking about a time-limited threshold for this then 100 is far too small. Maybe 10,000? ArthurPSmith (talk) 22:55, 1 September 2024 (UTC)[reply]
There are imports based on existing identifiers - these should be documented on property talkpages (e.g. new mass import of newly created identifiers every month, usually using QS). Next big group is import of existing geographic features (which can be photographed) - these have coordinates, so are visible on maps. Some of them are in focus of few people only. Maybe document them in country wikiproject? JAn Dudík (talk) 15:49, 2 September 2024 (UTC)[reply]
My thoughts on this matter :
we indeed need a page (maybe a policy, maybe just a help page, a recommandation, a guideline, etc.) to document how to do good mass-import
mass-import should be defined in more precise terms, is it only creation? or any edits? (they are different but both could be problematic and should be documented)
100 items is very low
we are just the 2nd of September and 3 people already created more than 100 items ! in August, 215 people created 100 or more items, the community can't process that much
I suggest at least 1000, maybe 10 000 items (depends if we focus only on creations or on any edits)
no time span is strange, is it even a mass-import if someone create one item every month for 100 months? since most mass-import are done by tools, most are done in a small period, a time span of a week is probably best
the quantity is a problem but the quality should also be considered, also the novelty (it's not the same thing to create/edit items following a well know model and to create a new model rom scratch, the second need more review)
could we act on Wikidata:Notability, mass-import should be "more" notable? or at least, notability should be more thoroughly checked?
the 2 previous point are based on references which is often suboptimal right now (most imports are from one source only, when crossing multiple references should be encouraged if possible)
finally, there is a general problem concerning a lot of people but there is mainly a few power-user who are borderline abusing the ressources of Wikidata ; we should focus the second before burden the second, it would be easier and more effective (ie. dealing with one 100 000 items import rather than with 1000 imports of 100 items).
I have two points to make at this stage. Firstly, I think the limit of 100 items is way too low. To give an example from my own experience, when I created items for streets of some Warsaw boroughs using OpenRefine, there were usually around 200-300 items created per borough (and Warsaw has 18 of those). I find it more harmful than beneficial to force users to go through a lenthy process with that sort of scale of work. Secondly, I would like to see a written policy draft before giving my final opinion. From what I read here, I'm still not sure if it would be ok to create, let's say 150 items per day using, for instance, Mix'n'Match or Cradle, which are hardly automated tools. Powerek38 (talk) 15:54, 2 September 2024 (UTC)[reply]
I think when planning an import the key question to ask is "how many items would it be if replicated worldwide?" For streets, that would be a very large number, so I think there would be valid concerns about that. While I'd not argue for a moratorium on new ideas while we back-fill, we don't want hugely inconsistent data coverage, so a plan how the idea would be replicated systemwide is key. Vicarage (talk) 16:02, 2 September 2024 (UTC)[reply]
@Vicarage: it seems too restrictive to only think in term of instance of (P31). Not all streets are the same ; in some places, there is easily 2-3 good references even for small streets, in other places it's hard to find even one reference (same goes for other aspects, like do we already have items that needs this streets, like buildings located or people born there). The first should be imported, not the second. It's inconsistent if you look at the P31, but it's consistent if you look at data quality. Cheers, VIGNERON (talk) 16:42, 2 September 2024 (UTC)[reply]
Perhaps the 4000odd Warsaw streets were notable, but its probably an order of magnitude more than the notable inhabitants of such a historic city. Its one reason why a mass import needs to be documented to convince others of its merit. There is a danger that people sneak in trivial things under the 'structural need' argument, as part of pet project, and we get the inconsistent data quality neither of us want. Its a problem that bots can pour data in, but humans to decide on quality. Vicarage (talk) 17:01, 2 September 2024 (UTC)[reply]
I totally agree. I have never used a street item. Is there a WikiProject where streets are discussed as noteworthy of import? Are the current street items used by any other Wikimedia project?
The same goes for books and papers. Do we really want to import all books in existence? All papers ever published in scientific journals? I would say no. So9q (talk) 08:56, 5 September 2024 (UTC)[reply]
A lot of streets have a Commonscat, since there have been taken pictures and uploaded on Commons, some also have articles. According to Wikidata:Notability, street Objects with Commonscat and/or article(s) should be notable. Also see
In my opinion, items for streets are very useful, because there are a lot of pictures with categories showing streets. There are street directories. Streets often have their own names, are historically significant, buildings/cultural heritage monuments can be found in the respective street via street categories and they are helpful for cross-referencing. So please keep items for streets. Triplec85 (talk) 10:26, 5 September 2024 (UTC)[reply]
As streets are very important for infrastructure and for structuring of villages, towns, cities, yes, they are notable. Especially if we consider the historical value of older streets or how often they are used (in the real world). Data objects of streets can be combined with many identificators from origanizations like OpenStreetView and others. And they are a good element for categorizing. It's better to have images categorized in Hauptstraße (Dortmund) (with a data object that offers quick facts) than only Dortmund. Also, streets are essential for local administrations, which emphasizes the notability. And you can structurize where the street names come from (and how often they are used) etc. etc., with which streets they are connected etc. For me, I see many good reasons for having lists of streets in Commons, Wikidata, whatever; it gives a better overview, also for future developments, when streets are populated later or get cultural heritage monuments, or to track the renaming of streets... --PantheraLeo1359531 (talk) 10:37, 5 September 2024 (UTC)[reply]
Regarding the distribution / portion of content by type (e.g. scholary articles vs. streets / architectal structure) see this image:
Hello, from my point of view, there would be some questions regarding such a policy, like:
What is the actual goal of the policy? What is is trying to achive? How will this goal be achivied?
Is it only a recommendation for orientation (which easily can be ignored)?
Is this policy realized in a technical manner, so users are blocked automatically? Currently, for example QuickStatements already implements some policy and disables the creation of new objects with the error massage: Cannot automatically assign ID: As part of an anti-abuse measure, this action can only be carried out a limited number of times within a short period of time. You have exceeded this limit. Please try again in a few minutes. How will the new policy be different from the current anti-abuse policy?
Who will control and decide, if the policy if followed/ignored and how? What are the consequences if the policy is ignored?
Does this policy only include objects without sitelinks or also objects with sitelinks to any language version or project like wikisource, commons, wikivoyage, wikibooks, ...?
Does this policy only concern the creation of new objects or also the modification of existing objects?
How is quality defined regarding this policy? How and by whom will be decided if a user and/or user task is accepted for a higher limit?
There are always thousands of unconnected articles and categories in any language version and project (including commons), for example
Who will connect them to existing objects (if existing) or create new objects if not yet existing and when (especially, if there is a new artificial limit to create such objects)? Will someone implement and operate a bot for all 300 wikipedia language versions and all articles, all categories (including commonscats), all templates, all navigation items, ... to connect sitelinks to existing objects or create new objects if not yet existing?
From my point of view, time and ressources should be spent on improving processes and tools and help, support and educate people in order to improve data quality and completeness. For example, in my opionion the meta:AutosuggestSitelink-Gadget should be activated for all users on all language versions per default in the future.
Another questions: do we have the necessary resources to control such a policy or will there be some (maybe constantly growing) backlog like for example we had for property creation?
This wasn't written but when the discussion started here, but here is a summary of the growth of the databases, that this policy partly addresses: User:ASarabadani (WMF)/Growth of databases of Wikidata. There are also some relevant links on Wikidata:WikiProject Limits of Wikidata. For an extremely high overview summary, Wikidata is growing so quick that we will hit various technical problems and slowing down the growth (perhaps by prioritizing quality over quantity) is a way to find time to address some of the problems. So the problem is wider than just new item creations, but slowing that would certainly help. Ainali (talk) 08:09, 3 September 2024 (UTC)[reply]
Please note that "Cannot automatically assign ID: As part of an anti-abuse measure, this action can only be carried out a limited number of times within a short period of time. You have exceeded this limit. Please try again in a few minutes." is not a error message or limit imposed from QuickStatement; it is a rate limit set by Wikibase, see phab:T272032. QuickStatement should be able to run a large batch (~10k commands) in a reasonable (not causing infra issue) speed. If QuickStatements does not retry when rate limit is hit, I consider it a bug; batches should be able to be run unattended with error recovery mechanism GZWDer (talk) 14:50, 4 September 2024 (UTC)[reply]
I would echo the points raised above by M2k~dewiki. My feeling is that when we actually think about the problem we are trying to solve in detail, there will be better solutions than placing arbitrary restrictions on upload counts. There are many very active editors who are responsible and actually spend much of their time cleaning up existing issues, or enriching and diversifying the data. Many GLAMs also share lots of data openly on Wikidata (some exclusively so), helping to grow the open knowledge ecosystem. To throttle this work goes against everything that makes Wikidata great! It also risks fossilising imbalances and bias we know exist in the data. Of course there are some folks who just dump masses of data into Wikidata without a thought for duplication or value to the wider dataset, and we do need a better way to deal with this but I think that some automated checks of mass upload data (1000s not 100s) to look for potential duplication, inter connectivity and other key indicators of quality might be more effective at flagging problem edits and educating users, whilst preserving the fundamental principals of Wikidata as an open, collaborative data space. Jason.nlw (talk) 08:34, 3 September 2024 (UTC)[reply]
We definitely need more clarity on the guidelines, thanks for putting that up! Maybe we can start with some very large upper boundary so we can at least agree in the principle and enforcement tooling? I suggest we start with a hard limit for 10k new items / month for non-bot accounts + wording saying creation of over 1000 items per month should be preceded by a Bot Request if items are created based on the same source and any large scale creation of items (e.g. 100+ items in a batch) should be at least discussed on Wiki, e.g. on the related WikiProject. Also, I think edits are more complicated than new item creations; author-disambiguator.toolforge.org/, for example, allows users to make 100k edits in a year semi-manually. It may be a good idea for simplicity to focus only on item creation at this point. TiagoLubiana (talk) 21:00, 3 September 2024 (UTC)[reply]
Just a first quick thought (about method and not the content): apart from pings (which are very useful indeed), I think that the best place to make decisions on such an important matter would be an RfC; IMHO a RfC should be opened as soon as possible and this discussion should be moved to in its talk page, in order to elaborate there a full set of questions to be then clearly asked to the community. Epìdosis13:49, 4 September 2024 (UTC)[reply]
I don't really understand what the proposal here is or what problem it is trying to solve, there seem to be quite a number of things discussed.
That said, I am absolutely opposed to any proposal that places arbitrary limits on individual editors or projects for new items or edits simply based on number rather than quality of edits. I think this will be detrimental because it incentivises working only with your own data rather than contributing to other people's projects (why would I help another editor clean up their data if it might mean I go over my quota so can't do the work that is more important to me?).
And in terms of my own WikiProjects, I could distribute the new item creation to other editors in those projects, sure, but to what end? The items still get created, but with less oversight from the most involved and knowledgeable editor and so likely with greater variability in data quality. How is that a good thing? DrThneed (talk) 23:50, 4 September 2024 (UTC)[reply]
As someone involved in game development, especially with creative games like Toca Boca, I’ve been thinking about how we can better utilize Wikidata to support and enhance our projects. Wikidata’s structured data could be incredibly valuable for game developers, particularly when it comes to organizing in-game data, tracking character relationships, or even managing large amounts of game-related content.
For example, imagine using Wikidata to dynamically update in-game databases or to create more interactive and data-driven gaming experiences. This could also help in maintaining consistency across different game versions and localizations.
Has anyone here explored using Wikidata in game development, or do you have any thoughts on how we could leverage its capabilities in this field? I’d love to hear about any experiences or ideas you might have. Stephan0098 (talk) 22:33, 31 August 2024 (UTC)[reply]
@Stephan0098: I'm a bit sceptical if all of that data would meet our notability policy, especially if the game is not yet published. However, the software behind Wikidata (Wikibase) is free and open for everone to use and customize. I would encourage you to have a look at that :) Samoasambia✎00:58, 1 September 2024 (UTC)[reply]
I have a painting that is dated by the the museum as "1793 (1794?)", so it seems it was likely made in 1793 but there is a small chance that it was only made in 1794. When I type them both I get an error report. How to fix that? How to give one the preffered rank, I don't find a fitting field. Carl Ha (talk) 06:42, 1 September 2024 (UTC)[reply]
What should be do if we have a work where there is no consensus by art historians what the "preferred" dating is? The dating of Q570188 is disputed but Wikidata wants me to prefer one statement. Carl Ha (talk) 08:38, 2 September 2024 (UTC)[reply]
@Carl Ha I don't think Wikidata constraints are written in stone and the real world sometimes brings challenges that no constraint can predict. In this case, in my view, you can disregard the exclamation marks, just leave it as it is for now. Wikidata constraints are here to serve us, not the other way round. Vojtěch Dostál (talk) 06:38, 5 September 2024 (UTC)[reply]
Could we include things that have P31 as "icons" (Q132137) as this is a type of painting. I don't know how to include that technically in the wiki code. Carl Ha (talk) 08:36, 1 September 2024 (UTC)[reply]
I tried and now it seems that it just includes all elements including sculptures etc.
Would it be possible to have in the column "inventory number" has just the inventory numbers connected with Art Culture Museum Petrograd and not the ones connected with other institutions (in this case always the Russian Museum) that later owned the paintings? Because now it is not sortable after the inventory number of the Art Culture Museum. Thanks! Carl Ha (talk) 09:40, 1 September 2024 (UTC)[reply]
@GZWDer and @Dexxor , after deleting all the outdated data on Q83873387, my bot was able to link the article to the item using Pywikibot. I'm the reporter of the mentioned Phabricator ticket. I just wanted to mention that there is en:w:Template:COVID-19 data/data (see here for a clearer view of the data) updated daily by a bot, with the last update on 17 August 2024. I believe there will be no more updates from the endpoint. Thanks. Aram (talk) 19:27, 3 September 2024 (UTC)[reply]
Announcing the Universal Code of Conduct Coordinating Committee
I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:
North America (USA and Canada)
Ajraddatz
The following seats were not filled during this special election:
Latin America and Caribbean
Central and East Europe (CEE)
Sub-Saharan Africa
South Asia
The four remaining Community-At-Large seats
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.
Here's your quick overview of what has been happening around Wikidata over the last week. This is the Wikidata summary of the week before 2024-09-02.
Discussions
Project chat: Wikidata:Project chat#Mass-import policy - A new mass-import policy has been proposed, focusing on improving the quality of existing items rather than importing new ones, with a suggested limit of 100 new items before requiring community approval.
Next Linked Data for Libraries LD4 Wikidata Affinity Group session 3 September, 2024: We have our next LD4 Wikidata Affinity Group Session on Tuesday, 3 September, 2024 at 9am PT / 12pm ET / 17:00 UTC / 6pm CET (Time zone converter). Christa Strickler will be our first Project Series lead with her joint project with the Wikidata Religion & Theology Community of Practice to contribute biographical data to Wikidata from the IRFA database using the Mix’n’Match tool. We are excited to learn more about this project, provide a forum for discussion and shared learning, and lend a hand while building new skills. Event page: Wikidata:WikiProject LD4 Wikidata Affinity Group/Affinity Group Calls/First Project Series
(id) Registration is open for the Wikimedia Indonesia Research Grant 2024 program. Open until 30 September 2024. This program opens funding opportunities for research on topics related to Wikidata, Wikipedia, or other Wiki projects, and Linked Open Data.
Blogs: (de) Wikibase4Research - Easily manage, share and visualize knowledge data, tailored for academic purposes, WB4R simplifies the installation and use of MedaWiki software. By Kolja Bailly.
Display Wikidata Info on sister projects by User:Yair rand. This user-script will add the articles corresponding Wikidata item Label, Q-ID, Description and Short Desc. neatly under the article title. If no Wikidata item is linked, option to CreateNewItem page on Wikidata is provided.
Showcase Items: Wikimedia disambiguation page (Q4167410): type of wiki page usually in main namespace (article namespace, ns=0) containing links to articles with similar names, and very little details only, use with P31 "instance of" (2024-09-02)
The WMF Search Platform team is putting the finishing touches on the new Query Service servers that contain the two parts of the split graph.
We are analyzing which percentage of current queries are better served by other systems like the REST API or search.
Wikimedia projects integration:
We have worked on moving the Wikidata Item link out of the toolbox section of the sidebar of an article. It has been rolled out to the first wikis: ukwiki, hewiki, fawiki (phab:T66315)
We are working on decreasing the amount of irrelevant changes from Wikidata in the watchlist and recent changes on Wikipedia and co by correcting the tracking behaviour of the Lua function mw.wikibase.entity:getSitelink() (phab:T295356)
Wikibase REST API: We continued improving errors and error messages.
The Campaigns team at the Wikimedia Foundation is exploring how to expand it's work on campaigns, to support other kinds of collaboration. We are interested in learning from diverse editors that have experience joining and working on WikiProjects, Campaigns, and other kinds of on-wiki collaboration. We need your help:
Take a survey about your experience with collaborations: on Google Docs
The date of death of Q19695615 has now been changed to 1905[2]; the source says 20th September - is there a reason it should be 19th? I reverted the recent additions to Q107059238 - I would have moved them to a new item, but one of the references for a 1601 date of death is claimed to have been published in 1600, and the links don't work for me ("The handle you requested -- 21.12147/id/48db8bef-31cf-4017-9290-305f56c518e9 -- cannot be found"). Q5942448 just had an incorrect date (1474 should have been 1674 - I removed it and merged with an item that already had 1674). Peter James (talk) 13:07, 4 September 2024 (UTC)[reply]
Regarding Charles-Louis-Achille Lucas (Q19695615), the death certificate has been established on September 20, but the death happened the day before, on September 19. Ayack (talk) 14:46, 4 September 2024 (UTC)[reply]
We have that happen with obituaries all the time, people add the date of the obituary rather than the date of death. --RAN (talk) 19:17, 4 September 2024 (UTC)[reply]
We are now entering a transition period until the end of March 2025. The three SPARQL endpoints will remain in place until the end of the transition. At the end of the transition, https://query.wikidata.org/ will only serve the main Wikidata subgraph (without scholarly articles). The query-main and query-scholarly endpoints will continue to be available after the transition.
I would very much like to avoid a graph split. I have not seen a vote or anything community related in response to the WMF idea of splitting the graph. This is not a good sign.
It seems the WMF have run out of patience for this community to try to mitigate (e.g. by deleting the part of the scholarly graph not used by any other Wikimedia project) and thus freeing up resources for items that the community really care about and that has a use for other Wikimedia projects.
This is interesting. I view this as the WMF technical management team has in the absence of a timely response and reaction from the Wikidata community themselves decided how to handle the issues that our lack of e.g. a mass-import policy has created.
This sets a dangerous precedent for the future of more WMF governance which might impact the project severely negative. I view this as a very strong kick in the butt of this community.
I urge therefore the community to:
address the issue with the enourmous revision table (e.g. by suggesting to WMF to merge or purge the revision log for entries related to bots so that e.g. 20 edits in a row from a bot on the same date get squashed into 1 edit in the log)
immediately stop all bots currently importing items no matter the frequency until a mass-import policy is in place.
immediately stop all bots making repetitious edits to millions of items which inflate the revision table (e.g. User:LiMrBot)
immediately limit all users to importing x items a week/month until a mass-import policy is in place no matter what tool they use.
put up a banner advising users of the changes and encourage them to help finding solutions and discuss appropriate policies and changes to the project.
take relevant community steps to ensure that the project can keep growing in a healthy and reliable way both technically and socially.
assign a community liason that can help communicate with WMF and try avoid the graph split becoming a reality.
At Wikimedia Commons, I made a proposal of batch uploading all the candidates portraits from Brazilian elections (2004-2024). The user @Pfcab: has uploaded a big chunk and while talking with @DaxServer:, he noticed that since the divulgacandcontas.tse.jus.br has so much biographical data (example), it could be a relevant crosswiki project.
Would this be possible? There's any bot that could - firstly - look for missing names in the Wikidata (while completing all the rest), exporting the missing Superior Electoral Court biographical data, and adding the respective images found in Category:Files from Portal de Dados Abertos do TSE?
Hi, why is there not a symmetric "has subclass" for the property "subclass of (P279)" ?
I contribute on social science concepts and it is honestly complicated to build concepts hierarchies when you are not able to see the "subclasses item" from the "superclass item" page.
Making a property proposal is a bit beyond my skills and interests, anyone interested to look into the question ?
Relateditems gadget is useful for a quick look of subclasses. Though sometimes it gets overcrowded if there's too many statements about an item. You can enable it here. Samoasambia✎19:01, 4 September 2024 (UTC)[reply]
Done — Martin (MSGJ · talk) 10:59, 3 September 2024 (UTC)
