Wikidata:Project chat: Difference between revisions

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

• Frequently asked questions
• Requests for deletions
• Merging instructions
• Report a technical problem
• Requests for protections, undeletions and other matters requiring administrator attention. To report vandalism, click here.

For realtime chat rooms about Wikidata, see Wikidata:IRC or the Telegram groups.

Start a new discussion

• Afrikaans
• العربية
• беларуская
• беларуская (тарашкевіца)
• български
• Banjar
• বাংলা
• brezhoneg
• bosanski
• català
• کوردی
• čeština
• словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
• dansk
• Deutsch
• Zazaki
• dolnoserbski
• Ελληνικά
• English
• Esperanto
• español
• eesti
• فارسی
• suomi
• føroyskt
• français
• Nordfriisk
• galego
• Alemannisch
• ગુજરાતી
• עברית
• हिन्दी
• hrvatski
• hornjoserbsce
• magyar
• հայերեն
• Bahasa Indonesia
• interlingua
• Ilokano
• íslenska
• italiano
• 日本語
• Jawa
• ქართული
• қазақша
• ಕನ್ನಡ
• 한국어
• kurdî
• Latina
• lietuvių
• latviešu
• Malagasy
• Minangkabau
• македонски
• മലയാളം
• मराठी
• Bahasa Melayu
• Mirandés
• مازِرونی
• Nedersaksies
• नेपाली
• Nederlands
• norsk bokmål
• norsk nynorsk
• occitan
• ଓଡ଼ିଆ
• ਪੰਜਾਬੀ
• polski
• پنجابی
• português
• Runa Simi
• română
• русский
• Scots
• davvisámegiella
• srpskohrvatski / српскохрватски
• සිංහල
• Simple English
• slovenčina
• slovenščina
• shqip
• српски / srpski
• svenska
• ꠍꠤꠟꠐꠤ
• ślůnski
• தமிழ்
• తెలుగు
• ไทย
• Tagalog
• Türkçe
• українська
• اردو
• oʻzbekcha / ўзбекча
• Tiếng Việt
• Yorùbá
• 中文

Edit

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 2025/08.

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days.

Several hundred new statements Wikidata property instance of numeric identifier

Several hundreds of Wikidata properties (edits in a range of almost 24h, running from 2023-04-12 03:25 [1] to 2023-04-13 03:08 [2]) but in different edit groups (e.g. https://editgroups.toolforge.org/b/CB/295014b0344344d1b3be6cff974df6fc/ = 35 edits and https://editgroups.toolforge.org/b/CB/62a69c26a5034390a334c3de24c7f881/ = 1905 edits) received a statement instance of (P31) = numeric identifier (Q93868746) (current English label "mumeric ID").

Is there presedence for such kinds of statements? Other P31 statements on Wikidata properties have as object items that have a name starting with "Wikidata". Only few items seem to use "numeric ID" (e.g. 2023-01-09 OpenStreetMap numeric user ID P279 ... [3]).

On the other hand "has quality" also uses "numeric ID" as object (e.g. 2023-04-04 [4]). GeoGQL (talk) 12:42, 18 April 2023 (UTC)

@Midleading: Can you explain why your bot created those statements? ChristianKl ❪✉❫ 13:07, 18 April 2023 (UTC)

Because some existing properties link to Q93868746 via P31, for example, X (Twitter) numeric user ID (P6552) and Genius artist numeric ID (P6351) (Q93868746 links to these two examples at that time), and I think it is a good idea to link every other numeric ID properties to Q93868746 as well. This bot is used as a generic QuickStatements replacement because it's quicker to hit run than login on QuickStatements. Midleading (talk) 14:43, 18 April 2023 (UTC)

@Eurohunter: seems to have added those existing one's back in 2020.

I think that removing all of them from properties would make more sense given that they follow a different form than the usual P31 we have for properties. ChristianKl ❪✉❫ 15:03, 18 April 2023 (UTC)

I still think linking numeric IDs to Q93868746 is useful, and P31 is the appropriate property. You can create a new item specific to Wikidata with label beginning with Wikidata for this purpose and make it subclass of Q93868746. Midleading (talk) 15:48, 18 April 2023 (UTC)

Adding three different P31 values is generally a bad pattern. If you want to have something specific about the ID being numerical, making it a subclass of Wikidata property to identify online accounts (Q105388954) would make more sense. ChristianKl ❪✉❫ 17:02, 18 April 2023 (UTC)

numeric identifier (Q93868746) have nothing to do with Wikidata property to identify online accounts (Q105388954). X (Twitter) username (P2002) is non-numerical Wikidata property to identify online accounts (Q105388954), MediaWiki page ID (P9675) is numerical but not a Wikidata property to identify online accounts (Q105388954). If you are concerned with numeric identifier (Q93868746) not being specific to Wikidata properties, create a new subclass item as I said. And why should we limit the number of P31 statements? Lots of properties have 4 or more P31 statements. Midleading (talk) 17:25, 18 April 2023 (UTC)

I agree that discussed statements should be mass-moved to has characteristic (P1552)numeric identifier (Q93868746). As you can see here, we already use it for various purposes to highlight specific features of identifiers: existence of check digit, zero-padding, case-sensitivity, all lowercase/uppercase, "MediaWiki title" (no spaces, first letter capitalized and other rules) and so on. "Identifier is consists of digits" is a useful information (and it would be even more useful to split zero-padded numbers and common [1-9]\d* numbers and make MediaWiki page ID a subclass of common numbers). But it should not be stored in P31, because we don't store such information there. One could argue that we have instance of (P31)Wikidata property linking to external MediaWiki wiki (Q62619638) and it says something about format, but it does not always works: for example, Rodovid ID is a Wikidata property linking to external MediaWiki wiki, but it should not be treated as MediaWiki page title, because actually, it is a number. --Lockal (talk) 19:52, 18 April 2023 (UTC)

+1 on Lockal, moving from instance of (P31)numeric identifier (Q93868746) to has characteristic (P1552)numeric identifier (Q93868746). --Epìdosis 20:06, 18 April 2023 (UTC)

Ok Midleading (talk) 20:46, 18 April 2023 (UTC)

Q93868746 needs to be redefined as quality of identifier (Q853614) rather than subclass of Q853614 if you would move them to P1552. Midleading (talk) 21:11, 18 April 2023 (UTC)

Why? GeoGQL (talk) 15:33, 19 April 2023 (UTC)

"has quality": the object should be a quality, right? Currently Q93868746 is a subclass of ID rather than a characteristic of ID. Midleading (talk) 09:10, 20 April 2023 (UTC)

Is "numeric ID" a quality? GeoGQL (talk) 20:59, 26 April 2023 (UTC)

nominal number (Q2004972)

There is already 'nominal number (Q2004972)' - those identifiers that use [1-9][0-9]* are probably of type 'nominal number'. The description of numeric identifier (Q93868746) says 'identifier in the format of a number, regex [0-9]+' which maybe isn't restrictive enough, or can numbers start with leading zeros and at the same time is too restrictive or do numbers have to use only [0-9]? GeoGQL (talk) 15:38, 19 April 2023 (UTC)

Q93868746 is [0-9]+, which means they can have leading zeros, like Lobatse (Q165768)postal code (P281)"0000". Q2004972 is superclass of Q93868746 and also doesn't specify whether leading zeros are allowed. Maybe you want to create a new item for [1-9][0-9]*. Why are you removing descriptions for Q93868746 in all languages? Midleading (talk) 09:17, 20 April 2023 (UTC)

Q93868746 isn't [0-9]+. GeoGQL (talk) 20:12, 20 April 2023 (UTC)

Before you removed descriptions from all languages and changed P279 of Q93868746, it is [0-9]+, so why are you asserting it isn't? Previously Q93868746 has nothing to do with Q2004972, and Q2004972 isn't restricted to [1-9][0-9]*. Midleading (talk) 05:46, 23 April 2023 (UTC)

"Before you removed descriptions from all languages" - didn't do that. GeoGQL (talk) 20:57, 26 April 2023 (UTC)

Goombrat statement help

I'd like to add two statements to Goombrat (Q117774969), but I'm having trouble finding appropriate properties:

- Goombrats have an unknown relationship to Goombas

- Goombrats resemble persimmons (Is based on (P144) appropriate? Mario Party: Star Rush just states they 'look like' a persimmon.) LilWaddleDee (talk) 11:12, 19 April 2023 (UTC)

What do you mean with "unknown relationship"?

based on (P144)'s current description is "the work(s) used as the basis for subject item". That's very different than "look like". ChristianKl ❪✉❫ 10:51, 22 April 2023 (UTC)

In the case of unknown relationship, Super Mario Run states 'Nobdody [sic? there's a chance this is just an error in the Super Mario Wiki] is quite sure of their exact relation to Goombas' - although I suppose this kind of thing might not be suitable for Wikidata. It felt wrong to me not to mention Goombas somewhere on the Goombrat page; but that's just how it goes sometimes, I guess.

