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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Edit

deidetected.com, a self-published source potentially used for harassment

[edit]

This website launched and run by the creator of the "Sweet Baby Inc detected" Steam curator would fall under the definition of a self-published source on Wikipedia. The Steam curator has been linked to the harassment campaign against Sweet Baby Inc. by reputable sources like PC Gamer, The Verge, and multiple others.

Wikidata has a page for the website, with the website linked via the described at URL property, by User:Kirilloparma on more than one if not every occasion. Even within the scope of that source, it is done in a very targeted way in that the website seems to be added to the Wikidata pages only when the game is recommended against at deidetected.com (e.g. The First Descendant, Abathor, Valfaris: Mecha Therion recommended as "DEI FREE" by deidetected do not have the property set). Based on that, its goal of harassment or POV pushing appears to be evident.

Does Wikidata have any guidelines that would explicitly allow or disallow this behavior or the coverage of deidetected.com at all? Daisy Blue (talk) 09:45, 14 September 2024 (UTC)[reply]

There is no policy on WD for blacklisting websites for other than malicious cases such as spam or malware Trade (talk) 11:59, 14 September 2024 (UTC)[reply]
Now from having read the property description for described at URL on its talk page, which explains that it's for "reliable external resources", I'm convinced the website has no place on Wikidata, as it's not a reliable source (at least not per the guidelines of Wikipedia (WP:RSSELF)). What is the best place to initiate its removal without having to start a potential edit war? A bot would also do a more efficient job at removing it from all the pages. Daisy Blue (talk) 12:03, 14 September 2024 (UTC)[reply]
You might have more luck if you stopped bringing up Wikipedia guidelines and used the Wikidata ones instead Trade (talk) 00:09, 15 September 2024 (UTC)[reply]
Wikidata itself cites the Wikipedia guidelines on self-published sources (and on original research). Daisy Blue (talk) 05:04, 15 September 2024 (UTC)[reply]
English Wikipedia policy is im many cases useful to decide what should be done in Wikidata (e.g. which sources are reliable), but should never be considered normative and have no more authoritativeness than policies in any other project. GZWDer (talk) 06:37, 15 September 2024 (UTC)[reply]

This could be used to mass undo 18 of the edits that introduced the links, but it's not progressing for me when trying. Daisy Blue (talk) 11:14, 15 September 2024 (UTC)[reply]

Seems like a low-quality, private website that doesn't seem to add anything of value to our items. There are countless websites out there, but we generally don't add every single site via described at URL (P973) just for simply existing. IIRC, there were various cases in the past where users added unreliable websites to lots of items, that were then considered spam and deleted accordingly. And if the site's primary purpose is indeed purely malicious and causing harassment, there's really no point in keeping it. Best to simply put it on the spam blacklist and keep the whole culture war nonsense out of serious projects like Wikidata. Additionally, DEIDetected (Q126365310) currently has zero sources indicating a clear lack of notability. --2A02:810B:5C0:1F84:45A2:7410:158A:615B 13:50, 15 September 2024 (UTC)[reply]

I've already nominated that and Sweet Baby Inc detected for deletion citing the same reason, though specifically for the curator, one could stretch point 2 of Wikidata:Notability to argue against it, but I'm not sure what value it would bring to the project apart from enabling harassment and its use to justify any other related additions. Daisy Blue (talk) 16:06, 15 September 2024 (UTC)[reply]
Just add this website to the spam blacklist, no one will be able to add links to this website on Wikimedia projects anymore. Midleading (talk) 17:18, 16 September 2024 (UTC)[reply]
What's the proper venue for proposing that? Also, seeing how you have a bot, could you suggest a quick way to mass remove the remaining instances from Wikidata? I've already undone a number by hand but it's not the greatest experience. Having the knowledge may also help in the future. Daisy Blue (talk) 18:24, 16 September 2024 (UTC)[reply]
On the home page of Meta-Wiki, click Spam blacklist, and follow instructions there.
To clean up links to this website, I recommend External links search. A WDQS search is likely to time out. I also recommend reviewing each case manually, sometimes the item should be nominated for deletion, but tools can't do that. Midleading (talk) 01:27, 17 September 2024 (UTC)[reply]
Thanks. I'll remove the rest by hand then. As for the Wikimedia spam blacklist, it says that "Spam that only affects a single project should go to that project's local blacklist". I'm not sure if there have been any attempts to cite deidetected on Wikipedia or elsewhere. We can search for the live references (there are none) but not through the potential reverted edits, I don't think. Daisy Blue (talk) 07:33, 17 September 2024 (UTC)[reply]
Well, you may request this website be banned on Wikipedia first, then you may find some users who agree with you. Midleading (talk) 08:45, 18 September 2024 (UTC)[reply]
I believe Wikipedia has the same policy in that if it hasn't been abused (and I wouldn't know if it has been specifically on Wikipedia), then there is no reason to block it. On Wikidata, as it stands now, the additions come from one user, Kirilloparma, who pushed back on my removals here but hasn't reverted. Unless it becomes a sustained effort by multiple users, it will come down to whether Kirilloparma concedes that described at URL is for reliable sources and the website is not a reliable source. Daisy Blue (talk) 12:14, 18 September 2024 (UTC)[reply]
For some reason Kirilloparma keeps making points on the subject on the Requests for deletions page rather than here (despite having been informed), now arguing that the short property description takes precedence over the property documentation on the talk page, which is dismissed as "outdated". Daisy Blue (talk) 09:29, 20 September 2024 (UTC)[reply]
  • Wikidata has items for many websites even if those websites are worthy of criticism. Knowing that "Sweet Baby Inc detected" is linked to "DeiDetected" is useful information even if both of those sources would be completely unreliable.
I don't see any use of links to deidetected.com within Wikidata where it's used for the purpose of harassement which would justify putting it on a blacklist. ChristianKl ❪✉❫ 13:09, 26 September 2024 (UTC)[reply]
The whole purpose of that website is to incite harassment, so intentionally linking to it within Wkkidata directly contributes to that problem. --2A02:810B:5C0:1F84:2836:F2FD:EE77:CF71 19:38, 28 September 2024 (UTC)[reply]
@ChristianKl: Quite frankly, your comment is insensitive and I agree with the IP. Note that the OP did say that the only edits adding them have been to "recommended against" games' items, so your point does not stand I'm afraid. Other than information on the sites themselves, we really should not provide "described at" claims linking them to people. Such is arguably a gross violation of Wikidata:Living people.--Jasper Deng (talk) 19:41, 28 September 2024 (UTC)[reply]
What part of Wikidata:Living people do you believe is violated here and by which edits?
Instead of focusing on what the OP said, why don't you look yourself to get an impression of what we talk about?
The OP asked for the item to be deleted. Currently DEIDetected (Q126365310) does link to Sweet Baby Inc detected (Q124830722). The described at URL (P973) claims on Sweet Baby Inc detected (Q124830722) seem to me like the go to relatively neutral sources like Wired saying things like "Although early efforts began on sites like notorious harassment hub Kiwi Farms last year, much of the misinformation about Sweet Baby has coalesced around Sweet Baby Inc Detected, a Steam curation group that bills itself as “a tracker for games involved with” the company." ChristianKl ❪✉❫ 13:40, 2 October 2024 (UTC)[reply]
I don't oppose the existence of these items and the existing claims you quoted. It is when these claims are added to particular games' items that it begins to create problems for the game's developers by inviting harassment targeted around their alleged ties to Sweet Baby and other organizations.--Jasper Deng (talk) 18:18, 2 October 2024 (UTC)[reply]
If deidetected would dox individual employees, that would be a privacy violation. Saying that a particular company was consulting another company for developing a product is not a violation of the privacy of individual people. Boycott of commercial products like games based on political justifications, is not something that the living people policy is intended to prevent. Using the word "harrassement" for it, does not mean it's the same as actions against individuals.
That said, we do have discussions over whether to add properties for external sources to require consensus to sources to all entries of a website and using described at URL (P973) as a workaround because there's no property for an individual website is generally a bad idea. ChristianKl ❪✉❫ 23:38, 3 October 2024 (UTC)[reply]
@Kirilloparma: Please do not reintroduce any of these links in the future. Doing so is a violation of Wikidata:Living people on the grounds of privacy.--Jasper Deng (talk) 19:47, 28 September 2024 (UTC)[reply]
That policy is about living people, not companies. As far as i can tell none of the entries even names any living persons in the first place Trade (talk) 03:41, 5 October 2024 (UTC)[reply]
The policy touches on groups as well, with emphasis on small groups. Sweet Baby Inc. consists of only 16 people. Some of the targeted games were made by as many or fewer (e.g. Sable, Neo Cab). Moreover, the website absolutely names living individuals, as exemplified by its page on Life is Strange: Double Exposure. Daisy Blue (talk) 07:02, 10 October 2024 (UTC)[reply]

