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

Wikidata:Project chat

From Wikidata
(Redirected from Wikidata:PC)
Jump to navigation Jump to search

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

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

For realtime chat rooms about Wikidata, see Wikidata:IRC.
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.

Rendering of coordinate values

[edit]

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.
- Nikki (talk) 05:58, 29 August 2024 (UTC)[reply]

Special rules for Wikinews categories?

[edit]

Hello! As I understand it, there is a general rule in Wikidata that if an item has its own category in at least 1 Wikimedia project (except Commons), then we create a separate item for the category and then we link all categories from around Wikimedia to this "category item" (example: Poland (Q36) is Poland and Category:Poland (Q1455901) is Category:Poland). However, my fellow Polish wikimedian Marek Mazurkiewicz has just pointed out to me that this rule does not apply to Wikinews. Apparently, Wikinews categories should be linked directly to the main item. Could anyone else please confirm that there is such an exception (and what are the reasons for that, if you know them?). Thank you in advance. Powerek38 (talk) 08:16, 26 August 2024 (UTC)[reply]

Yes, I can confirm this. The reason is that for Wikinews a category is the basic object, they do not have an analog of a Wikipedia article (a single news is not such an analog). Ymblanter (talk) 17:55, 26 August 2024 (UTC)[reply]

Wikidata weekly summary #641

[edit]
Thanks for providing this :) So9q (talk) 05:27, 1 September 2024 (UTC)[reply]

Wiping 賀錦麗 off the aliases in Kamala Harris (Q10853588)

[edit]

Is there someone who could and would be willing to wipe 賀錦麗 off the nearly 100 remaining aliases it does not belong on on Kamala Harris (Q10853588)? Thanks. - Yupik (talk) 06:52, 27 August 2024 (UTC)[reply]

Why did nobody revert the bot that added these in a single edit? Would have been much easier. Sjoerd de Bruin (talk) 08:34, 27 August 2024 (UTC)[reply]
No idea, but it wouldn't let me anymore since other people had been deleting them off individually. - Yupik (talk) 10:24, 27 August 2024 (UTC)[reply]
This may be part of the problem: Q10853588#P742 RVA2869 (talk) 08:43, 27 August 2024 (UTC)[reply]
Thanks for deleting them! - Yupik (talk) 10:25, 27 August 2024 (UTC)[reply]

SPARQL to connect any two Qs

[edit]

Inspired by six degrees of separation (Q2855754), I am just wondering if there is a general SPARQL statement to connect any two entities. The key part is wildcard for Ps. Thanks

Think of Wikidata as directed graph as it is, Qs are nodes and Ps (as main properties and qualifiers) are edges. There are 2 versions :

(a) treat it as directed graph, with example : −1 (Q310395) instance of (P31) integer (Q12503) studied in (P2579) number theory (Q12479) and

(b) as Undirected graph , like between integer (Q12503) and real number (Q12916) via type of number (Q47460393)

Thanks. JuguangXiao (talk) 07:27, 27 August 2024 (UTC)[reply]

You can use RDF GAS API to query the number of steps between two items using some properties (directed or undirected), for example. However (1) RDF GAS API is a Blazegraph extension, and since WDQS will move out of Blazegraph (as it is abandonware), such feature will discontinue in some point; (2) It is not scalable for all of Wikidata items - the query example use child (P40) as undirected graph, and child (P40) is used in a little fewer than one million items, where the entire Wikidata has more than 100 million items; even with such number of items, the query often fails or timeouts so you need to try it multiple times before getting a result.--GZWDer (talk) 12:17, 27 August 2024 (UTC)[reply]

Fictional location from work vs. Fictional location in work

[edit]

Which one of the two descriptions is the better one to use? Trade (talk) 13:28, 27 August 2024 (UTC)[reply]

This seems like a bit of a stretch or is that just me? Trade (talk) 16:42, 27 August 2024 (UTC)[reply]

Doesn't seem far-fetched to me. Do terrorists not seek political or social change? One man's freedom fighter is another man's terrorist. -Animalparty (talk) 01:41, 28 August 2024 (UTC)[reply]
Googles Dictonary suggests that acting the in the pursuit of political aims is part of the definition of what makes someone a terrorist. ChristianKl15:29, 2 September 2024 (UTC)[reply]

Q2842000 is missing some info

[edit]

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]

Moved this section back to PC.

--Wüstenspringmaus talk 09:26, 28 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]
@ArthurPSmith: Kxeon is unable to edit the item because it's semi-protected. --Wüstenspringmaus talk 19:00, 28 August 2024 (UTC)[reply]
@Wüstenspringmaus Maybe @Kxeon should edit some more (non-semi-protected pages) to become auto-confirmed.
Wikidata:Autoconfirmed users RVA2869 (talk) 16:59, 29 August 2024 (UTC)[reply]