In the case of based on (P144), yeah, it is - that's what I thought too - I think I was confused by it also being known as 'modelled after'. Is there something more appropriate? LilWaddleDee (talk) 11:07, 22 April 2023 (UTC)

MediaWiki:Wikibase-SortedProperties - new properties missing and therefore sorted out of place

E.g. P11713 Patreon user numeric ID is not sorting alphabetically next to P4175 (Patreon ID). Could some having the right to do so run User:DannyS712/SortedPropertiesUpdater.js? GeoGQL (talk) 17:23, 19 April 2023 (UTC)

"Wikidata weekly summary #569" [5] mentions sixteen new external identifiers, of which only Amarkosh ID has been put into the correct position by User:MSGJ [6] after they were asked if they could do so [7]. A further request at the same page to the same user regarding one property existing in a wrong section got no reply. [8].

What can be done to have at least weekly updates to the page, maybe around the same time as the weekly summary is delivered? GeoGQL (talk) 21:09, 26 April 2023 (UTC)

Wikispecies author categories

We have a number of items like Category:Taxa named by Peter R. Møller (Q111925612) which relate to en.Wikipedia (or other Wikipedia) categories.

Wikispecies also has species:Category:Taxa named by Peter R. Møller.

We don't generally make items for Wikispecies categories in that series; but should we link them to our items where they already exist? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 20 April 2023 (UTC)

I don't see any problem linking them with related category (P7084) — Martin (MSGJ · talk) 13:10, 20 April 2023 (UTC)

That requires an item to exist. Are you proposing that we make a separate item for each such Wikispecies category? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 20 April 2023 (UTC)

If an item exists (like in your example above), then just add a link to the Wikispecies category like to any other Wikimedia project.
If an item does not exist, there are no problems at all if you create an item. Michgrig (talk) 17:13, 20 April 2023 (UTC)

Each of those things are not current practice; my question is whether current practice should change. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:14, 20 April 2023 (UTC)

> Each of those things are not current practice
Why? What is the difference here between Wikispecies and Commons? Michgrig (talk) 05:42, 21 April 2023 (UTC)

Presumably, because on Commons, in the vast majority of cases, the category is the primary page on a topic, with no corresponding mainspace page; whereas on Wikispecies it never is; and there is always a corresponding mainspace page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 21 April 2023 (UTC)

OK then. On Wikipedias, there are categories that accompany mainspace pages, like in the starting example of the thread. So what's the problem of linkiing Wikipedia mainspace pages with Wikispecies mainspace pages and, if any, Wikipedia categories with Wikispecies categories? It does look like current practice for other projects. Michgrig (talk) 17:48, 21 April 2023 (UTC)

The evolution of a statistics tool

So a while back I noticed that someone has tried to use SPARQL to make reports about missing labels. Of course since SPARQL is by nature really inefficient at that sort of thing, the result was effectively non-functional.

It was pointed out by an administrator, forgot who, that the search engine kept track of labels and thus could handle this efficiently. And so I made a tool that did just that.

The second iteration of this tool used concurrency, or rather asynchronous operations, to speed up things.

The third iteration uses Elasticsearch replicas. Even without doing things in parallel here I got some nice speedups by having the Elasticsearch engine do multiple aggregations for me. This is not something that would be possible using the Mediawiki API. I suspect this is an underutilized service and more people should probably consider it.

The downside is of course that very few people would be familiar with Elasticsearch and its DSL query language. I have some ideas for improvement but I don't know how to proceed. One idea is to query per language since there are less languages than properties, and then do aggregations per property, which is the opposite of what I'm doing now. Another idea is to avoid specifically listing the things you want to make an aggregation bucket out of. Could you for instance ask, for every property give me an aggregated count of labels for every language, without having to specify the languages up front? The third idea I had was, could I make a Franken-query that basically distilled every single item in the main Wikidata namespace based on property and language label, and then just filter that report client-side?

Here are the reports currently being generated: [9] [10]

You can find the tool here: https://public-paws.wmcloud.org/User:Infrastruktur/langreport/

If you are familiar with Elasticsearch and think you can help making it more awesomecakes, leave a message on my talk page. Thank you. Infrastruktur (talk) 18:35, 20 April 2023 (UTC)

Well, I’m kinda curious. What is the best documentation for Elasticsearch that you are aware of? I have not had any interaction with this thing until now. —MisterSynergy (talk) 19:25, 21 April 2023 (UTC)

Primarily I wanted to learn about Elasticsearch, being able to improve my reporting tool is just a bonus. Just recently started watching tutorial videos on Youtube to get a feel for the basics, for specifics I consult the official reference documentation. The mapping that's used on Wikidata strikes me as using advanced features, so it is harder to understand. I had to go look in the source code for the Wikibase Cirrussearch extension to find out what the Elasticsearch equivalent of "haswbstatement:P4342 -haslabel:nb" in Cirrussearch was. Elasticsearch is a clustered version of the Apache Lucene search engine. It is built atop a document database, something that surprised me. Infrastruktur (talk) 23:26, 21 April 2023 (UTC)