I have boldly block-listed the domain on Wikidata. In accordance with the Wikimedia Foundation DEI principles, linking a low-quality harassment site in a way that causes LP violations is not appropriate. Exceptions, such as for items on articles covering the site, can be handled using edit requests. I request that the blacklisting stand unless an explicit consensus rises against it.--Jasper Deng (talk) 20:05, 28 September 2024 (UTC)[reply]

  • Since my username keeps appearing in this thread and I'm being accused of things, I think I'll comment in detail and answer questions early/mid next week. There's a lot to talk about, especially since the user who started this thread, while I was away, is deleting everything related to this video game database (recent disruptive edits where the user deleted quite valid sources [1], [2], [3], [4]), which would be useful for structured data. For instance database provides information about the developers and publishers for a particular game and this fact is completely omitted here, anyway I will comment on everything here soon. Regards Kirilloparma (talk) 04:13, 17 October 2024 (UTC)[reply]
    You are already aware of the reasoning, but for those unaware, see the talk on Requests for deletions as well as my argumentation on the talk page for DEIDetected that came with those edits. It is unfortunate that edit summaries aren't a thing on here. Daisy Blue (talk) 09:31, 17 October 2024 (UTC)[reply]

Enabling the CampaignEvents Extention on Wikidata

[edit]

The Campaigns Product team at the Wikimedia Foundation is proposing to enable the CampaignEvents extension on Wikidata by the second week of October.

This extension is designed to make it easier for organizers to manage community events and projects on the wikis, and it makes it easier for all contributors to discover and join events and projects on the wikis. Once it's enabled on Wikidata, you will have access to features that will help with planning, organizing, and promoting events/projects on Wikidata.

These features include:

  • Event Registration: A tool that helps organizers and participants manage event registration directly on the wiki.
  • Event List: A simple event calendar that shows all events happening on the wiki, particularly those using the Event namespace. It will also be expanded soon to have an additional tab to discover WikiProjects on a wiki.
  • Invitation Lists: A feature that helps organizers identify editors who might be interested in their events, based on their editor history.

Please note that some of these features, like Event Registration and the Invitation List, require users to have the Event Organizer right. When the extension is enabled on Wikidata, the Wikidata admins will be responsible for managing the Event Organizer right on Wikidata. This includes granting or removing the right, as well as establishing related policies and criteria, similar to how it’s done on Meta.


We invite you to help develop the criteria/policy for granting and managing this right on Wikidata. As a starting point for the discussion, we suggest the following criteria:

  1. No active blocks on the wiki.
  2. A minimum of 300 edits on Wikidata.
  3. Active on Wikidata for at least 6 months.


Additional criteria could include:

  1. The user has  received a Wikimedia grant for an event.
  2. The user plans to organize a Wikidata event.


We would appreciate your input on two things:

  1. Please share your thoughts and any concerns you may have about the proposal to enable the CampaignEvents extension on Wikidata.
  2. Review the starting criteria listed above and suggest any changes or additions you think would be helpful.

Looking forward to your contributions - Udehb-WMF (talk) 16:00, 19 September 2024 (UTC)[reply]

300 edits may be too low; Wikidata edits are generally very granular, so it's easy to make a lot of them. Maybe set the minimum at 1000? ArthurPSmith (talk) 18:04, 19 September 2024 (UTC)[reply]
I think 300 or 1000 matters little. The rights also don't give much room to mess up, so it is okay to have a low bar. From the additional criteria, I think a grant is way too restrictive, but the plan to organize is a must. Why else would the rights be needed? Ainali (talk) 18:22, 19 September 2024 (UTC)[reply]
I think the proposed criteria are reasonable. It is really hard to judge someone by the amount of edits because of the tools we are using on Wikidata. Perhaps we want to use a trial period for granting the rights (at least for less experienced users). We could grant it temporary for one year and renew it if it is still needed. --Ameisenigel (talk) 19:35, 19 September 2024 (UTC)[reply]
Hello! As a staff from an affiliate, I'd suggest to add a criteria that bypasses the number of edits for staff that belongs to an affiliate. In the case of Wikidata it's always useful if they know the platform before running an event, but it could be among the responsibilities of a new member of an affiliate staff to organize an event. Other than that, the criteria seems to follow what other wikis are currently discussing or implementing. Scann (WDU) (talk) 12:48, 20 September 2024 (UTC)[reply]
That's an interesting point that makes me question why we need an extra limit at all. Couldn't this right just be added to what autoconfirmed users can do? If someone misbehaves, it wouldn't be too much hassle to notice it and block, and the harm they can do wouldn't be any worse than being able to create items or pages in the Wikidata namespace. Ainali (talk) 13:38, 20 September 2024 (UTC)[reply]
We could start of without an edit limit for Wikidata and see whether any problems arise that way. If problems arise we can still increase the limit later.
If I remember right there was in the past some grant funded event that produced a few problems with bad edits. Does anyone remember more and whether the people in question would have fulfilled the limits that are proposed here? ChristianKl ❪✉❫ 20:23, 23 September 2024 (UTC)[reply]
@ChristianKl: I think you mean Wikidata:Project chat/Archive/2023/12#Wikidata-related grant proposals and Wikidata:Administrators' noticeboard/Archive/2023/12#Recent crop of new Nigerian items. --Matěj Suchánek (talk) 07:44, 26 September 2024 (UTC)[reply]
@Udehb-WMF: what do you think about the case Matěj linked to? Should we assume that the WMF is capable of not repeating that mistake in future grants for events? If so we wouldn't need an amount of edits of Wikidata as a limit. ChristianKl ❪✉❫ 10:47, 26 September 2024 (UTC)[reply]
Thank you for your comment/question, @ChristianKl.
I would like to clarify that the Event Organizer right and the CampaignEvents extension are not limited to grantees or events funded through grants. These tools are designed to help any organizer, whether they are running events, WikiProjects, or other on-wiki collaborations, to manage organizing more easily on the wiki.
The community will decide who can use these tools on their wiki. That’s why we are having this discussion now - The idea behind the edit count, as one of the qualifying criteria for the right, is that it could help show a level of experience and engagement on Wikidata. The 300-edit threshold I suggested was just to start the discussion, but the community will ultimately decide on the final criteria.
Exceptions could also be made for affiliate staff members, similar to how it's handled on Meta, since they may need access to these tools to carry out their roles. -Udehb-WMF (talk) 11:05, 27 September 2024 (UTC)[reply]
With regards to the question on grants, the team confirmed responding to the questions raised in the past; Grants talk:Programs/Wikimedia Community Fund/Rapid Fund/Wikimedia Awareness in Nafada (ID: 22280836) - Meta . The team has also been stringent in its grant request review process and remains open to further improvement. Feel free to share your input on the grants talk page or connect directly with VThamaini (WMF) at vthamaini@wikimedia.org. -Udehb-WMF (talk) 17:40, 27 September 2024 (UTC)[reply]
We currently don't use an edit threshold to decide who to give rollback rights or property creators rights but have qualitative criteria. Given that people with the same amount of edits have quite different amounts of real experience and understanding of Wikidata I don't think that a number-based criteria would be useful. ChristianKl ❪✉❫ 09:21, 4 October 2024 (UTC)[reply]
Thank you, @Ainali, for your comment/question.
The reason for the Event Organizer right, instead of giving it to all autoconfirmed users, is that this right grants extra abilities that are specifically useful for event or wikiproject organizers, but not necessary for all autoconfirmed users. These abilities include:
  • Sending mass emails to registered event participants using the event registration feature(see demo).
  • Collecting participant demographic data through the event registration feature(see demo)
  • Creating invitation lists based on user contribution history via the Invitation List feature (see demo)