possibly same organization

[edit]

I would be very surprised if Institute for Security Studies (Q18126017) and Institute for Security Studies (Q61931531) are distinct organizations (same name, same year of inception, same web domain for their official sites) and would not be at all surprised if Institute for Security Studies (Q74432455) is also the same. I'd want to add said to be the same as (P460), but may I do that without a citation? - Jmabel (talk) 23:11, 28 August 2024 (UTC)[reply]

So the first two items have different ROR ID (P6782) values, and their entries in ROR would indicate that Q61931531 is a child organisation of Q18126017 which would make sense as the latter is described as their "head office" and the former a "regional office" on their website. So perhaps tying them together using parent organization (P749) or part of (P361) would be better than said to be the same as (P460)? M2Ys4U (talk) 01:42, 29 August 2024 (UTC)[reply]
I merged Institute for Security Studies (Q74432455) into Institute for Security Studies (Q18126017) as they are surely the same. Institute for Security Studies (Q61931531) is said to be in Kenya, so it may be related but it is definitely not the same as the South African institution, assuming that location is correct. ArthurPSmith (talk) 19:29, 29 August 2024 (UTC)[reply]

Property:P1813 short name with countries

[edit]

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]

Looking at the examples of this property, both abbreviation and "short text but not abbreviated" look to be both accepted https://www.wikidata.org/wiki/Property:P1813#P1855 Bouzinac💬✒️💛 08:05, 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]
Unfortunately, it looks like your proposal has been tried already in January of this year: Wikidata:Property proposal/abbreviation --Flominator (talk) 09:13, 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]
Thanks. Let's hope Wikidata:Property proposal/initialism is less confused. --Flominator (talk) 10:03, 30 August 2024 (UTC)[reply]
That sounds like what the label is for. The label is supposed to be the name the item is most commonly known by (see Help:Label). We normally use official name (P1448) for the long/formal name. I don't know why United States of America (Q30) has the formal name as the label, even the English Wikipedia article is "United States". - Nikki (talk) 05:28, 1 September 2024 (UTC)[reply]

Settlement population by ethnic group

[edit]

I'm trying to find a good way to add the population of specific settlement (village, town, city) by ethnic group. I tested with Blagoevgrad (Q173277). I added statement ethnic group (P172), set it to Bulgarians (Q133255) and added qualifiers determination method (P459) with census (Q39825), point in time (P585) with the census year & quantity (P1114) with the number of citizens from that ethnical group. What I'm concerned is if ethnic group (P172) could be a statement at all for that object and is there better way to structure this data? StanProg (talk) 15:32, 29 August 2024 (UTC)[reply]

I would use population (P1082) but with qualifiers applies to part (P518) always having ethnic group (Q41710) as object and ethnic group (P172) having the particular ethnic group as object. Also each statement should have a reference to the census from which the data comes from. here is a sample statement on the same wikidata item. --Nikola Tulechki (talk) 15:49, 29 August 2024 (UTC)[reply]
That's what I would have suggested, but a different structure is used for places in North Macedonia (example: Q2862113). The ethnic group property is still used as the main statement, but since 2020 has linked to new items that are instances of ethnic group by settlement in Macedonia (Q106474968) instead of including the numbers directly in the item, although there are issues such as duplication of Macedonian cadastral municipality ID (P8542) values, and use of of (P642) (which could be improved by using located in statistical territorial entity (P8138) or located in the administrative territorial entity (P131) to link directly to the village Armatuš (Q2862113) (which should be an instance of cadastral municipality of North Macedonia (Q98497401) or whatever represents its administrative or statistical status). I don't know if there was a reason for the use of Q106474968 and could not find anything similar for other countries (although most just have population statements for different years. Peter James (talk) 16:04, 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]

UK Parliament Image ID property

[edit]

Hi. Do we have a property describing the ID as here? If not, would it be useful to use it in Commons SDC? DaxServer (talk) 19:55, 30 August 2024 (UTC)[reply]

Mass-import policy

[edit]

Hi I suggested a new policy similar to OpenSteetMap for imports in the telegram chat yesterday and found support there.

Next steps could be:

  • Writing a draft policy
  • Deciding how many new items users are allowed to make without seeking community approval first.

The main idea is to raise the quality of existing items rather than import new ones.

