Shortcuts: WD:PC, WD:CHAT, WD:?
Wikidata:Project chat
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
|
- 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á
- 中文
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/12. |
Allowed-entity-types constraint
[edit]Hi everyone, I am new-ish to wikidata and describing commons uploads on wikidata. What is the allowed-entity-types constraint? For example on File:2022 Australian federal election Wright alluvial diagram.svg and commons:File:World War II Allies to Axis GDP Ratio.svg.
On the alluvial diagram pages (one for every seat) I have office contested (P541): member of the Australian House of Representatives (Q18912794), with qualifier electoral district (P768): Wright (Q2594455) (or whatever seat it is)
On the allies to axis chart, I have category combines topics (P971): World War II (Q362) & economics (Q8134)
Both of these say allowed-entity-types constraint, saying "The property should not be used on this type of entity, the only valid entity type is Wikibase item.". Can someone explain? I have tried reading the help pages, although I don't really understand still. Is it because they are images not items? How would I otherwise describe these in a structured data way, or should I just be not going that deep with it? MarkiPoli (talk) 15:02, 30 November 2024 (UTC)
- @MarkiPoli: I don't understand why you're getting that error, but maybe somebody with more experience with the Commons structured data should comment. But to answer the question on entity types - it's basically within Wikidata determined by the prefix letter. Qxxx is a Wikibase item, Pxxx is a Wikibase property, Lxxx is a lexeme, etc. ArthurPSmith (talk) 16:00, 2 December 2024 (UTC)
- Properties have statements indicating where and how they are intended to be used. Properties like creator (P170) or copyright status (P6216) have the statements property constraint (P2302)allowed-entity-types constraint (Q52004125) with the values Wikibase item (Q29934200) (use on Wikidata items) and Wikibase MediaInfo (Q59712033) (use in Structured Data on Commons). The properties you used on those files, on the other hand, weren't created or intended to be used on Commons to model the content of files. So they don't have the Wikibase MediaInfo (Q59712033) value and throw an error when used there.
- category combines topics (P971) for example is intended for use on Wikidata items about categories, not on files. You'd probably have to ask over on Commons (commons:Commons talk:Structured data) about how they want to model this kind of file content. It's indeed possible that the Commons community didn't think about modelling the contents in such a detailed way. --2A02:810B:581:C300:FD46:81F6:126F:B70E 07:19, 4 December 2024 (UTC)
Recently, User:Daask merged most frequent value (Q74524855) (before: "most frequent value") and most frequent value (Q71538638) (before: "generally used form"). I wonder if that was right since Q7452455 was defined as being a facet of (P1269) point estimation (Q1192065), while Q71538638 was a facet of (P1269) name (Q82799). What do you think? Dorades (talk) 16:48, 30 November 2024 (UTC)
- I don't know if point estimation (Q1192065) should have been there, but Q71538638 was originally only about forms of a name, not for other values, although it was being used in other ways, in some cases where Q74524855 would have been better. Peter James (talk) 20:48, 30 November 2024 (UTC)
- I feel like both have the same meaning as Wikibase reason for preferred rank (Q71533077) and can't think of an example where it's worth distinguishing the two concepts. ChristianKl ❪✉❫ 15:50, 4 December 2024 (UTC)
This conversation should also cover generally used form (Q112627455), of which I was previously unaware, but seems largely identical to the pre-merge Q71538638. The statement generally used form (Q112627455)subclass of (P279)role (Q4897819) seems wrong in any case. @عُثمان: Pinging item creator for their input, but looking at the page history it seems like a duplicate created in a different language.
Returning to the remarks above, I don't see any utility in having a separate item specifically for name (Q82799) or personal name (Q115642094), if that's the issue.
Let's consider some of the ways these items are used on Wikidata:
Description of meaning | Examples |
---|---|
These are typical uses of "most frequent value". These are preferred because they are most commonly used in the way a value for this property is typically used (not in databases and records, unless that is the typical use for this property). They are used on items where a single value is expected to some degree. | |
Uses where there are multiple different values for a property which accepts multiple values, but one or some of these values are significantly more commonly used in the way a value for this property is typically used. I'm not sure this use of preferred rank is appropriate. I've started a discussion about given name (P735) of John Coltrane (Q7346) at Wikidata talk:WikiProject Names § Marking commonly and uncommonly used given names. | |
These mean something like "other statements are true, but would be misleading by themselves because this/these preferred statement(s) are the overwhelming majority. I feel like this should be a new item, but I'm not sure what to call it. I'm not sure what "use" would mean for the values of these properties, although they are intuitively similar to the last group. | |
A case where the description of "generally used form" seems apt, where there are two versions of what is regarded as the same name. In Wikidata terms, the values of the property could be linked together using said to be the same as (P460) and another database might merge them, but Wikidata has chosen to have separate items for the separate forms. I think "most frequent value" is appropriate for this meaning, but a separate item "most common form among related values" would be more precise. This could be a case for reverting the merge. | |
Uses for a personal name in the sense of "most frequent value" where the alternatives are not alternative forms of the same name and "most common form among related values" would not be appropriate. | |
These database records are "most frequent value" in the sense that they are most frequently used in the referenced external database itself, which is, I suppose, the way a Open Library subject ID (P3847) is typically used. "generally used form"/"most common form among related values" in the sense described above also makes some sense. However, I think most complete record (Q105749746) and/or most linked record (Q131399043) is most appropriate for these, and all Open Library subject ID (P3847) items using "most frequent value" should be replaced with those.
(most complete record (Q105749746) and most linked record (Q131399043) are essentially synonymous in this case, where the record is entirely generated from record linkages. When the record includes both metadata and linkages, they are sometimes different. Even with purely generated records, most linked record (Q131399043) could also include incoming links to the record from external sources in its consideration.) |
|
This is about most widely linked/frequently used value on Wikidata/Wikipedia. I think this is an improper use of any of the items or meanings we've discussed, but I'm not sure what would be. Should we use most complete record (Q105749746) where the object isn't an external record but is a Wikidata item? | |
This seems to mean something like "conventional level of precision". In my opinion, this would be a different item than any of the aforementioned meanings. However, while it's conceptually coherent and distinct, I don't think this is actually a reason for preferred rank that we should use on Wikidata, and instead would make the alternative the preferred rank using most precise value (Q71536040) in every case. It appears on a number of items, though, so obviously others disagrees with me. | |
I just replaced a number of uses of most frequent value (Q71538638) with best referenced value (Q98386534), where editors seem to have understood it as "most frequently used in known sources" |
I'm not sure what I recommend about all this, but don't want to delay sharing my thoughts and findings any longer. Daask (talk) 23:02, 6 December 2024 (UTC)
Do we have this Wikidata:Property proposal/role named as but for movies?
[edit]I was recently notified about Wikidata:Property proposal/role named as which is about video game credits. Do we already do something like this for movie cast in how their roles appear in the movie credits? SuperUltraHardCoreGamer (talk) 10:21, 1 December 2024 (UTC)
Date of Women and Men vote suffrage
[edit]We can probably use Wikidata to store the date when women+men suffrage was introduced by each country.
How to do that? Where to discuss this?
At the moment I'm proposing something like this.
To say Australia=1902 and Switzerland=1990 we could do:
- Australia (Q408)significant event (P793)introduction of universal suffrage for men and women (Q131367891)
point in time (P585)1902 - Switzerland (Q39)significant event (P793)introduction of universal suffrage for men and women (Q131367891)
point in time (P585)1971
Thanks for your opinion dear Wikidata hackers --Valerio Bozzolan (talk) 13:28, 1 December 2024 (UTC)
- P.S. thanks to "Nikki" for the above tip from Wikidata Telegram chat https://t.me/c/1224298920/137467 Valerio Bozzolan (talk) 13:30, 1 December 2024 (UTC)
- There are a lot of event that you could possibly store on the items of countries, but Wikidata is not doing well with having thousands of statements. I would rather have an item about the introduction in a given country and give that item the relevant statements. ChristianKl ❪✉❫ 01:13, 2 December 2024 (UTC)
- Introducing 200 new items seems less efficient than 200 statements. But it might be better adding those statements to introduction of universal suffrage for men and women (Q131367891) with country (P17) qualifiers than start a trend for adding events to countries, which could be huge and make the item unreadable Vicarage (talk) 01:30, 2 December 2024 (UTC)
- @Vicarage: What property do you suggest? --Valerio Bozzolan (talk) 06:59, 2 December 2024 (UTC)
- @Vicarage 200 statements to a single item is certainly better than adding it to individual countries.
- It's worth noting that universal suffrage for men and women means "all man in women" and many countries. That does include prisoners and many countries do not allow them to vote, Ireland for example only allowed that in 2006. The US does not have it.
- If you want to focus on the date where women where allowed to vote, women's suffrage (Q205204) is the better item. The personhood of prisoners is worth respecting. ChristianKl ❪✉❫ 11:42, 2 December 2024 (UTC)
- Its certainly a can of worms. https://commonslibrary.parliament.uk/research-briefings/cbp-7461/ show that even as late as 2018 England (but not Scotland)
- were changing the rules. But better to record the broad brush details than not at all. Devolution to Scotland shows why applies to jurisdiction (P1001) is better than country (P17) Vicarage (talk) 11:59, 2 December 2024 (UTC)
- "It's worth noting that universal suffrage for men and women means "all man in women" Depends whom you ask Trade (talk) 16:48, 6 December 2024 (UTC)
- Introducing 200 new items seems less efficient than 200 statements. But it might be better adding those statements to introduction of universal suffrage for men and women (Q131367891) with country (P17) qualifiers than start a trend for adding events to countries, which could be huge and make the item unreadable Vicarage (talk) 01:30, 2 December 2024 (UTC)
Rotten Tomatoes and Wikidata
[edit]When filling in the "Critic's response" in a film's en.wikipedia article, I update the Wikidata for the film, then use the following in the WP article:
{{RT prose|{{RT data|score}}|{{RT data|average}}|{{RT data|count}}|prose prose prose prose|ref=yes|access-date={{RT data|date}}}}
Short and sweet, very very convenient, automatically updates the WP article if some user later updates the Wikidata fields.
A challenge is that, if the information for the Rotten Tomatoes average rating has "/10" included in the Wikidata field, it results in a double "/10/10" appearing in the WP article. For example, for the 2021 film Oxygen https://en.wikipedia.org/wiki/Oxygen_(2021_film), putting 6.8/10 in the Wikidata field results in the en.wikipedia article displaying:
- ... of 106 critics' reviews are positive, with an average rating of 6.8/10/10.
The only way to avoid this is to not include the "/10" when filling in the Wikidata field, resulting in the en.wikipedia article properly showing:
- ... of 106 critics' reviews are positive, with an average rating of 6.8/10.
While this "workaround" resulted in a nice output for en.wikipedia articles, it has been brought to my attention, by de.wikipedia editor Eiragorn, that leaving out some of the extra detail in the cross-language shared Wikidata is resulting in issues for the templates used in the WP articles in other languages. The "workaround" to make the en.wikipedia template work is hurting other ill.wikipedia templates.
I should point out that, until very recently, this "double display" issue would also happen if the Tomatometer score, in the Wikidata file, had the "%" symbol included, resulting in a double "%%" appearing in the en.wikipedia article. For the Oxygen example, this produced:
- On the review aggregator website Rotten Tomatoes, 90%% of 106 critics' reviews...
It appears this has been fixed in the en.wikipedia template. In fact, it is "beyond fixed", as you can now do a Wikidata input with the digits by themselves (90), or the digits and the symbol (90%), and the result in always a single "%" appearing in the en.wikipedia article. For the Oxygen example, this now always produces:
- On the review aggregator website Rotten Tomatoes, 90% of 106 critics' reviews...
I checked with an en.wikipedia administrator today, who recommended discussing this with you good folks at Wikidata first, and asking here what the proper format for recording the information is in Wikidata. They pointed out that Wikidata might have some different way of recording the /10 denominator and that it was best to check if a user should - or shouldn't - include it in the Wikidata field. It was mentioned that you folks would also have the ability to introduce constraint violations or make mass edits to enforce the proper format. Once that's done, each of the Wikipedias would then work with that as a baseline.
If I have placed this discussion item on the wrong Wikidata page, please let me know and I will redo at the proper spot. Thank you, in advance, for your help and direction. Jmg38 (talk) 01:31, 3 December 2024 (UTC)
- review score (P444) usage seems to be X/Y for Rotten Tomatoes, and there is no constraint applied on the input to limit the characters used, so I think the onus is on WP to accept that as is. Clearly you could have a special WD review property "TripAdvisor stars", forced to 1-5, and WP formats that to add a '*', but that's not the case here, and I doubt we'd want lots of separate properties. Vicarage (talk) 10:31, 3 December 2024 (UTC)
- @Jmg38: Doesn't this work better:
{{RT data|prose|consensus=prose prose prose prose|ref=yes|access-date={{RT data|date}}}}
- Difool (talk) 13:27, 3 December 2024 (UTC)- Thank you, Vicarage and Difool. And a thank you to Indagate, who also pointed out that the long clunky nested templates I came across years ago were unnecessary, with just one minor reduction from the already significant improvement that Difool included above:
{{RT data|prose|consensus=text text text…|ref=yes}}
Overall, another terrific outcome from the wiki community. Thank you all. Jmg38 (talk) 19:01, 3 December 2024 (UTC)
- Thank you, Vicarage and Difool. And a thank you to Indagate, who also pointed out that the long clunky nested templates I came across years ago were unnecessary, with just one minor reduction from the already significant improvement that Difool included above:
- The examples of review score (P444) all are worded like X/Y. Wikipedia templates should be able to handle that. ChristianKl ❪✉❫ 16:04, 4 December 2024 (UTC)
'Founder of' property or similar
[edit]Hello everyone! I am scratching my head and can't come up with a reasonable alternative to 'founder of', which doesn't exist as a property presently. 'Founded by' already exists, so I am looking for its opposite.
Before I propose a new property, I wondered what alternatives there are? eg. Octavia Hill would be 'founder of' the National Trust; Alexander Keiller would be 'founder of' the Morven Institute of Historical research; Wallace Heaton would be 'founder of Wallace Heaton Ltd; Ivison Macadam would be 'founder of' the National Union of Students...
With thanks! Medievalfran (talk) 10:14, 3 December 2024 (UTC)
- We generally don't record symmetrical properties, as the query system makes it easy to query ?founded wdt:P112 ?founder to find the relation both ways. It keeps the number of statements down and reduces clutter. Vicarage (talk) 10:22, 3 December 2024 (UTC)
- This is previously proposed six times: 2013, 2016, 2016, 2017, 2023, 2024.--GZWDer (talk) 15:25, 3 December 2024 (UTC)
- If something's been proposed six times, that might be an indicator that we need it. DS (talk) 03:06, 6 December 2024 (UTC)
- Counterpoint: if something has been proposed and rejected 6 times, that might be an indicator it's not needed. William Graham (talk) 04:36, 6 December 2024 (UTC)
- If something's been proposed six times, that might be an indicator that we need it. DS (talk) 03:06, 6 December 2024 (UTC)
- This is previously proposed six times: 2013, 2016, 2016, 2017, 2023, 2024.--GZWDer (talk) 15:25, 3 December 2024 (UTC)
P31 = numeric identifier on Wikidata properties
[edit]Hello all friends of Wikidata properties! See my proposal regarding moving numeric identifier (Q93868746) from instance of (P31) to has characteristic (P1552) on Wikidata talk:WikiProject Properties. Thanks. Samoasambia ✎ 22:03, 3 December 2024 (UTC)
- Done. Apologies for floodig your watchlists. Samoasambia ✎ 00:21, 9 December 2024 (UTC)
Adding (Ancient) Egyptian lexemes from Thesaurus Linguae Aegyptiae
[edit]The Thesaurus Linguae Aegyptiae (Q122748326) project seeks to donate about 15T of approx 40T lexical entries of the Egyptian (Q50868) language in Leiden Unified Transliteration/Transcription (Q131362896) and Egyptian hieroglyphs (Q132659) to Wikidata. This is part of a cooperation project funded by the consortium Text+ (Q98271443) of the German National Research Data Infrastructure (Q61658497).
In a first batch, we are focusing on the main parts of speech, largely excluding proper noun (Q147276), title (Q216353), and epithet (Q207869). Examples: ḥꜣ.tï/𓄂𓏏𓏭𓄣 (L1391335), sw/𓇓𓅱 (L1385334), ẖr.ï/𓌨𓂋𓏭 (L1391360), ky/𓎡𓇋𓇋 (L1391327) wḏꜣ/𓅱𓍑𓄿𓂻 (L1385371); selected frequent proper nouns and titles, e.g. Wsꞽr/𓊨𓁹 (L1391321), Ppy (L1391324), nb-Tꜣ.wï/𓎟𓇾𓇾 (L1391331), ẖr.ï-ḥꜣb.t/𓎛𓌨𓃀 (L1391337); see also: https://situx.github.io/paleordia/language/?q=Q50868&qLabel=Egyptian, https://ordia.toolforge.org/language/Q50868.
We also created a language modeling page for Egyptian.
We are currently requesting a bot flag for our ThesaurusLinguaeAegyptiaeBot (talk • contribs • logs), so that we can perform maintenance tasks more efficiently in the future: Wikidata:Requests_for_permissions/Bot.
Any comment and support is very welcome.
Dwer (talk) 13:04, 4 December 2024 (UTC)
Wiktionary sitelinks in items for Unicodes
[edit]Are Wiktionary sitelinks in items for Unicodes allowed? Since they are inherently translingual/mul, would a sitelink to wikt:℥ in ℥ (Q87523885), along the other interwikts, be fine? LIrala (talk) 03:38, 5 December 2024 (UTC)
- As far as I see, it's not one of the expections that currently in https://www.wikidata.org/wiki/Wikidata:Wiktionary/Sitelinks , but I currently can't think of a problem that would come with adding an expection for it. ChristianKl ❪✉❫ 11:28, 5 December 2024 (UTC)
- Aren't Wiktionary sitelinks handled by Cognate? I'm not familiar with it, but I'd advise not to add any sitelinks unless it can't be handled by the existing mechanism. Infrastruktur (talk) 21:25, 5 December 2024 (UTC)
- But there is no way (property) for linking from wikidata to wiktionary entry, so existing mechanism isn't working here. JAn Dudík (talk) 09:07, 6 December 2024 (UTC)
- @LIrala: Why are sitelinks requested in the first place though? Is there a need to fetch data from Wikidata for the entries?
- @LIrala: Forgot to sign. Infrastruktur (talk) 14:15, 6 December 2024 (UTC)
- Wikidata doesn't require it unless it's for things outside mainspace, such as categories. However, for a Wikipedia article, it can be useful. fr:♌ vs wikt:fr:♌, w:🔞 vs wikt:🔞, pt:♀ vs wikt:pt:♀. Unicode items usually don't have non-redirect sitelinks to Wikipedia, there are a few. They would show at Wikipedia in the same Wikiquote and Commons are shown. LIrala (talk) 01:17, 7 December 2024 (UTC)
- Wikidata's data can be used without sitelinks, you just have to specify which entity you want to use. For example, incubator:Wp/sms/Kolari has an infobox generated from Kolari (Q543882) (even though sitelinks are not supported for Incubator) and wikt:bn:হৃদয় is generated entirely from হৃদয় (L301993) (even though lexemes don't support sitelinks at all). - Nikki (talk) 15:21, 7 December 2024 (UTC)
- No, they're not allowed. Wikidata:Notability excludes the main namespace and there is an abuse filter that tries to stop people from adding them. Wikidata:Notability/Exclusion criteria also excludes soft redirects like w:en:🔞.
- The main namespace in Wiktionary uses Cognate, not Wikidata, so adding them to Wikidata won't have any effect on Wiktionary pages. Wiktionary pages in the main namespace are also about specific text strings, whereas Wikidata items are about concepts. Wikidata does not support adding the same sitelink to multiple items, nor adding multiple sitelinks for the same wiki to the same item. For example, some people might want the Wiktionary page "♀" to be linked to ♀ (Q87526780), but others might want it to be linked to ♀ (Q13405286), and we can't do that.
- - Nikki (talk) 15:08, 7 December 2024 (UTC)
- Notability is only for item creation/deletion criteria, the items will exist (unless we mass delete all rule-basedly non-notable emojis and Unicode items). And they do have effect on Wiktionary pages, but only on desktop, such as the page we are at now (Project:Village pump (Q16503)). That filter isn't as strong as /doc or User: namespaces anyways. LIrala (talk) 23:51, 8 December 2024 (UTC)
I've noticed that within the last couple hours, more than a dozen users have registered accounts to create items about themselves, indicating they are members of mainzed (Q47213994). Is anyone aware of editor outreach or similar events happening with participants from Mainz University? William Graham (talk) 17:15, 5 December 2024 (UTC)
- I received a reply at User talk:Elisabeth Pilhofer. If anyone else wants to take a go at counseling this group of editors. William Graham (talk) 19:09, 5 December 2024 (UTC)
Annual Exhibition of the San Francisco Art Association
[edit]Hi, I have noticed that there are many items for these, but I can't find a generic one which would match the Commons category: c:Category:Annual Exhibition of the San Francisco Art Association. Should such an item be created, linking all the individual ones?
Idem for Annual Exhibition of San Francisco Women Artists, and c:Category:Annual Exhibition of San Francisco Women Artists. Thanks, Yann (talk) 11:18, 6 December 2024 (UTC)
This user seems not aware the multilingual nature of Wikidata labels, but I don't know what can be done.--GZWDer (talk) 12:41, 6 December 2024 (UTC)
Is there any way to curate suggested units?
[edit]It's always bothered me whenever i use "data size (P3575)" and type "gb" into the unit field that gigabyte (Q79738) is at the bottom. Is it really necessary to include the United Kingdom as one of the suggestions at all?
I just want a way to customize it so it fits to how i use the property (read; megabyte and gigabyte). Trade (talk) 16:51, 6 December 2024 (UTC)
- I'm not familiar with any script that adjusts this list, I share the same annoyances and am surprised it has such a low priority. Sjoerd de Bruin (talk) 10:06, 7 December 2024 (UTC)
- Currently we do have entity suggestions based on one-of constraint (Q21510859) and allowed qualifiers constraint (Q21510851) of the property. Adding a similar functionality to allowed units constraint (Q21514353) which is present on data size (P3575) would be a good idea. Samoasambia ✎ 11:02, 7 December 2024 (UTC)
- This is phab:T312962 (previously phab:T110673). - Nikki (talk) 15:27, 7 December 2024 (UTC)
Heads up -- I noticed an uptick of vandalism in certain items related to Mexico or Mexican politics.
[edit]As stated, I've noticed and cleaned articles that are related to Mexico or Mexican politics to have been vandalized by IP users. They're basically changing the name of articles to a non-sequitur name or to politicized names. TepeyacPilgrim (talk) 19:29, 6 December 2024 (UTC)
Gathering ideas for a Wikidata challenge for (Dutch) Wikipedians
[edit]Hi all! I am an active member of the gender gap working group on Dutch Wikipedia. We sometimes do small time-constrained challenges and activities, with a small reward (e.g. a book voucher) (example). Most of these challenges have been on Wikipedia itself, but we have been branching out to Wikiquote in the past year, participating in the international SheSaid challenge. There's a nice group of sympathetic Wikipedians on Dutch Wikipedia who actively participate in these.
Being mostly a Wikidatan myself, I am thinking of organizing a small challenge on Wikidata in 2025 around the Dutch-language gender gap (note that this is not only relevant for the Netherlands, but also other regions in the world where Dutch is spoken: Flanders, Suriname, etc.). I haven't organized any Wikidata challenges before and am curious if anyone has experiences and ideas.
I am already tracking the project's relevant Wikidata items via the on focus list of Wikimedia project (P5008)gender gap on Dutch Wikipedia (Q60687720) statement (incomplete, of course, but it's a start).
My current thoughts about such a challenge:
- It shouldn't take much time to organize and manage and track (for selfish reasons: I will be really busy next year)
- I'd like it to target Dutch-language Wikipedia editors who are sympathetic towards and curious about Wikidata. I would like to use the challenge as a springboard for them to learn more about Wikidata, and increase their skills and confidence contributing to Wikidata.
- I'd like the challenge to focus on improving existing Wikidata items (i.e. not creating new items). Adding and improving sourced statements, adding sources, improving sitelinks... mainly because I notice that this still needs a lot of work! We have so many items with barely any references, and I personally always discover items that can and should be improved.
But I welcome other ideas, taking into account that point #1 is really important :-)
My current questions:
- Has anyone here done a similar thing, and would like to share experiences?
- How could we track participation, contributions, and the quality of the contributions - specifically e.g. adding references? I know the Program and Events Dashboard allows some tracking of edits to Wikidata items, but in my experience it's very rough (I think it doesn't allow to track contributions to results of a specific Wikidata query, but I may be mistaken)
Any tips, ideas, suggestions and input welcome. Best, Spinster 💬 08:11, 7 December 2024 (UTC)
- I'm quite interested in this topic. Improving these items would give a good indication of notability for articles on Wikipedia as well. Wikidata:WikiProject Women/Wiki monitor/nlwiki has a few reports. Sjoerd de Bruin (talk) 10:53, 7 December 2024 (UTC)
Texas Tower Three
[edit]My husband was assigned to Texas Tower Three. I live in St Charles County Mo and they have a Veterans Museum. I would like to use the pictures I have of the Tower and tell the story do I have permission to copy the facts about TT3? to go along with the story about my husband's 20 years in the USAF. Whiteglovelady (talk) 15:15, 7 December 2024 (UTC)
- @Whiteglovelady Hi! Wikidata does not accept pictures, but you can contribute them to Wikimedia Commons. We don't accept stories either, but your photographs might be a good addition to en:Texas_Towers. Bovlb (talk) 19:56, 7 December 2024 (UTC)
Wikidata recentchanges replica incomplete?
[edit]For the popular items section on the main page, my bot queries the replica recentchanges table on Toolforge. Recently, the list was not updated anymore because the replica does not seem to contain any revisions beyond 2024-12-02, 10:12:17:
MariaDB [wikidatawiki_p]> SELECT rc_id, rc_timestamp, rc_namespace, rc_title FROM recentchanges ORDER BY rc_timestamp DESC LIMIT 3; +------------+----------------+--------------+------------+ | rc_id | rc_timestamp | rc_namespace | rc_title | +------------+----------------+--------------+------------+ | 2351040105 | 20241202101217 | 0 | Q51785014 | | 2351040104 | 20241202101217 | 0 | Q95947147 | | 2351040103 | 20241202101217 | 0 | Q131375221 | +------------+----------------+--------------+------------+
Did I miss some technical change to the database schema, or is something broken here? Special:RecentChanges does work without flaws and it does contain revisions up to now. —MisterSynergy (talk) 09:11, 8 December 2024 (UTC)
- Is this possibly connected to the lag reported on https://replag.toolforge.org/? --Dorades (talk) 10:26, 8 December 2024 (UTC)
- Yes it is, good to know. Has this been reported anywhere already? I wasn’t able to spot a related task in Phabricator, unfortunately. —MisterSynergy (talk) 10:28, 8 December 2024 (UTC)
- See this announcement on the cloud-announce mailing list. Sjoerd de Bruin (talk) 08:45, 9 December 2024 (UTC)
- It was also mentioned in the weekly summary (twice, like the cloud-announce email, because of the unexpected delay), though I don’t know how many people saw it there. But Dorades and Sjoerd are correct, and there’s not much that you can do other than wait for the schema change to finish and replication to resume (unless you can switch your use case to the API, which just like Special:RecentChanges is not affected). Lucas Werkmeister (WMDE) (talk) 10:35, 9 December 2024 (UTC)
- See this announcement on the cloud-announce mailing list. Sjoerd de Bruin (talk) 08:45, 9 December 2024 (UTC)
- Yes it is, good to know. Has this been reported anywhere already? I wasn’t able to spot a related task in Phabricator, unfortunately. —MisterSynergy (talk) 10:28, 8 December 2024 (UTC)
Latest label removals gone wrong?
[edit]Hi, @JnpoJuwan removed all 'Wikidata' labels from Wikidata (Q2013) and instead added a default label 'for all languages' (this is a new wikibase feature). In effect, only a few languages now have their own special label. I don't mind this but... my default language settings are Czech and I am now getting a Slovak label 'Wikiúdaje' as the item name on top of the Wikidata item page. Can this be customized so that the first preferred item label to display on top of the page is the 'default' version of the label? Vojtěch Dostál (talk) 19:54, 8 December 2024 (UTC)
- @Vojtěch Dostál oh dear, that is something weird. I do not have enough experience in the technical aspects of Wikidata, so please ping other users who are more knowledgable. JnpoJuwan (talk) 20:46, 8 December 2024 (UTC)
- Similarly, removing the English label from an American company like this made third-party reusers of the data showing raw Qids. Sure, they should perhaps update to fall back to mul, but I think it is reasonable to expect a label in the language of the item even if it is the same as mul. I suggest restoring all those labels (and always keeping one would help us track why the mul one was chosen). Ainali (talk) 09:33, 9 December 2024 (UTC)
- The Slovak label is presented due to MediaWiki language fallback chains where Slovak and Czech fall back on each other and only after that to the default label (mul). To my understanding these are defined for the whole MediaWiki software and not specifically for Wikidata. In most cases this fallback makes sense (e.g. if there is no Czech label for a person who's native name is writen in non-Latin characters, it makes more sense to present the Slovak translitterated label than the non-Latin default label) but in some cases like with Wikidata (Q2013) it may lead to unwanted results. I think a simple solution for these rare cases would be the best: just add a Czech label "Wikidata" to override the Slovak label and maybe add a short comment to the talk page explaining the reason for this action. Samoasambia ✎ 21:06, 8 December 2024 (UTC)
- @Samoasambia Yes, I thought it's something like that, but shouldn't we set the fallback in a way that it first falls back on the default mul label, and only then on the Slovak label? Vojtěch Dostál (talk) 08:31, 9 December 2024 (UTC)
- That sounds problematic when two linked languages are much closer to each other than mul, say those with different alphabets to mul. I'm not sure they've thought about this, the chain idea was new to me. Vicarage (talk) 08:42, 9 December 2024 (UTC)
- We discussed whether the
mul
fallback should come before or after the final, impliciten
fallback (and decided that it should bemul
beforeen
– except for languages that explicitly fall back toen
, such asen-gb
), but I don’t remember if we even considered puttingmul
before the language’s explicit fallbacks… to me that sounds like a strange idea. If themul
label has to be overridden in Slovak, then clearly it’s not suitable for all languages (which is fine, that’s why it can be overridden) – why should Wikibase assume that Czech speakers would be better served by themul
label than by the Slovak label, when MediaWiki says that Czech messages should normally fall back to Slovak translations (and vice versa) before English? - In the case of Q2013, I think the Czech label should not have been removed: labels should only be removed in favor of
mul
if that doesn’t change the displayed label, and in this case it did cause a change. If the removal was done by a bot, I’d say the bot code has to take the fallback chains into account (available in the API, by the way), though in this case it looks like it was actually done manually. Lucas Werkmeister (WMDE) (talk) 10:44, 9 December 2024 (UTC)- @Lucas Werkmeister (WMDE) All right, that sounds like a long-term solution. Let's not remove labels if the fallback chains cause Wikidata to display a different string. Vojtěch Dostál (talk) 11:13, 9 December 2024 (UTC)
- We discussed whether the
- That sounds problematic when two linked languages are much closer to each other than mul, say those with different alphabets to mul. I'm not sure they've thought about this, the chain idea was new to me. Vicarage (talk) 08:42, 9 December 2024 (UTC)
- @Samoasambia Yes, I thought it's something like that, but shouldn't we set the fallback in a way that it first falls back on the default mul label, and only then on the Slovak label? Vojtěch Dostál (talk) 08:31, 9 December 2024 (UTC)
Don't remove labels, we don't have any consensus for doing so and breaks stuff. Multichill (talk) 21:23, 9 December 2024 (UTC)
- @LiMrBot by @LiMr seems to be doing that too, perhaps a proper bot request should be started for that instead. Vojtěch Dostál (talk) 10:58, 10 December 2024 (UTC)
- a proper bot would be very appreciated. if the unintended errors by
are patched, please request that! JnpoJuwan (talk) 11:14, 10 December 2024 (UTC)mul
- a proper bot would be very appreciated. if the unintended errors by
Wikidata weekly summary #657
[edit]week leading up to 2024-12-09. Missed the previous one? See issue #656
Discussions
- New requests for permissions/Bot: KlaraBot - Task(s): Append a human's lifespan to descriptions when they can be authoritatively sourced.
- Closed request for comments: Audio transcription (P9533) - Closed with no consensus. The discussion is ongoing on the Property P5933 talk page.
Events
- Past: Amical Wikimedia, the Catalan-language and culture focused thematic Wikimedia Organization organized the Celebrem Wikidata (Let's celebrate Wikidata) project to celebrate Wikidata's 12th anniversary, from November 10 - 30. This included a Wikidata introduction workshop to equip participants with the editing skills to tackle the project's main aim. This was presented as a game to delete duplicate info on Wikidata and Catalan Viquipèdia infoboxes, in three areas: protected buildings, officers' positions and data related to sports teams players. At the end of the event, ~200 Wikidata-fed infoboxes and Wikidata items were improved and many Wikipedia editors edited Wikidata for the first time!
- Upcoming events:
- (Deutsch)Wikidata for Legal Historians - Tue. 10 December, 3pm - 7pm (UTC+1). This presentation explores Wikidata as a key platform for LOD, explains its Semantic Web foundation, introduces FactGrid (a Wikidata-based platform for historical research). Highlights potential of both platforms using examples and encourages discussion for legal historical research. Register here.
- Today (09.12.2024) is the last chance to submit an Abstract for the Wikidata and Research conference (5 - 6 June 2025). If you are interested in participating, please review the submission acceptance format before submitting here.
Press, articles, blog posts, videos
- Blogs
- MediaWiki Conference Highlights, featuring Wikibase talks including one by Christos Varvantakis and Jon Amar from Wikimedia Deutschland.
- Semantic Wikibase 2024 Update
- WMDE launches AI Knowledge project in collaboration with DataStax built with NVIDIA AI
- Ten years of Philippine local Govt. data for Wikidata's 12th Birthday. Read about SKAP's (Shared Knowledge Asia Pacific) efforts to add 10 years worth of financial data of local Government assets to Wikidata during a Datathon.
- Papers
- Developing an OCR - Wikibase Pipeline for Place Names in the RGTC Series - introduces a semi-automated workflow for extracting and digitally storing geographically relevant information, including spatial relations and contextual details, from place names in the Répertoire géographique des textes cunéiformes. By Matthew Ong (2024).
- Videos
- Wikibase4Research - Kolja Bailly presents ways in which the Wikibase4Research tool by the TIB Open Science Lab supports researchers in dealing with Mediawiki software for knowledge bases such as Wikibase and facilitates better and FAIR Research Data Management. Includes a live demonstration and beginner-friendly instructions.
Tool of the week
- CAT🐈: Metrics computing simple metrics (number of labels, number of descriptions, number of sitelinks, number of statements) for item matching a simple claim.
Other Noteworthy Stuff
- Template:Image properties New template listing properties that link to images.
- Let's Connect invites you to get involved in helping spread awareness and knowledge of Wikidata, potentially help organise a Wikidata Learning Clinic. Are you interested in participating? Please sign-up on this registration form.
Newest properties and property proposals to review
- Newest properties:
- General datatypes:
- reference illustration (an illustration of this subject to provide a detailed reference for its appearance. It should be ideally tied to the primary literature on the item.)
- External identifiers: Gallimard author ID, Football Kit Archive ID, Bibliothèque du Séminaire de Tournai author ID, Bibliothèque du Séminaire de Tournai publisher ID, Reg-Arts artist ID, EU Corporate body code, PBY Ben-Yehuda dictionary identifier, Academic Dictionary of Lithuanian entry ID, L'AF au champ d'honneur ID, Radio Algeria tag ID (Arabic), Radio Algeria tag ID (French), The American Heritage Dictionary of the English Language entry ID, Kamus Dewan Edisi Keempat ID
- General datatypes:
- New property proposals to review:
- General datatypes:
- land acknowledgement (acknowledgement of indigenous or native people whose ancestors lived at a location)
- homonym of (taxon item of which the taxon name is an exact homonym)
- taxon known by this common name (taxon item of which this common name refers)
- External identifiers: PCGames.de product ID, AniSearch character ID, Hachette author ID, El Watan tag ID, Albin Michel author ID, DNCI label ID, Battle.net game ID, Collectie Nederland ID
- General datatypes:
You can comment on all open property proposals!
Did you know?
- Query examples:
- Newest WikiProjects:
- WikiProject Highlights:
- Newest database reports: Unauthorized Bots - A list of bots and their edits, operating without a Bot flag.
- Showcase Items: Das Erste: A German public service television channel broadcasting for more than 70 years.
- Showcase Lexemes: Kerzu (L8153) the Breton word for December, directly translates from "totally black", rather appropriate for the cold, dark last month of the year.
Development
- 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.
Weekly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Contribute to the showcase Item and Lexeme above.
- Govdirectory weekly focus country: Ghana
- Summarize your WikiProject's ongoing activities in one or two sentences.
- 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!
Temporary Accounts - introduction to the project
[edit]The Wikimedia Foundation is in the process of rolling out temporary accounts for unregistered (logged-out) editors on multiple wikis. The pilot communities have the chance to test and share comments to improve the feature before it is deployed on all wikis in mid-2025.
Temporary accounts will be used to attribute new edits made by logged-out users instead of the IP addresses. It will not be an exact replacement, though. First, temporary users will have access to some functionalities currently inaccessible for logged-out editors (like notifications). Secondly, the Wikimedia projects will continue to use IP addresses of logged-out editors behind the scenes, and experienced community members will be able to access them when necessary. This change is especially relevant to the logged-out editors and anyone who uses IP addresses when blocking users and keeping the wikis safe. Older IP addresses that were recorded before the introduction of temporary accounts on a wiki will not be modified.
We would like to invite you to read the first of a series of posts dedicated to temporary accounts. It gives an overview of the basics of the project, impact on different groups of users, and the plan for introducing the change on all wikis.
We will do our best to inform everyone impacted ahead of time. Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms. At conferences, we or our colleagues on our behalf are inviting attendees to talk about this project. In addition, we are contacting affiliates running community support programs.
Subscribe to our new newsletter to stay close in touch. To learn more about the project, check out the FAQ and look at the latest updates. Talk to us on our project page or off-wiki. See you! NKohli (WMF) and SGrabarczuk (WMF) (talk) 00:00, 10 December 2024 (UTC)
Wikipedia Library link as reference url
[edit]Hello, in my watchlist I noticed a Wikipedia Library link used as reference url P854 (diff). In my opinion, the Wikipedia Library is very useful to found sources and access paywalled pages, but it is not to be used as a link for referencing items, because the link should be directly to the source, without the wikimedian access. I am right or it has never been discussed before? However, in this specific case I can't found a different link to the source, so I don't know what is best to do. (I notify also @RabbitFromMars who added the source.) Una tantum (talk) 11:10, 10 December 2024 (UTC)