Since the Wikidata mappings weren't suitable for learning purposes, I ended up installing an Elasticsearch and Kibana on my computer, and importing some sample data to play around with. Infrastruktur (talk) 15:21, 22 April 2023 (UTC)

IIRC, the blocker for extracting labels from Elasticsearch was that it mixes labels and aliases (see pt for example).

"for every property give me an aggregated count of labels for every language" - you can use Quarry (for testing) or Toolforge database with a query like

SELECT
cast(wbxl_language as char), COUNT(wbit_item_id) AS count
FROM wbt_item_terms
JOIN wbt_term_in_lang ON wbit_term_in_lang_id = wbtl_id
JOIN wbt_type ON wbtl_type_id = wby_id AND wby_name = 'label'
JOIN wbt_text_in_lang ON wbtl_text_in_lang_id = wbxl_id
WHERE wbit_item_id IN (1,2,3,4,5,6,7,8,9,10)
GROUP BY wbxl_language

where 1,2,3,4,5 is precollected ids if items bound as array. With SPARQL... it is still possible with slicing service, just get slice, increase offset, until property is processed. If you are still interested in merged labels and aliases in ElasticSearch - sorry, don't know :/ --Lockal (talk) 20:51, 21 April 2023 (UTC)

Thanks, that helps. I panicked a bit when you pointed out that labels and aliases were mixed, but then I remembered that the method I currently use for counting is based on whether the item has a label for the language or not, so items will only be counted once. This will probably incorrectly count items that have an alias set but no label, but I think the old Mediawiki Search API code did the same as well. I'm not sure there exists a method that works properly while also being efficient, your SQL approach is probably as good as it gets. Infrastruktur (talk) 23:26, 21 April 2023 (UTC)

• Documentation for the SQL term store is here: https://doc.wikimedia.org/Wikibase/master/php/docs_storage_terms.html It is not that simple in SQL only to intersect this with a property usage dimension, however.
• Using the WDQS slicing service is actually a viable idea here as well. One could relatively easily loop over all slices and collect labels (or the lack thereof) for a given property, concat everything together in a script and run various aggregations. It will by far not be as quick as the Elasticsearch approach, however.

—MisterSynergy (talk) 07:21, 22 April 2023 (UTC)

Batch edit query: Q117812206 / Medieval literature scholar

Hello everyone! Not sure this is right place to ask.

I'd like to quickly assign everyone instance of human who comes up with this search 'Medieval literature scholar': https://www.wikidata.org/w/index.php?fulltext=1&search=medieval%20literature%20scholar&title=Special%3ASearch&ns0=1&ns120=1

With this new property: medieval literature scholar (Q117812206)

Is there a way to do that? I've never used any batch editing tools before.

Thank you! Medievalfran (talk) 08:55, 21 April 2023 (UTC)

@Medievalfran,
Take a look at https://quickstatements.toolforge.org/#/ Michgrig (talk) 13:21, 21 April 2023 (UTC)

@Michgrig, thanks, will have a play! Medievalfran (talk) 11:11, 26 April 2023 (UTC)

Academia.edu profile URL (P5715)

Academia.edu profile URL (P5715)

Hi,

I came across this property, shouldn't this be an external identifier? RVA2869 (talk) 10:09, 21 April 2023 (UTC)

Yes it does look like the sort of thing we would have created as an identifier rather than a URL datatype. The other Academia properties are identifiers. Maybe a new proposal to replace this with an id would be best now? ArthurPSmith (talk) 14:07, 21 April 2023 (UTC)

No, because - as the examples on the property page show - there is a unique subdomain for each academic institution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 21 April 2023 (UTC)

Ah - thanks Andy Mabbett - I hadn't noticed that and it wasn't mentioned in the proposal discussion which I did check. ArthurPSmith (talk) 17:33, 21 April 2023 (UTC)

Issues with wrong LEI identifiers for companies being recently imported

Hi, I noticed that from 09/04 onwards this bot (?) "https://www.wikidata.org/w/index.php?title=User:Booktroll&action=edit&redlink=1" (named Booktroll) imported a lot of LEI numbers to companies and I identified that many of them are wrong. I changed these shortly after (see history) as they lead to complications. Examples:

• Imperial Oil (Q40650)
• Smith & Nephew (Q502509)
• Kuehne + Nagel (Q671267)
• Alcon (Q684825)

As many other companies are probably affected, is there a possibility to do something about this wrong information? Thank you in advance QA&cats (talk) 10:30, 21 April 2023 (UTC)

Artem Lysohor

Hi, I have created an article, Artem Lysohor, translated from the Ukrainian Wikipedia, however, there is a technical error which I am unable to add an inter-language wiki to that article. It'd be appreciated if you could merge these site links listed below:

Artem Lysohor (Q117817117)

Artem Lysohor (Q117678637)

Thanks.

Ivan Milenin (talk) 00:30, 22 April 2023 (UTC)

@Ivan Milenin:  Done Vahurzpu (talk) 04:47, 22 April 2023 (UTC)

Good idea? Bot that creates items for books in Amazon