I suggested a limit of 100 items or more to fall within this new policy. @nikki: @mahir256: @ainali: @kim: @VIGNERON: WDYT? So9q (talk) 12:11, 31 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.
M2k~dewiki (talk) 02:07, 1 September 2024 (UTC)[reply]
Time span does not really matter, intention does.
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.
Indeed increased steering and formality would be needed if we were to undertake having an import policy in Wikidata. So9q (talk) 06:19, 1 September 2024 (UTC)[reply]
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]
Sorry, I did not want to imply that discussion cannot happen elsewhere. But we should not assume that people here know what was discussed on Telegram. Egon Willighagen (talk) 10:36, 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]
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. ChristianKl15:37, 2 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)
  • the bot policies (especially Wikidata:Requests for permissions/Bot) probably need an update/reform too
  • 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).
Cheers, VIGNERON (talk) 09:20, 2 September 2024 (UTC)[reply]
  • 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]

Utilizing Wikidata for Enhanced Game Development

[edit]

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]

Dating for painting at Q124551600

[edit]

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]

Mark the one with the highest chance as "preferred"? And add a 'reason' qualifier to indicate it preference is based on higher chance? The "deprecated" qualifier (reason for deprecated rank (P2241)) for the statements has hundreds of reasons (there is list of Wikidata reasons for deprecation (Q52105174) but I am not sure it is complete; I think my SPARQL query earlier this week showed many more). Similarly, there is reason for preferred rank (P7452) and maybe most probable value (Q98344233) is appropriate here. Egon Willighagen (talk) 08:09, 1 September 2024 (UTC)[reply]
How do I mark it as preferred? Which qualifier do I use? Carl Ha (talk) 08:11, 1 September 2024 (UTC)[reply]
Ranking is explained here: https://www.wikidata.org/wiki/Help:Ranking
I would suggest the qualifier property reason for preferred rank (P7452) with the value most probable value (Q98344233). Egon Willighagen (talk) 10:42, 1 September 2024 (UTC)[reply]
Thank you! Carl Ha (talk) 11:12, 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]

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.

请求合并 Q31395213 和 Q4089188

[edit]

它们描述了同样的内容。Kone718 (talk) 09:17, 1 September 2024 (UTC)[reply]

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Midleading (talk) 14:39, 1 September 2024 (UTC)[reply]

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]

WDQS infrastructure

[edit]

I am curious over currently used infrastructure for running WDQS and its costs? Where could I find this information? Zblace (talk) 18:05, 1 September 2024 (UTC)[reply]

Try here this page has a summary https://diff.wikimedia.org/2023/02/07/wikimedia-enterprise-financial-report-product-update/ Baratiiman (talk) 05:37, 2 September 2024 (UTC)[reply]
That has nothing to do with the Query Service Zblace is asking for. LydiaPintscher (talk) 07:40, 2 September 2024 (UTC)[reply]

Persia

[edit]

Persian langauge is missing i cant add Baratiiman (talk) 05:35, 2 September 2024 (UTC)[reply]

Already exists: Q9168 Carl Ha (talk) 06:58, 2 September 2024 (UTC)[reply]
or do you mean in the box at the top of each item? there you have to type "fa" as language code. Carl Ha (talk) 06:59, 2 September 2024 (UTC)[reply]
@Baratiiman: what are you talking about? On items like femininity (Q866081) you did edit in Persian. But on Hawk Tuah Girl (Q127159727) you wrongly edited in English. Is your interface in Persian? If so, you should see Persian. Cheers, VIGNERON (talk) 09:23, 2 September 2024 (UTC)[reply]
@Baratiiman: You may want to add a Babel template like {{#babel:fa}} to your user page. Alternatively, enable LabelLister.--GZWDer (talk) 11:25, 2 September 2024 (UTC)[reply]

Why does this list not properly sort?

[edit]

Wikidata:WikiProject sum of all paintings/Exhibitions/0,10 The first column should be sorted by number but they are in wrong order. Carl Ha (talk) 06:57, 2 September 2024 (UTC)[reply]

Proposal to remove all case data from all "COVID-19 in <Place>" items

[edit]

Special:Contributions/CovidDatahubBot added a number of statements about COVID-19 cases in items such as Q83873387. Such data are now largely out-of-date and boost the item to the limit Wikidata can handle (and thus long not updated). It is better expressed such data in Commons dataset instead. Also, many item can not be edited further since it is reaching the size limit of Wikidata items, and causes issues like phab:T373554. GZWDer (talk) 13:28, 2 September 2024 (UTC)[reply]

Announcing the Universal Code of Conduct Coordinating Committee

[edit]
Original message at wikimedia-l. You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.

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.

On behalf of the U4C and the Elections Committee,

RamzyM (WMF) 14:05, 2 September 2024 (UTC)[reply]

Wikidata weekly summary #643

[edit]