Wikidata:Project chat/Archive/2023/07

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


Tool to identify or create items based on OSM？

https://www.openstreetmap.org/way/1161077977

i want to find the corresponding item, or create one if it doesnt yet exist. is there a tool for doing this conveniently? (so that when i create an item i dont have to manually copy paste data one by one?) RZuo (talk) 09:58, 25 June 2023 (UTC)

User:Bovlb/osm.js will add a link to the navbar for items that have a Wikidata mapping on the OSM side. Bovlb (talk) 14:33, 26 June 2023 (UTC)
That only works if OSM has a link to Wikidata. Now there's a new item (Q120025513) but I think it's a duplicate of Q84764643. Peter James (talk) 17:22, 1 July 2023 (UTC)

How to say a camera (Zeiss ZX1) has Adobe Lightroom built in

Hi all

I just wrote the English Wikipedia article for the Zeiss ZX1 camera Q115683385 and I want to include a statement on the Wikidata item that says it has Adobe Lightroom built in, its the only camera ever made to have this so feels important to include. Any suggestions very welcome

Thanks

John Cummings (talk) 19:59, 29 June 2023 (UTC)

maybe compatible with (P8956)? BrokenSegue (talk) 16:47, 30 June 2023 (UTC)
@John Cummings: I've used has part(s) (P527) to indicate it. I don't believe compatible with (P8956) would be appropriate because the compatibility isn't in question, it's the fact the software is included onboard. Different things. — Huntster (t @ c) 23:21, 30 June 2023 (UTC)
Super, thanks very much. John Cummings (talk) 13:28, 1 July 2023 (UTC)

Wikidata:Property proposal/Generic

Good evening! I have a very big question for the dear Wikidata contributors - why is this property creation page not being unloaded by creating new ones? There are about 60 properties in the pipeline and the pace of creation needs to be accelerated, given that the waiting time for some can exceed 3 weeks. MasterRus21thCentury (talk) 21:31, 30 June 2023 (UTC)

Hello @MasterRus21thCentury: after the last request/ping to WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. in March 2023 the backlog has been reduced from around 70 to 35 properties:
M2k~dewiki (talk) 15:17, 1 July 2023 (UTC)
This time the notification did not work due to a limitation of maximum 50 users: Wikidata:Project_chat/Archive/2023/03#A_bot_for_notifying_Wikiprojects M2k~dewiki (talk) 15:19, 1 July 2023 (UTC)

Hi, can someone add 市鎮 (保加利亞) to the link of item Q1906268? Here's a new article on Chinese version. 2001:B400:E33C:8182:7CDE:433E:72E4:548A 17:41, 1 July 2023 (UTC)

✓ Done --Wolverène (talk) 18:08, 1 July 2023 (UTC)

Link the Wikidata with a Article in Wikipedia ( Spanish Edition)

(Q116202453) are the data belongs to the Argentinian Actress Maria Eugenia Rigon, its linked to his spanish article, but dont show the correc charter as in other Biography.

Any can give some advice about how create nore faster the charter?

Best Regards

George Barahona GEORGEB1989 (talk) 23:24, 6 July 2023 (UTC)

@GEORGEB1989: If I understand you correctly, your problem is that the actor's biographical details do not show up on the side of the page; that is, there is no "infobox". I believe you can fix this on the Spanish Wikipedia by adding {{Ficha de persona}} to the page. Bovlb (talk) 00:17, 7 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Bovlb (talk) 15:46, 7 July 2023 (UTC)

Merging

Should curly hair (Q111189857) and curly hair (Q1636584) be merged? I find it hard to tell if the items refer to the same concept--Trade (talk) 21:36, 2 July 2023 (UTC)

They appear to be different things. The former is type of hair (inherent quality) and the later is a hairstyle (natural or not). -- William Graham (talk) 02:55, 3 July 2023 (UTC)

Inconsistent policy to inverse properties/statements

@ChristianKl, Yair rand, Hrishikes, ديفيد عادل وهبة خليل 2, DannyS712, Daniel Baránek:

On the one hand we have tens of inverse properties that are massively and routinely used, and in some cases, complementary inverse statements are even required via edit dialog and its warning messages, on the other hand, requests to create new properties are often adjudged by people who consider (all?) inverse properties and complementary statements redundant and undesirable.

For example, we have inverse properties repeals (P3148) and repealed by (P2568). However, amended by (P2567) has not its inverse property and the creation request was rejected, the proposer's arguments were ignored and attempts to reopen the discussion are blocked and rejected.

I'd also prefer if complementary statements (symmetric as well as inverse) were designed more intelligently and reliably from the start, so that two items could be linked to each other by a statement mutually in a bilaterally functional way without having to be duplicated. Unfortunately, such a solution was not chosen.

A situation where some inverse and symmetric statements are systematically and massively used and supported, while others are resisted and rejected as redundant, is fatally inconsistent. We should take a consistent position.

  • Nowadays, for each property that refers to another item in the parameter, there should exist a complementary property, and it should be ensured by bots that each statements is promptly mirrored by (automatic) creating a complementary statement.
  • In the future, as soon as the database structure and user interface state allow, all pairs of complementary properties and complementary statements should be merged. Currently, however, Wikidata does not have a two-sided-statements feature.

In the first phase, it is therefore necessary to direct those colleagues who resist the creation of inverse properties, and to create inverse properties systematically to all properties that refer to another item and lack the inverse property, and create tools that will systematically, efficiently and reliably maintain pairs of complementary statements. For the second phase, it is possible to consider how to merge these pairs without having to mirror the statements by duplication. ŠJů (talk) 13:17, 27 June 2023 (UTC)

Basically, you argue that we should do something without providing any argument for why you think value gets created by the change and without considering the costs of the change. Given that Wikidata wants to support SPAQRL queries we use databases that are not easily scalable. If we have less data duplication we can have more total data. We had times in the past where we had to rate limit edits because the software could not handle the amount of edits we wanted to happen. This is important enough that WMDE is working to reduce data duplication via steps like developing 'mul'.
Wikidata's UI is poorly made for displaying items which have a thousands or even a hundred claims for a given property.
The status quo is compatible with "we only have inverse statements when there's an explicit argument for why this particular case needs an inverse statement but generally we don't have inverse statements for all properties". ChristianKl ❪✉❫ 13:37, 27 June 2023 (UTC)
@ChristianKl: The mentioned example with existing repeals (P3148) and the missing and rejected analogous "amends" property well illustrates the nonsensicality and inconsistency of your position. Rather, the reality is that most properties and statements that are intended to refer to an instance need a complementary statement. Exceptions should rather be justified, where there would be too many inverse statements in one page and where they would not make sense. The property "amends" (rejected by you) is surely not such a case. However, it is true that for statements referring to very general concepts (colours, materials etc.), the lists of inverse statements should be rather generated by the database query.
As for saving machine time and capacity, direct storage of inverse statements can often be more efficient, than if the UI pages (templates, infoboxes) had to repeatedly call complex functions to calculate them. If such functions are actually available to regular users. --ŠJů (talk) 02:09, 28 June 2023 (UTC)
When it comes to performance, there are problems that can be solved by throwing more hardware at them and other problems that can't be solved that way. Data can be mirrored over multiple servers to handle read requests but when it comes to writing data it's not as easy. ChristianKl ❪✉❫ 15:28, 29 June 2023 (UTC)
One attraction to me with inverse properties is it makes the data entry much clearer. For example its recommended that awards given are properties of people, but its helpful for the award page to have a list of winners. The two sides facets are well matched, not too many awards are made, people don't win too many. If WD could only store one value, but have the UI display and allow edits both ways, that would be very helpful, and reflect the triplet ethos. Vicarage (talk) 13:47, 27 June 2023 (UTC)
There's an inverse statements gadget that adjusts the UI to display inverse statements; perhaps it should be more widely advertised. So this UI adjustment is already available for those who wish to use it. But in general what you describe ("not too many awards are made, people don't win too many") is not the typical situation - and not universal even for awards. There are many cases where the inverse property would result in a vast and unsupportable number of statements on an item - for example country (P17). Some of the widely used "inverses" in Wikidata are only partial inverses where this statement explosion can happen on either end and so the recommendation is to use the property that results in the fewest statements on a single item. ArthurPSmith (talk) 14:10, 27 June 2023 (UTC)
@ArthurPSmith: A gadget which is somewhere hidden and needs to be "advertised" is usable for several very specialized users. Until such a tool is a default part of the user interface, such a function is unavailable and unusable for the vast majority of users.
Btw., country (P17) is principially redundant in cases where it duplicates located in the administrative territorial entity (P131), which is the vast majority of uses. The existence of country (P17) causes more duplication and harm than good. For location, located in the administrative territorial entity (P131) should be always preferred. All other uses should have specific properties as country of origin (P495), country of citizenship (P27), applies to jurisdiction (P1001), valid in place (P3005), country for sport (P1532), country of registry (P8047), holds diplomatic passport of (P11747) etc. However, the proposal to delete country (P17) as reduntant was once rejected, while the proposal to create an analogous property "municipality" was also rejected. Community decision-making here is fundamentally chaotic, arbitrary and inconsistent. --ŠJů (talk) 02:09, 28 June 2023 (UTC)
I find country very useful, because it avoids arbitrary depth SPARQL queries which often time out, its universally present, and its a quick way for humans to see context of an item, when assessing which native label is best copied into the English one for example. Yes machines know, or it could be a derived statement at the bottom of the document, but we need reports and the editor UI to work for people. The same applies for many inverses, where we aren't ready for ontological perfection Vicarage (talk) 05:39, 28 June 2023 (UTC)
There's always tension between arbitrariness and fixed policy. I would agree that Wikidata over the last years had little development of fixed policy. This has some advantages because it makes Wikidata often less bureaucratic than a project like the English Wikipedia but it also has drawbacks.
That said, having more clear policy would likely be good overall. That requires having discussions about what people think and then thinking about how to make out of those views a policy that ideally goes through a RfC. ChristianKl ❪✉❫ 15:46, 29 June 2023 (UTC)
@ŠJů: there is a lot to say about your point of view. I wonder if consistency is - in itself - desirable and I also wonder if we really are inconsistent on Wikidata.
But more pragmaticaly, there is one point that is very wrong. You seems to thank that inverse propeties goes in pair : A ⇆ B. This is not true: there is self-inverted property which are A ⇆ A (like spouse (P26)), there is also triple and quadruple of properties A, B, C, etc. (like father (P22), mother (P25), child (P40) and parent (P8810)).
Also, as pointed by ChristianKl, the one-to-many problem will completely break Wikidata, on a technical level but also on an intellectual level : entities with two many statements are just not readable (by human and by machine alike).
If you really want to be consistent, I would argue to delete all the inverse properties (except maybe the self-inverted ones), there is less than 6% of them, there are the outliers here.
PS: country (P17) and located in the administrative territorial entity (P131) don't have the same scope, the first one is more political while the second is more geographical, you can't deduceone from the other (or vice versa) ; 4.4 million item have P17 and not P131 (and most of them can't have a P131).
Cdlt, VIGNERON (talk) 17:05, 3 July 2023 (UTC)

Problem between two Wikidata pages

Hello! In wikidata there are two pages, Club Deportivo Badajoz and Club Deportivo Badajoz 1905. The first page is linked to the current Badajoz team and the second is linked to the Badajoz team that disappeared in 2012, the problem is that both Wikidata pages contain the same information (information about the current team). Also, the Wikipedia pages linked to these articles are mixed up, some CD Badajoz articles in a certain language lead to one Wikidata page and other languages ​​lead to the other Wikidata page. I would like to know how to solve this problem, as a help Club Deportivo Badajoz 1905 is the name with which the current Badajoz team was founded but today both are called exactly the same (Club Deportivo Badajoz). Gonzalo 11789 (talk) 11:52, 3 July 2023 (UTC)

https://ca.wikipedia.org/wiki/Club_Deportivo_Badajoz_(2012) and https://ca.wikipedia.org/wiki/Club_Deportivo_Badajoz_(1905) are clearly separate Wikipedia pages and thus the items can't be merged. You can create redirects to help with interwikilinks. ChristianKl ❪✉❫ 13:36, 3 July 2023 (UTC)
Hello @ChristianKl. I don't want to merge anything, what happens is that both Wikidata pages contain current information when only one should have it. The old Badajoz existed from 1905 to 2012 and the new Badajoz was founded in 2012 after the other disappeared. Gonzalo 11789 (talk) 14:06, 3 July 2023 (UTC)
@Gonzalo 11789, I've tried to clean up both items. Let me know if any issues remain. That said, can you find me a source that says the current club was renamed to drop the "1905"? — Huntster (t @ c) 15:31, 3 July 2023 (UTC)
Thank you very much @Huntster, here is a reference even though it is in Spanish. https://www.elperiodicoextremadura.com/deportes/2013/12/14/cdb-1905-pasa-llamarse-club-44683865.html Gonzalo 11789 (talk) 15:44, 3 July 2023 (UTC)
@Gonzalo 11789, thank you! I've updated the item appropriately. — Huntster (t @ c) 17:02, 3 July 2023 (UTC)

Wikidata weekly summary #583

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: koavf 3 (RfP scheduled to end after 8 July 2023 13:16 UTC)
    • Closed request for adminship: Wolverène Welcome onboard \o/
    • New requests for permissions/Bot: UrbanBot (Task: UrbanBot's task is to mass-add English descriptions to items that don't have one)
    • Closed request for permissions/Bot: RomesfulImporterBot (Task: Creating and updating Russian Lexemes by transferring information from the Russian Wiktionary)
  • Events
    • Upcoming
      • The third iteration of the WikiWomenCamp will be hosted in New Delhi, India, from the 20th to the 22nd of October 2023.

Scholarship applications are now open.

  • Tool of the week
    • m:User:Base/Scripts/HaveWikibaseLabelLowercased.js - is a Userscript that adds an arrow next to the main label (page title) which upon double click (a tap and a confirmation on touch devices) automatically makes the label's first letter lowercase for the current interface language. If there was already a matching alias it gets removed.
  • Other Noteworthy Stuff
    • The WikidataCon 2023 call for proposals is running until July 31st. If you have questions or need advice before sending a program proposal, join the program team during one of the office hour sessions (online or in Taiwan, in Chinese or in English). More information
    • Scholia has a new aspect dedicated to profiling WikiProjects, e.g. toolforge:scholia/wikiproject/Q56241615 for WikiProject Invasion biology. Using it revealed inconsistencies across WikiProjects in terms of which properties they use (and how) to associate a page with a WikiProject, as discussed here.
    • Introducing Wikibase World. The Wikibase registry has moved. Add an entry for your Wikibase if it's accessible over the open internet.
  • Development
    • Wikibase REST API:
      • We finished the GetProperty endpoint with fields filter and Conditional headers (phab:T338141, phab:T338138)
      • We started working on the endpoints for reading statement data of Properties (both a single statement, and a list of all of a Property’s statement) (phab:T339356), phab:T338383)
    • Ontology issue survey: We put together an overview of solutions for the various types of issues and will share them this week.
    • mul language code: We are continuing to work through the language fallback issues that were uncovered.


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.


Hi, I'm struggling to find a way to add the badge "proofread" to a Wikisource site link. Here's my current attempted Pywikibot function:

add_wikisource_page_to_item 
def add_wikisource_page_to_item(item, wikisource_page_title):
    site = pywikibot.Site("wikidata", "wikidata")

    # # Retrieve the Wikidata item
    item = item_page(site, item)
    transcription_data = {
        'site': 'enwikisource',
        'title': wikisource_page_title,
        'badge': 'Q20748092',
    }
    item.setSitelink(sitelink=transcription_data, summary=edit_summary('Adding enwikisource sitelink...'))
    print_in_green(f"Added enwikisource sitelink to {item}.")
working function 
def add_wikisource_page_to_item(item, wikisource_page_title):
    site = pywikibot.Site("wikidata", "wikidata")

    # # Retrieve the Wikidata item
    item = item_page(site, item)

    proofread_badge = ['Q20748092',]

    transcription_data = SiteLink(
        title=wikisource_page_title,
        site='enwikisource',
        badges=proofread_badge,
    )
    
    item.setSitelink(sitelink=transcription_data, summary=edit_summary('Adding enwikisource sitelink...'))
    print_in_green(f"Added enwikisource sitelink to {item}.")


This function does successfully add the site link, but it fails to add the badge. I'm not finding any documentation on how to do this. Does anyone have an idea on how to do this? Thank you. PseudoSkull (talk) 06:08, 4 July 2023 (UTC)

https://public-paws.wmcloud.org/User:MisterSynergy/demos/badges/set_badges.ipynb —MisterSynergy (talk) 06:40, 4 July 2023 (UTC)
Resolved. PseudoSkull (talk) 07:17, 4 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:06, 9 July 2023 (UTC)

Merge

Please merge Großrubatscher (Q119978773) and Großrubatscher (Q119978883). 158.181.71.74 16:33, 5 July 2023 (UTC)

→ ← Merged RVA2869 (talk) 16:42, 5 July 2023 (UTC)
Thanks. 158.181.71.74 16:43, 5 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:06, 9 July 2023 (UTC)

Merge

Please merge Al-Awadi (Q119998805) and Al-Awadi (Q116193063). 158.181.71.74 16:53, 5 July 2023 (UTC)

→ ← Merged. –– Yahya (talk) 17:56, 5 July 2023 (UTC)
Thanks. 158.181.71.74 18:23, 5 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:06, 9 July 2023 (UTC)

Merge

Please merge Cisterna (Q120162861) and Cisterna (Q114560968). 158.181.71.74 17:54, 5 July 2023 (UTC)

→ ← Merged –– Yahya (talk) 17:57, 5 July 2023 (UTC)
Thanks. 158.181.71.74 18:24, 5 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:06, 9 July 2023 (UTC)

Merge

Please merge Adlas (Q120379029) and Adlas (Q47485733). 158.181.71.74 13:34, 7 July 2023 (UTC)

✓ Done — Huntster (t @ c) 14:17, 7 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:06, 9 July 2023 (UTC)

Q10405147