As you can probably guess, the risk of abuse seems low with this right. However, it’s still important to give this right to people the community trusts - people who meet the community's defined criteria. This is why local admins are responsible for managing this right on each wiki. If the extension is enabled on Wikidata, only users with the Event Organizer right on Wikidata will have access to these extra features. -Udehb-WMF (talk) 11:02, 27 September 2024 (UTC)[reply]
Good idea, if we can enable this extension, we may need to remove Wikidata:Account creators group?--S8321414 (talk) 12:34, 25 September 2024 (UTC)[reply]
This is completely unrelated since the event organizer role is only for the usage of the events extension. Account creator is nearly unused on Wikidata. --Ameisenigel (talk) 15:21, 25 September 2024 (UTC)[reply]
As a user who has used the Campaign extension in Meta, I'm happy to see it being enabled in Wikidata, especially with Wikidata's birthday approaching. Users will be able to use this for the upcoming birthday events on Wikidata. Since the right now allows users to create event pages and send mass messages to those who register for the event. I agree with @ChristianKl that there doesn't seem to be a need for a minimum edit count requirement. Many organizers may not have 300 edits or be active for 6 months on Wikidata. Affiliate members requesting this right may not meet these criteria. An endorsement from their affiliate group should be considered instead. Other users can also request the right with supporting links explaining why they need the right on Wikidata rather than Meta. Like in metawiki believe all the events created by the users will be listed at the Special:AllEvents page in WD. So this can be easily monitered can tracked.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 11:38, 27 September 2024 (UTC)[reply]
As a follow-up to this discussion, I have created a dedicated page for Wikidata:Event Organizers. This page provides details about the event organizers right on Wikidata, how to request for the right and the requirements/criteria on Wikidata. I removed the edit count criteria as it might seem as though that will not be needed. Please review the page and help improve it if anything is unclear or needs more detail. You can help make sure the page is useful for everyone in our community.
Also, we intend to enable the extension during the week of 14th(next week).
cc. @Ainali@Ameisenigel@ArthurPSmith@ChristianKl@Gnoeee@Matěj Suchánek@S8321414@Scann (WDU) -Udehb-WMF (talk) 10:40, 7 October 2024 (UTC)[reply]
@Udehb-WMF I don't feel like your summary of requirement/criteria reflects the views of this discussion.
@Gnoeee: given that you have used the campaign extension already, do you have an idea about how the qualitative criteria should be worded? (So that we have admins make good decisions the same way as happens with rollback/property creator rights? ChristianKl ❪✉❫ 13:01, 7 October 2024 (UTC)[reply]
@ChristianKl, So both the rollback and property creator rights are given to trusted users who have experienced in working against vandalism and users who have understanding of property namespaces. But for an Event Organizers right, people with experience as well as new users who wants to organize the event may apply for it. So for an Event Organizer role, the qualitative criteria should focus on the user's experience in organizing events, and their engagement with the community. The user can explain the events they have organized before or leading community events, either within or outside of Wikidata as the reason with the supporting links. Additional to it they also should confirm whether they have read the documentation page on metawiki that says how to use the tool. And for Wikimedia affiliate staff members (may have very few edits here) can request this right and ask their affiliate to endrose their application so that the admins can make good decision on the request.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 10:36, 8 October 2024 (UTC)[reply]
Thank you both, @Gnoeee and @ChristianKl for your feedback, and I apologize if I misunderstood or did not fully reflect the concensus on the criteria when creating the Wikidata:Event Organizers page. After considering @Gnoeee suggestion, would you say this new version reflects the agreed criteria?
  1. People with Wiki organizing experience who request the right should give clear examples of events they have organized or helped with, either within or outside of Wikidata. This should include links to relevant events as proof.
  2. Users should confirm that they have read and understood the instructions on how to use the Event registration tool or watched the video guide series on Commons before asking for the right.
  3. For Wikimedia affiliate staff members requesting the right, they should ask their affiliate to give an endorsement to support their application.
These could be added to the "reason" section of the request template.
Do you agree with this updated version? If no, please feel free to suggest any changes if something is missing.
Thank you again for all your contributions so far, and once again, I apologize for any confusion in the first version of the criteria. Also, @Gnoeee and @ChristianKl please feel free to edit the Wikidata:Event Organizers page directly if you prefer. - Udehb-WMF (talk) 10:52, 10 October 2024 (UTC)[reply]

Indian politician

[edit]

Are these the same? Dinesh Kumar(Q119204063) and Dinesh Kumar(Q64002564) ? Bouzinac 💬●✒️●💛 11:26, 6 October 2024 (UTC)[reply]

Seems both are different persons represented different parties in differerent period.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 14:57, 10 October 2024 (UTC)[reply]

Number of references

[edit]

Is there an ideal target range for the number of references we include with each statement value? (In other words: is there a point where it becomes counterproductive to add additional references, or is the intention to collect as much useful data a possible?) -- Cl3phact0 (talk) 11:26, 7 October 2024 (UTC)[reply]

WD is struggling with its database size, such that many disruptive restructuring changes are being introduced, so I wouldn't have more than one reference unless the fact is contentious. Vicarage (talk) 11:36, 7 October 2024 (UTC)[reply]
Thank you. If this is indeed the case, then I may need to re-evaluate some of my contributions. In some instances, I tend to add quality references as I come across them (and seldom delete them, as this seems like a loss of potentially valuable information). -- Cl3phact0 (talk) 17:52, 9 October 2024 (UTC)[reply]
@Cl3phact0: I wouldn't worry much about this unless you are mass-adding references via automated tools. Wikidata receives about 10 edits per second so a few references more or less won't make a huge difference. Dexxor (talk) 22:28, 9 October 2024 (UTC)[reply]
In fact, the additions in question are manual, one by one, and in the cases where I have added more than one to a given statement (usually not more than 5-10 maximum), are often a precursor to Wikipedia articles I intend to write or expand. My rational has been: if I find a particular reference source useful, perhaps someone else might benefit from easily locating it here too. In other words – I think of this practice as a handy way to keep my source reference links in one place, while also increasing the probability (or possibility) that they may serve a broader purpose too. -- Cl3phact0 (talk) 17:55, 10 October 2024 (UTC)[reply]

Autocomplete often shows values that are invalid for the property

[edit]

When writing something in the input field of a property like language of work or name (Property:P407) there are usually a lot of autocomplete suggestions for values that are configured to be invalid for the property – in this case any Wikidata items that are not languages.

Why is that and could you please change it so that e.g. in this example only instances of languages show up in the autocompletes? I thought this is already possible with other fields so I don't think it requires any change to Wikidata. It probably usually makes sense to allow people to enter invalid values / constraint-violating values so I think the autocomplete could still show once one has entered the entire term or when using a Q-id instead of writing things. But if the autocompletes show many invalid values it makes it hard to enter the correct value and sometimes even causes people to enter a similarly named but different item.

Moving this here since there was no reply here. Prototyperspective (talk) 17:07, 8 October 2024 (UTC)[reply]

Wikibase has no feature that prevents items that violate constraints from not being shown in autocomplete. It would be useful to have such a feature, but it's complex to implement. ChristianKl ❪✉❫ 21:55, 8 October 2024 (UTC)[reply]
Wouldn't it be able to check whether the value is within the set constraints before showing it? Is there a code issue about this? Prototyperspective (talk) 22:07, 8 October 2024 (UTC)[reply]
I remember discussing the issue previously in the context on allowing Wikipedia infoboxes directly edit Wikidata and developer from WMDE saying that it's complex to implement. I'm not sure whether or not there's an existing phabricator task. There might very well be one.
@Lucas Werkmeister (WMDE): do you know whether there's a ticket? ChristianKl ❪✉❫ 23:09, 8 October 2024 (UTC)[reply]
@ChristianKl: T168626 is the closest ticket I remember, though it’s not quite the same thing. Lucas Werkmeister (WMDE) (talk) 09:51, 9 October 2024 (UTC)[reply]
I do not recommend checking each value before showing it, because this way Wikidata will be too slow (it would be like when you are adding values, autocomplete items are shown one by one with a gap of a few second or more as requests are being sent to verify all property constraints for each search result, and this will also cause very high load on servers that validate property constraints). Midleading (talk) 04:33, 9 October 2024 (UTC)[reply]
I don't see why it would take a few seconds and couldn't be done in <100 milliseconds.
@Prototyperspective: Lucas is the developer for the the constraint functionality, so if there's a specific ticket he would likely know. It seems there no specific ticket for it. ChristianKl ❪✉❫ 10:01, 9 October 2024 (UTC)[reply]
It's the page load time of Special:ConstraintReport. If the server somehow is able to return a response in 200ms, sending 20 requests still takes 4s, and if some (or usually, most of) items fail to validate, then more requests have to be sent to find more valid candidates, so it will easily take 10s to load completely, considering the poor search ranking. Then when the user types in a key and these requests are sent again (logged-in traffic is uncached). Not to mention the server load caused by a single user generating 5 requests per second, which could amplify to a dozen of database accesses per second, continuously. Midleading (talk) 10:33, 9 October 2024 (UTC)[reply]
When a website loads it sends a lot of different requests in parallel and there's no need to spend 4 seconds for 20 requests that each take 200ms.
However, the implementation would need to be different then just querying Special:ConstraintReport. That's why I said above, that there's complexity to implementing the feature. Instead, of letting the user send queries via JavaScript, the backend would need to run constraint checks before returning search results. It would also need to do some caching while the user is typing. But probably no caching that's longer than that because there will be times where a user tries to find an item doesn't find it, makes the relevant changes so that the item doesn't violate the constraint anymore and then runs the query again. Maybe, you cache the first two or three letters of the query for longer. ChristianKl ❪✉❫ 11:46, 9 October 2024 (UTC)[reply]
We need to fix Special:ConstraintReport first. Currently using Special:ConstraintReport to check Q42 takes 19s rather than 200ms, that's horrible, and the server will be overloaded if everyone is sending 20 requests each takes 19s on the server all at once and send again when another key is pressed. Midleading (talk) 13:29, 9 October 2024 (UTC)[reply]
Q42 has more statements than the average item, so it's not typical but you are right, that we would likely need improvements in efficiency. Maybe, we need to cache a lot more database queries.
If a lot of caching is done there could be a switch for "Ignore the cache" where the search results will take longer to return to be used in those cases where the cache is wrong about constraint violations. ChristianKl ❪✉❫ 17:09, 9 October 2024 (UTC)[reply]
Makes sense but it doesn't need to check all constraints. There could be a different method for calculating what is shown in the autocompletes. In the example, only instances of language would be shown as autocompletes. This could be impolemented in a similar way as autocompletes are implemented in nearly all other websites which don't have some complex ConstraintReport and whatnot but simply show a list of possible values.
This could be done by fetching all items that are instances of language after having entered the property so once one is starting to type in the input box it already retrieved the possible values...and it could even have these values cached (maybe with a button to refresh). Each property value input box also could have some different set of autocompletes attached to it. Moreover, one could only remove items from the autocompletes after it fetched values in case there's issue with load times so autocompletes show right away...or one could stylize items that are in the input box' autocomplete e.g. with bold font-weight and show violating values only below them. However, I think the main solution I suggest is that one doesn't check many constraints but instead implements some method (it may be a novel method) to show only autocompletes that are subclass of or instance of what is expected by that property. Prototyperspective (talk) 20:23, 10 October 2024 (UTC)[reply]
Wikidata is more complex than the cases you have at many other websites. We have complex subclass trees. If you take language of work or name (P407), it currently accepts languoid (Q17376908) and not just language (Q315), language (Q34770) or language (Q4113741).
Looking through the list of constrains myself, value-type constraint (Q21510865) and none-of constraint (Q52558054) seem like the constraints the feature should care about.
I think it would be doable to create a solution, but would expect that it takes significant programming work. That work would be useful because it makes Wikidata generally more useable, easier to interact with for beginners and also helps with data-quality.
It seems like the thing that's worth a ticket and maybe an item at the next community wishlist survey. ChristianKl ❪✉❫ 00:50, 11 October 2024 (UTC)[reply]
Well that's a good point but that wasn't meant to be an argument or not the main point: what I meant to say is that other websites have a more simple way of getting/specifying possible values for autocomplete so we should probably not be gridlocked on trying to implement the most complete comprehensive way. This is partly because it would already be helpful if it showed 90% valid properties and still 10% values that are not okay according all constraints. Because in practice it then already results in not tons of invalid autocompletes showing up when entering En or Eng for English. I don't know how much work it requires and think maybe if done in an imperfect way as just roughly outlined it may not be so much, there's certainly more important issues (like getting videos to work in the Commons app or fixing issues with showing and importing subtitles of videos uploaded from YT etc to Commons). It would be great if you create an issue. If neither you nor somebody else here does, I will probably create it at some point ((with probably less useful info). Please link the issue here. Prototyperspective (talk) 09:17, 11 October 2024 (UTC)[reply]
Wikidata shows you English first in autocompletes because it's listed in one-of constraint (Q21510859). That constraint allows explicitely setting certain items as preferred results for autocomplete. German also seems to be hit by "en" and gets shown but once you type "eng" you get England as the second result and the English Wikipedia as the third result. As the forth result you get "British English" which is a valid result but it does not get shown on place two because it's not in the one-of constraint (Q21510859). ChristianKl ❪✉❫ 10:54, 11 October 2024 (UTC)[reply]
Well that's probably what I was looking for: then one would specify the languages in that one-of constraint (seems to be already done here) and only show autocompletes of these items (that's what this thread probably was/is about). Prototyperspective (talk) 11:01, 11 October 2024 (UTC)[reply]
We have 9967 languages in Wikidata but only the 26 most important langauges are listed in the one-of constraint and the system is not setup to do well with putting thousands of entries into the one-of constraint. ChristianKl ❪✉❫ 11:23, 11 October 2024 (UTC)[reply]
Alright, thanks for explaining. Maybe the best solution for now would be to improve that system so it can also handle so many languages. Prototyperspective (talk) 13:12, 11 October 2024 (UTC)[reply]
Having a system where a list with 9967 items has to be manually created and be stored somewhere would be a solution but it would be quite cumbersome to manage.
I created the Phabricator ticket: https://phabricator.wikimedia.org/T377071 ChristianKl ❪✉❫ 22:17, 12 October 2024 (UTC)[reply]

Are spiling (Q17126694) and bank revetment (Q2282104) about the same subject?

[edit]

Can spiling (Q17126694) and bank revetment (Q2282104) be merged? Are they about the same subject? I am a non-native English speaker and Google Translate doesn't help. If they cannot be merged: what are the differences? JopkeB (talk) 09:09, 10 October 2024 (UTC)[reply]

Give ChatGPT or Claude the text of the Wikipedia articles and ask it whether the topic is the same or there are differences. ChatGPT knows all the relevant languages while we don't. ChristianKl ❪✉❫ 10:05, 10 October 2024 (UTC)[reply]
Thanks ChristianKl for the suggestion (very good one, I'll use it more often when I have trouble to find the English equivalent for a Dutch word). Outcome: no they are not the same.
  • "Spiling" in English generally refers to the process of creating curves or patterns in shipbuilding or woodworking. It’s a technique used to transfer curves or shapes onto materials like wood. [My comment: then the description in Wikidata differs from the generally meaning in English according to ChatGPT.]
  • "Beschoeiing" in Dutch, however, refers to bank protection or revetment — a method used to reinforce and protect the edges of waterways, ditches, or canals, typically with wood, concrete, or metal to prevent erosion. [My comment: That seems correct to me. So I should use revetment (Q3742014).]
JopkeB (talk) 12:05, 10 October 2024 (UTC)[reply]
I wouldn't just use the label when asking ChatGPT. spiling (Q17126694) is not about shipbuilding or woodworking. It's better to use the start of the Wikipedia articles so that ChatGPT has the context. ChatGPT says:
The main difference between spiling and beschoeiing lies in their materials, purposes, and methods, though both are used for protecting riverbanks or shores.
Spiling:
Material: Primarily uses willow rods and posts that are woven together. The willow rods are typically live and root into the soil, promoting natural stabilization.
Purpose: A technique to prevent erosion of river and stream banks through natural and sustainable means, allowing the willow to grow and reinforce the bank over time.
Method: Living willow posts are driven into the bank and woven with rods. Additional measures, like stones or wooden planks, may be used to prevent undercutting. This is considered a form of soft engineering.
Context: Popular in the UK, this method encourages growth and is more environmentally friendly, used especially in temperate regions. It works best during the dormant winter season.
Beschoeiing:
Material: Can be made from wood, concrete, recycled plastic, or steel. Historically, hardwood (often tropical) has been used, though there is opposition to this due to environmental concerns. Newer materials like recycled plastic or fiberglass-reinforced concrete are becoming more common.
Purpose: A structural solution to protect shores, riverbanks, or construction sites from erosion, wave forces, or other threats to stability. It is used in both natural settings (like riverbanks) and construction settings (such as dry excavations).
Method: Posts (wood or steel) are driven into the ground, with sheets or planks (plastic, concrete, or wood) fixed between them. In deeper canals or construction zones, this might take the form of retaining walls.
Context: Used in civil engineering and construction sectors, beschoeiing is a more industrial or engineered approach compared to spiling and can involve more rigid materials to handle deeper or higher walls.
In summary, spiling is a more ecological and flexible method often used in natural environments, while beschoeiing is a more engineered solution that uses industrial materials for erosion control or construction support. ChristianKl ❪✉❫ 13:55, 10 October 2024 (UTC)[reply]
Thanks @ChristianKl: for your answer. Can the conclusion also be that Spiling is a subclass of Beschoeiing/bank revetment? JopkeB (talk) 04:59, 12 October 2024 (UTC)[reply]
I asked ChatGPT, and it would say yes, it's a subclass. In a case like this, where you first give ChatGPT the relevant information (through the text from the Wikipedia articles) it's a question that you can ask ChatGPT directly. ChristianKl ❪✉❫ 12:52, 12 October 2024 (UTC)[reply]

What is the best property for circumstances surrounding a work of art entering a collection?

[edit]

Hi everyone! I'm working on updating artworks in the Rijksmuseum and the museum website has a datapoint that specifies how a painting/etc entered their collection - bequest, donor, on loan from, acquisition from, etc. What would be the best way to add this data? I was thinking about adding a qualifier to the collection property, but couldn't find one that matches. The only acquisition-related one is for sports teams. AniaGrzybowska (talk) 11:03, 10 October 2024 (UTC)[reply]

There is beforehand owned by (P11811), proposed in combination with significant event (P793) or donated by (P1028), but both are only about ownership, which does not work for loaned works. NGOgo (talk) 11:58, 10 October 2024 (UTC)[reply]
Oh, that's super useful actually! I'll at least be able to do the ones who were purchased/donated. I'll do the on loan ones later once we maybe figure it out. Thank you! AniaGrzybowska (talk) 12:02, 10 October 2024 (UTC)[reply]
Hello, also see
M2k~dewiki (talk) 14:02, 10 October 2024 (UTC)[reply]
I usually think of using has cause (P828) (or a subproperty) as a qualifier. William Graham (talk) 14:14, 10 October 2024 (UTC)[reply]
Amazing - thank you both. I'll make sure to use all of the relevant properties. Will explore the projects as well!. AniaGrzybowska (talk) 09:58, 11 October 2024 (UTC)[reply]
@AniaGrzybowska: good to have some help with the Rijksmuseum! It's one of the first museums I imported as part sum of all paintings and I still update it every once in a while. I only do the paintings. I could do everything, but the prints alone are over a million works. Paintings generally have a "SK-A/C-<integer>" inventory number. SK stands for "SchilderKunst", A for owned works (example) and C for the loans (example). If a painting is first loans and later donated, it gets a new inventory number (should have preferred rank). I keep lists of missing inventory numbers: SK-A missing (newest is SK-A-5126) & SK-C missing (newest is SK-C-1849).
I guess the first step for provenance is adding when it entered the collection. My bot is doing the easy cases, need a human hand for the harder cases. Could you help with that?
I see that the API provides the credit line. I could make an extract of that so we can find common cases. Would that be useful?
As for how to exactly model provenance, I don't think the dust has settled on that yet, Wikidata:WikiProject_Visual_arts/Item_structure#Object_history_or_provenance is the best starting point. Multichill (talk) 09:59, 11 October 2024 (UTC)[reply]
That's amazing - thank you for your help! I'll have a look at the list of the harder cases and see what info I have! I'll double check how it's formatted, because for the paintings I've been looking at, it mainly states who helped with the bequest, who facilitated the donation, etc. Will have a look what you have this week! This is exciting :) AniaGrzybowska (talk) 11:24, 14 October 2024 (UTC)[reply]
@AniaGrzybowska: Wikidata:WikiProject sum of all paintings/Collection/Rijksmuseum/provenance. I have to re-run it because part is missing. Multichill (talk) 16:39, 14 October 2024 (UTC)[reply]

Launch of WikiProject Deprecate P642

[edit]

Announcing the launch of this WikiProject, recently spun out from WikiProject Data Quality. Swpb (talk) 15:02, 10 October 2024 (UTC)[reply]

WikiProject (Q16695773) deprecation (Q280943) of (P642) of (P642) :-). Multichill (talk) 09:26, 11 October 2024 (UTC)[reply]
Quite. Although "of" is a terrible basis for a property in a formal ontology, I'm not ready to throw it out of natural language! But to be pedantic, we'd model this as
⟨ WikiProject Deprecate P642 ⟩ has goal (P3712) View with SQID ⟨ deprecation (Q280943)  View with Reasonator View with SQID ⟩
object of occurrence (P12912) View with SQID ⟨ of (P642) ⟩
 :-) Swpb (talk) 15:02, 11 October 2024 (UTC)[reply]

