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

Wikidata:Project chat

From Wikidata
(Redirected from Wikidata:Chat)
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 2024/06.

Removal of ISNI by admin

[edit]

https://www.wikidata.org/w/index.php?title=Q37594&diff=prev&oldid=2179820220 - what is this about? User:Epìdosis removed a valid ID. This breaks database-connections, e.g. via OpenRefine. It might be OK for some secondary IDs, but for ISO-IDs that are widely used this causes much more trouble. Especially since it is a fixed lenght ID with no known widely used overlap, i.e. it can be used in regular search fields to find an item (not so for the IDs by e.g. DNB/GND, NTA). Friedrich Kettler (talk) 00:46, 15 June 2024 (UTC)[reply]

Reported at Wikidata:Administrators'_noticeboard#Removal of ISNI by User:Epìdosis Friedrich Kettler (talk) 00:50, 15 June 2024 (UTC)[reply]

Did you try talking to the other user on their talk page? William Graham (talk) 01:52, 15 June 2024 (UTC)[reply]
Hi! This is part of a slow cleaning of single-value constraint violations of ISNI (P213); if an ID has been redirected and has no source, or as only source itself (stated in (P248)International Standard Name Identifier (Q423048)), I usually remove it in order to gradually reduce the amount of items having 2+ ISNIs; if the ISNI is sourced, i.e. it has been imported on Wikidata from an external source, I write to the external source, I wait until it has been corrected in the external source and then I remove it from Wikidata. Keeping clear the lists of constraint violations has multiple beneficial effects for the checking of data quality (cf. par. 3 and 5.2). As of now I have not received any complaint in my talk page for these removals. Anyway, I have no problem in stopping this cleaning if it lacks consensus; let me know. Epìdosis 07:36, 15 June 2024 (UTC) P.S. "This breaks database-connections" is not completely true: a database making matches with Wikidata through ISNI can just make two passages, the first retrieving ISNI in order to check if some ISNIs have been redirected and obtain from ISNI the new ISNIs, and the second retrieving Wikidata in order to check the existence of new ISNIs. --Epìdosis 07:39, 15 June 2024 (UTC)[reply]
Both should remain if correct; one of the identifiers should have deprecated or preferred rank (I have been using deprecated rank for redirects as redirect (Q45403344) has instance of (P31):Wikibase reason for deprecated rank (Q27949697) but this conflicts with Help:Ranking which says deprecated rank is for statements that were never correct). Peter James (talk) 11:42, 15 June 2024 (UTC)[reply]
So better move to a new property ISNI redirect. But there are also withdrawn identifiers, I deprecated those, since I couldn't verify them. Friedrich Kettler (talk) 13:47, 15 June 2024 (UTC)[reply]
@Epìdosis:
  1. How many ISNI redirects have you removed?
  2. "has no source" - this is common for external identifiers