In my opinion this data object should be called Emahmime instead of Algena. The small town in Eritrea is called Algena or Alghiena in OSM and Google Maps (whereas the latter has wrong coordinates for the town and the connecting road network). There are local sources in the internet for the name Emahmime (see sources in the German article that I wrote). According to the sources it is the biggest settlement of the Karura/Karora subzone and in a distance of 160 km north of Nakfa. So there is no other possibility which town has to be Emahmime - it must be the one that is called Algena/Alghiena in the mentioned online maps. Extra fact: in goolge maps at the correct coordinates of the town there is a tag "Mahmimet hospital". --Grullab (talk) 21:08, 3 July 2023 (UTC)

If you have done your research, renaming the items is okay. I think it would be good to add the alternative names as aliases so that it's still easily findable for people searching for Algena. ChristianKl ❪✉❫ 22:34, 3 July 2023 (UTC)
Thank you for your answer. I renamed the item and left the alternative name visible. --Grullab (talk) 06:18, 4 July 2023 (UTC)
The German article says they are the same, and Bing Maps shows this as Algena, but the map on page 72 of https://www.unocha.org/sites/unocha/files/SHF_2019_Annual_Report_08Jun20.pdf has these as separate places, with a place called Mebaa in between. Geonames.org has two IDs for Alghiena (344242 and 8381550; 344242 was originally Algena), and one for Mahmimet (8385397), but there are other places for which Geonames.org has three IDs and several different names. There seems to be nothing where the name Alghiena appears on the UNOCHA map, but it's possible that other groups of buildings such as https://www.openstreetmap.org/way/435212858 are named, and there seems to be an abandoned town north-east of Mahmimet/Algena. Peter James (talk) 19:14, 4 July 2023 (UTC)

Veikko Väänänen

Could you please help me find some source for awards given to Veikko Väänänen (Q2512005)?-- Carnby (talk) 06:30, 5 July 2023 (UTC)

Proposing a small change to the property creation policy (vote)

I would like to amend Wikidata:Property creation, changing the second criteria from "The proposal was made by somebody other than the property creator." to "The proposal was made by somebody other than the property creator. You should also not conclude a property proposal if you are the only person who have voted in the proposal.".

This is already common practice so it should be put into writing. Also I don't think it is necessary to require that a property creator who has voted can't close the proposal, assuming that more people has voted and there is no obvious conflict of interest. Vote closes in one week. Infrastruktur (talk) 14:54, 4 July 2023 (UTC)

In favor

Opposed

  •  Oppose. Property creation is already painfully long because of a lack of committed people all along the procedure. No need to slow it down even more when it's actually making things easier that would be needed. Thierry Caro (talk) 18:49, 4 July 2023 (UTC)
  •  Oppose Rules should be made to solve problems. If we just add rules whenever we feel like it, the amount of bureautic rules rises continously and that makes everything more complex. ChristianKl ❪✉❫ 21:45, 4 July 2023 (UTC)
  • Fair point. On the other hand: Wikidata is woefully underdocumented. It’s a good thing if we document tacit knowledge of current practice. --Emu (talk) 14:03, 5 July 2023 (UTC)
  • Assuming the proposal passes, this could allow Administrators to both involve themselves in property proposals and close them as well. As it is today, if you interpret the non-involvement rule pedantically ("Administrators should avoid using their tools to perform actions where there are credible concerns about their impartiality. Those situations include using the tools in disputes in which they are involved parties. "), this is something we are largely prevented from doing. Some text could be added to the policy to clarify that this restriction does not apply to Administrators closing a proposal as long as theirs is not the only vote, putting them on par with property creators. Infrastruktur (talk) 15:30, 5 July 2023 (UTC)
  • I would argue that admins, which require a greater level of trust, should indeed be subject to more restrictions such as not closing their own property proposals. I actually oppose allowing one to close their own proposal altogether but such a conflict of interest rule has not gained consensus to be policy in the past.—Jasper Deng (talk) 11:48, 6 July 2023 (UTC)
  • The problem this solves is that it is already an unwritten rule and people who create properties when they're the only supporter are likely to receive complaints (e.g. like happened here). - Nikki (talk) 13:33, 6 July 2023 (UTC)

Making Wikidata work better on narrow screens and mobiles

I've recently been working on some CSS to make the desktop Wikidata site more usable on narrower screens, including mobile devices.

You can find more information about it, including screenshots and how to enable it at User:Nikki/NarrowUI.

A few people have tried it already and haven't mentioned any problems, but please let me know if you have any issues. :)

- Nikki (talk) 14:24, 6 July 2023 (UTC)

Thanks for this, it works really well on narrow and wide displays! Piecesofuk (talk) 09:16, 7 July 2023 (UTC)

document file on Wikimedia Commons versus image

"document file on Wikimedia Commons" and "image" for a news article or book, are both available. Do you use both with images of the same document, or only one if they are going to be the same? See: T-Sgt. Ray C. Gill Back From Overseas (Q120411274), so only use one or keep both?. For some books we have the pdf of the entire book with a blank book cover for "document file on Wikimedia Commons" and a jpg of the title page for "image". RAN (talk) 02:10, 7 July 2023 (UTC)

"document file" is mostly used when when the work is a book or volume (or film), and the document file is thus many pages long as a PDF or DjVu (or video). The "image" for such items is usually the front cover, dust jacket, title page, or frontispiece. For a newspaper article, the same item can serve as both if the image is small enough, but a long article might use a photo appearing with/in the article could be the "image". --EncycloPetey (talk) 07:47, 7 July 2023 (UTC)

Identifier with hoax

One of our identifiers have a hoax entry. Is there a way we can block anyone from adding it to items in the future? Trade (talk) 23:09, 6 July 2023 (UTC)

Maybe you could use a none-of constraint. Bovlb (talk) 00:21, 7 July 2023 (UTC)
How do you use none-of constraint to block a specific value?@Bovlb:--Trade (talk) 18:04, 7 July 2023 (UTC)
Hmm. Now I look closer, it appears that only works for item-valued properties, so you can't use it for a string-valued identifier. @Multichill?
We could create an abuse filter, but that's a rather blunt tool. Bovlb (talk) 18:14, 7 July 2023 (UTC)

Can't transclude a property proposal

Hi all

I'm was sure I was doing this right but its not worked like three times, I'm pretty confident I'm following the rules... I've tried to transclude Wikidata:Property proposal/World Geographical Scheme for Recording Plant Distributions ID maybe three or four times and it seems to work but then I check the next day and it shows the error message again. Could someone do it for me? I have no idea what's going wrong...

Thanks

John Cummings (talk) 16:19, 5 July 2023 (UTC)

@MasterRus21thCentury appears to have moved it. Bovlb (talk) 17:35, 5 July 2023 (UTC)
Ah, ok, thanks for the explanation, does it matter if it still has the big red message at the top of the page? I don't care, as long as it all works. Cheers, 12:08, 6 July 2023 (UTC)
As it was moved to Wikidata:Property proposal/Place, you could try changing your template from {{Wikidata:Property proposal/Authority control}} to {{Wikidata:Property_proposal/Place}}. Ideally @MasterRus21thCentury would have done that for you when making the move. Bovlb (talk) 15:52, 6 July 2023 (UTC)
@Bovlb I have a good reason for this - the themes of these templates are more related to geography rather than authority control. In addition, the Generic and Authority control categories are faced with an overflow of new properties, which in turn requires them to be unloaded.
Also, I have a lot of objections to administrators and property creators due to the fact that the process of creating them has been very slow. MasterRus21thCentury (talk) 06:49, 7 July 2023 (UTC)
@MasterRus21thCentury To the best of my knowledge, no-one is complaining about your moving proposals to more appropriate pages (and everyone is complaining about the backlog in property creation), but the OP's concern was the mysterious reappearance of an error message on the proposal page. Is it unreasonable to ask you to fix this when you make the move? Is there a possible technical solution? Bovlb (talk) 18:23, 7 July 2023 (UTC)
The proposal template has a line that says "|topic = authority control". This line produces the error message when the proposal is not listed on the authority control page. It's what you would need to change to make the error message disappear. ChristianKl ❪✉❫ 11:09, 8 July 2023 (UTC)

New Wikidata Maps

Hi all,

Just a heads up that there are now Wikidata maps generated and visible on https://commons.wikimedia.org/wiki/Wikidata_map

The new files to look at would be 2023 level 100, 2023 level 5, 2023 level 1.

You can play around with the live tool, but WARNING, its rather resource intensive and might crash your browser, so beware and maybe open in a fresh / separate browser? https://wmde.github.io/wikidata-map/dist/index.html

I also created some diffs between 2021 and 2023, 1, 5, 100

Here is one for your viewing pleasure!

·addshore· talk to me! 08:49, 7 July 2023 (UTC)

awesome visualization thanks for making this. I don't really understand what the layers mean though they look cool. I'm glad there isn't a huge spike at null island. BrokenSegue (talk) 16:36, 7 July 2023 (UTC)
The TLDR for the layers is that...
- Every entity whose coordinates relate to a pixel add some amount of brightness of that pixel, with a redish glow.
- Pink are areas that have changed between the 2021 and 2023 images, most likely showing areas that have more geo coordinate coverage.
·addshore· talk to me! 05:53, 8 July 2023 (UTC)
I wrote a little blog post covering this update and diving into the "intensity" a little more. https://addshore.com/2023/07/wikidata-map-in-2023/ ·addshore· talk to me! 06:57, 8 July 2023 (UTC)
Thank you, as always very interesting! We still seem to have accuracy problems in Mexico though … Emu (talk) 17:23, 7 July 2023 (UTC)

Missing person

How best to show that Joseph Force Crater (Q4263399) is a missing person? RAN (talk) 14:04, 7 July 2023 (UTC)

has characteristic (P1552). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 8 July 2023 (UTC)

Hi,

Is it customary to self link a country? RVA2869 (talk) 09:40, 9 July 2023 (UTC)

Hi, what do you mean by “self link”? A country item linking to itself? --Data Consolidation Officer (talk) 09:47, 9 July 2023 (UTC)
@Data Consolidation Officeryes RVA2869 (talk) 10:08, 9 July 2023 (UTC)
Do you have an example where you’d like a country item to link to itself? In general, I don’t see a reason why items shouldn’t be allowed to link to themselves, but whether it makes sense obviously depends on what is to be expressed. --Data Consolidation Officer (talk) 10:28, 9 July 2023 (UTC)
@Data Consolidation Officer query:https://w.wiki/6zqu RVA2869 (talk) 10:42, 9 July 2023 (UTC)
I see. Some thoughts on this:
  • This is about linking sovereign states to their countries. Apparently in many cases the sovereign state and the country are represented by the same item. I have no idea whether this is good or bad, but assuming that it is good, the self link doesn’t look problematic.
    • I’d think that a sovereign state is identical to one country (itself), but I might be wrong. (The opposite is more likely to be wrong: I can imagine that not every country is a sovereign state.)
    • If so, there is probably no point in having separate items for a sovereign state and its country.
    • It might still make sense to separate them for consistentcy reasons. (Additionally, there is the issue of historical development, i.e. there may be cases where one country used to be a different sovereign state than today – although then one could argue that it’s also a different country.)
  • If this causes issues with queries (because the self link is not present on some items), wdt:P17? could be used instead. (This might induce duplicates, though.)
Maybe someone else will comment on this, too. --Data Consolidation Officer (talk) 10:57, 9 July 2023 (UTC)
I don't think the state/country distinction is the reason why it's done - this isn't something I've seen brought up before. That's just the way the example query has been written, I think?
The first discussion on this is abut ten years old, and there it was intended as a way to easily confirm that the item is a country. There are various ways this is useful when writing queries, and conceptually - well, it's a little unusual but it's not obviously wrong. Since then it's been a pretty widespread convention (so to answer @RVA2869's question: yes, it is customary). Andrew Gray (talk) 00:18, 14 July 2023 (UTC)
@Andrew Gray Thanks! RVA2869 (talk) 07:43, 14 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 18:28, 14 July 2023 (UTC)

Merge

Please merge Metsvahi (Q120478633) and Metsvahi (Q120478599). 158.181.71.74 04:48, 12 July 2023 (UTC)

✓ Done. --Wolverène (talk) 04:52, 12 July 2023 (UTC)
Thanks! 158.181.71.74 04:55, 12 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 18:28, 14 July 2023 (UTC)

Merge 3 and 4

1) Please merge Lindepuu (Q120442354) and Lindepuu (Q49163852).

✓ Done — Huntster (t @ c) 07:38, 12 July 2023 (UTC)
Thanks! 158.181.71.74 11:30, 12 July 2023 (UTC)

2) Please merge Saluveer (Q120462978) and Saluveer (Q60594602). 158.181.71.74 05:35, 12 July 2023 (UTC)

→ ← Merged RVA2869 (talk) 07:39, 12 July 2023 (UTC)
Thanks! 158.181.71.74 11:31, 12 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 18:27, 14 July 2023 (UTC)

Property to indicate names of websites?

I’ve just noticed that on items like Genealogics (Q19847326) or The Peerage (Q21401824) about websites, the website’s name is only present in the item’s labels, not as a property value.

  • Is this sufficient or would it make sense to have an explicit statement giving the website’s name?
  • If such an explicit statement is desirable, which property to use for it? title (P1476)? name (P2561)? Something else?

Thanks in advance for your ideas! --Data Consolidation Officer (talk) 12:30, 8 July 2023 (UTC)

official name (P1448). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:44, 8 July 2023 (UTC)
Thanks! --Data Consolidation Officer (talk) 09:22, 9 July 2023 (UTC)

English statements as preferred rank?

I noticed many statements are preferred because they are in English, like Q10894621, Q633839, Q312, Q37470 and so on. However Help:Ranking doesn't mention English should be preferred, nor is there a Wikibase reason for preferred rank (Q71533077) that specifies a statement is preferred because it is in English. I think they should all be lowered back to normal rank. Midleading (talk) 09:23, 9 July 2023 (UTC)

