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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

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

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

For realtime chat rooms about Wikidata, see Wikidata:IRC.
Start a new discussion
Edit
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2023/07.

How to handle licensing problems[edit]

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)Reply[reply]

@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)Reply[reply]
en:Database right#European Union. --2A02:810B:580:11D4:5DB9:F4C3:580B:9714 19:23, 25 June 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]

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)Reply[reply]

Inconsistent policy to inverse properties/statements[edit]

@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)Reply[reply]

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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@Š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)Reply[reply]

Problem between two Wikidata pages[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]
@Gonzalo 11789, thank you! I've updated the item appropriately. — Huntster (t @ c) 17:02, 3 July 2023 (UTC)Reply[reply]

Wikidata weekly summary #583[edit]

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)
  • 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.


Q10405147[edit]

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)Reply[reply]

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)Reply[reply]
Thank you for your answer. I renamed the item and left the alternative name visible. --Grullab (talk) 06:18, 4 July 2023 (UTC)Reply[reply]
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)Reply[reply]

Adding badges to sitelinks with Pywikibot[edit]

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)Reply[reply]

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

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

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)Reply[reply]

In favor[edit]

  • Yeah I already personally follow a stricter version where I won't close a proposal if I participated at all (unless it's very clear). This is a good step. BrokenSegue (talk) 16:52, 4 July 2023 (UTC)Reply[reply]
  • As you said, this seems to be common practice anyway. --Emu (talk) 17:18, 4 July 2023 (UTC)Reply[reply]
  • This would make sense to codify, especially when there are still people who add "support as proposer" to their proposals (sometimes causing confusion as to those proposals' readiness). Mahir256 (talk) 22:46, 4 July 2023 (UTC)Reply[reply]
    That seems to me a different issue, and I think it would make sense to explicitely forbid the proposal to add support votes. ChristianKl ❪✉❫ 12:21, 5 July 2023 (UTC)Reply[reply]
  • It's only logical that someone should not close/pass their own proposal. Having it in writing ensures that someone cannot later do so and claim the all-to-common refrain "but it isn't against the rules". — Huntster (t @ c) 13:32, 5 July 2023 (UTC)Reply[reply]
  •  Support The whole point of separating out the property creator right was to have community vetting of proposed properties, and to not have a unilateral ability to create properties. @ChristianKl: Although I am also not a fan of policy creep, policies that solve known issues are needed.--Jasper Deng (talk) 19:00, 5 July 2023 (UTC)Reply[reply]
  •  Support --Succu (talk) 20:45, 5 July 2023 (UTC)Reply[reply]

Opposed[edit]

  •  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)Reply[reply]
  •  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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]

Deleting empty redirect items en masse[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
2.6k items with the intentional badge, and 45.5k with the basic one —MisterSynergy (talk) 09:20, 5 July 2023 (UTC)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

Veikko Väänänen[edit]

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)Reply[reply]

Can't transclude a property proposal[edit]

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)Reply[reply]

@MasterRus21thCentury appears to have moved it. Bovlb (talk) 17:35, 5 July 2023 (UTC)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@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)Reply[reply]
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)Reply[reply]

Merge[edit]

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

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

Merge[edit]

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

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

Merge[edit]

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

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

Making Wikidata work better on narrow screens and mobiles[edit]

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)Reply[reply]

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

Identifier with hoax[edit]

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)Reply[reply]

Maybe you could use a none-of constraint. Bovlb (talk) 00:21, 7 July 2023 (UTC)Reply[reply]
How do you use none-of constraint to block a specific value?@Bovlb:--Trade (talk) 18:04, 7 July 2023 (UTC)Reply[reply]
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)Reply[reply]

document file on Wikimedia Commons versus image[edit]

"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)Reply[reply]

"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)Reply[reply]

New Wikidata Maps[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Thank you, as always very interesting! We still seem to have accuracy problems in Mexico though … Emu (talk) 17:23, 7 July 2023 (UTC)Reply[reply]

Merge[edit]

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

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

Missing person[edit]

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

has quality (P1552). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 8 July 2023 (UTC)Reply[reply]

Subject as source for basic biographical data[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
c:Commons:Deletion requests/Creator:D. Benjamin Miller. Multichill (talk) 22:23, 7 July 2023 (UTC)Reply[reply]

Property to indicate names of websites?[edit]

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)Reply[reply]

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

English statements as preferred rank?[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]

Country self link[edit]

Hi,

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

Hi, what do you mean by “self link”? A country item linking to itself? --Data Consolidation Officer (talk) 09:47, 9 July 2023 (UTC)Reply[reply]
@Data Consolidation Officeryes RVA2869 (talk) 10:08, 9 July 2023 (UTC)Reply[reply]
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)Reply[reply]
@Data Consolidation Officer query:https://w.wiki/6zqu RVA2869 (talk) 10:42, 9 July 2023 (UTC)Reply[reply]
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)Reply[reply]

Links to GitHub users[edit]

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)Reply[reply]

GitHub username (P2037) would seem to be the more appropriate property in that case, I think. M2Ys4U (talk) 14:49, 9 July 2023 (UTC)Reply[reply]

New tab in Wikidata for "Officeholders"[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
"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)Reply[reply]

"expected" past events[edit]

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)Reply[reply]

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

Deletion of valid references[edit]

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Wikidata weekly summary #584[edit]

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.

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1932610803"