Yes, cleaning up constraint violations is great. How about storing redirects in a new property ISNI redirect, so there is a cleaner P213 and in the new property also redirect targets can be mentioned.
/"This breaks database-connections" is not completely true/ - it is. Try to connect to Wikidata from an ISNI that you have removed from Wikidata - fail! Friedrich Kettler (talk) 13:45, 15 June 2024 (UTC)[reply]
The idea of having a specific property for redirected ISNIs might have sense, but I think that the same is not done for any other property as of now, so it would probably need a broader discussion. For the other questions, I need more time to formulate a complete answer but I will have only a few minutes online in the next two days and half; I surely will do it as soon as possible. Good night, --Epìdosis 20:54, 15 June 2024 (UTC)[reply]
Another solution would be to have a new qualifier "incoming redirected ID", so the values can directly be attached to the redirect target. The general search will still find them. For ISNI, or any other systems with little overlap in ID values with values from other systems, this would be helpful. Friedrich Kettler (talk) 21:30, 15 June 2024 (UTC)[reply]
The property doesn't have a single value constraint though. - Nikki (talk) 10:07, 22 June 2024 (UTC)[reply]
Premise: in principle, the issue of how to manage obsolete (especially redirected) external IDs should be addressed through a general policy, but the RfC opened in 2020 became stalled in a few months and is far from reaching any pratical conclusion.
So, in general I think the three main reasons for which we could be interested in keeping obsolete IDs are: 1) historical purposes 2) help in matching with other IDs (especially for highly used IDs, such as VIAF and ISNI) and 3) avoid readdition. The main counter-reasons to the above reasons are: 1) obsolete IDs could be extracted from page histories, and anyway keeping track of the historical evolution of external databases is not a vital scope of Wikidata; 2) if the external database allows converting redirected IDs into valid IDs, Wikidata can ignore redirected IDs (because, if a database A wants to use redirected IDs taken from database B to match with Wikidata, can first use database B to convert its redirected IDs to valid IDs and then use valid IDs to match with Wikidata) and 3) if we make sure that the occurrences in external database of redirected IDs are all fixed, the readdition becomes reasonably impossible (consequence: if an ID has no source, we have no proof that it has any external use, so its readdition is improbable). Further reasons against keeping obsolete external IDs are expressed in the (unanswered) comment by Ivan A. Krestinin in the RfC. I would finally add that there is no consensus about how to keep obsolete IDs, since the most common use is deprecating redirected/obsolete IDs but this is in contrast with the norms prescribing to use deprecation only for never-valid data.
ISNI (P213), like VIAF ID (P214), has no single-value constraint mainly to avoid that users, in order to solve constraint violations, just remove the less relevant IDs instead of keeping them at least until the get merged. However, despite the absence of the constraint, most of the cases in which ISNI has 2+ IDs for the same persons should be effectively fixed in ISNI, since ISNI prescribes keeping multiple IDs only for persons with pseudonyms and in no other cases.
Anyway, in the next months I have in program to work mainly on ISNI unique-value constraint violations and only afterwards return systematically on cases of 2+ ISNIs in the same item; I hope that in the meanwhile some clearer consensus on the topic will have emerged. --Epìdosis 14:00, 22 June 2024 (UTC)[reply]
For ORCID which is a similar identifier for individuals I have been doing considerable cleanup by:
if the ORCID is just on the wrong person, move it to the correct one (often happens due to merges that need to be reverted)
if the ORCID is a redirect, set rank to deprecated, with qualifier reason for deprecated rank (P2241) redirect (Q45403344)
if it is just wrong, set rank to deprecated with qualifier reason for deprecated rank (P2241) refers to different subject (Q28091153)
I assume this procedure would be preferable for ISNI also. Identifiers should not be just deleted. ArthurPSmith (talk) 11:43, 16 June 2024 (UTC)[reply]
  1. Bad design. If it is "just wrong" move it to a new person. Otherwise what is the logic? Most IDs are wrong on millions of items, why would it stay there?
  2. Regarding using deprecated rank for a working redirect - why? It is still working and correct, opposed to conflated. Help:Ranking#Deprecated_rank "The deprecated rank is used for statements that are known to include errors" - are you editing against community consensus?
"I assume this procedure would be preferable for ISNI also." - no it wouldn't. ISNI that are wrong
  1. should be removed from the item where they are wrong, because it pollutes the item and
  2. moved to a correct item, so one can find out why it is wrong on the other
A human can have several ISNI, because they are identifiers for "identities", not for humans. If an ISNI is only marked as redirect one will not be able to see to which identity the value belongs. So one would need a qualifier "redirects to" and insert there the target value. Elisabeth Pommern (talk) 21:45, 18 June 2024 (UTC)[reply]
@ArthurPSmith: This is probably a bit of a derail, but in my experience when items with ORCIDs have a name that doesn't match the ORCID name, I have to to verify/update the object named as for every article with an author statement by reviewing the DOI external identifier. If a lot of them are mixed up with one other person, it's likely a severe enough conflation that requires treating that item as worthy of deletion, and then creating new item or items for the conflated persons. The number of older batch matching that didn't convert the author name string text into an object named as text makes those conflations a lot harder to catch and repair. (Even bigger derail) I use your tool Author Disambiguation and was wondering if there was a way to filter author works by ones missing an object named as. William Graham (talk) 22:20, 18 June 2024 (UTC)[reply]
@William Graham: yeah, I've been doing a lot of cleanup like that. I use a WDQS SPARQL query to find author works missing "object named as", but I agree it would be a helpful thing in the tool (right now there's an easy way to get a list of articles with a specific "object named as" value for the author, but not to get a list of ones without that qualifier). I'll look into it! ArthurPSmith (talk) 01:50, 19 June 2024 (UTC)[reply]
If you set the redirect to deprecated, you're saying the redirecting ID is wrong. If it's correct but not the preferred ID because it's a redirect, then you should set the non-redirecting one to preferred rank instead. And if that causes constraint violations, the constraints should be fixed (probably by replacing "single value" with "single best value"). - Nikki (talk) 10:19, 22 June 2024 (UTC)[reply]