In the case of the latter three, I don’t think they are preferred because of language of work or name (P407)English (Q1860) but because the respective URL doesn’t indicate a language (e.g. https://www.un.org/securitycouncil instead of https://www.un.org/securitycouncil/ru or https://www.un.org/securitycouncil/es). Some websites (I haven’t tested for the above) will even have such a “language-agnostic” main page to redirect to the language of the visitor (according to their browser preferences). On Q10894621 I think the statement should be lowered to normal rank; no URL there is language-agnostic (and I don’t see why a Chinese museum should prefer the English version of its website). --Data Consolidation Officer (talk) 09:41, 9 July 2023 (UTC)
It seems sensible - as is the case in at least one of your examples - to prefer the home page (example.com) over a sub-page (example.com/foo), whatever the language of either. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:00, 9 July 2023 (UTC)

"expected" past events

Can somebody remove nature of statement (P5102): expected (Q50376823) as a qualifier from every statement of point in time (P585) where the point in time is in the past? Lights and freedom (talk) 04:07, 10 July 2023 (UTC)

presumably they should be looked at by hand to check if they actually ended up happening? BrokenSegue (talk) 05:47, 10 July 2023 (UTC)

Wikidata weekly summary #584

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Closed request for adminship: koavf 3 Welcome onboard \o/
    • New requests for permissions/Bot: FromCrossrefBot 1: Publication dates (Task/s: Using information from Crossref: 1 - Add publication date to items where they are not present in Wikidata 2 - Fix publication dates where they are erroneous)
  • Tool of the week
    • Duplicity is a tool on Toolforge that helps find articles on Wikipedia that do not have a Wikidata Item, and match them to an existing Item, or create a new one. (example for English Wikipedia)
    • HasProperty.js displays presence/absence of specific properties (configurable) after the Statements heading. Clicking a property name will jump to that properties section. For absent property, clicking property name will jump to the end of the page.
  • Development
    • Ontology issues: We published the overview of solutions and are looking for input on them now.
    • mul language code: We continued work on it focusing on showing it in the right place in the desktop termbox (phab:T316767)
    • Wikibase REST API: We continued working on the endpoints for reading statement data of Properties (both a single statement, and a list of all of a Property’s statement) (phab:T339356, phab:T338383)
    • Vector 2022 skin: We continued work on improving the search display (phab:T327510)
    • WMF Governance wiki is now connected to Wikidata so can be linked to in the sitelink section under multilingual sites (phab:T321967)

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.

How to handle licensing problems

Look at Q1055910#P1082 where the population by year was added to wikidata. But there is no clarification about the licensing and the source [1] says "© Hungarian Central Statistical Office, 2015", see page 3. How to handle this? --Poulsor (talk) 10:40, 25 June 2023 (UTC)

@Poulsor: The simple expression of facts (i.e., a list of population figures and their corresponding years) is generally considered to not be copyrightable, since there is no creativity in their expression. Now, how they are expressed in a particular work may be copyrightable if they are expressed in a creative way, but our use of these pop stats would not run afoul of this concept. Unless Hungary has some very unusual copyright laws I would think our use is okay, and that copyright you mention is applicable to the publication as a whole rather than the specific data points therein. — Huntster (t @ c) 13:24, 25 June 2023 (UTC)
en:Database right#European Union. --2A02:810B:580:11D4:5DB9:F4C3:580B:9714 19:23, 25 June 2023 (UTC)
Read Database Directive as well. I would argue that our use of that data would not constitute a breach as we're very selectively using small parts of that data. That said, this is of course just my opinion and I am not an expert in European law. — Huntster (t @ c) 19:49, 25 June 2023 (UTC)
See also Copyright: Hungarian Central Statistical Office (which is a bit strange - probably mistakes when writing the terms - but seems to indicate that the contents are CC-BY thus compatible with Wikidata). Cheers, VIGNERON (talk) 21:17, 25 June 2023 (UTC)
Thanks to all. But Wikidata makes its data available under CC0, so no other data license is compatible with Wikidata's requirements, see Wikidata:Licensing. The Hungarian Central Statistical Office offers its data as CC-BY-NC 4.0 and Wikidata "translates" it into CC0 because Wikidata makes it available under CC0. Will Wikidata replace every license with CC0 what is called en:Licence laundering? Is CC-BY-NC really compatible with Wikidata? --Poulsor (talk) 22:32, 25 June 2023 (UTC)
@Poulsor, the U.S. holds that simple data points cannot be copyrighted, so we're okay locally. I also do not believe that our use would fall afoul of the Database Directive (which is separate from copyright) per the ruling in "CV-Online Latvia" and others. Remember, copyright pertains to the specific selection and arrangement of the data, which we're certainly not copying. Their arrangement is CC BY-NC 4.0, our arrangement is CC0, which "Apis-Hristovich EOOD v Lakorda AD" seems to suggest is okay. — Huntster (t @ c) 04:36, 27 June 2023 (UTC)
In some cases things may be 100% legal in USA but use of Wikidata data in some jurisdiction would become illegal Mateusz Konieczny (talk) 12:12, 28 June 2023 (UTC)
@Poulsor Huntster Mateusz Konieczny please have a carefull look at the Copyright: Hungarian Central Statistical Office (or the original), the text says "BY-NC 4.0" but the links point to "BY 4.0" ! And then the text says "all of the content available on the Website -including tables, diagrams and infographics – (hereinafter: Contents) can be copied, reproduced and redistributed without limitations" (which is unclear but something between CC0 and CC BY).
This, plus the fact that this is uncopyrightable factual data, to me, it clearly looks like compatible with Wikidata.
Cheers, VIGNERON (talk) 16:47, 3 July 2023 (UTC)

I also think that my example above was no violation, but there is not even a place in Wikidata where to report supposed licensing violations, whereas Wikidata:Licensing sounds very strict to me. Of course, the statistical offices make the data publicly available and they all know what is done in Wikipedia and Wikidata. --Poulsor (talk) 17:21, 10 July 2023 (UTC)

Deleting empty redirect items en masse

Thoughts on deleting all items like Cultural influence of Plato's Republic (Q5193374). E.g. items which

  • have no statements
  • only have bot editors
  • only redirect sitelinks
  • no inbound statements

I feel like they only exist to make confusion more likely. Do we need bot approval to do this? Or could I just delete them all. BrokenSegue (talk) 18:16, 4 July 2023 (UTC)

How many such items exist? Would it make sense to unlink the redirect sitelinks and merge the itme with the item of the page the redirect points to? -- William Graham (talk) 18:18, 4 July 2023 (UTC)
48k items (no statements, one redirect sitelink, no backlinks). I don't think we should merge these into other items, but I am indecisive regarding a deletion. —MisterSynergy (talk) 19:13, 4 July 2023 (UTC)
merging seems unwise since going off the labels they don't represent the same concepts. my worry about not deleting them is that people will link to them. i argue that empty items are often worse then no items since they require us to do entity resolution later. BrokenSegue (talk) 19:30, 4 July 2023 (UTC)
I'd be interested to learn where these items come from. Some apparently have sitelinks to redirect pages that used to be proper articles in the past, but I have no idea whether this is the predominant pattern. Anyways, based on WD:N, these items do not meet notability requirements. —MisterSynergy (talk) 19:40, 4 July 2023 (UTC)
I think generally that is the pattern. They got autocreated by a bot. Then they were merged into another article and then a bot labeled them as redirects. I feel like one could argue for notability for some of these items. For example Arms and the Boy (Q4793856) is an actual published poem that someone would be free to make an item for (indeed it has a page on wikisource:en:Poems_by_Wilfred_Owen/Arms_and_the_Boy so I'll link it). BrokenSegue (talk) 00:15, 5 July 2023 (UTC)
I would support deletion as the notability isn't there according to our policy. I feel like having a discussion here to find consensus is enough and don't feel the need for a separate bot approval discussion. ChristianKl ❪✉❫ 22:01, 4 July 2023 (UTC)
How do these break down between sitelink to redirect (Q70893996) and intentional sitelink to redirect (Q70894304)? I would be more cautious about deleting the latter. Bovlb (talk) 00:34, 5 July 2023 (UTC)
2.6k items with the intentional badge, and 45.5k with the basic one —MisterSynergy (talk) 09:20, 5 July 2023 (UTC)
Can you give some examples of those with the intentional badge? I would not expect to see that in this context with items that have only bot editors. ChristianKl ❪✉❫ 12:22, 5 July 2023 (UTC)
"only bot editors" is usually not a useful criterion at Wikidata. That said, the intentional badge is usualy being set by human users via the UI. —MisterSynergy (talk) 16:14, 5 July 2023 (UTC)
I like to add the "only bot editors" flag because it means that it wasn't a real item vandalized to just be an empty item pointing at a redirect. it's a small safety mechanism. BrokenSegue (talk) 17:52, 5 July 2023 (UTC)
Is there a list of them or a query I could use to generate my own? I imagine a lot of the ones that used to be separate Wikipedia articles and were merged before anyone came along to add properties could be salvaged. Not the end of the world if they're deleted I suppose, but I would like to have a quick look anyway. —Xezbeth (talk) 12:27, 5 July 2023 (UTC)
In my opinion blank and redirect may be a better option: no bogus labels will be added and items can still be restored by anyone.--GZWDer (talk) 15:58, 5 July 2023 (UTC)
Per BrokenSegue above, a Wikidata redirect would be the wrong thing to do if they don't represent the same concept. We cannot make that assumption about client project redirects. Bovlb (talk) 17:39, 5 July 2023 (UTC)

Cultural influence of Plato's Republic is an example of why an automatic deletion would be risky. Once there was content – enwp often „deletes articles by redirection“. I don't see all information integrated into w:Republic_(Plato)#Cultural_influence.--U. M. Owen (talk) 22:33, 5 July 2023 (UTC)

There is no doubt that most of these items represent actual concepts, but Q5193374's page history with 2 bot edits in 10 years is not so unusual either. There is nobody who is willing to pick meaningful amounts of these items up. —MisterSynergy (talk) 22:43, 5 July 2023 (UTC)

Would it be meaningful to group the list by project? Redirects on Wikipedia can be meaningful, but less often so on other projects. On Wikisource, for example, our redirects are alternative spellings or alternative forms of titles, and these are things that ought to appear as alias labels rather than as separate data items. --EncycloPetey (talk) 07:42, 7 July 2023 (UTC)

Item counts broken down by sitelink type: wikipedia 47543, wikisource 445, wikivoyage 45, wikiquote 27, species 22, wikinews 21, wikibooks 2, wikiversity 1, wiktionary 1. This is predominantly about sitelinks to redirect pages at Wikipedias. —MisterSynergy (talk) 08:17, 7 July 2023 (UTC)
I assume that your counts include uses of Template:R with Wikidata item (Q116644654) (but perhaps not Template:Soft redirect with Wikidata item (Q16956589)). Hopefully all of those are marked as intentional redirects, but that's another category I would be cautious about deletion. Bovlb (talk) 18:56, 10 July 2023 (UTC)
I have not considered any of these templates yet. They are being used super inconsistently since they have basically not technical function, so I have never relied on them. —MisterSynergy (talk) 19:31, 10 July 2023 (UTC)

Subject as source for basic biographical data

This is following up on something Emu brought up, relating to a suggestion made by MisterSynergy last year on (for example) Wikimedians who are the subject of a Wikidata item and what sources are required for statements on these items.

"The metadata [on Commons] is usually unsourced/crowdsourced, and many of the items that we have due to the presence of a Commons category sitelink have a problematic sourcing situation in turn. We need to insist on serious external sources for those data items in order to avoid hosting potentially problematic content (incorrect, promotional, etc.). A "serious source" is usually independent of the described entity, not user-generated content, and not predominantly promotional. Statements that do not have such a source can be challenged and should potentially be removed." (MisterSynergy)
"So the solution could be to keep Commons category items but deny them their promotional or vanity value by heightened scrutiny of sources for non-trivial statements?" (Emu)
"Roughly like that, yes." (MisterSynergy)

Now, there are some things about this suggestion that make sense to me, but I think that it could be worth clarifying what is or isn't a "trivial" statement (as Emu puts it) — or, more precisely, what statements should be subject to heightened scrutiny (according to this suggestion or in general).

At least the way I read the suggestion (and I could be coming to a different reading than MisterSynergy intended), the basic issues here would be that information imported from Commons (where things are usually not sourced at all) would either be incorrect (e.g., a user, categorizing a person on Commons, adds inaccurate categories) or, if sourced back to the subject, who is only "borderline" notable, potentially unfactual in a promotional way (e.g., claims of various achievements, etc.).

Statements backed by references to accepted independent sources are acceptable; that much seems agreed upon. The question is, are basic biographical data (birth date, birthplace, citizenship) able to be accepted from a source created by the subject? I would suggest the answer should be yes.

(Note that this is a separate question from notability; this is about verifiability of statements. The relevant scenario here is one where the item does pass WP:N.)

This is a question about a general principle, but also relates to a specific case (Q113531294, which is a Wikidata item representing me). There are some statements there backed by independent sources. I have a self-published source which states my birth date, birthplace and citizenship.

Here is why I suggest that the answer should be yes, and these data should be included when sourced somewhere* (including to the subject):

  1. WD:Autobiography says, "If you add statements about aspects of your life history, like your birthplace, or things you have achieved, such as a job, qualification or honour, these must be sourced to a reliable, verifiable source. (You may use your website, blog, Facebook or Twitter, but they may only be used as references for information about yourself, not others.)"
    1. I can understand statements made about qualifications, awards, etc. may be dubious (and thus subject to potentially increased scrutiny), but I don't think the basic birthdate/birthplace/citizenship data should be subject to higher scrutiny.
  2. On Wikimedia projects, these basic data are generally accepted based on the subject's own statements. On Wikidata, Wikidata:Verifiability (which is a policy proposal) says "Self-published information (for example, personal blogs) are acceptable sources of information when they are used to support statements about their authors and the information is clearly not self-serving." Compare English Wikipedia's WP:ABOUTSELF policy, which allows citation of self-published information for information about the subject (not third-parties) that is not unduly self-serving or an exceptional claim.
    1. Generally, birthdate, birthplace and citizenship claims are not promotional/self-serving and are not exceptional. (An exception to the rule could be imagined, where the claim is outlandish — think world's youngest/oldest X — but this would be rare.)
    2. In a good number of cases, including for indisputably notable people, birthdate/birthplace and citizenship information are based on self-published sources created by that person (e.g., social media "happy birthday to me" posts, etc.).
  3. The data should be included when possible, not only because they can be sourced, but because they can have a significant disambiguating impact.
    1. In my case in particular, I happen to share my name with many other people, including other people represented in Wikidata. Basic biographical data would serve to prevent confusion between this item and other items that represent different subjects with the same or similar names.

I would also suggest the following general guideline for accepting autobiographical sources for statements on Wikidata.

  1. For basic biographical data (date of birth, birthplace, citizenship, etc.), the subject's own statements should be considered an acceptable source. When these are actually sourced to the subject, they should be included, since they are recommended basic metadata for people. Only in exceptional cases where there is good reason to doubt the veracity of the claim should these statements should be excluded.
  2. Especially when the source is not very highly covered (not a lot of sources in general), statements related to achievements, qualifications and awards should generally reference the awarder or an independent source, not the awardee. Even if the claims are not per se exceptional, lesser-known subjects should be subject to a bit more scrutiny with respect to claims to achievements.
    1. False qualifications or honors can certainly serve a promotional purpose (unlike basic biographical data).
    2. Anyone can claim to have an award or qualification; see Alan Mcilwraith. If the award actually exists, it should generally be verifiable. The scrutiny should be higher the greater the disparity between the prominence of the person and the prominence of the award. (Mcilwraith, a completely unknown figure claiming to have many extremely rare/prominent awards and qualifications, is an extreme example.)
    3. A person who has become a significant public figure can be reasonably expected to have told the truth about these qualifications (with exceptions such as George Santos), and so self-published sources (such as the autobiography of a politician or other public figure) can be considered generally reliable from such sources until shown otherwise.

In particular, I would request that the basic identifying statements (birthdate, birth place, citizenship) be added back to Q113531294, with reference to the self-published source (following WD:Autobiography and in line with the proposed policies/suggestions above).

D. Benjamin Miller (talk) 17:10, 7 July 2023 (UTC)

tl;dr A Wikimedia contributor really wants to have his own Wikidata item and wants it to contain all sorts of statements. The item is notable on Wikidata only because of what I think is a loophole in the notability criteria (Commons categories imply notability). The simply question – beyond technicalities about the official status of some formal or informal guidelines – is, do we want this preferential treatment. There has been a lot of discussion going on about preferential treatment (see the links at User:Emu/Notability#Wikimedia-related_stuff). My answer is and has been: No preferential treatment and mitigation of the Commons category loophole by only allowing statements that are sourced beyond reproach. --Emu (talk) 17:33, 7 July 2023 (UTC)
These statements are those which are basic ones normally made on any "human" item for which they are known, so they are hardly "all sorts of statements".
How is the usual practice for sourcing statements problematic here? You have no problem with statements that are independently sourced — in cases where those independent mentions occur and happen to include that information, you're fine with including the statements — so it's not even about the existence of these statements in general. What is the evidentiary issue which should lead to these self-made statements having less factual credibility than they do in all other cases?
I understand you're of the opinion that Wikimedia users (and other Wikimedia-related data) being included in Wikidata is in itself unacceptable preferential treatment — but that is a different subject. The "Questionable notability Wikimedians" items very often include these basic statements without external, independent sources — just as many items to across Wikidata. If we put aside your issue about whether or not those items should exist, then what is the issue about with these statements' sourcing?
D. Benjamin Miller (talk) 18:57, 7 July 2023 (UTC)
Or, simply, your position seems to be that — without changing the notability policy — there should be some special sort of source-based factual skepticism about ordinary identifying statements made on items which pass WD:N currently, but would not pass the notability criteria you would propose. But this seems to really just be saying the notability criteria should be changed (or perhaps that there should be some sort of "statement notability" system). D. Benjamin Miller (talk) 19:18, 7 July 2023 (UTC)
Or even shorter: If vanity or publicity is a concern, statements should be referenced beyond reproach. I think this is in line with the spirit of WD:S, WD:N and Wikidata:Autobiography. Yes, there are many items with questionable statements – that does not mean that your item gets to keep questionable statements as well. --Emu (talk) 20:12, 7 July 2023 (UTC)
So, you're saying the statements (on birthdate, birthplace and nationality) are not given a sufficiently authoritative source to be considered factual? I don't see how that follows from any of the guidelines you link to; Wikidata:Verifiability recommends following the Wikipedia:ABOUTSELF guidelines. The general rule for these types of statements is clearly that self-published sources are presumed authoritative for birthdate/birthplace/citizenship. I don't think it would be reasonable to assume that birthplace/birthdate/citizenship were falsified in a self-published source for any vanity/publicity reason (barring extreme exceptions). D. Benjamin Miller (talk) 20:46, 7 July 2023 (UTC)
No, I don’t think you falsified information. I do think that you shouldn’t get a vanity item and if, because of a technicality in the notability criteria, you do, you shouldn’t be able to add statements sourced solely by yourself. I think it’s no good to try to pinpoint any claim to such statements on specific word choice. It’s well known that Wikidata is woefully underdocumented so common sense is to be used.
Note: I’m about to go on vacation so I probably won’t be able to comment for about a week. --Emu (talk) 21:58, 7 July 2023 (UTC)
I certainly understand that for claims of some distinction (I don't think that it would make sense to accept everyone at their word who claims to be a Rhodes Scholar or whatever). I can also partly understand (although I'd disagree with) the concept that you'd not have these kinds of statements at all. But I don't see why a basic statement of this kind would be OK or not OK specifically because of the first-party vs. third-party source.
As for the break, that's no problem, of course. Enjoy the week's vacation. D. Benjamin Miller (talk) 00:26, 8 July 2023 (UTC)
For living people, authoritative sources, like birth certificates or identity documents, aren't usually publicly available, and the only practical source for such details is going to be the person themselves. If you see some biographical information in a news article, an academic paper, or some other publication, it probably just originated from the person, without being checked (such as by demanding ID or other confirming documentation, which I suspect wouldn't usually be done). So I suspect that some of these "independent sources" aren't independent or any more reliable, they are just laundering the information. Ghouston (talk) 03:00, 10 July 2023 (UTC)
At least in the case of D. Benjamin Miller's entry the answer to the question of notability might be to turn it into a "category item." Instead of it involving "instance of human", Then it really wouldn't matter and biographical information could be added to other statements somehow. The issue here though at least far as I'm concerned isn't so much having unauthoritative sources as it is treating an item for a person like it's a category item when it clearly isn't one. The guidelines seem clear that entries for people linked only to primary references like someone's website are promotional though and I don't think that fundamentally changes in any way or is overruled just because the entry contains a site link to Commons.
Like if it were an entry for a business that only linked to their sales landing page and one of their employees uploaded a few images of their store to Commons, which they a link to in the entry, would that fundamentally be any less promotional of an entry then one without the sitelink? Not really. If it were a "category item" to begin with we could just delete the references to their sales page and be done with it though. So I think the answer at least in cases like that or D. Benjamin Miller's entry is to convert them "category items", delete the unreliable references, and leave it at that. Otherwise there's no reason to treat the item any differently then one that doesn't contain a sitelink. It's ridiculous to allow someone to use Wikidata as an advertising platform just because they uploaded a couple of images to Commons though. --Adamant1 (talk) 21:51, 10 July 2023 (UTC)
c:Commons:Deletion requests/Creator:D. Benjamin Miller. Multichill (talk) 22:23, 7 July 2023 (UTC)

Merge 2

Please merge Tool (Q120458961) and Tool (Q37528780). 158.181.71.74 04:56, 12 July 2023 (UTC)

✓  Merged too. --Wolverène (talk) 05:02, 12 July 2023 (UTC)
Thanks again ;-) 158.181.71.74 05:05, 12 July 2023 (UTC)
you really should learn how to merge things BrokenSegue (talk) 05:27, 12 July 2023 (UTC)
As IP? IPs cannot use the merge function. 158.181.71.74 05:37, 12 July 2023 (UTC)
As an IP not but when you sing-in on Wikidata ,you can activate the merge gadget. FYI RVA2869 (talk) 07:44, 12 July 2023 (UTC)
while I respect your right to not make an account I have to wonder why. just make a new account every day if you want? BrokenSegue (talk) 18:03, 12 July 2023 (UTC)
This section was archived on a request by: — Huntster (t @ c) 13:23, 16 July 2023 (UTC)

Inscription

See: Johanna Gustava Ruuth (Q42418464) where the inscription is not allowed. Can someone change the parameters, so it is allowed? Or model it properly. RAN (talk) 01:14, 15 July 2023 (UTC)

@Richard Arthur Norton (1958- ) Inscription on a human? Did she have a tattoo? Ainali (talk) 12:46, 16 July 2023 (UTC)
Ainali, it seems someone had used inscription (P1684) as a reference, which isn't permitted. It was fixed by moving it out of the reference area. — Huntster (t @ c) 13:23, 16 July 2023 (UTC)
This section was archived on a request by: — Huntster (t @ c) 13:23, 16 July 2023 (UTC)

Property to define the total money invested

In the scheme USFIA (Q41804178), 147 million dollar were totally invested. Which property should I use to add this information? Cavernia (talk) 09:42, 11 July 2023 (UTC)

Hello! I am an academic researching eighteenth-century books which were published "by subscription", which was basically a way of crowdfunding. Books were published with lists of subscribers' names, to show who contributed money for that book's publication. I'm specifically looking at people who helped fund work by Black Britons like Ignatius Sancho. I'd like to make this data more widely available and Wikidata seems like a good fit, but I don't think there are any existing properties that capture this relationship. Basically, I'd like to add something to, e.g., John Ashburnham's wikidata entry after I have determined that he is the "Earl of Ashburnham" on Sancho's list of subscribers. Something like "subscribed to" as the property and the book as the value. Ideally this would be reciprocal so the book would also have the property "subscrinbed by" with the values for all its subscribers. Is this information suitable for Wikidata? How might I go about adding it? Thanks! LEvalyn (talk) 10:46, 11 July 2023 (UTC)

How about funder (P8324) on the book entry? Seems to me that this is more appropriate for the book than the person, and we don't usually do symmetrical/reciprocal properties on Wikidata — Martin (MSGJ · talk) 10:57, 11 July 2023 (UTC)
There is also sponsor (P859) and endorsed by (P8001) in case they are relevant — Martin (MSGJ · talk) 10:58, 11 July 2023 (UTC)

Field railway (Japanese National Diet Library)

In field railway (Q1402344) NDL Authority ID has two values, but I can't read Japanese. Could you please help me? Thanks.-- Carnby (talk) 11:31, 11 July 2023 (UTC)

field railway (Q1402344) seems to be a German narrow gauge industrial/field railroad when reading English Wikipedia; the NDL Authority ID refers to "light railways", so I replaced it with the Japanese Wikipedia's entry for "light railways", light railway (Q32680449). The confusion is due to the fact that the Library of Congress authority ID "Railroads, local and light" is linked to branch line (Q655677), which is linked to the NDL Authority ID as a synonym for "light railways". Afaz (talk) 14:27, 11 July 2023 (UTC)
Thanks!-- Carnby (talk) 18:06, 11 July 2023 (UTC)

On China Biographical Database (Q13407958) there is a statement for source code repository URL (P1324). The value URL does not point to a repository, though, but to a GitHub user page [2] with (at least) ten repositories.

  • Is this property intended to be used like this? (I’d say no, since there is a suggestion that a copyright license (P275) statement be added, which does not make sense for a GitHub user page since the licence could be different for each of the user’s repositories.)
  • If no, is there a more suitable property?

Thanks in advance for your ideas. --Data Consolidation Officer (talk) 10:35, 9 July 2023 (UTC)

GitHub username (P2037) would seem to be the more appropriate property in that case, I think. M2Ys4U (talk) 14:49, 9 July 2023 (UTC)
Thanks, I’ve changed it. --Data Consolidation Officer (talk) 13:24, 14 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 15:57, 19 July 2023 (UTC)

New tab in Wikidata for "Officeholders"

Currently we have tabs for "Item" and "Discussion", For items where we have instance_of=position, we should have the ability to create a new tab called "Officeholders" where we can display the table created by PositionHolderHistory|id= (officeholders) Currently the table appears in "Discussion" and can get lost in with the chatter that goes on there. Where would I bring this up, and what do you think? See Talk:Q19546 for a typical officeholder table. Generally these tables are not welcome at Wikipedia and there was a campaign recently to delete them for holders of offices not considered notable, for instance mayors of towns. Mayors of large cities were kept. RAN (talk) 18:24, 9 July 2023 (UTC)

who do you imagine would be the consumers of these tables? why would a new tab be better than discussion? it feels odd to have a new table for something so specific. maybe if we could put multiple visualizations there? BrokenSegue (talk) 19:34, 9 July 2023 (UTC)
An external tool should be built instead and display these tables. Wikidata should not be adapted for "viewing the data", they're not meant for browsing. Vojtěch Dostál (talk) 20:15, 9 July 2023 (UTC)
The assumption is that Wikidata is always used as a searchable database, I see it more and more as a final product/for browsing, that is more stable than Wikipedia. Most answers I want are in Wikidata on obscure people, and Google is the search tool, not SPARQL. There is lots of other information that can be formed into tables, it is only when you see it in table form can you see missing info and errors. The pope data had multiple errors that had been there for years. It took a month to harmonize the data and remove errors. --RAN (talk) 02:17, 10 July 2023 (UTC)
"I see it more and more as a final product/for browsing" --> In that case, maybe you should persuade key stakeholders about this first, because I think this is a minority view right now. No offense, just stating the obvious that the product should be developed with some general strategic vision in mind. Vojtěch Dostál (talk) 07:57, 10 July 2023 (UTC)
  • @BrokenSegue, Vojtěch Dostál: We recently added "Autodescription", perhaps the best place for the table information is in the autodescription portion. It would prevent the table from being deleted when the talk page is archived, and prevent it from being pushed down if people add a discussion to the top of the page. Who would I discuss this with? --RAN (talk) 21:23, 13 July 2023 (UTC)

Official Web URL conflicts

Hello,

I am trying to figure out how to resolve a conflict when I add an additional URL to the Official website URL section. Molliemch (talk) 18:52, 17 July 2023 (UTC)

@Molliemch: I believe you're saying that you want to add a second official website to an item, but you see a warning message that this should be a single-valued property.
Generally there are two approaches to fix this:
Bovlb (talk) 19:19, 17 July 2023 (UTC)
Hi Boblb! All I see in the Official Web URL statements are the ability to add a reference. So I am confused about the language or ranking options affecting 2 URLs. My page in question is this one: https://www.wikidata.org/wiki/Q7246673 Molliemch (talk) 19:36, 17 July 2023 (UTC)
See ranking and qualifiers. Both of these are only available after you click "edit" on a claim.
Also, please don't get overwhelmed by the constraint violations. These are "soft errors". Sometimes they're wrong. Even when they're right, it's not always appropriate to fix them immediately. Bovlb (talk) 21:04, 17 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 15:56, 19 July 2023 (UTC)

Question

How do you set sitelinks to Wiktionary? QuicoleJR (talk) 14:52, 19 July 2023 (UTC)

I would also like to know how to set sitelinks to Commons. QuicoleJR (talk) 14:56, 19 July 2023 (UTC)
I figured out Wiktionary, but I still need help with Commons. QuicoleJR (talk) 15:08, 19 July 2023 (UTC)
@QuicoleJR: It's under the "multilingual sites" category; put "commons" in the wiki box. Vahurzpu (talk) 15:18, 19 July 2023 (UTC)
Thank you! QuicoleJR (talk) 15:20, 19 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 15:55, 19 July 2023 (UTC)

Shock Waves – Diary of My Mind (Q48671731)

The page Shock Waves – Diary of My Mind (Q48671731) is currently a mix between 2 subjects: - Shock Waves, the complete series of 4 episodes broadcasted by the RTS in 2018 - Shock Waves - Diary of My Mind, the first episode of the series From the 4 Wikipedia pages linked to the entry, the English and French ones are about the complete series, the Russian and Ukrainian ones are about the first episode. The different statements are a mix between statements about the series and statements about the episode. How should this page be corrected ? Should it be a page for the series ? or should it be a page for the first episode ? Vivelalsace (talk) 17:27, 13 July 2023 (UTC)

there should be an item for each and the different languages should point to the one they are about. BrokenSegue (talk) 21:39, 13 July 2023 (UTC)
Split done. The original entry has been kept for the episode (which has also been released as a separate movie) and a new entry Shock Waves (Q120641323) has been created for the miniseries. Vivelalsace (talk) 03:23, 14 July 2023 (UTC)

replaces/replaced and replaced by

We have replaces (P1365) and replaced by (Q107995509), we use them wherever we have a succession in a position. Someone recently changed the word from the present tense "replaces" to the past tense "replaced". I reverted it because it had not been discussed, which should it be? The problem was that when filling in position_held without "replaces" the QID "follows" was suggested when I went to fill in the data. RAN (talk) 21:31, 13 July 2023 (UTC)

@Richard Arthur Norton (1958- ): replaces (P1365)/replaced by (P1366) ("replaces"/"replaced by" since the cache may not be updating properly) is for succession scenarios and situations where the timeline is generally non-concurrent (think political office succession). follows (P155)/followed by (P156) ("follows"/"followed by") is for items in a sequence that may overlap each other chronologically (think a series of products that coexist, maybe even are manufactured at the same time, but have a distinct sequence). So, the revert seems appropriate. — Huntster (t @ c) 02:45, 14 July 2023 (UTC)
I'd also use follows for a sequence of events that doesn't overlap or superceed, like the Olympics Vicarage (talk) 13:09, 14 July 2023 (UTC)
This is another of these distinctions (like start time (P580)/end time (P582) vs inception (P571)/dissolved, abolished or demolished date (P576)) where usage is so inconsistent that when building anything on top of Wikidata, many queries essentially need a lot of extra complexity to handle either being set (and worse, sometimes both, but to different values). I'm unconvinced that the extra nuance we gain from the subtle differences between them make enough sense to justify having separate properties for each. Oravrattas (talk) 13:36, 14 July 2023 (UTC)
I would say a new car model replaces an earlier one, not follows it, even though there is a production overlap. Politicians are replaced, peers follow. I agree that the nuances of these synonyms make little sense in English, let alone other languages, so consolidation as 'next in sequence' might avoid muddle Vicarage (talk) 14:16, 14 July 2023 (UTC)
I would not agree with car models being replaced. I think of items using "replace" as unable to co-exist, whereas items using "follows" can co-exist. There is, of course, nuance to all that. All this said, either these properties need consolidation (which I think might not be well accepted) or much more detailed definitions and use-cases developed so folks know when and how to use them. — Huntster (t @ c) 17:42, 14 July 2023 (UTC)
I don't necessarily disagree, especially when such data can often be more easily be placed in significant event (P793) (and with greater detail and precision). But, any potential deprecation must take care to not diminish the information we already have. — Huntster (t @ c) 17:37, 14 July 2023 (UTC)

How to convert Wikidata as references?

So, in some wikidata page, there's a warning that is easy to solve: " Wikidata items should not be used with this property. Use “inferred from” (P3452) or “stated in” (P248) as appropriate."

But when using P3452 or P248, you can't specify a specific section of the QXXXXXXXXX item.

For instance, I saw on a page: https://www.wikidata.org/wiki/Property:P3861#P2302

But, when I write "P3861" on P3452 or P248, they found the element, cool, but It doesn't seem possible to indicate the "#P2302" part. Is it possible? If not, is it a big deal?

Thx MacOS Weed (talk) 15:47, 14 July 2023 (UTC)

there are ways to do this but generally wikidata should not be used as a reference. just reference the underlying source BrokenSegue (talk) 16:00, 14 July 2023 (UTC)
Exactly as BrokenSegue says. This is why it's important for properties to have proper citations themselves, rather than relying on potentially circular references like imported from Wikimedia project (P143). — Huntster (t @ c) 17:31, 14 July 2023 (UTC)
@BrokenSegue@Huntster All right, thanks! I'll add a proper reference instead then; thanks MacOS Weed (talk) 14:08, 15 July 2023 (UTC)
You could use based on heuristic (P887) to specify more about how you interpret data from a given source. ChristianKl ❪✉❫ 14:25, 15 July 2023 (UTC)

How To Customize A Wikipedia:Manual Of Style/Layout

I Want To Customize The Wikipedia:Manual Of Style/Layout!

2001:16A2:E172:2584:39C9:AA3E:91FD:45CD 20:51, 14 July 2023 (UTC)

This page is for Wikipedia, if you want to change something at Wikipedia you should ask over there. Registering an account also generally helps. ChristianKl ❪✉❫ 14:27, 15 July 2023 (UTC)

Nonsense Instance Claims on Lexemes: Easy Way to Revert?

Running a SPARQL query I found that Mamman AA has recently created a lot of lexemes, adding statements such as instance of (P31)human (Q5) (e.g. Lexeme:L1138824, deleted here) or instance of (P31)human settlement (Q486972) (e.g. Lexeme:L942135), which are obviously nonsense. I’ve asked them to stop, but there is already a large number of such nonsense claims. Is there any easy way to bulk revert these edits (remove the claims)? --Data Consolidation Officer (talk) 17:47, 14 July 2023 (UTC)

See also: Wikidata talk:Lexicographical data/Archive/2023/03. If the terms are names of places, they should be converted to proper nouns.--GZWDer (talk) 17:10, 15 July 2023 (UTC)

Item Deletion

Hello, I am trying to update an item created but find out it has been deleted. Any help? Mistarflyy (talk) 17:04, 21 July 2023 (UTC)

This is being discussed at Wikidata:Administrators'_noticeboard#Restoration_of_a_deleted_item.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Bovlb (talk) 18:53, 21 July 2023 (UTC)

Threads property

Could someone please make a identifier proposal for this site? I cant access it in the European Union so my ability to contribute is very limited Trade (talk) 22:13, 10 July 2023 (UTC)

I could be wrong, but my understanding is that Threads identifiers are (currently) tied to Instagram usernames. See https://help.instagram.com/515230437301944 Bovlb (talk) 23:37, 10 July 2023 (UTC)
Somebody proposed it anyway: Wikidata:Property proposal/Threads username. Ghouston (talk) 06:39, 11 July 2023 (UTC)
Would you mind if i create the property since i did not participate? Trade (talk) 13:04, 16 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 17:12, 22 July 2023 (UTC)

Traitors

An edit I made was reverted by @Dogfennydd, and I wanted to know more about how Wikidata handles "POV" issues. Benedict Arnold is a notable traitor: an American military officer who negotiated a surrender of his important command in return for being personally paid £20,000 (~four million US dollars in modern money), and who later became an officer in the British Army and attacked the same soldiers he had previously commanded as an American Army officer. Lists of historical traitors put him on par with Quisling and Judas Iscariot. The English Wikipedia article says 'Benedict Arnold became permanently synonymous with "traitor" soon after his betrayal became public'.

The claim is easily sourced, and I provided four sources. I don't think that describing him as an "American military officer during the Revolutionary War (1740–1801)" is accurate, as (a) it omits the most important information, and (b) he was an American officer only from 1775 until his defection in 1780, and a British officer after that.

What do you think we should do? WhatamIdoing (talk) 16:36, 12 July 2023 (UTC)

My main objection was about putting betrayer (Q55176871) in the instance of (P31) field; for humans that should pretty much always be human (Q5). I have no objection to putting betrayer (Q55176871) in another field (with the cited sources); it is set up as a occupation (Q12737077) but it seems wrong to put it in the occupation (P106) field. Happy to consider other suggested fields. I also reverted the plain statement "traitor" from the description but I have no objection to putting that back if that is the consensus. The French description also includes the traitor description but contextualises it to American historiography, which may be more acceptable. Dogfennydd (talk) 16:46, 12 July 2023 (UTC)
Can a human not be an "instance of" many things? WhatamIdoing (talk) 03:18, 13 July 2023 (UTC)
@WhatamIdoing to give a bit of background, there is a convention to keep instance of (P31):human (Q5) as the single instance statement for people, and model everything else through more specific properties. Historically some of the complicated cases (saint, centenarian, murder victim) did get put in instance of (P31), but in general those have got phased out over time and switched into more specific properties.
For "traitor", I think the most common pattern is currently to model it as convicted of (P1399):treason (Q160128), though that assumes there was a trial rather than it just being widely accepted. There is also the possibility of using significant event (P793), which seems to be the one commonly used for modelling defections and would make sense by analogy.
Having said that, digging into this has highlighted that it's currently a bit of a grey area - there are plenty of items that simply have no directly relevant statements, eg Kim Philby (Q296313), who I think is another case like Arnold where there was never actually a trial per se but everyone knows what happened. Andrew Gray (talk) 12:21, 13 July 2023 (UTC)
I don't believe that a court martial was held, due to Arnold escaping. WhatamIdoing (talk) 05:04, 15 July 2023 (UTC)
Yeah betrayer (Q55176871) is not a valid value for instance of (P31). You are mistaken. BrokenSegue (talk) 16:55, 12 July 2023 (UTC)
Should it perhaps be subject has role (P2868): betrayer (Q55176871)? Lights and freedom (talk) 00:30, 13 July 2023 (UTC)
That sounds plausible to me. WhatamIdoing (talk) 03:18, 13 July 2023 (UTC)
I'm also interested in the description, which I think is better "American traitor and military officer during the Revolutionary War (1740–1801)". WhatamIdoing (talk) 03:14, 13 July 2023 (UTC)
You can also add qualifiers of statement disputed by (P1310) and/or statement supported by (P3680) to make it clear who thought the person was a traitor/betrayer. -- William Graham (talk) 18:47, 12 July 2023 (UTC)
AFAICT it isn't disputed anywhere. Even the British public at the time despised him for being a traitor. WhatamIdoing (talk) 03:16, 13 July 2023 (UTC)
I was discussing how to model the concept of a human being a traitor in the general case. In some occurrences there are disputes. William Graham (talk) 17:33, 13 July 2023 (UTC)
Wikidata decriptions are by policy neutral. Our policy says "Labels, descriptions and aliases need to be neutral and well-sourced (ideally based on referenced statements on the item)". ChristianKl ❪✉❫ 18:43, 15 July 2023 (UTC)
What does "neutral" mean to you? Does it mean "aligns with what high-quality sources say", or does it mean "don't mention anything negative"?
(Also, it looks like you have linked to a policy about living people, and we're discussing a man who died more than 200 years ago.) WhatamIdoing (talk) 23:24, 15 July 2023 (UTC)
The policy of neutrality in descriptions is not limited to living people. As such I would only include the wording “traitor” or similar if he was universally regarded as such, on both sides (which is indeed what you claim above). I don’t know much about the guy so I’ll defer to consensus. I would add a link to this discussion in the talk page for the item with a couple of source links, since descriptions can’t contain sources. Dogfennydd (talk) 13:56, 16 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 17:13, 22 July 2023 (UTC)

Request to merge items

Q10379506 and Q590311 actually have the same meaning, and it is recommended to merge them. Fumikas Sagisavas (talk) 09:19, 16 July 2023 (UTC)

@Fumikas Sagisavas is the Chinese page really a disambiguation page? Ainali (talk) 12:43, 16 July 2023 (UTC)

Merging two Nollywood items

There are two items for Nollywood (Q57696462 and Q21065894). Both have "film industry" but only one (Q21065894) has "byname of cinema of Nigeria." Are these distinct to keep as separate or can they be merged? I appreciate the help and I hope I've asked in the right place! Stonejamcar (talk) 20:49, 19 July 2023 (UTC)

They look the same to me, so I merged them — Martin (MSGJ · talk) 21:05, 19 July 2023 (UTC)
Thanks for the reply and the merge! Stonejamcar (talk) 16:40, 20 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 17:11, 22 July 2023 (UTC)

Deletion of valid references

I was astonished to receive the following message on my talk page, which I reproduce here in full:

References you added to Q113531294

Hi. I see added references to Q113531294 that involved links to Daniel Benjamin Miller's personal website and social media accounts, which I reverted. There was resiliently [SIC] a deletion request for the entry based partially on it being promotional where the outcome was that the entry wouldn't be deleted if links to his own website and social media accounts were removed. So I'd appreciate it if you didn't add them back. Otherwise, I'll just nominate the entry for deletion again. I rather not have to though since there was already a consensus to leave it but without the promotional links. Thanks. Adamant1 (talk) 07:13, 10 July 2023 (UTC)

Note:

I further observe:

  1. I did not cite any of the subject's social media accounts
  2. Adamant1did not merely remove the references that I added, but also my addition of official website (P856)
  3. there is no Wikidata policy prohibiting the inclusion of the subject's website using P856
  4. the existence of P856 implies community consensus that it is intended to be used
  5. there is no Wikidata policy prohibiting the subject's own website as a source for the given and family names they use (which are the only statements for which I used it as a reference)
  6. Wikidata requires that statements are cited wherever possible; doubly so for BLPs
  7. the subject's given and family names appear never to have been previously cited; therefore the citations I added were not in the scope of the deletion discussion
  8. P856 had never previously been used in the article; therefore it was not in the scope of the deletion discussion
  9. inclusion of the subject's website populates the corresponding field in the infobox on Wikimedia Commons; this is both perfectly acceptable and appropriate on that project.
  10. the deletion discussion was not closed by an administrator or other editor in good standing
  11. the claim that "the outcome was that the entry wouldn't be deleted if links to his own website and social media accounts were removed" is false
  12. the claim that "there was already a consensus to leave it but without the promotional [SIC] links" is false

Accordingly, Adamant1's reversion of my edit is harmful to this project and to Wikimedia Commons; and should itself be reverted.

Furthermore, I object strongly to the implication that my edit was in any way promotional.

Most egregious of all is the use of the threat of a repeated deletion nomination in an attempt to suppress the use of a valid source. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 10 July 2023 (UTC)

A few things, first of all the place to discuss this should have been on your talk page where I originally messaged you about it. Turning it in a conversation here before discussing it with me first seems rather bad faithed. Especially considering the 12 point screed you've apparently turned it into. We could have easily worked out a compromise on your talk page without you needlessly turning it into a wider discussion when there was no reason to.
Secondly, I'm not going to respond to your gish galloping, insulting nonsense. Nor I should I have to. The fact is that multiple people, including me, thought the entry was promotional but could stay if the links to his personal website and social media accounts were deleted. Someone commented the DR should be closed as keep with that outcome and no one, including you, objected. If you had an issue with that being the outcome then you should have said so at the time. This is clearly just a way to run around the consensus. The idea that me removing the links in the meantime is somehow harmful to Wikimedia Commons and should be reverted in the meantime is just laughable. What's harmful to the project is not accepting the outcome of a deletion request and trying to use Project Chat as a way run around having an actual discussion with the person you have the dispute with on your talk page when they message you about it.
One more thing, I didn't see who closed the DR, nor do I care because multiple administrators voted deleted and agreed that the entry as cited at the time was promotional. So your really just nitpicking. It shouldn't really matter if the DR wasn't closed by an administrator if it resulted in the outcome an administrator said they wanted, and again, no one objected to it. If you thought the links to personal website weren't promotional and shouldn't have been deleted the place to say so was in the DR. It's not on me that you didn't. This whole thing is totally ridiculous and bad faithed on your end in the meantime. There's zero reason you couldn't have just worked it out with me on your talk page. --Adamant1 (talk) 12:02, 10 July 2023 (UTC)
BTW, to point number 11 and 12 Emu said in the DR "a good way to end this absurd conversation is following this idea: Keeping the item per Commons category but deleting everything except for instance of (P31)", which I agreed to and then the discussion was archived almost three weeks later without any objections. So I don't really see how it's false that the consensus was to leave it but without the promotional links like Pigsonthewing is claiming. That was exactly what I and Emu agreed on and again no one disagreed with us. There was plenty of time for Pigsonthewing or anyone else to abject to that being the outcome if they wanted to. --Adamant1 (talk) 12:20, 10 July 2023 (UTC)
From my reading of the deletion request, it was closed "not deleted" on the basis that, for non-category items, a Commons Category link implies notability here at Wikidata. Regardless of my personal views on the matter, I concur with this reading of our current policy.
The "restriction" on adding "promotional links" was apparently added to the close by Adamant1. It seems a little odd for Adamant1 to now give this the imprimatur of an official decision. If the items is notable, then I see no reason it should not contain appropriate references and claims. Official website is generally not considered promotional, and use of self-published links is appropriate for referencing certain types of claim.
If you believe that we should not consider items like this to be notable, I recommend that you open an RFC to change our notability criteria. Bovlb (talk) 16:57, 10 July 2023 (UTC)
@Bovlb: 3 things.
1. It wasn't "closed" as anything, it was archived.
2. If you read through the discussion Emu suggested that a good compromise to continuing the conversation since there was as many people who wanted it deleted as not was to delete everything accept for "instance of" so it could still serve a structured purpose like Daniel Benjamin Miller without clearly being promotional, which I agreed to because I wanted the discussion to end. That naturally involves deleting links to his personal homepage on entries that aren't "instance of" and I wasn't the one who suggested it either. You saying I added it to the close or came up with it impromptu is just patently false though. Emu was the who came up with it and I agreed. That's it. It wasn't my idea and I didn't "add it" to anything. Nor did I just invent it on the fly to justify my actions like your insinuating.
3. As to the specifics, while I agree that official websites are "generally" not considered promotional, entries are if that's all or mostly all they contain, and multiple people in the conversation thought the entry was promotional enough to justify deleting it. A part of that being due to the links to his official site being the main or only refences. In similar situations the entry is usually deleted as PROMO. The existence of a link to Commons would be fine as an indicator of notability if it was an entry for a category, but it isn't. It's one for a person. Wikidata:Notability says Commons categories being an indicator of notability applies in cases of "Category items" and Q113531294 obviously isn't one. So your handwaving about how Commons Category links imply notability isn't applicable. I'm totally fine with you or Pigsonthewing changing into a "category item" if either one of you wants to, but it doesn't work for notability until then and I'm not doing an RfC just to confirm something the guideline is already clear about. --Adamant1 (talk) 21:28, 10 July 2023 (UTC)
The request for deletion was archived because an admin marked it as "not deleted". This means that the decision was not to delete this item.
I see that a lot of points were raised in the discussion, but so far as I'm aware, we don't really have a class of items that are "notable but don't add claims or references". I don't understand why we would want to have such a thing.
N1.4 says that category items are not made notable by a Commons link. It's not phrased as clearly as it might be, but the implication is that for non-category items, a link to commons (whether category or not) is sufficient to establish notability. The presence of a Commons sitelink on this (non-category) item therefore establishes notability. A lot of people believe that this shouldn't be the case, but that's what our current policy says. Bovlb (talk) 21:50, 10 July 2023 (UTC)
The request for deletion was archived because an admin marked it as "not deleted" I didn't see the specific edit that lead to it being archived but there was no comments after Emu and I commented and according to Pigsonthewing it wasn't closed by an administrator. Whatever the details though, I don't think it's that usually or out of procedure to follow recommendations made in a discussion if people in it agree to follow them. It happens all the time. Even if said discussion isn't officially closed or whatever. So I don't see what the issue is. I'm sure it will happen here to. Again, there was a 2 week period where people could have disagreed with deleting everything other then "instance of" or came up with an alternative. No one did either one. If it were any other discussion (including this one), where a couple of people decided to do something a certain way and no one objected, it would be fine to follow the decision. So I don't see why this should be treated differently then how it works in literally every other conversation.
We don't really have a class of items that are "notable but don't add claims or references" Isn't that essentially how category items work? Like Q8928318 for example is referenced purely to Wikipedia. Most category items don't even have that much. Lets say this was an item for a business that only had primary references to said business's store front and a sitelink to Commons. I think it would be perfectly reasonable in that case to delete the primary references and convert it into a category item. Especially if the item can't just be deleted as spam "because sitelink" or whatever. Otherwise your just using the existence of a sitelink as a weird loophole to let businesses use Wikidata for promoting themselves, which at least IMO isn't in the spirit of the guidelines or project. If deleting the primary references and/or turning it into a category item isn't adequate though, cool. What's your alternative to the entry being promotional then? --Adamant1 (talk) 22:28, 10 July 2023 (UTC)
The closing admin (Emu) did not note in their closing any specific ongoing restrictions on the item. There is nothing on the discussion page of the item to indicate such a restriction. Such restrictions would be extremely unusual. The only comparison I can think of is a handful of cases where we try to exclude certain claims for BLP privacy reasons, but that clearly does not apply in this case.
Some of our items (e.g. categories, discographies, list items, disambiguation pages, templates, portals) are a little special because they only represent pages on Wikimedia projects, and not real-life entities or concepts. Our notability guidelines place special restrictions on such pages, which is why criterion 1 has so many sub-parts. None of these apply to Q113531294. It does have a sitelink only to Wikimedia Commons, but it is not a category item. It is therefore notable according to the letter of current policy.
If we had an item for a business that had a sitelink to Wikipedia Commons, category or not, that would be sufficient to establish notability. It would not be appropriate to convert the item to a category item. This comes up all the time at RFD. We often have to delay item deletion until after the corresponding Commons category (or other sitelinks) is deleted. We are, in that sense, subordinate to the notability decisions of our client projects.
You may think of this as a weird loophole that goes against the spirit of the project, and I suspect that many editors would agree with you, but that is what our current policy says. Bovlb (talk) 22:58, 10 July 2023 (UTC)
The closing admin (Emu) did not note in their closing any specific ongoing restrictions on the item. I thought the discussion was archived? Either way, Emu was the one who made the original recommendation and then he archived the DR after I agreed with him about it. So it's implied in him closing the discussion to begin with that he was doing so under the guise of the everything except for "instance of" being deleted. Otherwise the DR wouldn't have been archived. There's no rule that the reason a discussion was closed has to be formally and/or explicitly stated anywhere for it to be valid either. That said, if you disagree with Emu about it, cool. Take that up with them. It's pretty clear from the discussion that deleting everything but "instance of" was the condition that lead to the conversation being archived though. It's not problem if Emu didn't follow the proper procedure or whatever when he archived it in the meantime either. That said, if you want to discuss it with Emu be my guest and I'll respect whatever you both decide on, but IMO the reason it was closed should be valid until then. There's definitely no reason to ignore it just because of some minor procedural pedantry about how Emu decided do things.
As to the last part of your comment, I get how things generally work. Handwaving about things are "generally" handled doesn't address my question of what to do in cases where an item is clearly promotional due to being referenced to primary sources but contains a sitelink. It also ignores the fact that the notability guideline your citing only applies to "category items" and like you yourself say it's not a item for a category. So there's zero reason a sitelink on it's own would make it notable. Even if it was notable due to being a "category item" that contains a site link (which again it isn't), there's zero indication in the guidelines that an item containing a sitelink being notable overrules or cancel's out everything else related to not allowing Wikidata to be used for promotional purposes. So even if I bought your clearly baseless claim that it's notable due to having a sitelink, that doesn't deal with the issue of it being a purely or mainly promotional item. So again, if you don't think deleting the primary references and/or turning it into a category item isn't adequate, cool. What's your alternative to the entry being promotional? Or do you just not care if people use Wikidata as a way to promote themselves as long as their item contains a link to Commons? --Adamant1 (talk) 00:13, 11 July 2023 (UTC)
I'm evidently doing a poor job of explaining this. I'll give it one more go.
  • Our notability policy says that an a item is acceptable if and only if it fulfils at least one of the three criteria.
  • Criterion 1 says that the item must contain at least one sitelink (e.g. to Wikimedia Commons).
  • Criterion 1 also includes a number of exceptions, cases where a sitelink does not make an item notable.
  • In particular, N1.4 says that category items are not notable solely because of a Wikimedia Commons link, but also have to meet other criteria in order to be notable.
  • Q113531294 has a link to Wikimedia Commons and is not a category item.
  • Q113531294 meets the general provisions of criterion 1, is not covered by any of its exceptions, and is therefore considered notable.
I care deeply about stopping the Wikidata project from being abused, for promotional purposes, for slander, for hoaxes, or whatever. I have deleted many thousands of items. I maintain a large number of abuse filters. I have written a tool that makes it easier to find repeat offenders.
Our notability criteria do not mention promotional purposes as an exception. Instead they state that a non-category item with a Wikimedia Commons link is considered acceptable. The policy is clear. As an admin, my job is to enact community consensus, not override it. If you'd like to see us deleting such items, then there needs to be a community process to change the policy. Bovlb (talk) 02:26, 11 July 2023 (UTC)
N1.4 says that category items are not notable solely because of a Wikimedia Commons link Exactly. Your the one who keeps bringing up Commons links and acting like it's the only thing the item needs to have. Otherwise what other criteria does it qualify for notability under? 10 bucks says you can't site a single reason aside from the sitelink for why it's notable. If you can't then I'd ask you to follow your own standard, what the guideline says, and just admit it isn't notable because the only thing that gives it notability is the sitelink.
Q113531294 meets the general provisions of criterion 1, is not covered by any of its exceptions, and is therefore considered notable. No it doesn't. The only thing that makes it notable is the sitelink and criterion 1 makes it clear that an item can't be notable based purely on satisfying that alone. You can nitpick that it's not technically a "category item" all day long just because Benjamín decided to create it using "instance of human" instead of "instance of category." There's zero reason it would exist right now if it were not for the sitelink and that's literally the only argument anyone has given for why it and the references should be kept. So cool, follow your own argument and call it what it is instead of acting like it's not a category item.
It's ridiculously bad faithed to act like I just want the item to be deleted in the meantime when I'm not even the one who started this discussion and was just going along with Emu's recommendation in the DR when I removed the references. I could really give a crap if the item exists or not. I just don't want it to be promotional. That's it. You can't seem to give an actual answer to how we solve that other then my suggestions of removing the primary references or turning it into a category item. So your just handwaving though and Strawmaning me when I could really care less either way outside of removing the promotional links. That said, I'm totally fine with putting this on hold until Emu gives their opinion and then going from there. I'm definitely done dealing with having to respond to your clearly fallacious and vacuous nonsense. --Adamant1 (talk) 03:22, 11 July 2023 (UTC)
@Emu I think I'm done explaining here. Do you want to have a go? Bovlb (talk) 03:49, 11 July 2023 (UTC)
I think they said in another discussion that they are on vacation for a couple of days. Not surprising your done "explaining" things to me either consider you apparently can't do a simple thing like answer to deal with a promotional item if it's not deleted without lecturing me about a bunch of things that have nothing to do with the question lmao. Just an FYI for next time, but "explaining" something to someone usually isn't going to go anywhere if what your "explaining" to the person has nothing to do with the conversation or the comment your replying to. --Adamant1 (talk) 03:52, 11 July 2023 (UTC)
Yes, I’m on vacation, just received the ping. I won’t be having access to a proper computer until Saturday. Sorry, I don’t think it would be a good idea to engage in this rather complex discussion at this point in time. I’ll have a look as soon as I come back though, promise! --Emu (talk) 06:59, 11 July 2023 (UTC)
 Comment I think Bovlb's interpretation of the current policy is correct, as Q113531294 is not a category item (instance of Wikimedia category (Q4167836)) and therefore not excluded by 1.4. The confusion seems to stem from whether 1.4 applies to non-category items, and I'd like to provide some background information on this matter. Actually, in the past the exception clause used to be "an item with only a sitelink to a category page in Wikimedia Commons is not allowed on main article items" (bold text emphasized by me), which would have excluded items like Q113531294 but allowed category items with a single sitelink to a Commons category. However, sometime in 2018, the clause was changed to "sitelinks on category items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites", which now disallows category items but permits general items with only a sitelink to Commons. Some relevant discussions at the time can be found at Wikidata:Project_chat/Archive/2017/11#Proposed_change_to_WD:N_regarding_Commons_categories and Wikidata_talk:Notability/Archive_4#RfC:_Notability_and_Commons.--Stevenliuyi (talk) 12:02, 11 July 2023 (UTC)
I appreciate the background information. Although at least on my end the confusion is less about when to apply 1.4 and more about how to deal with a promotional item or one that only contains primary references when it can't be deleted as promotional because it contains a sitelink. That doesn't really having to do with 1.4 since it's not really a notability question at that point. The notability/1.4 thing was just a tangential side thing that Bovlb brought up for some reason when it wasn't really relevant. If you look at Pigsonthewing's original comment and my subsequent ones you'll see neither one of us said we thought the entry should be deleted and it has nothing to do with this.
What it does have to do with is that Pigsonthewing thought I shouldn't have deleted references to Daniel Benjamin Miller's personal website, which I did because both me and Emu decided in the DR that doing so would be a good way to keep the entry without it promoting Daniel Benjamin Miller in the process. So the question is if that's a valid way to deal with a promotional entry that can't be deleted due to containing a sitelink or not. Everything else is just an unrelated distraction that has nothing to do with the original point in the discussion and I'd still like the question of how to deal with a promotional item that can't be deleted because it contains a sitelink to be answered regardless of how we apply 1.4 or whatever. --Adamant1 (talk) 14:23, 11 July 2023 (UTC)
"me and Emu decided" That decision is not yours to make. Further, you persist in describing the item as "promotional", without basis. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:40, 11 July 2023 (UTC)
The last time I checked Emu is an administrator and I doubt they would have suggested removing everything except "instance of" to make the entry not be promotional if it was against the project goals. You'd have to take that up with them though since I wasn't who the made recommendation to begin with. Nor do I know where Emu got the idea from. In the meantime though, there's clearly guidelines against allowing for promotional entries and Emu's solution of how to deal with that in particular case seems perfectly reasonable to. I also have yet to find anything in the guidelines saying it isn't or that promotional links can't be removed from entries. Although as I've stated multiple times now I'm fine with dealing with it being promotional in another way if someone presents one. No one seems willing to suggest an alternative though. I certainly haven't seen you provide any.
Also, there's plenty of basis for describing the item as "promotional" and I'm not the only one who has described it that way. Other people in the DR did to. I'm not here to reiterate points that have already been made multiple times by multiple people in multiple conversations already though. Except to say Emu didn't just come up with removing everything except for "instance of" off the top of their hat for no reason. You can read through the DR to find out why though since again, I'm not going to waste my time repeating things just because you apparently can't be bothered to read the deletion request for some reason. --Adamant1 (talk) 15:56, 11 July 2023 (UTC)

a few days later after Emu came back from vacation

Adamant1, Andy Mabbett, Bovlb, Stevenliuyi, MisterSynergy, D. Benjamin Miller, Ghouston, Multichill (sorry if I missed somebody or pinged them without good reason): Okay, thank you for your patience, I’m back from vacation. In short:

  1. I closed the RfD as an admin with the rationale that the item conforms to our notability policy (because of the Commons category). I did not try to attach any preconditions or reservations onto this decision and I don’t think that this would be possible anyway.
    • One might question if this was a wise decision considering Wikidata:Administrators#Involved_administrators and my involvement in the discussion. At the time, I felt that this wasn't an issue since (a) it’s a pretty clear-cut case and (b) the decision was against my own personal wishes (that is, deletion). I probably should have at least addressed this issue, sorry for that.
    • To be honest, I just wanted this gargantuan RfD resolved, since there was no point for this discussion to go on any further.
  2. As discussed a few topics further up on this page (Wikidata:Project chat#Subject_as_source_for_basic_biographical_data) I have changed or deleted many statements on Daniel Benjamin Miller (Q113531294) after the decision to keep.
    • This wasn’t done in my capacity as admin. Sorry if it looks that way.
    • As mentioned on the deletion discussion, I do think that we should enforce stricter sourcing rules when the existence of items relies solely on Commons categories. I also think that this is a rather elegant compromise between our current notability criteria and our quality standards. It has however become clear from this discussion that this isn’t consensus.
    • I think it’s pretty clear that this is a vanity item, it was even created by the depicted person. Yes, that’s not against any rule. No, I don’t think that this is a good idea.
    • As for the edits of Andy: I would have probably ignored them. They don’t seem to be necessary but I don’t see the harm in them.

I’m not quite sure if I understand all subtleties and detours of this conversation so please feel free to press me on aspects I haven’t mentioned yet. Sorry again for the long waiting time. Sorry also because it seems that I wasn’t as clear in my communication as admin as I should have been. --Emu (talk) 14:43, 15 July 2023 (UTC)

Thanks Emu.
  • As discussed at length above, I agree that the keep decision was clear-cut, based on our notability criteria. I see no issue of involvement here.
  • I also agree that it's a bad idea for editors to create items on themselves. It's not technically against the rules, but time and again people have proven to be poor judges of their own notability.
  • Outside of the awkward problem of privacy violations, I say that once we have accepted an item as notable, it's appropriate to represent it as well as we can. In particular, adding the official website and social media links (including as references) is not any more promotional than simply having the item in the first place.
  • Our primary mechanism for excluding promotional content from Wikidata remains the notability criteria. If the community feels that we are letting in too much promotional content, then we should discuss changing or clarifying those criteria.
Bovlb (talk) 22:22, 17 July 2023 (UTC)

Wikidata weekly summary #584

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: Tomodachi94 (RfP scheduled to end after 21 July 2023 05:02 UTC)
    • New requests for permissions/Bot:
      • Peuc bot 3 (Task: One-time import of a database of Québec written literary works)
      • MajavahBot (Task: Import version and metadata information for Python libraries from PyPI)
  • Tool of the week
    • Wikidata Recent Changes API (simple front-end to the actual API) lets you query Wikidata edits by either properties, or labels/aliases/descriptions/sitelinks. You can retrieve any changes, or specify added/changed/removed. Current lag to Wikidata: 1 seconds. (blog)
  • Development
    • Vector 2022 skin: We finished working on removing the strange bolding pattern of the Search Results on Wikidata. Should be rolled out in the next train (phab:T327510)
    • EntitySchemas: We are working on showing the Label of EntitySchema in Statements and Special pages (phab:T339924)
    • Mismatch Finder: We are working on adding the Language Selector to the Mismatch Finder (phab:T328149)
    • mul: We trying out changing how placeholders in Wikibase termboxes work: They’ll soon start falling back across the fallback chain of the language until they hit mul (phab:T340832)

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.


There is also archives at (P485) and supporting values like collection (P195) and catalog (P972). Also noticing that most archives have tjeir own identifier for å file or person i the arcjhive like UK National Archives ID (P3029) and Swedish National Archive reference code (P5324)

Screen Actors Guild

Anyone want to help build the table for the Presidents of the Screen Actors Guild, since they are in the news. See: Talk:Q120638159. You edit position= at the entry for the person. The master list is at the link at President of SAG (Q120638159). RAN (talk) 01:37, 16 July 2023 (UTC)

✓ Done Quesotiotyo (talk) 20:53, 16 July 2023 (UTC)

Wikidata property suggester php api alternative?

Hello, I have been checking ways to recommend properties for classes extracted from Wikidata for a school project. The extraction of classes I am doing is based on the values from "instance of" and "subclass of" properties on items. The next step would be recommend properties for classes. For example something like Recoin does (counting appearances of properties for instances of the same class). I have noticed there exists internal PropertySuggester for wikidata when editing statements on items and found out a php api (e.g. "https://www.wikidata.org/w/api.php?action=wbsgetsuggestions&properties=P1174"). From the specificatition stems that it should be able to recommend additional properties for a given list of properties and given list of types (which i assumed were classes). Such query would be "https://www.wikidata.org/w/api.php?action=wbsgetsuggestions&properties=P31&types=Q215627&language=en&format=json&limit=10" as properties lists properties and types lists classes. So I would assume that for my use case, asking for additional properties if there is "instance of" property and the item is of class "Q215627" would recommend the same thing as if I was adding statements while editing item with only statement "instance of property with value Q215627". However the api returns always the same properties no matter the type.

Is there a way to get programatically the recommendations I need, that is to say, for a given class get used properties? For example with a python script quering the php api or access the property suggester? I have noticed that the php api works well if the item actually exists with the "intance of property with a class value". But creating empty classes seems like a very bad idea.

I would be very glad, for any advice or help regarding the topic for recommendation. Martin Gora (talk) 18:52, 18 July 2023 (UTC)

i believe if you access the DB directly you can compute this yourself. see https://www.mediawiki.org/wiki/Extension:PropertySuggester/wbs_propertypairs_table BrokenSegue (talk) 20:35, 18 July 2023 (UTC)
Thank you very much for your reply @BrokenSegue.
I was also wondering whether the behaviour of the api with the "types" + "properties" parameters is correct or maybe I just used it incorrectly. I would assume that changing values inside type parameter randomly for properties parameter containing a single property, such as P21 (Sex or gender), would result in different recommendations, but it is always the same, even the rating values. (To provide example: P21+Q5(Human) vs P21+Q1330675(Mosaic)).
I also wanted to ask in your reply, if you would please navigated me towards accessing the database directly, I admit I have no idea how to do that. Sorry if that does not belong here, maybe I should post another question? Martin Gora (talk) 07:34, 19 July 2023 (UTC)
you can access the DB directly by asking for a toolforge account. See [3] and [4]. i believe the property suggester logic is only "smart" about values P31/P279. This is just a performance consideration. Computing the probability of every property given every combination of every other property is expensive. But if you want more detail you're really going to need to read the property suggester PHP source code. I believe you want to read [5].
I'll be honest that I don't fully understand what you are trying to do so it's a little hard to offer advice. BrokenSegue (talk) 14:20, 19 July 2023 (UTC)
Thank you for your time and directions @BrokenSegue. And I am sorry I was not clear what I tried to accomplish.
My goal:
For my school project I will extract classes from json dumps based on the values from item properties "instance of" and "subclass of". As I understand, a class is an item that is used as a value of either "instance of" or/and "subclass of" property (for "subclass of" it works both ways: i1 -[subclass of]-> i2, i1 and i2 are both classes).
As a next step in my application a user will select a class, e.g. Q5 a human (it is a class since people are instances of human). For the user selected class I would like to recommend properties that can be used on items that are instances of the class. To accomplish that I wanted to use the php api of property suggester and make it recommend the same properties as if I manually created empty item in wikidata and added single property "instance of" with the value equal to the user selected class (e.g. if user selected a class Q5, then the item in wikidata would have only "instance of"=Q5). If i continued in wikidata client and wanted to add statements to the item, the property suggester would recommend me properties used for the type/class (type/class == value of the instance of property) that are missing on the item. And via the php api of the property suggester, I wanted to accomplish the same behaviour.
The api has two variants. The first variant takes an item id of an existing item in wikidata and for that item it recommends properties that are relevant to add for that item. The second variant takes a list of properties and list of types. A list of properties contains properties that I have (imagine imaginary item that has these properties) and the property suggester will recommend additional properties that are used with the list of given properties. The list of types is an additional help for the suggester, since it tells the class (as if the imaginary item had instance of=type for each type in the list).
The second variant for my use case is exacly what I wanted. To my undestanding, to mirror the behaviour of the first variant, I wanted to place "list of properties"=P31 and "list of types"=Q5. But as I mentioned above, when I use the api with the additional list of types, the suggestions does not seem to differ from when I used only the list of properties, so it looks like the property suggester does not take them into an account. Another point is that when list of properties contains P31(instance of), it seems it recommends the same things even if the list contained other properties.
So my question would be, how to accomplish behaviour of the first variant if the item does not exists? Martin Gora (talk) 20:33, 19 July 2023 (UTC)

Hyalosepalum scytophyllum

Is there any reason why this specie is not created? I am not an export on Wikidata. Regards! Oesjaar (talk) 19:28, 18 July 2023 (UTC)

Aangename kennis. I think it may be because the species name is unresolved: species:Tinospora. —Justin (koavf)❤T☮C☺M☯ 19:44, 18 July 2023 (UTC)
Nice to meet you! See Plants of the World Online Regards. Oesjaar (talk) 19:51, 18 July 2023 (UTC)
@Oesjaar: It is apparently a synonym of Tinospora uviforme (Q15325358)? See EOL and Catalogue of Life. But, Hyalosepalum scytophyllum (Q120734721) was created today, and I'm not exactly sure how synonyms are handled here, just that they're not merged. — Huntster (t @ c) 21:00, 18 July 2023 (UTC)

The items for taxa here are usually created by bots which use the data for taxa with status valid/accepted in taxonomy databases. WFO Plant List shows the status unplaced for the species within the genus of Hyalosepalum, it may be a valid taxon, or a synonym, or a representative of a closely-related genus (=syn. too). It's okay if kew.org lists the species as accepted (it's reliable source) but note that the situation may be changed in the future. I don't mind if the WD item and afWP article exist. --Wolverène (talk) 07:49, 19 July 2023 (UTC)

Indexing our medical journal in DOAJ,or SCOPUS, or EMBASE..

Can you help us our medical journal to get indexed in Any one of these,Pubmed or medline.or WOS, or DOAJ,or SCOPUS, or EMBASE or SCI./SCIE wos .Indian journal of applied basic medical sciences www.themedicalacademy.in contact :appiguj@gmail.com Ijabms (talk) 04:23, 18 July 2023 (UTC)

we cannot do that here BrokenSegue (talk) 04:34, 18 July 2023 (UTC)
Like @BrokenSegue said it's not something we can do. Ypu need to contact each of those databases and they will tell you what their specific procedure is. DGtal (talk) 13:11, 19 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 12:43, 26 July 2023 (UTC)

WorldCat Entities for French churches

I wonder why I'm not able to find WC Entities for Notre-Dame de Paris (Q2981) and Notre Dame du Haut (Q638250). Why weren't they created by WorldCat?-- Carnby (talk) 07:16, 18 July 2023 (UTC)

This is not limited to French churches; I checked a few other items such as St. Patrick's Cathedral (Q624556), and Hagia Sophia (Q12506). These bear the property WorldCat Identities ID (superseded) (P7859), and following the linked identifier results in an error. Cross-checking those entities in the OCLC Entity Search engine yields no results, yet there exist entities for a few very minor such churches. It seems to me that the old database has been invalidated, and the new one isn't fully populated. Elizium23 (talk) 10:46, 21 July 2023 (UTC)
So we just have to wait?-- Carnby (talk) 21:17, 21 July 2023 (UTC)
OCLC/Worldcat is a library-based service, yes? So they catalog books and other works that are carried by libraries, and listed in library catalogs. I'm not sure how we could expect them to have a comprehensive list of objects that a library can't carry, Worldcat's past notwithstanding. Elizium23 (talk) 22:15, 21 July 2023 (UTC)
So, how can we deal with the issue?-- Carnby (talk) 07:16, 22 July 2023 (UTC)
Perhaps it would be helpful to know, what is the problem you are trying to solve, or the goal you are trying to accomplish? Elizium23 (talk) 10:35, 22 July 2023 (UTC)
The warning in WorldCat Identities ID (superseded) (P7859). Without a valid WorldCat Entity it doesn't disappear. And those churches, as well as other things, don't have a WorldCat Entity.-- Carnby (talk) 05:53, 23 July 2023 (UTC)
Okay, let's dig deeper. Why are you working on WorldCat Identities IDs? Elizium23 (talk) 06:58, 23 July 2023 (UTC)
There, I've quelled the warning messages in two steps: edit 1, edit 2. Is that helpful? Elizium23 (talk) 07:11, 23 July 2023 (UTC)
Looks good. Thanks.-- Carnby (talk) 07:35, 23 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 12:42, 26 July 2023 (UTC)

Request for a proposed property to be created

Hi all

Three weeks ago I proposed Wikidata:Property proposal/World Geographical Scheme for Recording Plant Distributions ID which has three supporters and no objections. Not having the property available is really starting to delay our project (a partnership with Kew Gardens). Could I please ask a property creator to take a look at it?

Thanks very much

John Cummings (talk) 10:43, 20 July 2023 (UTC)

Just created the property. In the future, if a proposal meets the necessary requirements (it's been up for a week and there are no serious objections), you can flag the property as ready using |status=ready in the proposal template. That puts it in Category:Properties ready for creation, so property creators can easily find it. Vahurzpu (talk) 23:37, 20 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 12:41, 26 July 2023 (UTC)

Numbering system for a position

@Quesotiotyo: For Ken Howard (Q1320640) the SAG website says: "Ken Howard was elected the 25th president of Screen Actors Guild. " User:Quesotiotyo wants to use their own numbering system for the ordinal, making him the 28th president (counting the three times a person was given a non consecutive reelection). Should we use the Screen Actors Guild's own numbering system (NOT counting the three times a person was given a non consecutive reelection) or should we use the Quesotiotyo numbering system for the position. Note that we use the numbering system rules for Mayors and Governors and Presidents and Popes that the entities themselves use. For instance:

So, which numbering system should we use, the Quesotiotyo numbering system or the Screen Actors Guild own numbering system? RAN (talk) 12:20, 20 July 2023 (UTC)

Not sure we need a position numbering system at all. Jklamo (talk) 14:33, 20 July 2023 (UTC)
You wrote: "Not sure we need a position numbering system at all". I don't think we need any of the information we collect on people, but what we do add, we need it to be accurate. You would not renumber the Presidents of the United States or the Popes by any other system than the official one they use. --RAN (talk) 15:17, 20 July 2023 (UTC)
Series ordinal (P1545) is for indicating sequential ordering, not simply providing a count. The sentence that you quoted is doing the latter (it would be doing both were there not prior nonconsecutive terms involved). This information can be stored using quantity (P1114) on President of SAG (Q120638159) if you wish to record it somewhere.
--Quesotiotyo (talk) 18:48, 20 July 2023 (UTC)
I forgot to point out that the infobox at w:en:Ken Howard refers to him as the "28th President of the Screen Actors Guild". --Quesotiotyo (talk) 18:53, 20 July 2023 (UTC)
Does that mean Wikipedia is right and SAG is wrong? Do we change the numbering of Mayor of New York City (Q785304) and Governor of New York (Q2347975) to fit your unique numbering scheme? Or, do we just follow the numbering system the SAG website uses? One of the reasons we use the ordinal is so that "data to prose" programs like Siri and Alexa and ChatGPT will correctly refer to him as the "25th president of Screen Actors Guild". --RAN (talk) 22:58, 20 July 2023 (UTC)
In case it matters, the ordinal in the infobox was added by @Nuitetjour back in 2019, at a time when that claim did not appear in Wikidata. Bovlb (talk) 00:14, 21 July 2023 (UTC)

Christchurch Harbour (Q2055615)

Christchurch Harbour (Q2055615) is categorised as a "human settlement". It seems odd to me. Is a body of water a "human settlement"?? ITookSomePhotos (talk) 22:57, 23 July 2023 (UTC)

It should be a geographical feature. That its been wrong for 9 years shows how big a task it is to pick up mistakes here. Vicarage (talk) 06:06, 24 July 2023 (UTC)
OK, thanks, I changed it. ITookSomePhotos (talk) 08:20, 24 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 12:41, 26 July 2023 (UTC)

Adding a draft as a Wikipedia entry for a dataset

Hello, I'm in the process of creating an article about Philippe Hurel to the English Wikipedia. I'm experimenting with the Infobox person/Wikidata-template, but this requires for the English draft to be linked to the Wikidata item. Is it OK to add a draft as an article to the Wikipedia-variable to https://www.wikidata.org/wiki/Q3380040? There are already articles linked for Catalan, German, Spanish and French. NotAGenious (talk) 08:11, 25 July 2023 (UTC)

You shouldn't add sitelinks to draft articles on Wikipedia. Instead you can override the Wikidata item being used. E.g. {{Infobox person/Wikidata|fetchwikidata=ALL|qid=Q3380040}} Infrastruktur (talk) 09:43, 25 July 2023 (UTC)
Thank you for your help! NotAGenious (talk) 10:47, 25 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 12:40, 26 July 2023 (UTC)

Pterocarpus tessmannii

Can somebody please create this for me? Regards! Oesjaar (talk) 19:35, 25 July 2023 (UTC)

@Oesjaar: This one: Pterocarpus tessmannii (Q15525190)? --Succu (talk) 20:20, 25 July 2023 (UTC)
Succu, yes, thanks! Regards! Oesjaar (talk) 14:27, 26 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 17:27, 26 July 2023 (UTC)

Problem logging in in Wiki Edu

Hello,

I am trying to log in into Wikipedia, but it tells me I am not able to log in and complete therefore my tutorials. Any help?

Thanks FedericaCuccato91 (talk) 16:56, 21 July 2023 (UTC)

@FedericaCuccato91 You are logged in here, and your account does not seem to be blocked anywhere. Which project are you attempting to access and what is the error message you see when you attempt to log in? Bovlb (talk) 18:55, 21 July 2023 (UTC)
CC @Bluerasberry Bovlb (talk) 18:57, 21 July 2023 (UTC)
The error message I get when trying to log in Wikipedia or a project i have a link for is “ This IP address has been blocked from editing Wikipedia.” and when i follow all the links from the help page it tells me I’m blocked out of the site. FedericaCuccato91 (talk) 19:47, 21 July 2023 (UTC)
Can you log into a Wikimedia project? https://en.wikipedia.org/wiki/Help:Logging_in
Say more about what is happening. Are you trying to track your Wikidata edits in https://dashboard.wikiedu.org/ ? Bluerasberry (talk) 19:04, 21 July 2023 (UTC)
Well, yes. I am trying to log in into WikiEdu, but it seems my IP is blocked. I can log in here fine for some reason though! FedericaCuccato91 (talk) 19:44, 21 July 2023 (UTC)
If you're seeing a message like “This IP address has been blocked from editing Wikipedia” that suggests that the IP address you're using is subject to either a hard account block or a hard IP address block (see en:Wikipedia:Blocking_policy#Common_blocks_imposed). Either way, you need to appeal the block on the local project, probably by posting {{unblock|1=<the reason for your unblock request>}} on your user talk page, but the process varies by project. You will probably need to include the full text of the error message you see when you try to log in. Bovlb (talk) 00:37, 22 July 2023 (UTC)

This combination of ship and award needs deleting

Robert Foster Cherry Award (Q15716118) is a mixture of an an unnamed ship and a reference to a completely unrelated wikipedia article on an award. As there seems no way of establishing which ship is being talked about, can it be deleted. Vicarage (talk) 15:20, 27 July 2023 (UTC)

Situation handled. All the ships of that class were accounted for, and the award the Kannadan article refers to had another item on WD. These have been merged. — Huntster (t @ c) 17:39, 27 July 2023 (UTC)
This section was archived on a request by: — Huntster (t @ c) 17:39, 27 July 2023 (UTC)

Preferred rank for full dates

What happened to the project to mark preferred_rank to all the full dates of birth and death, so that year-only dates do not display in the infobox ? RAN (talk) 17:11, 21 July 2023 (UTC)

Wikidata:Bot_requests/Archive/2021/11#request_to_automate_marking_preferred_rank_for_full_dates._(2021-05-28) Bovlb (talk) 23:44, 21 July 2023 (UTC)
my bot is still doing this. see for example this edit. Unfortunately the SPARQL query it uses to find dates to fix is too slow and often times out. So it's hard to comprehensively go through all items and fix them all. I haven't had time to go back and make it more robust. BrokenSegue (talk) 15:57, 22 July 2023 (UTC)

How important is the stability of identifier values?

A good number of proposals for sports identifiers appear to link to websites that list only current players, which means that IDs won't be stable.

I'm wondering how important other people, with property creation permissions, think this is. Would you for instance pass a proposal that is otherwise okay, and has more than enough profiles to warrant creation and no other technical or common-sense issues? Infrastruktur (talk) 18:43, 22 July 2023 (UTC)

only having current players is a little sketchy to me. generally I'm ok with values changing or leaving if there is a good chance an archiver will get there before the value disappears. unfortunately the archiving bots don't autoarchive our external IDs. BrokenSegue (talk) 19:15, 22 July 2023 (UTC)
What should be considered more is (1) whether the IDs will change even if the entry is not withdrawn, i.e. one subject will have different ID over time; and (2) whether withdrawn IDs get reused. GZWDer (talk) 20:47, 22 July 2023 (UTC)
I imagine most websites that uses numeric identifiers would typically use an ID that is set to auto-increment which will prevent reuse. Thanks for the informative answers. Infrastruktur (talk) 21:16, 22 July 2023 (UTC)

Warning Sign

Hello,

I already created an item, I used it as a source for another information but it is showing a warning sign.

What do I do? Did I do something wrong? Mistarflyy (talk) 18:32, 25 July 2023 (UTC)

@ Mistarflyy: which item was the warning on? What did the warning say? Click on the warning for details? BrokenSegue (talk) 18:38, 25 July 2023 (UTC)
Q120868912 maybe — Martin (MSGJ · talk) 11:51, 26 July 2023 (UTC)
It should have inverse statement owned by Bolarinwa Kashif Ololade. Mistarflyy (talk) 12:31, 26 July 2023 (UTC)
@Mistarflyy To fix this warning, go to Bolarinwa Kashif Ololade (Q120557001) and add a owned by (P127) owner of (P1830) claim.
But in general don't get too stressed by these warnings. Some of them indicate a problem you ought to fix, and others are just a suggestion for improvement. Bovlb (talk) 16:12, 26 July 2023 (UTC)
Alright. Thank you. Mistarflyy (talk) 21:03, 26 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 11:19, 28 July 2023 (UTC)

Question about WD:N

Is having a profile at Cravo Albin enough to pass WD:N? I'm still getting use with notability criteria here and any insight from an experienced user would be much appreciated. Thanks. Kacamata (talk) 21:56, 26 July 2023 (UTC)

Cravo Albin seems to have pretty detailed biographies attesting to their notability. I think having a record there is probably enough to establish notability. -- William Graham (talk) 00:21, 27 July 2023 (UTC)
Thank you for your insight. Kacamata (talk) 18:44, 27 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 11:19, 28 July 2023 (UTC)

New item co-ordinate help

I've created Allée Charlotte-Perriand (Q120972228): street in 7th arrondissement of Paris, France but am having difficulty getting the co-ordinate information entered correctly. Any help would be appreciated. Cheers, Cl3phact0 (talk) 05:44, 28 July 2023 (UTC)

You made a duplicate. With this Allée Charlotte-Perriand (Q62030626). RVA2869 (talk) 07:43, 28 July 2023 (UTC)
Resolved duplicity Isidre blanc (talk) 09:48, 28 July 2023 (UTC)
Apologies for making a duplicate. Thank you for cleaning-up after me. Cl3phact0 (talk) 13:56, 28 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 11:17, 28 July 2023 (UTC)

Usability of typically sells (P7163) and typically sold by (Q106882595) with specific products and shops

Hello,
I'd like to know opinions about if it is okay linking a shop to a specific product (pex. <brand> muesli) that is sold in that shop/store by the typically sells (P7163).

My question raises from the fact that looking up those properties, I haven't seen a specific example, leading me to believe that the property must be used only with generalizations.

Is it okay to use it for specifics? (a shop could have thousands of links to products)
Would it be needed to have a new property?

Thank you Saicpp (talk) 07:04, 24 July 2023 (UTC)

I can see that chocolate shop (Q47504660) sells chocolate, but I can't see how anything more specific could be useful in the fast-moving world of retail. You would have a very incomplete and obsolete dataset. Vicarage (talk) 08:24, 24 July 2023 (UTC)
Okay I just checked and I misunderstood the intended use of OpenFoodFacts properties.
I had thought to contribute by linking WikiData to OpenFoodFacts, but I can see your point, and why it could backfire.
Thank you and sorry for the inconveniences :D Saicpp (talk) 09:00, 24 July 2023 (UTC)
We seem to have 4 WD properties for Open Food Facts (Q3353146), work with those would be much appreciated. Vicarage (talk) 09:27, 24 July 2023 (UTC)

Wikidata weekly summary #585

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: Yahya (RfP scheduled to end after 26 July 2023 17:46 UTC)
    • Closed request for adminship: Tomodachi94 (unsuccessful)
  • Events
    • Upcoming
      • Missed the initial office hour sessions for preparing a WikidataCon 2023 submission? Join the next sessions on 20th, 22nd, and 26th and bring all your questions. Wikidata:WikidataCon 2023#Office hours (available in both Mandarin and English)
      • Live Wikidata editing in Italian, July 25 at 9:00 PM CEST on YouTube
    • Ongoing
      • Ongoing: Weekly Lexemes Challenge #102, Money (Challenge started on 2023-07-24 12:01:19)
  • Tool of the week
    • Images near items - helps to find Wikimedia Commons images near Wikidata items without image. It can load a category tree of Commons images with coodrinates, and then find Wikidata items of a certain P31 with coordinates but without images. Then, it will try to find nearby (<50 meters) pairs. (example link for UK red phone booths)
  • Development
    • EntitySchemas: We expanded the new datatype that is in testing. When a statement links to an EntitySchema it will now show its label when available (phab:T338613). We are also working on showing them by their label in recent changes and similar places (phab:T214885).
    • mul language code: we are working on improving the termbox to integrate this new language code better (phab:T340644)
    • Mismatch Finder: We are working on adding a language selector to it so you can switch the language of the tool (phab:T328149)
    • Wikibase REST API: We completed two new endpoint for the Wikibase REST API:
      • Retrieve all statements from a Property - /entities/properties/{property_id}/statements
      • Retrieve a single statement from a Property - /entities/properties/{property_id}/statements/{statement_id}
      • You can also retrieve a single statement from a Property from the existing /statements/{statement_id} endpoint

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.

Correction: Wikidata:Requests for permissions/Administrator/Tomodachi94 is unsuccessful. Ymblanter (talk) 15:50, 24 July 2023 (UTC)
My bad. Thanks for spotting it. -Mohammed Sadat (WMDE) (talk) 07:46, 26 July 2023 (UTC)

What is an “image of relevant illustration of the subject” ?

In particular, do these contributions fall within this framework? 1869922409, 1894647009, 1894649703, 1894651850, 1939816642 or 1939820108, for Property:P18. As a courtesy, I notify this topic to @Celinea33 and @MHM55. Regards. — Ideawipik (talk) 14:36, 26 July 2023 (UTC)

this controversy has come up before. generally they do. BrokenSegue (talk) 18:05, 26 July 2023 (UTC)

Diversity and bias in DBpedia and Wikidata as a challenge for text-analysis tools

Summary: Diversity Searcher is a tool originally developed to help analyse diversity in news media texts. It relies on automated content analysis and thus rests on prior assumptions and depends on certain design choices related to diversity. One such design choice is the external knowledge source(s) used. In the linked article, they discuss implications that these sources can have on the results of content analysis. They compare two data sources that Diversity Searcher has worked with – DBpedia and Wikidata – with respect to their ontological coverage and diversity, and describe implications for the resulting analyses of text corpora. They describe a case study of the relative over- or underrepresentation of Belgian political parties between 1990 and 2020. In particular, they found a staggering overrepresentation of the political right in the English-language DBpedia. --Jensbest (talk) 12:08, 27 July 2023 (UTC)

Was the representation on Wikidata better than DBpedia? I would expect it to be. BrokenSegue (talk) 00:55, 28 July 2023 (UTC)

My colleagues have data on wikidata and this data appears on the Google search engine, but my problem is that my data does not appear on the Google search engine. Can you help me solve this problem, knowing that I waited more than two months for it to appear automatically, but to no avail. Zayn Hesham (talk) 16:56, 27 July 2023 (UTC)

@Zayn Hesham Hi! Thanks for following up.
First of all, you should know that we discourage editors from creating items about themselves.
Secondly, the relevant item appears to be Q119790860. There is a Google Knowledge Graph id which appears valid. When I search for "Zayn Hesham", Google appears to be using a knowledge graph entry, but everyone is going to see slightly different Google results.
What specifically are you doing, what is the result, and what were you expecting to happen instead? Bovlb (talk) 17:28, 27 July 2023 (UTC)
You may also want to join the discussion at Wikidata:Requests_for_deletions#Q119790860. Bovlb (talk) 19:14, 27 July 2023 (UTC)
Wikidata is not intended to improve the search results for a specific query. It's not associated with Google, so even if Wikidata items seem to effectively affect the Google search results, Wikidata isn't 'working' with the results directly. WD is just one of millions of websites indexed by Google (Yahoo, Yandex, whatever), and WD never guaranteed an assistance in a sort of promotion. Its main goal is structuring the data which could be used in Wikipedia and its sister projects.
Additionally, the search engine actually 'knows' you, and your name/alias is connected to a G- knowledge graph. --Wolverène (talk) 12:34, 28 July 2023 (UTC)

Local notability policy

What is the "local notability policy", it keeps turning up in deletion arguments as a reason to remove people that aren't famous, but no one can define it, or point to some written policy guideline. It may be a concept imported from English Wikipedia. RAN (talk) 16:38, 29 July 2023 (UTC)

Do you mean a fragment of my reply on WD:RFD? I meant Wikidata:Notability. I didn't guess that the wording local notability policy may sound obscure for the English speakers, I was sure that local policy in this context means a policy within the project we are using at moment, here it's Wikidata. --Wolverène (talk) 18:38, 29 July 2023 (UTC)
Also, I never said that a person must be famous to be notable for Wikidata. --Wolverène (talk) 18:58, 29 July 2023 (UTC)
  • It sounds like someone who may only be famous locally, like in the town where I live where the reference material may be the local paper. You argument for deletion was: "Mr Archibald Olive just lived his life as a farmer, he wasn't either an election candidate, or a soldier, or a trade unionist.", which to me is more like the English Wikipedia policy of fame. --RAN (talk) 22:09, 29 July 2023 (UTC)
    If the local paper had anything substantial to say about Mr. Archibald Olive, we wouldn’t have this conversation, now would we? --Emu (talk) 22:51, 29 July 2023 (UTC)
  • Yes, we would still be here because the argument is that he is not an "election candidate, or a soldier, or a trade unionist." Of course if both of you just followed our actual policy where: "It refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references", we would all be saved lots of time both at deletion debates and here at project chat. --RAN (talk) 23:37, 29 July 2023 (UTC)
    Of course, election candidates, soldiers, and trade unionists were examples of people who might be described by something more than US census data (mandatory existing for everyone by the law) or an obituary (roughly speaking, obituaries and written birthday greetings are equally useful in the matter of making subjects clearly identifiable). And by something more than a entry in a database which can be edited by anyone with any intentions. Also, AFAIK not every "Election candidate, or a soldier, or a trade unionist." is notable by the enWP policy... with which I probably familiar worse than you, but seems definitely not every of them. Should we really continue wasting time discussing the English Wikipedia?
    These debates are becoming more emotional than constructive, and it's not good. Is not it better to start a discussion which can help us all to understand if Find a Grave or similar websites suggest notability? I am not sure that only I doubt that they suggest. In partucular, I don't see Find a Grave memorial ID (P535) listed here.
    P.S. Just in case, I'd like to apologize for my words which might've sounded like I believe that farmers are not notable. Of course, some farmers are notable. Just like election candadates, some trade unionists and actors. --Wolverène (talk) 02:09, 30 July 2023 (UTC)
    @Richard, accusing two admins of not following notability policy is a pretty serious charge. Please at least try to understand that your reading of WD:N, while shared by a vocal minority, is far from general consensus. --Emu (talk) 08:21, 30 July 2023 (UTC)
  • If you can't win an argument by logic and persuasion, remember to threaten to use the Admin card. --RAN (talk) 15:38, 30 July 2023 (UTC)
    Again, it sure looks like you are accusing me of inappropriate behavior as admin (intimidating users). Per AGF and because English is not my first language, I will assume that this is not the case. Might I just remind you that I haven’t acted in my capacity as admin in this discussion? --Emu (talk) 17:08, 30 July 2023 (UTC)
  • Why would someone mention they were an Admin if it wasn't intended to intimidate? Why don't you and I just end it here, and let other people express their opinions. You made your point and I made my point, all the needless repetition is just wasting everyone's time. --RAN (talk) 22:38, 30 July 2023 (UTC)
    Because accusing a non-admin of not following notability policy is irrelevant because they don’t have to. Admins do. But sure, let’s end this discussion that you started at this point. --Emu (talk) 23:29, 30 July 2023 (UTC)

Property for linking vital records / civil registration to the institution they kept them

Hi, do we have or need the possibility to link online vital records or civil registrations to the institution (religious institution, state organization) that kept them? Something along the lines of:

This would probably help a lot if maintained consistently. A possible name could be “registration records available at“.

ChristianKl (talk) 15:11, 24 June 2017 (UTC) Melderick (talk) 12:22, 25 July 2017 (UTC) Richard Arthur Norton Jklamo (talk) 20:21, 14 October 2017 (UTC) Sam Wilson Gap9551 (talk) 18:41, 5 November 2017 (UTC) Jrm03063 (talk) 15:46, 22 May 2018 (UTC) Egbe Eugene (talk) Eugene233 (talk) 03:40, 19 June 2018 (UTC) Dcflyer (talk) 07:45, 9 September 2018 (UTC) Gamaliel (talk) 13:01, 12 July 2019 (UTC) Pablo Busatto (talk) 11:51, 24 August 2019 (UTC) Theklan (talk) 19:25, 20 December 2019 (UTC) SM5POR (talk) 20:17, 29 May 2020 (UTC) Pmt (talk) 23:22, 27 June 2020 (UTC) CarlJohanSveningsson (talk) 12:13, 30 July 2020 (UTC) Ayack (talk) 14:39, 12 October 2020 (UTC) EthanRobertLee (talk) 19:17, 20 December 2020 (UTC) -- Darwin Ahoy! 18:20, 25 December 2020 (UTC) Germartin1 (talk) 03:13, 30 December 2020 (UTC) Skim (talk) 00:13, 10 January 2021 (UTC) El Dubs (talk) 21:55, 29 April 2021 (UTC) CAFLibrarian (talk) 16:36, 30 September 2021 (UTC) Jheald (talk) 18:50, 23 December 2021 (UTC)

Notified participants of WikiProject Genealogy --Emu (talk) 12:04, 17 July 2023 (UTC) Emu (talk) 12:04, 17 July 2023 (UTC)

There is also archives at (P485) and supporting values like collection (P195) and catalog (P972). Also noticing that most archives have their own identifier for å file or person i the archive like UK National Archives ID (P3029) and Swedish National Archive reference code (P5324) Pmt (talk) 14:06, 17 July 2023 (UTC)
When the subject item isn't identical to merely the registry itself (such as Saint Wolfgang Church (Dorf an der Pram) (Q22041143) or Vienna (Q1741)), but is an entity with a purpose beyond being a registrar, the registry should preferrably have a Q-item of its own, and the appropriate URL property assigned to that item instead. This will allow a registry changing hands, splitting or merging it, and assigning various other existing generic properties to it, without the need to create a large number of new properties for the vital records only.
Applying the start time (P580) and end time (P582) qualifiers to the target URL would otherwise be ambiguous; say, would a start time of 2015 indicate that a new registry was established, or that an existing registry became available on the Internet that year? Merely providing a URL property for something that existed long before the Internet is insufficient; the URL should be optional.
And an archive is different from an actively maintained registry, which may later become archived, but I believe you know that already. --SM5POR (talk) 15:22, 23 July 2023 (UTC)
@SM5POR I think I understand your point but I‘m not sure about the specifics. In the case of Q116201377 we indeed have an organization (or at least a division within an organization) which is solely responsible for keeping life records. I’m not so sure about religious institution. Do you mean something along the lines of parish Vienna 03, Rennweg, Maria Geburt (Q105890802)? Although this is also kinda conflated because it mixes the institution of the local church parish with its district, i. e. its territorial (and personal) scope. Also, the parish has all sorts of other duties which are not limited to keeping life records. What would you propose in such (very common) cases?
I’m not sure about your concerns with start time (P580) and end time (P582). Wouldn’t this issue be solved with those values acting as qualifiers? Or do you want to point out that we use start time (P580) and end time (P582) for very different ontological concepts: The meaning of those qualifiers in Q156487#P39 is indeed very different to the meaning in Q48256#P227. It’s not as bad as described at User:Lucas Werkmeister/P642 considered harmful but it is an issue (CC Kolja21 because of a potential GND ID (P227) modeling issue)
Not so sure what you mean by your last sentence, could you maybe elaborate a bit? Thank you! --Emu (talk) 19:42, 23 July 2023 (UTC)
We have start of covered period (P7103) and end of covered period (P7104) which could be used here instead of start time (P580) and end time (P582). M2Ys4U (talk) 01:52, 24 July 2023 (UTC)
@M2Ys4U Thank you, I didn’t know those properties! That’s better, probably also for GND ID (P227), @Kolja21? --Emu (talk) 11:20, 24 July 2023 (UTC)
I don't see the need for it. If you look at Dnipro (Q48256): Q48256#P227
  • The years given are not about an archive the years are about the city.
GND + start time (P580) is used by 1.145 items. --Kolja21 (talk) 20:52, 24 July 2023 (UTC)
Yes, but GND 1269131966 was created on 2022-09-29 and that would probably be the “time an entity begins to exist or a statement starts being valid” in this case. --Emu (talk) 20:58, 24 July 2023 (UTC)
To clarify, Vienna (Q1741) is a city (the capital of Austria), not merely a vital records registrar. If you were to define a new property "death registry" with a URL datatype, pointing to a resource listing those who died in Vienna during a particular period in time, you are skipping a number of important links betwen the geographical location and the records you are referring to, which risks making the long-time maintenance (and use) of this property for multiple locations a nightmare, or at least an inconvenient burden. These are the links I'm thinking of, links that the users accessing the resource need to be aware if:
  1. The first entity has an arbitrary type, making its relation to the records unclear. In addition to the city of Vienna, you mention Saint Wolfgang Church (Dorf an der Pram) (Q22041143) among your examples. Does this resource list residents of Vienna/members of that church who have died (somewhere), people who have died in Vienna/been buried at the church irrespective of their residency/membership, or people appearing in any death registry that happens to be maintained by the vital records registrar employed by the city/church? These are all different relations, and which records should be searched depends on what the user is looking for. Therefore I suggest one property should be "vital records registry", refering to the registry maintained by that corporate entity (city, church, whatever), and it must be a Q-item, not a URL. All cities may not have their own registries, but the registrar could be found on the provincial or national level.
  2. The registry, in turn, may have different parts, such as birth records, marriage records, or death records, organized differently by different registrars. If that registry has an official Internet presence, you could add a URL to their item. But are the vital records themselves available via that URL? Maybe, maybe not. If they are, you can of course add more specific URLs to the same item, using qualifiers to indicate what records they pertain to.
  3. The registrar should be in charge of the current registry to be able to update it, and may also retain records from long ago, never to be updated again (unless an error is discovered and corrected). But eventually a set of old records is transferred to an archive, which may be an entirely different organization, responsible for safekeeping and providing access to old records, but not updating them (this is what I referred to in my last sentence above). It would then need its own Q-item, and may be referred to from the registry item using archives at (P485). The archive could then have a set of URLs provding access to its holdings.
  4. In your examples, you mention Ancestry and FamilySearch. These are neither official vital records registries nor archives, but independent collections of records, often from multiple sources (typically archives, but also user-contributed data). Give them their own Q-items. Their holdings may be organized in entirely different ways, and the URLs listed for them should reflect that.
Adding a property to Vienna (Q1741) pointing directly at a FamilySearch URL providing records pertaining to Vienna would be inappropriate, in my opionon. A significant part of genealogy research is finding the best source of records, where researchers have to evaluate both reliability and relevance of individual pieces of information in the specific cases they are concerned about. Wikidata cannot do that job for them. At most, Wikidata could indicate which archives have been included in which collections (if that is even possible; limiting a search to a particular source of theirs or telling where their data comes from isn't very easy to do), but going beyond that and listing every single geographic location appearing in their collections (and adding corresponding URLs from each location to those collections) would be pretty pointless. You might just as well add pointers from year or name items to collections with records referring to them; it would serve no useful purpose.
The semantics of the start time (P580) and end time (P582) qualifiers would depend on the items and statements they are applied to. On the suggested "vital records registry" property, start time (P580) would refer to when the registry was established. On an archives at (P485) link, it would indicate the age of the oldest records from the subject item that exist at the archive; same thing with collection (P195). On a URL property if would indicate when that particular URL became valid. --SM5POR (talk) 09:47, 27 July 2023 (UTC)
It seems to be that we have very different use cases in mind. You wrote: A significant part of genealogy research is finding the best source of records, where researchers have to evaluate both reliability and relevance of individual pieces of information in the specific cases they are concerned about. Wikidata cannot do that job for them. How true, Wikidata will never be able to weigh different sources against each other. What Wikidata could do is solving rather trivial tasks that many historians, family history enthusiasts and/or Wikimedians face every day:
  1. “I know from later records that this person was baptised in church X, where can I find the records, preferably online?“
  2. “It is suspected that this person died around 1880 in the northern parts of Lower Austria. Which churches (that existent around the time of suspected death) are there in this region and where can I find their records, preferably online?“ In many cases, it’s simply trial and error.
There’s nothing improper about using third-party sources. Let me address some of your arguments:
  • Does this resource list residents of Vienna/members of that church who have died (somewhere), people who have died in Vienna/been buried at the church irrespective of their residency/membership, or people appearing in any death registry that happens to be maintained by the vital records registrar employed by the city/church? These are all different relations, and which records should be searched depends on what the user is looking for. Does it matter? In the case of Austrian Catholic death records this would often be quite fuzzy, something along the lines of “In principle, only Catholic people who lived and died in the parish, but sometimes dying there is enough and sometimes being buried here or somewhat nearby is enough and sometimes having some sort of religious ceremony is enough and sometimes it’s enough if the body was discovered within the parish or in the vincinity or indeed if somebody feels that this person or their family has a close connection to this parish even when another parish is officially responsible. Oh and sometimes there are records of Protestants, Muslims, Jews or atheists because maybe there was no appropriate registry here or Protestantism was still illegal or somebody just assumed they were Catholic or nobody could remember exactly what was happening.“ That’s all very interesting but you could never model that in Wikidata. It’s not really necessary anyway because in light of this fuzziness you often have to search in various records anyway.
  • Therefore I suggest one property should be "vital records registry", refering to the registry maintained by that corporate entity (city, church, whatever), and it must be a Q-item That doesn’t really answer my question from above. What is the “vital records registry“? The organization, the abstract concept of registry?
  • The registrar should be in charge of the current registry to be able to update it, and may also retain records from long ago, never to be updated again (unless an error is discovered and corrected). But eventually a set of old records is transferred to an archive, which may be an entirely different organization, responsible for safekeeping and providing access to old records, but not updating them (this is what I referred to in my last sentence above). That’s of course true but I’m not sure how this would be relevant here.
  • Ancestry and FamilySearch […] Give them their own Q-items. Each collection? I’m not sure that this would be a terribly good idea.
I’m not dead set on the URL datatype and I would be happy to accommodate any needs for a more complex modeling. However, I still don’t quite understand what you are proposing. Could you maybe give me a possible set of statements that could achieve to accommodate my use cases? Or is there a problem with my use cases? --Emu (talk) 11:45, 27 July 2023 (UTC)
no 5.21.241.21 11:23, 31 July 2023 (UTC)

Catalonian buildings

These folks are working on something I can't quite figure out. The house in Barcelona has been demolished, apparently, but many of its properties are marked imported from Wikimedia project (P143): Catalan Wikipedia (Q199693), but what article? There has never been a linked article that describes this item only, as far as I can tell, so how do these quickstatements imports work?

Furthermore, there is a lot of deletion of instance of (P31): tourist attraction (Q570116) and unfinished building (Q1570262) from items. Sagrada Família is the sine qua non of unfinished buildings, as well as a verifiable tourist attraction! Why are properties such as this being removed en masse?

Catalan translation

Aquesta gent està treballant en una cosa que no acabo d'entendre. La casa de Barcelona ha estat enderrocada, pel que sembla, però moltes de les seves propietats estan marcades imported from Wikimedia project (P143): Catalan Wikipedia (Q199693), però quin article? Mai no hi ha hagut un article enllaçat que descrigui només aquest article, pel que puc dir, com funcionen aquestes importacions de declaracions ràpides?

A més, hi ha una gran quantitat de supressió de instance of (P31): tourist attraction (Q570116) i unfinished building (Q1570262) dels elements. La Sagrada Família és el sine qua non dels edificis inacabats, a més d'una atracció turística verificable! Per què s'eliminen en masse propietats com aquesta? Elizium23 (talk) 17:22, 23 July 2023 (UTC)

With instance of (P31) we try to avoid over use as so many properties can be described as an instance of something else. As all churches can be viewed as tourist attractions you don't want to label each as such, and state of conservation (P5816) would be better for buildings. Vicarage (talk) 05:59, 24 July 2023 (UTC)
As for the house, it was imported from the heritage register Inventari del Patrimoni Arquitectònic de Catalunya (Q1393661) to Cultural heritage monuments in Aiguafreda (Q11932939), and imported from the list to Wikidata. The article was merged with Habitatge a la carretera de Barcelona, 21 (Aiguafreda) (Q19255897). Once removed from the register, it has been removed from the list and marked as deprecated. You are right, these imports should have been reported more specifically. Vriullop (talk) 08:05, 31 July 2023 (UTC)

Still alive and well (centenarians)?

I own the book A Practical English Grammar (Q28132035) by Audrey Jean Thomson (Q105812645) and Agnes Wallace Martinet (Q112356982). Are they both still alive and well? I would be happy for them (they would be 103 and 102 years old, respectively)...-- Carnby (talk) 17:30, 30 July 2023 (UTC)

Wikidata weekly summary #587

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Tool of the week
    • osm.js will add a link to the navigation for items that have a Wikidata mapping on the OSM side.
  • Development
    • Wikibase REST API:
      • We released the following new stuff to Wikidata:
        • GET /entities/properties/{property_id}/statements (phab:T339356) (new route)
        • GET /entities/properties/{property_id}/statements/{statement_id} (phab:T338383) (new route)
        • GET /statements/{statement_id} (now supports statements on Properties)
      • We started work on a new route for replacing the data of a statement on a Property (phab:T340006)
    • EntitySchemas:
      • We worked on improving the termbox (the table of labels, descriptions and aliases) on EntitySchema pages to bring it more in line with the one on Items and Properties
      • We made sure that EntitySchemas are shown by their label instead of ID when available in Recent Changes and similar lists (phab:T339924)
    • Mismatch Finder: We added a language selector so you can switch the interface language (phab:T328149)
    • mul language code: We are working on showing more labels from fallback languags in the termbox (phab:T340832, phab:T338330)

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.

Merge request (São Gonçalo do Sapucaí)

São Gonçalo do Sapucaí (Q22065156) should be merged with São Gonçalo do Sapucaí (Q952405) as both refer to the same city in Brazil. I don't understand why the former has two interwiki links. Mateussf (talk) 23:39, 27 July 2023 (UTC)

@Mateussf: This is another bot-created-article situation. The two WD items cannot be merged as there are Wikipedia articles at both ceb.wiki and sv.wiki. I'll mark it as a permanently duplicated item. — Huntster (t @ c) 13:31, 28 July 2023 (UTC)
For some reason, those two wikis have separate articles for the cities and the municipalities, even when the city is the whole municipality. I've seen it with many cities in my country as well. –FlyingAce✈hello 15:10, 31 July 2023 (UTC)
@FlyingAce: Yes, this is because those articles were created by a bot based on Geonames.org entries. It's frustrating, but this is the best way currently to deal with these situations. — Huntster (t @ c) 21:39, 31 July 2023 (UTC)

Mark people as dead

Is it possible to mark a person a dead without knowing anything about its death except that it happened? --Jobu0101 (talk) 06:25, 31 July 2023 (UTC)

Ah, I guess with P570 and unknown value. --Jobu0101 (talk) 06:27, 31 July 2023 (UTC)
In all likelihood the source will have some clue as to when the death happened, you can specify a death happening some time in the 1800s for instance. This is preferable to using unknown value. You can also add the qualifiers earliest date (P1319) and latest date (P1326) and even sourcing circumstances (P1480). Example: Ramesses IV (Q1532). Infrastruktur (talk) 06:50, 31 July 2023 (UTC)
@Jobu0101: also see
M2k~dewiki (talk) 15:23, 31 July 2023 (UTC)

Individual Constituency Heves County (Hungary)

in Individual Constituency Heves County No. 3 (Q15891201) there is a lack of reference for eligible voters (P1867) and successful candidate (P991) seems to be wrong for an electoral district. I cannot read Hungarian, is there someone who can help me? Thanks.-- Carnby (talk) 21:40, 31 July 2023 (UTC)

References

When I click to add a reference "reference url" is no longer popping up as a choice, what happened? How can we restore the choice? RAN (talk) 23:44, 28 July 2023 (UTC)

it's a choice for me if I type it out but I feel like it used to be suggested immediately. not sure what changed. it looks like hwbsgetsuggestions is returning reference url with lower probability. BrokenSegue (talk) 00:27, 29 July 2023 (UTC)
@Harej recently made an edit but that diff looks innocuous and unrelated to the autocomplete. Harej is a WMF employee, though, so perhaps changed something else behind the scenes? Elizium23 (talk) 00:41, 29 July 2023 (UTC)
I haven't been a Wikimedia Foundation employee in four years, and there is no way that edit would have caused it. Harej (talk) 18:04, 30 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 13:17, 6 August 2023 (UTC)

Authority Control on Neema Parvini´s Wikipedia page

Hello as he is on Wikidata and Wikidata now has references on his page to the British Library, I am wondering why Authority Control won´t show on his WP page, please correct me if my understanding is wrong, I would just like to know why? StrongALPHA (talk) 10:07, 30 July 2023 (UTC)

I think I've fixed it. Neema Parvini (Q120922120) RVA2869 (talk) 12:19, 30 July 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 13:18, 6 August 2023 (UTC)

Mix'n'Match behaviour

Has Mix'n'Match changed its behaviour?

I'm using a new laptop (Windows 11, also new to me, less powerful and so slower than my usual Dell XPS, but with my usual browser, Firefox). When I confirm, or reject a match a new tab opens. The status bar of that tab shows progress, then the new tab self-closes.

This makes M'n'M much slower to use for multiple changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:38, 30 July 2023 (UTC)

I assume you mean the Mix’n’match user-script, User:Magnus Manske/mixnmatch gadget.js? If so it appear to be intentional per Special:Diff/1925293932 which added « USE HACK AROUND MNM OAUTH ISSUE ». Jean-Fred (talk) 21:38, 5 August 2023 (UTC)
@Jean-Frédéric: Yes, I did mean the user-script. Thank you for clarifying my ambiguity, and your helpful reply. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:50, 6 August 2023 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. RVA2869 (talk) 13:20, 6 August 2023 (UTC)

Dark mode

Can an interface admin please import the dark mode gadget on enwiki? This means importing the following:

The last page may need to be modified for Wikidata's special UI. Jasper Deng (talk) 10:07, 21 July 2023 (UTC)

@Jasper Deng: Imported. Do you want to have me activate it right away? --Matěj Suchánek (talk) 16:55, 28 July 2023 (UTC)
@Matěj Suchánek: Thanks for importing it. Yes, do activate it right away as a gadget.--Jasper Deng (talk) 17:36, 28 July 2023 (UTC)
✓ Done Should work now. --Matěj Suchánek (talk) 18:30, 28 July 2023 (UTC)
Nice, but this gadget seems to interact poorly with the ImageHeader gadget. The images at top right are shown with inverted colours, which is a little disconcerting for photographs. Bovlb (talk) 18:52, 28 July 2023 (UTC)
@Jasper Deng, Matěj Suchánek, Ladsgroup: Do you have any solution for this problem? Bovlb (talk) 16:25, 3 August 2023 (UTC)
No, sorry. I know nothing about how to adapt either tool. --Matěj Suchánek (talk) 16:34, 3 August 2023 (UTC)
I can take a look but I'm a bit swapped. Give me a bit. Amir (talk) 17:50, 3 August 2023 (UTC)
@Bovlb Fixed Amir (talk) 21:14, 5 August 2023 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2023/07&oldid=1952756977"