How useful or harmful would it be to Wikidata a bot that iterates through all books in Amazon and creates Wikidata items for them (given that there's no existing item with that ISBN-10 (P957), ISBN-13 (P212) or Amazon Standard Identification Number (P5749))? Please let me know your thoughts.

-- Rdrg109 (talk) 20:11, 22 April 2023 (UTC)

BitOneZero did that once, and Wikisaurus at least didn't like it. Mahir256 (talk) 20:13, 22 April 2023 (UTC)

I think it is ok to add statements of the form "version" "is a version of" "book", but adding all the statements of the form "book" "has a version" "version" is redundant (one can use a simple Query request) and makes the element of the book too big to use. Wikisaurus (talk) 20:22, 22 April 2023 (UTC)

Definitely not for all the books on Amazon considering the amount of autotranslated garbage and self-published cruft on it. If the item already exists on Wikidata though, I have no objection to a bot autolinking it to the item on Amazon as long as the correct version is linked to. -Yupik (talk) 21:19, 22 April 2023 (UTC)

No, please no. Signal to noise is not good enough. Multichill (talk) 21:20, 22 April 2023 (UTC)

You need to be clear on the distinction of literary work, edition and individual physical book. While we might want all instances of the first in WD, an Amazon trawl could produce a muddle of the second. Vicarage (talk) 19:47, 23 April 2023 (UTC)

Please don't do it. Both the Amazon and Google Books can have errors in their books descriptions. If you want to create items for books, consider the Library of Congress Catalog. It seems to be a reliable source. D6194c-1cc (talk) 23:06, 23 April 2023 (UTC)

Looking for an appropriate property

When politicians submit a bill to government, they are not necessarily the author of that bill. Bills are often passed around between politicians in a party before one of them submits it, and some countries show a record of the different politicians in charge of that bill at different times.

Would there be an existing property that could represent this? In my country the official term is "Member in Charge". If there's no property, I might make a proposal, but I'd look for a more generic term that could apply to countries that don't call their politicians "Members". ElDubs (talk) 00:10, 24 April 2023 (UTC)

After further research, I feel maintained by (P126) would be just perfect. ElDubs (talk) 01:58, 24 April 2023 (UTC)

Ramesses (Q86010029)

What to do with this page? In any case, it's not a page of given names. See also Ramesses (Q220794). --HarryNº2 (talk) 09:54, 24 April 2023 (UTC)

I don't see what the problem is.StarTrekker (talk) 11:48, 24 April 2023 (UTC)

Have a look at the descriptions, chance is high the item is mixing concepts by containing sitelinks to either disambugation pages or pages about given names. Sjoerd de Bruin (talk) 11:52, 24 April 2023 (UTC)

I have attempted to clean up the confusion. I am not sure about including native label (P1705) for an ancient Egyptian name, and if this item should be used with given name (P735) at all (or if name in hiero markup (P7383) is enough). Hopefully someone with expertise in this area will weigh in.

--Quesotiotyo (talk) 17:51, 24 April 2023 (UTC)

Wikidata weekly summary #569

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New requests for permissions/Bot:
    • AddLetterboxdFilmIdBot (Task: Adding Letterboxd Film ID (P6127) statements to items which already have a TMDB Film ID (P4947))
  • Closed request for permissions/Bot:
    • Kristbaumbot 1 (Task: Add identifiers from Wörterbuchnetz to German lexemes)
  • New request for comments:
    • Creating properties which link to an archived website

• Events
  • Upcoming
    • Next Linked Data for Libraries LD4 Wikidata Affinity Group Working Hour April 24, 2023: Would you like to know how to join and use Telegram? Two regular Wikidata Telegram users will provide an introduction to Telegram and its available Wikidata channels. They will discuss how they use it, how it can provide help with Wikidata work, and how it can facilitate connections with other Wikidata users Event page
  • Ongoing
    • Weekly Lexemes Challenge #89, Ear
  • Past
    • Wikidata+Wikibase office hour session log: Telegram office hour 2023-04-19

• Press, articles, blog posts, videos
  • Blogs
    • How to put an end to best book lists once and for all
  • Papers
    • Documenter l'histoire queer sur Wikidata (Documenting Queer History on Wikidata - French), John Samuel, Panel: Queer Data : les plateformes numériques d'archives, Collectif Archives LGBTQI+, Paris, 23 April 2023
    • Hypotheses in urban ecology: building a common knowledge base
  • Videos
    • Using PetScan and Wikidata Terminator, Mooré Wikimedia Community (in Mooré)
    • Wikidata Atlas: Putting Wikidata on the Map
  • Notebooks
    • Probability of having notable parents by occupation and gender
    • Living with Machines: Toponym recognition and resolution — input and output exploration
  • Twitter thread
    • Average number of words in Wall Street Journal articles by author gender

• Tool of the week
  • User:Nikki/colour icons.css - is a Userscript to add colour to the editing icons. It uses green for add/save, yellow for edit, red for remove, orange for cancel and blue for help.

• Other Noteworthy Stuff
  • The Wikibase newbie docs are here (to help to onboard new Wikibase users easier).

• Did you know?
  • Newest properties:
    • General datatypes:
      • handled, mitigated, or managed by (approach or method that can be used to address an issue or problem)
      • holds diplomatic passport of (country of the diplomatic passport held by the person)
    • External identifiers: Dailymotion video ID, Databáze sérií ID, Universo del corpo ID, Enciclopedia delle scienze sociali ID, AML ID, AniList character ID, Amarkosh ID, Moly.hu author ID, Podcast Index ID, SINTA affiliation ID, Hall of Light developer ID, Hall of Light publisher ID, Hall of Light artist ID, Kinoglaz person ID, Michaelis ID, Kino1TV ID
  • New property proposals to review:
    • General datatypes: none
    • External identifiers: KPU Plant Database ID, SoccerPunter team ID, HAL non-registered author ID, Master's degree Mon master ID, Dizionario dei prodotti DOP e IGP ID
  • Query examples:
    • Administrative subdivisions with more than 10 million inhabitants (source)
    • Rivers in France over 50 km long (source)
    • List of mental disorders (source)
    • Paintings once owned by Red Flag Names (source)
    • Top album languages found on Wikidata right now (Week 16, 2023) (source)
    • Place of birth of humans with Github username (source)

• Development
  • REST API: We continued work on making it possible to create or replace a label, or a description in a given language (phab:T323813)
  • EntitySchemas: We continued working on the new datatype for linking to EntitySchemas. It is now available on beta in a very bare-bones version but not ready for wider testing yet. (phab:T332139)
  • Ontology issues: We are evaluating the results of the survey we ran earlier this year.

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.

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Contribute to a Showcase item.
  • Help translate or proofread the interface and documentation pages, in your own language!
  • Help merge identical items across Wikimedia projects.
  • Help write the next summary!

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 16:25, 24 April 2023 (UTC)

SUL not working well on Wikidata?

In theory, Wikidata should be using Wikimedia's Single User Login (SUL) with automated login if already logged in via another Wikimedia project such as Wikipedia or Commons, right? But in the last 1-2 years or so, this very rarely works for me when I visit Wikidata. That is, I'm logged in with my SUL account in Wikipedia, for example; I visit https://www.wikidata.org/ but I'm not getting logged in here, reload doesn't help, I have to enter my login credentials here again. Often I forget this and then unintentionally make edits as an IP / anonymous contributor, which is annoying. Is this a known issue? Any hope it will get fixed? Gestumblindi (talk) 21:49, 24 April 2023 (UTC)

Please check your setup first. Most likely there is either some privacy (adblocker) addon interfering, or the cookie policy in your browser’s security/privacy settings is too strict. Without further knowledge of your setup (browser and relevant addons in particular), there is nothing more I can help at the moment. —MisterSynergy (talk) 22:35, 24 April 2023 (UTC)

I had noticed this, too.

I guess that it's the "strict" setting in Firefox' "Enhanced Tracking Protection". Toni 001 (talk) 06:45, 25 April 2023 (UTC)

See phab:T226797.--GZWDer (talk) 13:31, 25 April 2023 (UTC)

First, I would like to note that the issue for me only affects Wikidata. Automated login from Wikipedia to Commons or other Wikimedia sites works, just not on Wikidata. - I'm usually using Firefox with Adblock Plus. Did some testing: Even if I disable Adblock Plus and set Firefox' "Enhanced Tracking Protection" to "Standard" (not "strict"), automated login to Wikidata when logged in in Wikipedia doesn't work. If I manually disable the "Enhanced Tracking Protection" specifically for Wikidata, I'm still not getting logged in automatically when visiting the site, but there is a change in that I'm getting logged in without entering the credentials when clicking "Log in". Gestumblindi (talk) 17:27, 25 April 2023 (UTC)

As much as I am aware, it does not try to auto-login at each and every request. Please try once again with "standard" cookie settings, but after closing and restarting your browser.
I have had similar problems, and relaxing the Firefox cookie policy helped in my case. After logging in at Wikipedia, I did observe the same behavior (no auto-login) for all Wikimedia projects that do not end with .wikimedia.org (i.e. Commons in particular does not have this problem, but Wikibooks, Wikiquote, Wikisource, Wikinews, Wikidata, etc. all do). I am using "custom" privacy settings in Firefox, and the cookie policy that works is: block "cross-site tracking cookies". What does not work is: block "cross-site tracking cookies, and isolate other cross-site cookies".
Not sure about Adblock Plus, though. I am using other adblockers (uBlock origin and uMatrix) which do require custom rules for auto-login to work. —MisterSynergy (talk) 18:13, 25 April 2023 (UTC)

@MisterSynergy: Thank you, that's the solution! Changing block "cross-site tracking cookies, and isolate other cross-site cookies" to block "cross-site tracking cookies" only (with Adblock Plus disabled for Wikimedia sites) fixes the issue (btw, closing and restarting the browser is of course what I always do when testing such things ;-) ). As the only Wikimedia sites which I visit fairly regularly besides the Wikipedia language versions and Commons are meta.wikimedia.org and Wikidata, it's quite likely that I would have had the same issue at Wikibooks etc. So, the problem is solved for me - but of course it's not a very obvious fix and others will still encounter the issue... Gestumblindi (talk) 20:11, 25 April 2023 (UTC)

Spam, or useful?

What is people's opinion on such edits? It seems to me that if an item has an English name and alias, that can be denoted in the English name and alias. Why should foreign-language labels be polluted with exactly the same text as the English? If there is no substantial translation and the name/alias used by speakers of, say, Traditional Chinese is exactly the same as the English name, the English labels suffice, do they not? What more is gained by spamming all languages like this? It seems to be a chilling effect to discourage foreign-language speakers from populating these fields, if indeed there is a variant in that language. Elizium23 (talk) 06:47, 25 April 2023 (UTC)

I see that this comes from a tool that may have been around 10 years: User:Jitrixis/nameGuzzler.js. Is this sanctioned as a useful and constructive tool for Wikidata? What is the purpose of spamming all languages? Elizium23 (talk) 06:52, 25 April 2023 (UTC)

@Elizium23: There's actually no reason to revert such edits and claim they're non-constructive or spam: first of all, Traditional Chinese was not (!) even labelled, secondly a person's name does not change from English to any (Latin script) language (let's say, Spanish? French? German?), last but least I added labels and aliases for languages that merely use Latin script (and Traditional Chinese is not among them). --France3c0 (talk) 07:01, 25 April 2023 (UTC)