All library-land identifiers (VIAF, ISNI, ORCID, LCCN, etc) are NAME identifiers not person identifiers. If a person writes (or wrote) under pseudonyms, an identifier (with gender and other metadata) should be minted for each. This is the way authority control works in the Western library tradition. Linking them to people in wikidata was a data modelling choice which we continue to pay for, they should have been linked to a Q82799. Stuartyeates (talk) 02:16, 25 June 2024 (UTC)[reply]

Removal of en-description containing birth and death place and time

[edit]

https://www.wikidata.org/w/index.php?title=Q110213478&diff=prev&oldid=2179644177 - is there any rule for that? Friedrich Kettler (talk) 02:14, 15 June 2024 (UTC)[reply]

Please talk to them, smth clearly went wrong in this batch. Ymblanter (talk) 07:22, 15 June 2024 (UTC)[reply]
The rule for English descriptions is Help:Description#Guidelines for descriptions in English, which prescribes for persons in general "For a person: [country] [career the person is known for]" as the formula upon which a description should be constructed. The use of birth and death dates and of birth and death places is always avoided in English descriptions. BTW, the case reported above is clearly linguistically wrong: "* 25.10.1856 Aarau,† 27.10.1909 Bern 1856", apart from using "*" for birth and "†" which are not of commonly used in English, repeats 1856 at the bottom of the string in an unclear way. This batch of 47 edits was meant to remove a group of descriptions which were clearly incorrect in English because copied from texts either in German or in Dutch. Epìdosis 07:53, 15 June 2024 (UTC)[reply]
Seems like a correct removal to me, now a bot can provide a proper description. Sjoerd de Bruin (talk) 10:23, 15 June 2024 (UTC)[reply]
And we are waiting for why that would be so... Friedrich Kettler (talk) 13:50, 15 June 2024 (UTC)[reply]
Having year of birth and death in description is commonly done. It is often, next to the names, essential to identify humans. The property yob and yod are far down on many pages, so the removal is very bad for working on human items via the standard interface. Friedrich Kettler (talk) 13:50, 15 June 2024 (UTC)[reply]
I repeat: these descriptions were linguistically-incorrect in English, because copied from texts either in German or in Dutch; this is the reason of the removal. As @Sjoerddebruin: added, having no description instead of a linguistically-wrong description will allow a bot to add new linguistically-correct descriptions. Epìdosis 14:25, 15 June 2024 (UTC)[reply]
"* 25.10.1856 Aarau,† 27.10.1909 Bern 1856" - removal of "1856" at the end would have been sufficient. And a bot can surely convert * and † if desired. Friedrich Kettler (talk) 15:11, 15 June 2024 (UTC)[reply]
If Wikidata had been made for such descriptions, we would have already synthesized them from statements, imported them for every supported language and wouldn't have been wasting time on stuff like Douglas Adams (Q42): English author and humourist (1952–2001).
Fortunately, it had not, and these instances are just an outcome of various careless imports, laziness or lack of invention. Unfortunately, even humans do this deliberately [1]. Matěj Suchánek (talk) 17:19, 15 June 2024 (UTC)[reply]
"If Wikidata had been made for such descriptions, we would have already synthesized them from statements" - it has been made for such description.
"and wouldn't have been wasting time" - "Fortunately, it had not," - Fortunately, there are people that consider wasting time not as something that is a result of a situation that exists "[f]ortunately". Andres Ollino (talk) 23:05, 20 June 2024 (UTC)[reply]
Although the ultimate purpose of this project is to feed robots (i.e. Amazon, Google, and ChatGPT) endless amounts of data, humans might actually use Wikidata from time to time, and appending year of birth & death (albeit not full date and place) is often essential to help narrow down the list of potential matches (for us poor humans). There are more than one John Smiths (even more than one who happen to be American politicians), and more than one Henry Joneses. Using source-imported descriptions like "Peerage person ID=270674" or "viaf:56932" are not generally helpful for humans who aren't already familiar with the source database. "Good enough" seems to be the predominant philosophy. Despite ostensibly appearing otherwise, Wikidata basically has no law, and most of the few 'rules' in place tend to be either silly, impractical, routinely ignored, or unenforced. This project will always be a hodgepodge of random data bits whose quality varies wildly but hopefully makes sense to most humans, until the point when machines take over completely. -Animalparty (talk) 00:14, 21 June 2024 (UTC)[reply]
appending is harmless, and indeed possibly useful. But you append something to something. I was mostly referring to edits like this. --Matěj Suchánek (talk) 12:19, 22 June 2024 (UTC)[reply]