Question about notability criteria in Wikidata:Notability

[edit]

Per Wikidata:Notability an item is notable if meets at least one of the three notability criteria. I'm not going to cover the whole thing here, but according to point two an item is notable if "it refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references." Whereas point three says an item is notable if "it fulfills a structural need."

I understand the spirit behind both of those criteria but There seems to be issues when people create unreferenced items for things simply because said items fulfill a structural purpose. To give an example, there's upwards of a thousand items for "fictional universes" that seem to be notable simply because they fulfill a structural need for fictional universe (Q559618). Even though the items aren't referenced to anything what-so-ever. So my question is, can an item meet the notability guidelines simply because it meets a structural need even if it isn't an instance of a clearly identifiable concept described using serious and publicly available references? Adamant1 (talk) 01:32, 12 October 2024 (UTC)[reply]

Short answer: yes. Cheers, VIGNERON (talk) 10:56, 12 October 2024 (UTC)[reply]
In the context of Wikidata "a thousand items" is a relatively insignificant amount of items.
In this case, the items we have for fictional universe (Q559618) generally exist because there are entities in that fictional universe that are notable. If you take for example the fictional planet Tschai (Q929640) itself is notable enough to have a Wikipedia article. If entities in a universe are notable and can be described with sources, that generally means that there are also sources that describe the universe itself.
Note, that we don't have a "fictional universe for this book" property. As a result just because a book is notable, the fictional universe in which that book is set isn't automatically notable under (2). ChristianKl ❪✉❫ 11:53, 12 October 2024 (UTC)[reply]
Topic starter forgot to mention Wikidata_talk:WikiProject_Fictional_universes#Notability_criteria_for_fictional_universes. Multichill (talk) 14:30, 12 October 2024 (UTC)[reply]
We have a "fictional universe for this book" property: takes place in fictional universe (P1434). A fictional entity would only produce a structural need for an item representing the universe it appears in if it was required for a fictional entity to have a from narrative universe (P1080) statement. This is (currently) not the case: it is completely ok for a character or entity not to have a from narrative universe (P1080) statement. We have present in work (P1441) to link to the work and this is in most cases sufficient. There is currently the question if two works set in the same universe that are not part of a bigger work (e.g. being from the same series) produce a structural need for a fictional universe. Multichill already provided a link to the discussion. - Valentina.Anitnelav (talk) 19:44, 12 October 2024 (UTC)[reply]
The thing with fictional universes is one example of many. It's not the sole or only reason I asked the question though and I would like an answer regardless of the property being discussed somewhere else. Otherwise it just seems like deflecting from the overall question. --Adamant1 (talk) 04:01, 15 October 2024 (UTC)[reply]
@Multichill: I didn't forget the mention the conversation. It's a more general question outside of fictional universes. that was just one example of many. Thanks for derailing this by making it about that though. --Adamant1 (talk) 04:05, 15 October 2024 (UTC)[reply]