What is the benefit/advantage of filling in all these blanks with a non-native term? Elizium23 (talk) 07:09, 25 April 2023 (UTC)

@Elizium23: Labels are filled in with a person's actual name. More like, what is the point of claiming it is "spam"? France3c0 (talk) 07:14, 25 April 2023 (UTC)

What is the benefit/advantage to filling these in?

Wiki software is perfectly capable of handling the fact that a language does not have an alias and defaulting to English.

You will need to justify the edits by stating your purpose and benefit these additions have to the project.

I see them as a net negative. They are unnecessary bloat and pointless duplication, unless you can adequately explain otherwise.

They are also a burden on future editors. Say that Eilish changes her name, via marriage, transgenderism, or we decide via consensus. What is an editor to do, make 300 edits to change them all at once? They are the same value! Elizium23 (talk) 07:19, 25 April 2023 (UTC)

Furthermore, you have no proof. You have no sources. Have you researched a body of literature in each of 300 languages and determined that each refers to Eilish by this name? Have you walked among the Cherokee to hear them refer to her? It is common to require sources to back up assertions, especially extraordinary ones, and names/labels have the unfortunate feature that they cannot be cited, but I am afraid that I must demand your proof that you have identified her name as such in each of these languages. Elizium23 (talk) 07:23, 25 April 2023 (UTC)

@France3c0, please do not edit-war while your edits are in an unresolved dispute. They may become difficult to undo. Consensus is required for such extraordinary changes. Elizium23 (talk) 10:57, 25 April 2023 (UTC)

There are currently no rules against it. It's however likely that it will be all deleted once we adopt 'mul'. ChristianKl ❪✉❫ 13:50, 25 April 2023 (UTC)

I don't think "no rule against it" is a compelling reason to be doing it. Typically, adding properties, qualifiers etc. serves a definite purpose that improves the project. Nobody's been able to articulate what improvement is brought by spamming these names. Elizium23 (talk) 17:55, 25 April 2023 (UTC)

@Elizium23: It seems to me you're taking this nonsense too far. Why would adding labels in different languages be spam? Perhaps, you gotta reason that first. France3c0 (talk) 18:06, 25 April 2023 (UTC)

I'm worried that you are continuing to do mass changes while this discussion is taking place, even for items with titles like Never Gonna Not Dance Again (Q115108001) where I doubt the song is known by that English phrase in 200 languages. Is your ideal for every WD item to have 200 language labels in the end? Vicarage (talk) 06:21, 26 April 2023 (UTC)

(EC) The addition of the aliases means that a user who has a particular language set in their WD UI, or in their WDQS report, will see the alias value. That's actually quite a big win. You can argue the toss about whether it's appropriate for a name in a particular style to be an alias for a particular language, but I question whether it is worth losing sleep over; aliases, in particular, allow users to find items, and so should IMO obay Postel's law - which would support their addition.--Tagishsimon (talk) 18:08, 25 April 2023 (UTC)

I am not sure I quite understand. In my WD UI I see all aliases in every language. Are you saying that there are users who are not able to see the values of English labels, like if they only edit in Cherokee? Does WD/WDQS hide values that do not match the user's declared languages? Elizium23 (talk) 18:28, 25 April 2023 (UTC)

Surely I see the thirst for more and better data across the board. Certainly filling out blank fields is a plus and inflates our numbers here well. I am afraid that this user does not speak, understand, or really care about these minority/obscure languages, has not done any actual research into usage among the speakers or writers of such languages, and doesn't actually care. Many of these languages are so small they don't even have Wikis on Wikimedia. It almost seems like Cultural Imperialism to impose aliases, derived from English, into their space. Meanwhile this user is less interested in engaging in discussion or building consensus, and would prefer to edit-war to keep their preferred changes in, despite reasonable objections by people like me and Lucas. Elizium23 (talk) 18:32, 25 April 2023 (UTC)