Complete sets

[edit]

Is there a way to represent and to query for complete sets for situations like the following? I want to know what securities (and/or what companies) are in the S&P 500. If I query "SELECT distinct ?company ?companyLabel WHERE { 

 ?company wdt:P361 wd:Q242345.
 SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

}" then I get 530 results. I want either 503 (securities) or 500 (companies) results. Is there really no way to record that X is the complete list of all securities/companies in the S&P 500 as of June 20, 2024? I don't want to have to do a complicated query for this sort of thing, though if there's an easy way to adjust the query that is not fragile it might be helpful. Relying on updates of the individual items is not reasonable, though.

Basically the same question with regard to recording data. I can get a list of the 500/503 companies/securities currently in the S&P 500. Is there a way to record this as a complete set (in RDF, a bag)? JustHydrogen (talk) 12:37, 20 June 2024 (UTC)[reply]

You need to filter out the companies that have been in S&P 500, but are no longer in there. You can do it like this:
SELECT distinct ?company WHERE {  
?company p:P361 ?s.
?s ps:P361 wd:Q242345.
FILTER ( NOT EXISTS { ?s pq:P582 ?end. } )
}
However, there are still to many companies in the result. I guess, there are some companies with outdated statements. --D3rT!m (talk) 17:50, 20 June 2024 (UTC)[reply]
Yeah, relying on end time is problematic. It's hard to find that information, while it's easy to find which securities are currently part of the index. Maybe end time can be set to unknown or precision can be set to "century" or "millenium"? JustHydrogen (talk) 18:26, 20 June 2024 (UTC)[reply]
I would recommend using unknown value Help rather than extremely broad precisions for something like this. Precisions are not supported in the interface for the query service, and the vast majority of queries that fetch dates use the wrong predicates (such as pq:P582, which loses all precision information, instead of pqv:P582, wikibase:timeValue and wikibase:timePrecision). There are other qualifiers like earliest end date (P8554) and ‎latest end date (P12506) that can be used to describe possible ranges with a lot more flexibility. - Nikki (talk) 09:25, 22 June 2024 (UTC)[reply]

Removing redundant 'spamblacklistlog' right from Wikidata-staff

[edit]

Hi, the spamblacklistlog flag is automatically granted to all the registered users. I noticed that the wikidata-staff usergroup still has it. Can we remove it from them (since they already have it as registered users)? I'd like to point out that nothing changes for those who are part of this usergroup :) Thanks! Superpes15 (talk) 11:23, 21 June 2024 (UTC)[reply]

 Support, follows up gerrit:405670 Lucas Werkmeister (WMDE) (talk) 13:25, 21 June 2024 (UTC)[reply]
 Comment This could also apply to en:WP:Edit filter helpers (T175684), if I’m not mistaken :) Lucas Werkmeister (WMDE) (talk) 13:28, 21 June 2024 (UTC)[reply]