@ChristianKl: I'm not really sure I follow you. Are you saying it doesn't matter if Wikidata:Notability is met for items having to do with fictional universes or if they aren't sourced to anything because the overall number of them is relatively low? Aside from that I'm not really sure what your point is about the fictional universes generally existing. To give another example besides fictional universes, people exist. But it doesn't mean every single person on the planet is inherently notable or worthy of having a Wikidata correct? I assume an item for any given person would still need to sourced to something instead of just providing a structural need for human (Q5) or some other item. --Adamant1 (talk) 04:45, 15 October 2024 (UTC)[reply]

I used the word "exist" in the context of items existing in Wikidata. I have not made any claims about how fictional universe might exist or not exist, and that's also not a question that matters given that exist is not a word used in our notability criteria.
We have items in Wikidata because it's useful for us to have them. In the case of items for fictional universes, that usefulness is about being able to make statements that link items about different entities in a fictional universe together to a common universe. The "structural need" criterium is about allowing us to have items for a purpose like that. ChristianKl ❪✉❫ 09:09, 15 October 2024 (UTC)[reply]
Obviously. That's how it meant it to. I could really care less if fictional universes exist as a concept. That's not what the conversation is about. But "existence" does matter to something like CSI universe (Q110918424). As it's obviously pointless to have an item for a "CSI universe" if said universe isn't a thing to begin with. I don't think the part about it being useful is really relevant if there's "CSI universe" to begin with either. From what I can tell nothing in Wikidata:Notability indicates that we can create items for whatever made up thing we want to as long as it serves a "structural need."
With "fictional universes" specifically there's already items for franchises and the like anyway. So I really don't see the point there. Q110918424 is literally just a duplicate of Q264198, which is actually sourced. But it seems like your totally cool with it simply because the items serves a structural need for items related to fictional universes on here more generally. Apparently even regardless of the lack of sourcing and again, the fact that it just duplicates an existing item. Weird opinion if I'm being honest, but alright. So it doesn't matter if an item is sourced to anything, actually exists as a concept, and/or duplicates exiting items. It's totally cool "because structural need." Got it. --Adamant1 (talk) 19:25, 15 October 2024 (UTC)[reply]

Almost identical labels

[edit]

Hi,

I stumble quite often on pair of items with (almost) the same label in English for very similar concept. For instance list of Bundesliga top scorers (Q1750068) and list of Bundesliga top scorers by season (Q695847) or List of Penthouse Pets (Q2719030) and list of Penthouse Pets (Q3623106). Could someone have a look at these pairs?