I agree that there’s no benefit to these additions – aliases exist to improve search, and search already uses aliases in all languages, so copying identical aliases into additional languages serves no purpose whatsoever. Lucas Werkmeister (talk) 18:09, 25 April 2023 (UTC)

"no purpose whatsoever" is clearly incorrect, Lucas. If I ask for Welsh language aliases of an item in WDQS I will not see English language aliases. There is a major-language hegemony on WD, which we would do well to break. --Tagishsimon (talk) 18:37, 25 April 2023 (UTC)

Surely the query system allows you to specify a language hieracy for labels. Ensuring it does allow for Welsh, default English in all cases seems much better than having the Welsh editors copy English text. Vicarage (talk) 06:09, 26 April 2023 (UTC)

@Elizium23 the fact that you see no compelling reasons for doing an edit does not give you a right to undo the edit. You need to have a reason why it would be good for the edit not to exist to undo it.

Wikidata is a place where different people with different goals come together and just because you don't care for the reasons why someone else made an edit does not give you the right to undo it. ChristianKl ❪✉❫ 21:00, 25 April 2023 (UTC)

Speaking of 'mul'; What will happen to transliterations/transcriptions of proper nouns once 'mul' rolls out? Will those get removed too, or kept? Or will just transliterations/transcriptions into different writing systems be kept? Infrastruktur (talk) 18:34, 25 April 2023 (UTC)

I don't think we have made final decisions on this but one proposal is "You are not allowed to add values that are duplicates of the value that's in mul into other languages" (not allowed meaning the software won't let you).

If you have transliterations that differ from the mul value they are of course allowed. ChristianKl ❪✉❫ 20:58, 25 April 2023 (UTC)

Is there a place where mul is being discussed? Vicarage (talk) 06:11, 26 April 2023 (UTC)

I think we had a few discussion on the project chat and there are software changes made that are life on the test wiki, but I don't think we have a centralized place. ChristianKl ❪✉❫ 12:15, 26 April 2023 (UTC)

• Wikidata New "mul" term language code available on Test Wikidata
• https://phabricator.wikimedia.org/T312097 EPIC: MUL - Introduce intentional language fallback in Wikidata via the `mul` language code
• https://phabricator.wikimedia.org/T285156 GOAL: Add termbox language code mul to reduce redundancy in Wikidata Labels and Aliases

M2k~dewiki (talk) 12:20, 26 April 2023 (UTC)

Please watch your tone. You can ask what the purpose of copying labels to hundreds of languages is without repeatedly calling the edits spam and speculating that the editor is trying to discourage speakers of other languages from editing. - Nikki (talk) 18:40, 25 April 2023 (UTC)

The editor is literally using a tool that's designed to spam as many languages as possible. There is zero chance that the editor speaks most, if any of these languages in question. The editor has no sources, no research, no demonstrated interest in any of these languages. The editor is wholly unable to articulate why they're doing it in the first place. It's spam by an edit-warrior. I stand by everything I've said. Elizium23 (talk) 20:15, 25 April 2023 (UTC)

@Elizium23 Please clarify: Is the use of nameGuzzler for languages that one does not speak prima facie spam? --Emu (talk) 08:51, 26 April 2023 (UTC)

@Emu, it is not for me to make that judgement. It is my opinion that nameGuzzler is a tool that has been created to spam for no discernible advantage or benefit to the Wikidata project. Whether it is "prima facie spam" can be decided by consensus. I think it makes little difference whether the tool user speaks the languages or not -- how would we even tell? Elizium23 (talk) 12:54, 26 April 2023 (UTC)

@Elizium23 I would seriously advise you to retract your statement that nameGuzzler “is a tool that has been created to spam for no discernible advantage or benefit to the Wikidata project”. This “opinion” of yours goes against WD:AGF and, quite frankly, strikes me as a little absurd, too. --Emu (talk) 15:04, 26 April 2023 (UTC)

@Emu, @Nikki, currently @France3c0 has been warned about edit-warring and continues to make nameGuzzler runs in contravention of emerging consensus here. I see at least 3 editors opposing these changes and I don't see a lot of rousing support on the other side.

What would you suggest as the next step in dispute resolution, as France3c0 continues to ignore our opinions? Elizium23 (talk) 12:58, 26 April 2023 (UTC)

Edits should be correct, not some subjective justification of "useful". If you have specific reasons those edits are incorrect or should otherwise not be done, then please raise that. But there's no value to asking how an edit is "useful".

You did raise an interesting issue above where you brought up the burden on future editors if Eilish changes her name. This would require editing every alias. That would indeed be an annoyance. ElDubs (talk) 21:03, 25 April 2023 (UTC)

Edits do need to be useful in a system constrained by computing limits and where information can change. Stating things only once, such that the query process does the duplication, is a good idea. Names, which generally only differ by script, are best done dobe by mul, if that is likely to be Latin script.

A little duplication is not worth getting upset about, but these changes are likely to make WD unwieldy. Vicarage (talk) 06:05, 26 April 2023 (UTC)

Has there been any statement from WMF that we'll need to be careful of the amount of content on wikidata for fear of limited computing resource? I very much doubt it. I do not believe this is a concern. ElDubs (talk) 09:03, 26 April 2023 (UTC)

Recently, there was a post about steps that the developers take to reduce computing usage. One of them is to add the 'mul' type with the hope of preventing data duplication like that. SPARQL is very useful but one of the effects of having all data queriable via SPARQL is that you can't just scale it to whatever size you want the way you could a standard NoSQL database. ChristianKl ❪✉❫ 12:28, 26 April 2023 (UTC)

Yes there is. We've said many times that the WDQS is under huge strain and we are struggling to stabilize it. Please see Wikidata:SPARQL query service/WDQS backend update among others as well as this talk among others. A big part of the problem is duplicate data in labels and descriptions. Lydia Pintscher (WMDE) (talk) 16:20, 26 April 2023 (UTC)

Thanks for this, hopefully it's an issue that can be resolved as regardless of edits that are considered "useless", edits everyone agrees are useful and legitimate will push us to that ceiling. ElDubs (talk) 21:26, 26 April 2023 (UTC)

I am not sure how a useless edit could be "correct". It would seem that every edit must be a net improvement to the project in some way. It adds a useful fact, it clarifies something, it expands knowledge of the item, it reverses vandalism. "Useful" "beneficial" edits are recognizable, objective, and quantifiable.

Now if the person who is making an edit can't even say why they are doing it, and can't describe how it improves the Wikidata project, I think we can agree that that is an undesirable edit, or at least needs additional scrutiny and analysis before mass changes proceed, yes? Elizium23 (talk) 13:04, 26 April 2023 (UTC)

Just to be sure: Is there any compelling argument that the edit in question is against any guideline or consensus? --Emu (talk) 15:06, 26 April 2023 (UTC)