@Lucas Werkmeister (WMDE): Yep yep! I opened this thread after T367683 (so I'll do both in a single patch) :D Superpes15 (talk) 16:16, 21 June 2024 (UTC)[reply]
 Support --Matěj Suchánek (talk) 12:20, 22 June 2024 (UTC)[reply]

Unify these two wikidata page of Kafir and Kufr

[edit]

Please unify these two page of kafir (Q629608) and Kufr (Q13452658). 103.230.106.15 13:01, 21 June 2024 (UTC)[reply]

 Not done: These are two different concepts. "Unbeliever", referring to a person, vs. "unbelief", referring to the concept of not believing. — Huntster (t @ c) 17:16, 21 June 2024 (UTC)[reply]
Additionally, the items can't be merged because there are wikipedias with two different articles for those two concepts (like azwiki and ukwiki).--Pere prlpz (talk) 19:44, 21 June 2024 (UTC)[reply]

Bot blocked?

[edit]

Hello,

I'm the maintainer of MystBot (talk • contribs • logs) and it seems the bot is now read-only. I tried to find why without success. Can someone know how to check why my bot is now in readonly?

Edit: to add informations, my issue is when I try to interact trough the API. I tried a Bot password and an OAuth 2 token, with high-volume access (bot), Edit pages, Edit protected pages and create, edit and move pages. But everytime I got the message "You do not have the permissions needed to carry out this action.".

Thanks, Myst Myst (talk) 21:18, 21 June 2024 (UTC)[reply]

@Myst: looking at the logs I'm not seeing anything suggesting anything was done. no idea. BrokenSegue (talk) 02:51, 22 June 2024 (UTC)[reply]
Does changing the User Agent string from "Updating French Population" to something that identifies the operator help? E.g. "MystBot - Updating French Population (User:Myst)". If you run stuff from Wikimedia infrastructure they are probably a bit stricter about this. Infrastruktur (talk) 08:35, 22 June 2024 (UTC)[reply]
I found the issue, it seems there's a shadow ban for GitHub IPs. I tried to work from GitHub Codespaces and got the error message. I copied the same code on my computer and got no issue. I hope this will help others. Thanks for your messages @BrokenSegue and @Infrastruktur . Myst (talk) 09:05, 22 June 2024 (UTC)[reply]
oh we could maybe make your account ip ban exempt? BrokenSegue (talk) 14:32, 22 June 2024 (UTC)[reply]
Hello, Thanks but I don't think it's necessary. It was only because I tried to work remotely and gh codespace was a good way to do it. I've setup my own solution so the issue won't appear again. Myst (talk) 11:41, 24 June 2024 (UTC)[reply]

Media rating information

[edit]

I'm in the need of a way to represent media rating information. For example the rating shown at allsides.com. I propose we represent this as:

assessment
Normal rank AllSides Media Bias Rating edit
assessment outcome left-wing
test score -1.3
point in time June 5, 2024
0 references
add reference


add value

Does this make sense? I'm not sure if there are relevant wikiprojects on wikidata that would care about this. @Hearvox: who I believe will care.

BrokenSegue (talk) 03:04, 22 June 2024 (UTC)[reply]

I think this makes sense, it's a pretty neat visualisation. I think that there should be a constraint that it can't be with 0 reference. This is both due to it being sensitive information, and also it should be easy to do a reference because the source of information is readily available. Egezort (talk) 06:55, 22 June 2024 (UTC)[reply]

Olivetti Valentine Q3881837

[edit]

How can I indicate two sets of dimensions for the Olivetti Valentine (i.e., both with and without its hard-shell case, which is an integral feature of the design of the object itself)? The source for the information is an entry on the Smithsonian site (see: "Dimensions"). How should this data be entered here? Cheers, Cl3phact0 (talk) 12:22, 23 June 2024 (UTC)[reply]

@Cl3phact0: maybe you could enter both sets of dimensions and qualify one set with applies to part (P518) physical container (Q987767) (or similar) BrokenSegue (talk) 14:58, 23 June 2024 (UTC)[reply]
I feel like we need an item like "carrying case" that's a little more specific than physical container (Q987767). "container made for carrying objects"? — Huntster (t @ c) 15:28, 23 June 2024 (UTC)[reply]
Thank you. I've made the addition using physical container (Q987767) for the time being. Please let me know if there is a better qualifier and I will amend. -- Cl3phact0 (talk) 17:24, 23 June 2024 (UTC)[reply]
@Cl3phact0: created carrying case (Q126890836) and added it to Olivetti Valentine (Q3881837) along with a couple of other updates. — Huntster (t @ c) 20:07, 23 June 2024 (UTC)[reply]

Thank you both. Another question: Would adding a zero decimal place and using "millimetres" be preferable (per this example) for the "Unit (optional)" information field? -- Cl3phact0 (talk) 16:27, 23 June 2024 (UTC)[reply]

@Cl3phact0: I would use the given measurements, no decimal. "100 mm", "330 mm", and "345 mm". Nevermind, I see what you mean. No, using centimetres is fine. — Huntster (t @ c) 17:20, 23 June 2024 (UTC)[reply]

Lexicodays: join the event on June 28-30 - Lexicodays: Ayo bergabung dalam acara pada 28-30 Juni!

[edit]

- Indonesian version below -

Hello all,

The Lexicodays 2024, online event dedicated to Lexicographical Data on Wikidata, will take place this week, on June 28, 29 and 30!.

The event will take place both on Zoom and Jitsi, and the access will be free without registration (the access links will be added to the program page). However, if you’re planning to join, we invite you to add your username to the Participants page. The event will include sessions replicated in different languages and at different times across time zones.

Here are a few interesting sessions that you will find in the program:

  • Introduction to Lexicographical data and how to model words in Wikidata
  • Discussions about modelling proverbs, sayings, compound words and predicates
  • Presentation of some useful tools
  • Modelling sessions and editathons in various languages of Indonesia
  • Introduction to Abstract Wikipedia and how it will work together with Lexemes
  • Exploring how to generate sentences with Lexemes

Note that most sessions will be recorded and available after the event.

If you have any questions, feel free to reach out to Léa (Lea Lacroix (WMDE)) or Raisha (Raisha (WSC)).

We’re looking forward to seeing you at the Lexicodays!

---

Halo, semua!

Lexicodays 2024 adalah sebuah acara daring yang didedikasikan untuk Data Leksikografis di Wikidata. Lexicodays akan diselenggarakan pada pekan ini, tanggal 28, 29, dan 30 Juni 2024!

Acara ini akan berlangsung melalui platform Zoom dan Jitsi, dengan akses yang terbuka tanpa registrasi khusus (tautan akses akan tersedia pada halaman acara). Meski demikian, jika Anda berencana untuk bergabung, kami mengundang Anda untuk menambahkan nama pengguna Anda ke halaman Peserta. Dalam Lexicodays, kami akan membawakan sesi yang direplikasi ke dalam berbagai bahasa dan berbagai sebaran zona waktu.

Berikut adalah beberapa sesi menarik yang akan Anda temukan di dalam acara ini:

  • Pengantar data leksikografis dan cara memodelkan kata-kata di Wikidata
  • Diskusi tentang pemodelan peribahasa, pepatah, kata majemuk, dan predikat
  • Paparan tentang beberapa alat bantu yang berguna
  • Sesi pemodelan dan penyuntingan dalam berbagai bahasa di Indonesia
  • Pengenalan Abstract Wikipedia dan bagaimana hubungannya dengan Leksem
  • Mengeksplorasi cara membuat kalimat dengan Leksem

Kami akan merekam sebagian besar sesi, dan rekaman sesi dapat diakses setelah acara berlangsung.

Apabila Anda memiliki pertanyaan, jangan ragu untuk menghubungi Léa (Lea Lacroix (WMDE)) atau Raisha (Raisha (WSC)).

Kami sangat menantikan kehadiran Anda di Lexicodays! Lea Lacroix (WMDE) (talk) 10:23, 24 June 2024 (UTC)[reply]

Wikidata weekly summary #633

[edit]
Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-06-24. Please help Translate.

Events

  • Past: The 200th online Wikidata meetup in Swedish was held.
  • Upcoming: Lexicodays, online event dedicated to Lexemes on Wikidata, will take place on June 28-30. It takes place across time zone and both in English and Indonesian. Check the program and find the access links on the event page.

Press, articles, blog posts, videos

Tool of the week

  • Wikidata in Prometheus - Prometheus is a non-commercial image archive for art and cultural studies. It hosts images from a variety of image and media databases and now works can be connected with Wikidata.
  • New Mix'n'match feature: For lists of (full or auto) matches where both the MnM entry and the Wikidata Item have coordinates, it now shows the distance between them in the description. (source)

Other Noteworthy Stuff

  • The Wikidata development team at Wikimedia Deutschland is planning a brief survey to understand the various ways people contribute to the project and identify user contribution patterns. A request has been made for a CentralNotice banner to deploy the survey to a broad audience. Your feedback, comments, and questions on this request are welcome: m:CentralNotice/Request/Wikidata Community Survey 2024
  • The second iteration of the Wikidata:Open Online Course will begin from July 1 until August 11. Whether you're a beginner taking your first steps, an individual in need of a refresher on Wikidata concepts, or a seasoned trainer looking to level up your skills - this course is right for you.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • [Breaking Change Announcement] Upcoming Changes to Wikibase: EntitySchema data type
  • EntitySchemas: We prepared for the release of the new data type to link to EntitySchemas in statements on July 2nd.
  • Mul language code: We picked up the remaining issues before enabling it by default on Wikidata
  • Wikibase REST API:

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

Mix'n'Match scraper help

[edit]

I'm completely bemused by the scraper feature in Mix'n'Match; would anyone care to kindly walk me through the process for scraping [2] for Avibase person ID (P12837)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 24 June 2024 (UTC)[reply]

Felon and criminal

[edit]

are they the same ? felon(Q117025743) and criminal(Q2159907) Bouzinac 💬●✒️●💛 19:33, 24 June 2024 (UTC)[reply]

In some jurisdictions (like the US) they are clearly different, as crimes are split into felonies (serious crimes with 1+ year sentences) and misdemeanours, and a felon is a subclass of criminal. While most WD's just redirect both terms to "crime", I don't think we have a reason to merge them here. Vicarage (talk) 22:11, 24 June 2024 (UTC)[reply]
That is, felon is a "very bad" criminal ? Bouzinac 💬●✒️●💛 04:51, 25 June 2024 (UTC)[reply]
Insofar as "felons" are criminals that have committed an offence that is classified as a felony, and felonies are generally seen as more serious crimes than misdemeanours, yes. But one could be a "very bad criminal" and not have committed any felonies. M2Ys4U (talk) 16:44, 25 June 2024 (UTC)[reply]
Okay. Something interesting for those interested into this topic : https://www.dukeupress.edu/criminal-man Bouzinac 💬●✒️●💛 18:27, 25 June 2024 (UTC)[reply]

Adding USDA Census of Agriculture data to the WIKI platform

[edit]

I do outreach for the state of Oregon and am part of UDSA-NASS (National Agricultural Statistics Service). At the end of February 2024, we released the 2022 Census of Agriculture dataset that details Farm demographics, income, expenses, crops and livestock data and much more, at the National, State, and county level if publishable. The Census is done every five years, and I reached out last time to WIKI to try and see if there was an automated way for you to populate this information on your pages. In many rural counties, agriculture is the only industry that provides income to people and there is no data on WIKI pages. It would be ideal to search for "wheat", and be able to see the data at many levels where grown in the U.S., etc.. Our website is https://www.nass.usda.gov/AgCensus NASS makes the Census data available in multiple machine-readable formats through downloadable data sets as well as through web API’s. Loshdav (talk) 21:47, 24 June 2024 (UTC)[reply]

what data are you imagining people seeing when they search wheat and on what pages? like do you want this on en:Wheat? or on the pages for these rural counties? BrokenSegue (talk) 23:54, 24 June 2024 (UTC)[reply]

Regarding two entities of the same institute

[edit]

There is Eijkman Institute for Molecular Biology (Q1303680) and Eijkman Molecular Biology Research Center (Q114921293), which refers to the same research institute, but under different ownership (and different name while we're they're moving). Should this be merged or not? Hans5958 (talk) 04:43, 25 June 2024 (UTC)[reply]

@Hans5958: the two items should probably be linked by replaces (P1365)/replaced by (P1366). Since they have different names and different owners it seems good to have two separate items. ArthurPSmith (talk) 17:59, 25 June 2024 (UTC)[reply]

Talk:Q37793136 : Aya Nakamura

[edit]

As this page is protected, I cannot offer a better image than the one currently used. I extracted from the document that provided the current image an image that I was able to correct with Photoshop: File:Aya Nakamura-23Sept2019.jpg. But I can't make the change myself because the page is protected. Can a person with rights make this modification? THANKS! First ismoon (talk) 10:42, 25 June 2024 (UTC)[reply]

I'm not sure if this would really be an improvement. D3rT!m (talk) 14:10, 25 June 2024 (UTC)[reply]
Blurry image might be worse than bad lighting IMO. Infrastruktur (talk) 14:44, 25 June 2024 (UTC)[reply]
Well. I would like to point out that the current photo is also slightly blurry. I offer you a slightly larger photo in original pixels, not so blurry, and with colors more respectful of the model. File:Aya Nakamura-3. What do you think ? First ismoon (talk) 14:03, 26 June 2024 (UTC)[reply]

Voting to ratify the Wikimedia Movement Charter is now open – cast your vote

[edit]
You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello everyone,

The voting to ratify the Wikimedia Movement Charter is now open. The Wikimedia Movement Charter is a document to define roles and responsibilities for all the members and entities of the Wikimedia movement, including the creation of a new body – the Global Council – for movement governance.

The final version of the Wikimedia Movement Charter is available on Meta in different languages and attached here in PDF format for your reading.

Voting commenced on SecurePoll on June 25, 2024 at 00:01 UTC and will conclude on July 9, 2024 at 23:59 UTC. Please read more on the voter information and eligibility details.

After reading the Charter, please vote here and share this note further.

If you have any questions about the ratification vote, please contact the Charter Electoral Commission at cec@wikimedia.org.

On behalf of the CEC,

RamzyM (WMF) 10:51, 25 June 2024 (UTC)[reply]

[edit]

I'm trying to link the article concerning the medical condition Dysphagia, at the Dutch Wikipedia, to the correct Wikidata entry, 623289. On trying to do this, I'm told that the link to nl Wikipedia's entry for Dysphagia, is already in use at 2599000. Q2599000 contains no other interwiki links, they're all on Q623289. Because I've not done much here before, I don't know how to remove the link from Q2599000, or whether I even should. Would someone please take a look and help me out? I don't want to screw this up! Thanks :) DaneGeld (talk) 18:31, 25 June 2024 (UTC)[reply]

Hello,
From my point of view, these two objects should not be merged, nor should the link to nl-article for the journal be changed to the other item for the disorder/symptom. After the article nl:Dysfagie about the disorder/symptom has been written, it could be connected to d:Q623289 M2k~dewiki (talk) 19:39, 25 June 2024 (UTC)[reply]

Victorin

[edit]

What is the best way to link en:Victorin to Wikidata? We have items Victorin (Q19914352) for the given name and Victorin (Q37075799) for the family name. But the article covers both. — Martin (MSGJ · talk) 12:25, 26 June 2024 (UTC)[reply]

[PROPOSAL] Link labels, aliases and monolingual text with Lexemes

[edit]

Archive/2024/06-[PROPOSAL] Link labels, aliases and monolingual text with Lexemes I don't know if here is the right place to propose it. It would be nice to link item labels, item aliases and monolingual text from statements with a corresponding lexeme. This could be optional, either enter plain text or select a lexeme from the selector. I have no clue about how realistic or difficult to implement it could be. I created an image that I hope explains what I mean. 5628785a (talk)
Sorry for taking so long to get back to you @5628785a. I've added the proposal to our WIT Meta page so it won't get lost in Archives. I will have another reply to you by EoW. Kind regards, Danny Benjafield (WMDE) (talk) 14:56, 26 June 2024 (UTC)[reply]

Incorrect author in item description and in author statement

[edit]

Hi, re. The Last Storytellers: Tales from the Heart of Morocco (Q7746061) The author is actually Richard Hamilton (who has no en wiki article), not Barnaby Rogerson. He wrote the foreword. Am too new to wikidata to make the required edits. Esowteric (talk) 16:56, 26 June 2024 (UTC)[reply]

@Esowteric I went in and added a qualifier to indicate Rogerson only wrote the foreword and added an author name string for Hamilton as the main author. William Graham (talk) 17:41, 26 June 2024 (UTC)[reply]
Many thanks! I'll check how you did it. Esowteric (talk) 17:44, 26 June 2024 (UTC)[reply]
I initially used author name string (P2093) for Hamilton, but after finding a Library of Congress name authority for him, created Richard Hamilton (Q126912726) to use. William Graham (talk) 17:49, 26 June 2024 (UTC)[reply]
The "author of foreword" property also works great for this. Iamcarbon (talk) 00:59, 27 June 2024 (UTC)[reply]
Many thanks again, guys. Esowteric (talk) 08:33, 27 June 2024 (UTC)[reply]

How to encode posthumous scandal?

[edit]

Q4383892 was involved in a well documented scandal which only emerged after his death. How is this kind of thing encoded? Stuartyeates (talk) 20:23, 26 June 2024 (UTC)[reply]

@Stuartyeates
Below is my attempt at encoding the alleged assault. Not sure how to capture the posthumousness of the effects or that the withdrawn award was specifically Arts Foundation of New Zealand Whakamana Hiranga Icon Award (Q104629144).
significant event
Normal rank sexual assault
edit
sourcing circumstances
allegedly
subject has role
sex offender
has effect
restorative justice
has effect
withdrawal of an award
0 references
add reference


add value
I didn't include the reference that you can flesh out by using the CiteTool gadget in after enabling it in your preferences at https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-gadgets
Lovelano (talk) 00:27, 27 June 2024 (UTC)[reply]
Thank you. I would not have got there. I'm already a CiteTool user. Stuartyeates (talk) 07:57, 27 June 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2189705408"