Bonus question: how to find them all (in this case, it's list with only the first letter being uppercase or lowercase but there is other cases).

Cheers, VIGNERON (talk) 10:56, 12 October 2024 (UTC)[reply]

https://www.wikidata.org/wiki/Wikidata:WikiProject_Duplicates is related. ChristianKl ❪✉❫ 09:14, 15 October 2024 (UTC)[reply]

Who is right?

[edit]

See [5]. The edit war seems never-ending. --Matěj Suchánek (talk) 10:59, 12 October 2024 (UTC)[reply]

I don't know what is the right birthdate but it's clearly wrong to edit an item like this, especially with no sources. An admin should semi-protect this item (probably for a long time as the edit war has been going on for 2+ years!). Cheers, VIGNERON (talk) 11:26, 12 October 2024 (UTC)[reply]
Both people because engaging in edit wars is against our rules. Given that it's IP accounts, I think the most straightforward way in cases like this is, is to semi-protect the item. I protected this item. Our living people policy suggests that when there's controversy regarding pivacy relevant information we rather remove it, especially when unsourced so I delete the date of birth. If someone wants to add one it should have a proper source. ChristianKl ❪✉❫ 11:29, 12 October 2024 (UTC)[reply]

Adding a custom P625 JS button

[edit]

Hello, I would like with my common.js a small script that could automatise a link button under P625 statements and that would link to https://www.openstreetmap.org/?mlat=LATITUDE&mlon=LONGITUDE&zoom=17#map=17/LATITUDE/LONGITUDE&layers=T (replace the coordinates with the content of P625). Where could I ask for this? Bouzinac 💬●✒️●💛 06:27, 13 October 2024 (UTC)[reply]

Undoing a batch

[edit]

I made a mistake for the batch https://editgroups.toolforge.org/b/QSv2/238496/ and when I try to undo it, I get a "Server Error (500)". Is there a way to get the batch undoing working? Is it generally broken? ChristianKl ❪✉❫ 11:22, 13 October 2024 (UTC)[reply]

Indeed, I don't get my OAUTH working for EditGroups. --Lymantria (talk) 13:19, 13 October 2024 (UTC)[reply]
@ChristianKl: It looks like your batch is only missing qualifiers. You can just run QuickStatements again and it will add the qualifiers to the values (no need to remove the values first). Dexxor (talk) 13:37, 13 October 2024 (UTC)[reply]
Unfortunately not, the problem is that some of the qualifiers were wrong. I pulled down to copy value and it counted the property numbers for the qualifiers up (some errors that result in no data but also a bunch of wrong data). ChristianKl ❪✉❫ 13:45, 13 October 2024 (UTC)[reply]
Ah, I see. You could make a new batch that removes values with bad qualifiers and re-adds them with the right qualifiers (aka using QuickStatements as a poor man's undo batch button). Dexxor (talk) 13:47, 13 October 2024 (UTC)[reply]

Preliminary results of the 2024 Wikimedia Foundation Board of Trustees elections

[edit]

Hello all,

Thank you to everyone who participated in the 2024 Wikimedia Foundation Board of Trustees election. Close to 6000 community members from more than 180 wiki projects have voted.

The following four candidates were the most voted:

  1. Christel Steigenberger
  2. Maciej Artur Nadzikiewicz
  3. Victoria Doronina
  4. Lorenzo Losa

While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.

Learn more about the results on Meta-Wiki.

Best regards,

The Elections Committee and Board Selection Working Group


MPossoupe_(WMF) 08:24, 14 October 2024 (UTC)[reply]

House numbers, Inc.

[edit]

On 1-57, Ovington Street Sw3 (Q26319042) I would like to say that the item includes 1-57 of the house numbers, but feel constrained to just include 1 and 57 and hope the casual reader infers the rest. Is there a way to say the house numbers include the sucessive numbers? No Swan So Fine (talk) 10:50, 14 October 2024 (UTC)[reply]

Use house number (P670)1-57. This is explicitly allowed by the format constraint (Q21502404). Dexxor (talk) 12:50, 14 October 2024 (UTC)[reply]
@No Swan So Fine I don't know if there's a way to show that these are the odd-numbered houses in the street other than by putting it in the description or label, like in Nos 95 to 101 (Odd Numbers) (Q29492369) Piecesofuk (talk) 15:37, 14 October 2024 (UTC)[reply]
Would a qualifier of applies to part (P518)odd number (Q13366129) be sufficient? William Graham (talk) 20:30, 14 October 2024 (UTC)[reply]

Shizuko Onda (Q59462533)

[edit]

Shizuko Onda (Q59462533) has an uncited claim, added by a user who is no longer active, that this artist is female. I don't have a citation to the contrary, but believe that is wrong. I'm not sure what I should do in that circumstance. - Jmabel (talk) 16:18, 14 October 2024 (UTC)[reply]

Their name is wrong as well, it should be Shizuko. As for the gender, I believe it should simply be removed if it is in question and there's no source to point to. —Xezbeth (talk) 17:56, 14 October 2024 (UTC)[reply]
National Museum of Visual Arts in Uruguay says she's female: [6] / [7] Shizuko would be a female name. En-wiki en:Shizuka says Shizuka can be male or female. Jheald (talk) 10:01, 15 October 2024 (UTC)[reply]
On the other hand, Oxford Reference says he's male [8], but gives him the female name Shizuko. Jheald (talk) 10:06, 15 October 2024 (UTC)[reply]
Two reports about her works in Bucharest both name her Shizuko and call her "she", [9], [10]. Another article includes photos with the museum labels, that do indeed call her Shizuko [11]. Jheald (talk) 10:16, 15 October 2024 (UTC)[reply]
The Shizuko vs. Shizuka seems to be a typo on my part. Apologies! I've corrected it. Mcampany (talk) 14:51, 15 October 2024 (UTC)[reply]
The Museo Nacional de Artes Visuales also uses "Shizuka" so it should be an alias.
I have pointed to the sources shared here, and put female as preferred and male as deprecated. GrandEscogriffe (talk) 19:14, 15 October 2024 (UTC)[reply]

Wikidata weekly summary #649

[edit]
Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2024-10-14. Missed the previous one? See issue #648

Events

  • Upcoming:
    • Next Linked Data for Libraries LD4 Wikidata Affinity Group session 15 October, 2024: We have our next LD4 Wikidata Affinity Group Session on Tuesday, 15 October, 2024 at 9am PT / 12pm ET / 16:00 UTC / 6pm CEST (Time zone converter). https://zonestamp.toolforge.org/1729008000 Christa Strickler will be our first Project Series lead with her joint project with the Wikidata Religion & Theology Community of Practice to contribute biographical data to Wikidata from the IRFA database https://irfa.paris/en/en-learn-about-a-missionary/ using the Mix’n’Match tool. We are excited to learn more about this project, provide a forum for discussion and shared learning, and lend a hand while building new skills. Event page: [12]
    • The next Wikidata+Wikibase office hours will take place on Wednesday, 16th October 2024 at 18:00 CEST in the Wikidata Telegram group. The Wikidata and Wikibase office hours are online events where the development team presents what they have been working on over the past quarter, and the community is welcome to ask questions and discuss important issues related to the development of Wikidata and Wikibase.
    • Wikidata:Twelfth Birthday: We already have 30 events scheduled on the list 😍. As a reminder, when your event is ready, don't forget to:

Press, articles, blog posts, videos

Tool of the week

  • Elemwala (এলেমওয়ালা) (https://elemwala.toolforge.org): is a proof-of-concept interface that allows you to input abstract content and get natural language text in a given output language. There may well be errors with particular inputs, and the text may not be quite as natural as you might expect, but that's where your improvements to your language's lexemes, other Wikidata items, and the tool's source code come in!
  • mlscores: Tool for calculating multilinguality score of Wikidata items (including properties). E.g. for Wikidata (Q2013), the scores are - en: 99.66%, fr: 89.49%, es: 84.07%, pt: 68.47%. For instance of (P31), the scores are - en: 99.86%, fr: 87.12%, es: 80.83%, pt: 61.37%.

Other Noteworthy Stuff

  • Launch of WikiProject Deprecate P642: The goal of this project is to prepare for deprecation, and eventual removal, of the property of (P642). Currently, of (P642) is labeled as "being deprecated", meaning its use is still allowed, but discouraged. From a peak of around 900,000 uses, the property now has around 700,000 uses (see status here). Our goal is to reduce that as much as possible in a systematic way, while ensuring that appropriate properties exist to replace all valid uses of of (P642). The latter is key to officially deprecating the property. Before removing the property, we want to get as close to zero uses as possible.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • EntitySchemas: We are continuing the work on making it possible to find an EntitySchema by its label or aliases when linking to an EntitySchema in a statement (phab:T375641)
  • Design system: We are continuing the work on migrating the Query Builder from Wikit to Codex
  • REST API: We finished the work on language fallback support in the REST API (phab:T371605)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

I really like the blog post about the SNAIL approach https://commonists.wordpress.com/2024/10/09/small-data-slow-data-a-snail-approach-to-wikidata/ PAC2 (talk) 05:35, 16 October 2024 (UTC)[reply]

Notability of items sourced purely to a Wiki Loves Monuments ID

[edit]

A couple of weeks ago I had nominated some items for gravestone for deletion that were linked nothing to else but a Wiki Loves Monuments ID. Since there's nothing in Wikidata:Notability or the original proposal for the property saying that it is an indicator of notability. Which would make sense considering Wiki Loves Monuments IDs are user generated and based purely on the existence of said monument.

@Multichill: Subsequently closed all the deletion requests as keep because Wiki Loves Monuments is supposedly a well established criterion for notability and then they threatened to block me if I renominated the items for deletion. Which, aside from just coming off like bad faithed bullying, really doesn't make much sense. So does anyone besides @Multichill: know if Wiki Loves Monuments IDs are an indicator of notability or know of any past discussions about it? Adamant1 (talk) 04:26, 15 October 2024 (UTC)[reply]

A WLM id usually means an item has been named in an official heritage register, that may not be available online. So if a WLM id exists, it's probably best to start from the assumption that the item probably is notable, unless there are any very clear reasons to think otherwise. Also, consider that removing items from the WLM list here is disruptive to a high-profile project, and may affect Wikipedia pages that automatically draw on the list here.
Looking at consequences, it would seem to me that the downside of including an item here that may not be notable is rather less that the downside of not including an item here that is notable. There is also the question of removing other people's work; and affecting images on Commons that may refer to the item here.
For all these reasons, I would suggest to be disposed to tread very softly in respect of items that have a WLM id. If there is a group of items that you think should not be included, it probably makes sense in the first place to take it up with the national group that put together the WLM list for that country. I would strongly advice that any deletion request here should not be made unless it has been cleared and approved by that group first. Best regards, Jheald (talk) 09:53, 15 October 2024 (UTC)[reply]
A WLM id usually means an item has been named in an official heritage register @Jheald: From what I understand that's not actually the case. Supposedly one of the reasons there's Wiki Loves Monuments IDs in the first place is because there's a lot of monuments that aren't in official government databases. So the IDs serve to fill in the gaps. Which makes since because there's be no point in the IDs to begin with otherwise. I know that's the case at least with monuments in Ukraine and Russia though. There's a lot of monuments in both countries that aren't in official databases that Wiki Loves Monuments has IDs for.
May affect Wikipedia pages that automatically draw on the list here. All of the items that I nominated for deletion weren't connected to other projects. Let alone where they notable enough to have Wikipedia articles or anything like that. Same goes for there being images for them on Commons. None of them did. So I don't really see how them being deleted would be disruptive or have an effect on anything. --Adamant1 (talk) 19:13, 15 October 2024 (UTC)[reply]
Afaik, the least currently of Wiki Loves Monuments ID is that it could be used in external tools. For example Wikimedia Commons app (Q12528989) and https://app.wikilovesmonuments.it uses it. More globally the Monuments database would transition to use Wikidata as backend. The reason for using single property instead of multiple ones is that in software development point of view it is overly complex to manage rules for multiple different properties. There are is also SPARQL performance reasons why one will want to keep the number of properties smaller. --Zache (talk) 13:24, 17 October 2024 (UTC)[reply]
Generally, the interpretation of what we see as falling under our notability policy gets decided over at deletion requests and some discussions about undeletion of items that happen elsewhere. Simply, renominating items after you see that a category of items get decide to be kept at Request of Deletion causes unnecessary work and is disruptive.
It's worth noting that our policies speak of "can be described using serious and publicly available references" and not "are described using serious and publicly available references", so the absence of references on an item is not in itself a reason why the item is not notable. ChristianKl ❪✉❫ 10:43, 15 October 2024 (UTC)[reply]
@ChristianKl: I totally agree that something's notability should be decided over at deletion requests. The problem is that Multichill unilaterally closed the deletion requests as keep when I had just opened them and there was no discussion. Otherwise I would have been more then happy to not start this conversation and let the normal process play out. You can't have it both ways where it's disruptive to renominate an item for deletion but then it's totally fine for admins to unliterally close DRs after a couple days based on their own personal opinions and regardless if there's been any discussion about it though.
I could ultimately care less if items for monuments that are actually notable exit on here. The problem is that Multichill made a blanket pronouncement that every monument with a Wiki Loves Monuments ID is de-facto notable and then unliterally steamrolled any sort of discussion about it. At least IMO it's totally valid to renominate said items for deletion in an instance like that. Any disruption or extra work it might cause is totally on Multichill for unliterally closing the DRs out of process. --Adamant1 (talk) 19:13, 15 October 2024 (UTC)[reply]
Hey all, I'm one of the folks who create items for component parts of monuments that lack references or monuments that lack references, usually in Brazil. I believe a low percentage of listed monuments in Brazil even have a Wikidata item -- which I know from experience. And certainly not any references. I've visited the regional federal offices for listed monuments (IPHAN) to locate the monuments of a region, and there's a lack of documentation at all levels of government--federal, state, and municipal. WMB is actively collecting sources at all levels of government and academia, but it's very time consuming, or the references exist in documents that are rare or lost.
I think the context of the regions we're working with on Wiki Loves Monuments is important. Can I request that folks take a pause on deleting monuments, or components of monuments? Creating an item with no references is an interesting process, because putting the cart (the item) before the horse (references) puts you on the lookout for the references themselves! I often find highly detailed information signs, but I consider them within copyright so I don't upload them.
Most importantly, thank you all for your work on monuments in Wikidata. You're contributing to an architectural inventory that does not exist elsewhere for individual countries or even regions, and in practice does it contribute to the survival and/or preservation of these works? It sure does! Prburley (talk)
Putting the cart (the item) before the horse (references) puts you on the lookout for the references themselves! It really doesn't though. The items just stay unreferenced for years and then they can't be deleted because people like Multichill and ChristianKl complain about how doing DRs for unsourced items cause extra work or whatever. Regardless, it's ridiculous to create a bunch of unreferenced items purely because you think sources might exist for them and/or you plan on adding them later at some point in the future. Wikidata:Notability might as well not even exist at that point. But hey, screw the notability guidelines because nominating the items for deletion causes extra work though. Sounds like a great way to run a website. --Adamant1 (talk) 03:49, 17 October 2024 (UTC)[reply]
Wikidata:Notability does not say that items staying unreferenced for years is a problem. It just doesn't.
Wikidata is not run so with the intention of work of well intentioned contributors get deleted but so that a lot of different people can contribute to Wikidata.
The spirit of deletionism isn't healthy for Wikipedia either and we don't need it on Wikidata. ChristianKl ❪✉❫ 10:53, 17 October 2024 (UTC)[reply]
@ChristianKl: I mean, realistically there are serious usability problems on both projects that are caused by being to inclusionist. With Wikidata specifically the main reason I got into this was because there was an item for the fictional city of New York that was being automatically added to items instead of the actual city. Otherwise I could really care less, but I don't think your handwaving about how a lot of different people can contribute to the project should necessarily come at the cost of being able to do basic things like add a location to an item. Maybe that's just me though.
I originally asked the question so I wouldn't needlessly be nominating similar items for deletion in the future if monuments with Wiki Loves Monuments IDs were in fact notable. I know admins are their own special kind of fragile, but I do find you calling me a deletionist just because I asked a question about the guidelines rather patronizing. I'm sorry if this whole thing upset you that much, but there's no reason to insult me over it. I wasn't planning on nominating any more unsourced items for deletion anyway. It was just something I thought was worth clarifying. That's all. Have fun degrading usability of the site though ;) --Adamant1 (talk) 13:18, 17 October 2024 (UTC)[reply]
My opinion is that the goal is to move national Wiki Loves Monuments databases to Wikidata. To achieve this, detailed Wikidata items are necessary, either because they are notable in their own right or because they are part of larger notable objects. For example, they could be buildings located on an island that is protected as a whole. This is why these items are needed and should not be deleted. --Zache (talk) 14:07, 17 October 2024 (UTC)[reply]
I don't have a problem with "detailed Wikidata items" for the monuments. The problem is that they inherently can't be detailed if they are unsourced. There's certainly monuments with IDs out there that are detailed though, but that's not what I'm talking about. The problem comes in where there's a years old, unsourced item for a monument that has no other information except the location, name (which is usually made up to begin with), and a Wiki Loves Monuments ID.
I've certainly added more information to a few them myself, but at the end of day the responsibility for doing that should be on the original creator of the item and it should be done when the item is created. Not 12 years later by a random passerby. Just like with any other thing on here. I highly doubt the same standard would apply for anything else. I've certainly seen unsourced items for people, movies, locations, Etc. Etc. deleted before. Monuments just seem to get special pass for some reason. I have my suspicions as to why, but their clearly treated differently. I'm sure this whole thing would have gone a lot different if this it was about something else besides monuments. --Adamant1 (talk) 14:33, 17 October 2024 (UTC)[reply]

Property: previously named as

[edit]

Does a property for former name exist? Prototyperspective (talk) 09:29, 15 October 2024 (UTC)[reply]

@Prototyperspective: For organisations etc, use official name (P1448) if appropriate, or otherwise name (P2561), with the qualifier end time (P582) = date. If you don't know the date, qualifier end time (P582) = unknown value will do. For human beings birth name (P1477) and family name (P734) may also be appropriate. If another name is the name that is current, make a statement for that too, and give it preferred rank. Hope that helps, Jheald (talk) 09:35, 15 October 2024 (UTC)[reply]
Okay thanks, I think it solves it. I would use it for organizations, websites, and software – let me know if it doesn't work for any of these. I think many items miss this data and only have it in their description or aliases (maybe largely because it's so unclear?). See e.g. here. Prototyperspective (talk) 09:44, 15 October 2024 (UTC)[reply]
official name (P1448) works for anything that actually has an official name. That means that there has to be some official entity that gives out the name, which is usually true for organizations, websites, and software. We have nickname (P1449) and native label (P1705) and a few other name properties for other kind of names. ChristianKl ❪✉❫ 10:35, 15 October 2024 (UTC)[reply]
@Prototyperspective: It's not a property but there's former name (Q29569274). Although it only seems to have a hundred or so uses. So I doubt it's worth adopting more generally. --Adamant1 (talk) 05:48, 16 October 2024 (UTC)[reply]
A hundred or so is not little on its own and also because that is probably only a tiny proportion of what the use would be if there was a a dedicated and easy to find well-known property for it. Seems like former name is used in the qualifier "reason for deprecated rank" (mostly?) and the former name is set on properties like given name. I don't know what the downsides of adopting this property are if there are any. I don't think it's important but I do see an issue with the lack of it causing data quality to be lower as people put the same info into all sorts of different fields such as the aliases and so on. Prototyperspective (talk) 10:35, 16 October 2024 (UTC)[reply]
The main reason the item exists is because ja-wiki has a page for it. In contrast to new property generation that has a process that prevents people from creating properties that go against the way we model data, people can easily use items for purposes for which they don't exist.
While someone added "reason for deprecated rank" it's not a valid reason for deprecating a statement. We just set the current name as preferred rank.
We have the name (P2561) and subproperties for allowing user to had high quality data about names that have proper qualifiers and that can have references. Actually stating end time (P582) takes more effort, but it leads to higher quality data then without it. ChristianKl ❪✉❫ 11:19, 16 October 2024 (UTC)[reply]
Thanks for the info. Briefly reiterating that not having a property for this leads to lower data quality. I thought a property for this already exists so I asked here instead of proposing it which I'm quite unsure of whether I will do. Prototyperspective (talk) 11:46, 16 October 2024 (UTC)[reply]
We have a general principle of stating with end time (P582) when a claim that was true in the past is not true anymore. That principle finds application with properties related to names but also any other property where there are changes over time.
Requiring data that's entered to be high quality (be explicit about the end time) does lead to less data being entered, but I don't think it's as easy to summarize that as "lower data quality" because there's less data entered.
Having a general principle around how time works allows people to learn to use end time (P582) with any property instead of needing to learn a separate property for each case where time comes into play. ChristianKl ❪✉❫ 14:01, 16 October 2024 (UTC)[reply]
Okay thanks for these clarifications. In that case, I think somewhere or somebody should probably organize items with texts like "previously named" or "prior name" (or e.g. having prior names only in aliases) to have their data converted according to the best practice / standard you just described here. Prototyperspective (talk) 15:29, 16 October 2024 (UTC)[reply]
There are plenty of different names in aliases. Actually, chosing the right name property, right qualifiers and a good reference for a claim about names, is not something you can easily automate based on looking at the aliases.
In practice, there's also the case where one organization gets replaced by a different organization with a different name and we have one item for each. Someone might write in the description of an item that X is the former name of Y when in fact X was the predessor organization to Y.
If someone in interested in improving the quality of certain items, documenting all the names properly is a way of doing so. At the same time, most people are likely not interested in improving the names of random items. There are many cases in Wikidata where improvements are made. ChristianKl ❪✉❫ 20:24, 16 October 2024 (UTC)[reply]
Nowhere was I talking about automating it. I don't understand how this relates to my comment. I was saying somebody should probably look at e.g. https://www.wikidata.org/w/index.php?search=previously+named&title=Special%3ASearch&ns0=1&ns120=1 and move the previous name into proper fields such as via using the end time property as you described. Prototyperspective (talk) 22:00, 16 October 2024 (UTC)[reply]
@Prototyperspective: I'm not sure what the deal with "former name" is. The reason I said it's probably not worth using is because low usage numbers for something like that can sometimes show it's not an "accepted" property for other items and/or that it's being phased out. So I'm just trying to save you the hassle of getting reverted if turns out to be a bad property or whatever. It is an option though. --Adamant1 (talk) 14:38, 17 October 2024 (UTC)[reply]

Documentation warning that mobile users can't add Statements

[edit]

Would it be possible/appropriate for someone to add that mobile users can't add statements to Help:Statements#Adding_statements and maybe the nutshell. Quite frustrating and confusing. Commander Keane (talk) 04:52, 16 October 2024 (UTC)[reply]

Just curious, were you using mobile itself when looking at the Help page? If so, perhaps we can add a fairly visible notice to that page for mobile only? As well as a smaller note somewhere else. ·addshore· talk to me! 17:46, 16 October 2024 (UTC)[reply]
Yes I was on mobile at the time, attempting to create my first item on mobile. Commander Keane (talk) 22:07, 16 October 2024 (UTC)[reply]
Do you think it would be more useful to have a note on the item page when you are editing it? or on the help page? or both? ·addshore· talk to me! 23:16, 16 October 2024 (UTC)[reply]
If it can be applied to mobile only then on the item page would be good. The help page should mention it regardless, probably a hat note in the section I initially linked to. Commander Keane (talk) 05:10, 17 October 2024 (UTC)[reply]

Commemorative stamp

[edit]

The Israeli national postal service issued a commemorative stamp to mark the 70th anniverary of an organization's founding. What's the property for commemorative stamp for adding this info to the organization's WD item? -- Deborahjay (talk) 09:06, 16 October 2024 (UTC)[reply]

There's no good reason to link from the item of Israel Postal Company (Q671700) to the stamp. The stamp should likely link to Israel Postal Company (Q671700) via issued by (P2378) and maybe use commemorates (P547) to an item like "70th anniverary of the issuing organization". Maybe, also something else for commemorates (P547) that uses qualifiers. ChristianKl ❪✉❫ 10:34, 16 October 2024 (UTC)[reply]

RESTATING QUERY: @ChristianKl: With which Property to add the Statement "commemorative stamp (Q1756502)" to the WD item of the organization (Gevatron), perhaps similar to the Property "award received (P166)"? There's no WD item for the stamp itself; what's notable is that this organization received recognition with a commemorative stamp. Or must the stamp have its own WD item to proceed? -- Deborahjay (talk) 13:37, 16 October 2024 (UTC)[reply]

I think the solution is to add no WD item to the organziation itself, but to have an item for the stamp. But it could be that someone else has a different idea of how it should be modelled. ChristianKl ❪✉❫ 13:55, 16 October 2024 (UTC)[reply]
I created a WD item for the Gevatron 70th anniversary commemorative stamp which still needs details added per a postage stamp's Statement "has characteristic" (P1552). However, I still believe there needs to be a reciprocal indication on the WD item of the stamp's topic, Gevatron. -- Deborahjay (talk) 14:34, 16 October 2024 (UTC)[reply]

Ceb

[edit]

Bautzen (Q31906993) looks essentially the same as Bautzen (Q14835) except 1 machine generated article. what to do? RoyZuo (talk) 12:41, 16 October 2024 (UTC)[reply]

Formally, one item is for the municipality, and another one for the town which happens to be the seat. I did not check whether the municipality only consists of the town, but this is likely the case here. In the past, I proposed to make an exception to the notability criteria, so that the presence of the Cebuano sitelink does not create notability. Until this has been accepted, both items are notable, and we have to let it go. Ymblanter (talk) 19:33, 16 October 2024 (UTC)[reply]

Subject type contraint

[edit]

For the Property P2378 (Issued by) regarding a postage stamp, there's a Statement Q21503250 (Subject type constraint) flagged that this subject type doesn't apply - though it does to such items as "banknote" and "coin". Could "postage stamp" be added to the Subject type (or the Property "Issued by")? Or what Property to use as a Statement on the WD item to indicate the official body (Israel Philatelic Federation) that issued the postage stamp? -- Deborahjay (talk) 14:27, 16 October 2024 (UTC)[reply]

Seeking volunteers to join several of the movement’s committees

[edit]

Each year, typically from October through December, several of the movement’s committees seek new volunteers.

Read more about the committees on their Meta-wiki pages:

Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.

For the Committee Support team,


-- Keegan (WMF) (talk) 23:07, 16 October 2024 (UTC)[reply]

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