Of course there is. Several editors in this thread have objected. Therefore there is no consensus in favor of the edits, a possible consensus against the edits, and there is no basis for this editor to continue edit-warring. Further, consensus should be based in policy, and no user who is supporting or neutral in this case has provided any facts about how the edits are a net benefit or improvement to our project. Elizium23 (talk) 15:14, 26 April 2023 (UTC)

Okay, could you point out the compelling argument? --Emu (talk) 16:59, 26 April 2023 (UTC)

Peerage person ?

I don't know if every peer should be listed here, but I'm unfamiliar with this mainly British phenomenon so I accepted as it is. However, the information is sometimes very limited. At least it should contain information like Peerage person in the description-section so that we could differ between a composer and a peer with the same name. There's a lot of persons with the same English name and it would be very helpful if every element have a short description. For example there are at least three person with the name Irene Boyle in Wikidata and all three are peers, but only one have that information in the description. Ezzex (talk) 13:46, 25 April 2023 (UTC)

Plenty of times, there will be composers who do have noble titles. Being a very accomplished composer is something for which the Queen can give someone a peerage. The data of birth and death is more useful to know for distinguishing people. ChristianKl ❪✉❫ 14:08, 25 April 2023 (UTC)

I think that's the key-word here: To distinguish between people in an easy way. There are over 100 million elements in Wikidata, I don't know how many of them are about people, but it must be millions.--Ezzex (talk) 14:31, 25 April 2023 (UTC)

See Help:Description. This is not exactly new ground. Items should have descriptions that disambiguate one item from another. Many people on this site work to improve descriptions. The Peerage data import is just a subset of the wider issue. Ideally we'll get on and improve them all. (There are iirc a touch more than 10.6 million human items on WD). --Tagishsimon (talk) 17:00, 25 April 2023 (UTC)

If you take your example of Irene Boyle, the description were (born 1943) and (1919-2010). Years of birth and death are good ways to disambiguate people.

Generally, whether or not they have a link to the peerage website isn't very important for most task to distinguish people. It doesn't help you to distinguish whether or not the person is the composer you are looking for. ChristianKl ❪✉❫ 17:42, 25 April 2023 (UTC)

• The Peerage also had many duplications and conflations, we track them at Wikidata:WikiProject Authority control/The Peerage errors. It took almost a full year to find conflations and duplications and fix them. we are at diminishing returns now. I think that is why we are reluctant to load Findagrave at 10x the size. --RAN (talk) 16:52, 26 April 2023 (UTC)

SNK

SNK Corporation (Q1073880) was founded in 1978 but went bankrupt in 2001. Later, in 2001, Playmore (Q1044563) was established and eventually renamed as SNK Corporation in 2016. While the Japanese version of this article is divided into two items, the English version combines both phases of the company's history into a single article about SNK. What would be the best way to structure this items? Afaz (talk) 16:00, 25 April 2023 (UTC)

It definitely should be two items (as we have now). The official name (P1448) can be given start time etc. qualifiers. ArthurPSmith (talk) 16:15, 25 April 2023 (UTC)

It definitely should be three items, if the EN Wiki article is a bonnie & clyde. --Tagishsimon (talk) 18:15, 25 April 2023 (UTC)

@Afaz, Tagishsimon: Well this case seems more "Bonnie & Bonnie's reanimated body" than "Bonnie & Clyde", but either 2 or 3 items would be ok with me. ArthurPSmith (talk) 19:21, 25 April 2023 (UTC)

item-requires-statement constraint for fictional location

capital of (P1376) has two item-requires-statement constraint that do not need to apply to fictional items (eg Messantia (Q5703763)): GeoNames ID (P1566) and coordinate location (P625). Some time ago, I requested a way to add exceptions in these cases. Can you help me please? Thank you. --Fantastoria (talk) 18:16, 25 April 2023 (UTC)

Wildly niche WD copyright question

All structured data from the main, Property, Lexeme, and EntitySchema namespaces is available under the Creative Commons CC0 License; text in the other namespaces is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy.

Since item descriptions aren't really structure data, are they CC BY SA 4 (as they would be for text on WD talkpages)? It affects what license I give screenshots of Wikidata items. T.Shafee(evo&evo) (talk) 12:09, 26 April 2023 (UTC)

I personally would see the descriptions as counting as they Item -> description -> short sentence has some structure but I don't know whether this legally works. If you care about that talking with Lydia and/or Wikimedia legal to get a better formulation would make sense. ChristianKl ❪✉❫ 12:17, 26 April 2023 (UTC)

It's for publishing screenshots in an academic journal that is otherwise CC BY 3.0. They're keen to be specific about the attribution I use for images (current attributions added below). The fifth one seems like link overkill, but if the history pages for each description need to be linked to, I think that's the safe option! @Lydia Pintscher (WMDE) Do you have an opinion on this? No worries if not, and I'll email legal.

Current attribution = These screenshots contain structured data released under a CC0 licence and descriptive text released under a CC BY SA 4.0 by their contributors (panel B, panel C); Panels B and C are therefore also licensed CC BY SA 4.0.

Current attribution = The map image is produced under a CC BY SA 4.0 licence using basemap shapefiles by OpenStreetMap under an Open Data Commons Open Database License (ODbL); Panel C is therefore also licensed CC BY SA 4.0.

Current attribution = These screenshots contain only structured data released under a CC0 licence.

Current attribution = This screenshot contains text released under a CC BY SA 4.0 licence by its contributors; This figure is therefore also licensed CC BY SA 4.0.

Current attribution = This screenshot contains structured data released under a CC0 licence and descriptive text released under a CC BY SA 4.0 by their contributors (property 1, 2, 3, 4, 5); This figure is therefore also licensed CC BY SA 4.0.

T.Shafee(evo&evo) (talk) 12:46, 26 April 2023 (UTC)

Thanks for the ping! The intention of the wording in the footer was to have it include descriptions under the broad term of structured data. So they are CC-0 as well. Lydia Pintscher (WMDE) (talk) 16:10, 26 April 2023 (UTC)

Thanks - that should simplify several of the attribs since 1,3,5 only contain CC0 text and data. I think therefore that only figs 2 and 4 will still need to by ccbySA4 for the map image and projectspace screenshots respectively. T.Shafee(evo&evo) (talk) 03:41, 27 April 2023 (UTC)

Seeking volunteers for the next step in the Universal Code of Conduct process

More languages • Please help translate to your language

Hello,

As follow-up to the message about the Universal Code of Conduct Enforcement Guidelines by Wikimedia Foundation Board of Trustees Vice Chair, Shani Evenstein Sigalov, I am reaching out about the next steps. I want to bring your attention to the next stage of the Universal Code of Conduct process, which is forming a building committee for the Universal Code of Conduct Coordinating Committee (U4C). I invite community members with experience and deep interest in community health and governance to nominate themselves to be part of the U4C building committee, which needs people who are:

• Community members in good standing
• Knowledgeable about movement community processes, such as, but not limited to, policy drafting, participatory decision making, and application of existing rules and policies on Wikimedia projects
• Aware and appreciative of the diversity of the movement, such as, but not limited to, languages spoken, identity, geography, and project type
• Committed to participate for the entire U4C Building Committee period from mid-May - December 2023
• Comfortable with engaging in difficult, but productive conversations
• Confidently able to communicate in English

The Building Committee shall consist of volunteer community members, affiliate board or staff, and Wikimedia Foundation staff.

The Universal Code of Conduct has been a process strengthened by the skills and knowledge of the community and I look forward to what the U4C Building Committee creates. If you are interested in joining the Building Committee, please either sign up on the Meta-Wiki page, or contact ucocprojectwikimedia.org by May 12, 2023. Read more on Meta-Wiki.

Best regards,

Xeno (WMF) 19:00, 26 April 2023 (UTC)

Claims about UTC offsets added to hundreds of items

[11] - are such edits desired? If something is located in a specific city or sometimes country, the offset can be inferred them item. Shall it be added to each street, building, entrance, memorial, tree, tower, grave etc. individually? GeoGQL (talk) 02:54, 27 April 2023 (UTC)

They seem pointless, but the user has been inactive since May last year. In an ideal world

located in time zone (P421) would have usage constraints, and a tidying bot would remove them, but we are a long way from consensus about 'useful edits', see the language label discussion above. Vicarage (talk) 03:43, 27 April 2023 (UTC)

same claims repeated, mix of claims and reference sculpture (Q860861) etc p170, disturbing tl:artwork

The new user User:Markraf6969 claims working in a project of the university of Florence and is not editing in compliance with our rules. His edits were discussed before here Wikidata:Project chat/Archive/2023/03#P2561. He is editing e.g Mary Magdalene by Desiderio da Settignano (Q3842297), two claims for sculpture (Q860861), and 2 different creator (P170). He references two Vasari editions from 1903 and 1568 (imagine he would do dozens more). As is the case with 1568 and 1903 these are historical references, so you may not use stated in (P248), as it is not scholarly proven with regard to actual research. Without different statements and ranks and by this lot of information our users cannot see the real creators etc. I doubt, that this historical emphasis of this user is within the general educational scope of this encyclopedic project. I think that his repeated use of the same property like p170 together with P585 ist not correct. It should all be done by references only and point in time (P585) is not necessary, because the references are stating their dates anyway. A great problem with art, where we use tl:artwork is, that when

User:Markraf6969 uses repeatedly the claims, especially creator (P170), it shows 3 times the creator template in tl. artwork which is a great mass and causes too much unuseful and disruptive data. I therefore want to inform the

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Musedata102 (talk) 20:27, 26 November 2019 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
User:Martingggg
Zeroth (talk) 02:21, 4 June 2018 (UTC)
User:7samurais
User:mrtngrsbch
User:Buccalon
Infopetal (talk) 17:54, 9 August 2019 (UTC)
Karinanw (talk) 16:38, 24 March 2020‎ (UTC)
Ahc84 (talk) 17:38, 26 August 2020 (UTC)
User:BeatrixBelibaste
Valeriummaximum
Bitofdust (talk) 22:52, 26 March 2021 (UTC)
Mathieu Kappler
Zblace (talk) 07:22, 24 December 2021 (UTC)
Oursana (talk) 13:16, 17 May 2022 (UTC)
Ham II (talk) 08:30, 25 January 2024 (UTC)
DaxServer (talk) 16:00, 24 May 2024 (UTC)
User:Ebakogianni
User:Jerimee
User:Archivalbrowser
User:Daehan

Notified participants of WikiProject Visual arts.

So tl:artwork shows three times the creator via wikidata by User:Markraf6969 incorrect edits.  – The preceding unsigned comment was added by Oursana (talk • contribs) at 06:14, 27 April 2023‎ (UTC).

@Elizium23--Oursana (talk) 04:19, 27 April 2023 (UTC)

• We don't have any rules that forbid using historical references for stated in (P248). If there are historical references and they are wrong, deprecate the relevant claim instead of deleting it. ChristianKl ❪✉❫ 11:04, 27 April 2023 (UTC)
  • But we certainly have the rule not to damage tl:artwork, and using historical material must be in the right relation. The user must himself deprecate, otherwise he cannot edit. Or who is going to repair it--Oursana (talk) 12:27, 27 April 2023 (UTC)

    Can you link to the rule you are referring to? ChristianKl ❪✉❫ 12:50, 27 April 2023 (UTC)

Special ways of describing the labels

Hello everyone. I don't want to provoke any conflict/editwar, just curious if such an identification of context can be acceptable as a kind of description, and if it complies with Genus–differentia definition (not my words, was somewhat blessed to learn what it is). -- Wolverène (talk) 06:24, 27 April 2023 (UTC)

Wikidata descriptions are not definitions. Wikidata items are defined by their statements. One of the primary purposes of description in Wikidata is diambiguation and that descriptions you linked helps with that. It's possible to have a better description than that but it's better than nothing. ChristianKl ❪✉❫ 10:51, 27 April 2023 (UTC)

Should we have WikiProject:mul?

The labels in many languages debated has shown that the implementation of a mul(tiple) language code is complicated, needing discussion on its purpose, replacement of en, possible mass deletions of entries, education on its performance benefits, SPARQL queries etc. A quick go on test.wikidata.org suggests the implementation there still has problems. I think a new WikiProject be a good focal point? Vicarage (talk) 07:20, 27 April 2023 (UTC)

I think a help/mul page along with it's talk page would be better than a Wikiproject. ChristianKl ❪✉❫ 10:43, 27 April 2023 (UTC)

Q: re: Statement/Employer

I am actively editing articles about architecture, design, and the arts (and adjacent subjects) on Wikipedia, and have become increasingly interested in (and active on) Wikidata. I would appreciate guidance concerning the definition of what constitutes a valid "Value" under the statement "Employer". A specific example is the industrial designer Richard Sapper (Q64699): currently, the only P108 value listed is the Stuttgart State Academy of Art and Design. My question is whether companies with whom the designer maintained a long-term professional relationship such as IBM, Alessi, and Brionvega should be included here too (i.e., is a client/professional relationship considered "Employment" in this case, regardless of the nature of the contracts between the parties)? Cheers, Cl3phact0 (talk) 07:20, 27 April 2023 (UTC)

Hello @Cl3phact0, Arch2all: something similar has been discussed in March at Wikidata:Forum/Archiv/2023/03#Neue Property für (Büro-)Partner sinnvoll?

Related properties for business relationsships between people and organisations might be:

• Property:P108
• Property:P127
• Property:P169
• Property:P1037
• Property:P1327 - also see Property_talk:P1327#Broadening
• Property:P1416
• Property:P2652
• Property:P2828

M2k~dewiki (talk) 13:34, 27 April 2023 (UTC)