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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Edit

Kenneth Clark (Q371258)

[edit]

Our data for Kenneth Clark records his place of burial as the Church of St Peter and St Paul, Saltwood, Kent. I think this is entirely accurate but I cannot find a usable source to support the claim on Wikipedia. The only source I can find is the, unusable, Find A Grave. Do we have any further information on the source for the Wikidata statement? It's currently saying "no references". KJP1 (talk) 09:03, 2 January 2025 (UTC)[reply]

It was manually added by @Rouletteer here, perhaps they can indicate their source. Sjoerd de Bruin (talk) 11:27, 2 January 2025 (UTC)[reply]
@KJP1: Find-a-Grave should be usable on Wikipedia, given that there's an image [1] (and the gravestone describes him as "Art Historian", so there's no chance of confusion). Essentially you're citing the gravestone, with FG as a convenience link. (See also the various RS discussion for FG linked from en:Wikipedia:RSPFINDAGRAVE). Given that it's the local parish church for Saltwood Castle, there's no surprise about finding him there, either. If anyone pushes back, they're elevating rules-for-the-sake-of-rules over any assessment of actual reliability, contrary to WP:IAR. Jheald (talk) 13:50, 4 January 2025 (UTC)[reply]
Jheald - That's very helpful. I've always steered clear as it's classified as "generally unreliable", being user-driven, Wikipedia:RSPFINDAGRAVE, but I shall try it and see. Thanks and regards. KJP1 (talk) 13:57, 4 January 2025 (UTC)[reply]

Fediverse WikiData-Bridge-Bot API

[edit]

Hello,

I'm currently developing a social-Bot, which people on Mastodon can send SPARQL-queries to to retrieve data form Wikidata (https://se-bridge.org/). However, SPARQL-queries are too complicated for the average user. The newly-released SPINACH-bot could be of great help here.

The idea is that users can send natural language requests to the bot and the bot replies with the information. Also, the bot would be rate-limited and after a number of requests, the user would be requested to also send some knowledge, which is then send to the WikiData-API (which would benefit both Mastodon and WikiData).

Is there a way to access the SPINACH-bot through an API? Or another way? Bluebbberry123 (talk) 20:18, 2 January 2025 (UTC)[reply]

Honestly an easier way to solve the SPARQL issue would probably be just to give the damn thing an GUI. Just seems like common sense Trade (talk) 02:44, 5 January 2025 (UTC)[reply]

Date of announcement

[edit]

Which qualifier can be used to indicate that a given date of death is the date on which the death is announced in the news, but the date of death itself is not publicly known? I was thinking of a value for sourcing circumstances (P1480), but couldn't find one in the list of possible values. Dipsacus fullonum (talk) 22:55, 2 January 2025 (UTC)[reply]

These are examples with qualifier announcement date (P6949). So maybe like this: http://www.wikidata.org/entity/statement/Q65215757-9cad9486-41eb-ffb8-3323-afe50a18d74d - Difool (talk) 07:31, 3 January 2025 (UTC)[reply]
I asked about this due to the recent death of Cristóbal Ortega (Q1140491). Now date of death (P570) has the value 2 January 2025, but the source doest't say that, but only "América announced on January 2nd the passing of Cristóbal Ortega".
But it's clear from the context that the death just happened even though the exact date is not mentioned, so I don't think "unknown value" would be appropriate. I would prefer a qualifier that says that the date listed (2 January 2025) is the announcement date. Dipsacus fullonum (talk) 10:35, 3 January 2025 (UTC)[reply]
inferred from publication date (Q110393725), perhaps? M2Ys4U (talk) 11:55, 3 January 2025 (UTC)[reply]
Or alternatively "unknown value" with latest date (P1326) qualifier if we can assume the journalist was not a clairvoyant. Infrastruktur (talk) 16:00, 3 January 2025 (UTC)[reply]
What difference does make if the journalist was clairvoyant? They didn't write a date of death. Dipsacus fullonum (talk) 16:31, 3 January 2025 (UTC)[reply]

Penalty score

[edit]

Hi! How to specify the penalty score for a football match (Q268567, Q55659738)? Maybe we should suggest a new property for the score? Mitte27 (talk) 16:53, 19 December 2024 (UTC)[reply]

From Special:WhatLinksHere/Q2691960 I found Q55350317#P1363 where match interval (P6887) is a qualifier for points/goal scored by (P1363). For the score I found Q4597128#P1923 but I'm not sure about that as score method (P1443) only works as a qualifier for one of the number of points/goals/set scored (P1351) qualifiers, not for the participating team (P1923). Peter James (talk) 17:13, 19 December 2024 (UTC)[reply]
I think @Mitte27 has asked about the second usage, the score — unfortunately I think this example is not viable, because there score method (P1443) is a qualifier for Nigeria men's national football team (Q181930) and Cameroon men's national football team (Q175309) values, and not a qualifier for the number of points/goals/set scored (P1351) qualifier's second value. Well very well (talk) 11:49, 20 December 2024 (UTC)[reply]
Returned from archive. Well very well (talk) 03:06, 5 January 2025 (UTC)[reply]

Vocaloid modeling

[edit]

I was speaking with Moebeus about the subject and from the way he responded it didn't sounded like WD had any modeling in place on how to handle Vocaloid music.

Any suggestions how the items should be done?--Trade (talk) 04:50, 5 January 2025 (UTC)[reply]

Let's add some context: In a Vocaloid song there are at least four performers involved. The Vocaloid-P, the Vocaloid voicebank used to make the music and the character who represents the voicebank and the VA behind the voicebank itself. Question is how should these three entities be modeled into the item? --Trade (talk) 04:59, 5 January 2025 (UTC)[reply]
Since Vocaloid songs are performed by fictional characters, the characters themselves should be credited as the singers.(see Tell Your World EP (Q11250586).) Conversely, it would be incorrect to credit the voice actors as the performers, as they are not the ones actually singing; their voices are simply sampled to create the characters' vocals. Given that Vocaloid songs are often entirely written, composed, arranged, and produced by Vocaloid producers (Vocaloid-Ps), I believe they should also be credited as performers. Afaz (talk) 00:47, 6 January 2025 (UTC)[reply]
Where does the circle Livetune (Q859315) and the voice actors fit into this? Trade (talk) 01:29, 6 January 2025 (UTC)[reply]
"the characters themselves should be credited as the singers." But the character is not currently credited as the singer. The voicebank is. Trade (talk) 02:01, 6 January 2025 (UTC)[reply]
The Japanese interface shows Hatsune Miku (Q552682) as a fictional character, and p31 is also labeled as a fictional human (Q15632617). The voicebank is Hatsune Miku (Q112748598), which lists Saki Fujita (Q1066065) as the voice actor. I added Livetune (Q859315) as they were not credited as a performer. Afaz (talk) 04:33, 6 January 2025 (UTC)[reply]
Do you think we should use voice actor (P725) as a qualifier on performer? Trade (talk) 05:24, 6 January 2025 (UTC)[reply]
No, it’s not. This is because Saki Fujita (Q1066065) herself doesn’t sing the song. She is the voice provider for Hatsune Miku (Q552682), and that information is already recorded in the Q552682. Afaz (talk) 15:51, 6 January 2025 (UTC)[reply]
I made a few changes. Thoughts? Trade (talk) 09:46, 7 January 2025 (UTC)[reply]
I believe your change is incorrect. I don’t understand why we need to individually record the voice provider's data for each Vocaloid song. It should follow a format similar to existing databases like MusicBrainz. Afaz (talk) 00:33, 8 January 2025 (UTC)[reply]

Does this sound reasonable to you? @Moebeus:--Trade (talk) 02:29, 6 January 2025 (UTC)[reply]

I don't know the first thing about Vocaloid, all I have to offer is general advice like "look at how the streamers (Spotify, iTunes JP), large music databases like MusicBrainz, and speciality sites (vocadb.net ?) are doing it, and try not to reinvent the wheel". Oh, and not everyone involved belong in performer necessarily, contributor to the creative work or subject is your friend. Moebeus (talk) 14:23, 6 January 2025 (UTC)[reply]
Vocadb have a field dedicated to the vocaloid named "Vocalists". Just trying to figure out how to translate that to Wikidata Trade (talk) 09:45, 7 January 2025 (UTC)[reply]

"Participant in" (P1344) with a role

[edit]

Hello all. How do I specify the role of a "partcipant in" (P1344) for a sporting event? In this case an official at a world championship event who has the role of a "lacrosse onfield official" (Q131460158) in the context of that event. Is "subject has role" (P2868) OK or is there a better way? See the entry Q125984091 for an official who participated in the 2023 world championship as an example. Please forgive a newbie if this is a silly question. Gjblyth (talk) 20:11, 5 January 2025 (UTC)[reply]

Data Reuse Days: proposals welcome until January 12th

[edit]

Hello everyone,

As a reminder, we're welcoming proposals for the Data Reuse Days online event until January 12th. On the talk page you can already see a few interesting proposals from the Wikidata community and reusers.

We're especially looking for short presentations/demos of tools using Wikidata's data, in areas such as GLAM, civic tech, AI and LLMs, services and games.

If you have any questions or doubts before publishing a proposal, feel free to reach out to me. Lea Lacroix (WMDE) (talk) 07:44, 6 January 2025 (UTC)[reply]

Consensus has been reached to change the label for Q30 to "United States"

[edit]

The full discussion of Trying to get a consensus on English label for Q30 -- "United States of America" vs "United States" has been archived, so here's a quick summary and the results.

Summary

[edit]
  • Background: There has never been a consensus on "United States of America" or "United States" -- despite the visibility of the topic, the length of time it has been kept as "United States of America", the persistence of the reversions back to "United States of America", and the edict issued (without consensus) on the talk page.
  • Proposal: Change the label to the shorter and more commonly used "United States" over the "United States of America" on the basis that it overwhelmingly better follows Wikidata's general principles for labels:

Results

[edit]
  • Consensus has been reached to change the label for Q30 to "United States": after two weeks, from Dec 23 2024 to Jan 6 2025, eight members  Support changing the label to the original "United States" while two members  Oppose the change
  • Any other changes to the label, such as changing it again to "United States of America", should only be done after opening a new discussion for consensus. Otherwise the change will be being done without consensus.

Lorenmaxwell (talk) 12:05, 6 January 2025 (UTC)[reply]

Oldest human

[edit]

SPINACH Wikidata agent created this query in response to my question "who are the top 10 longest-living humans?" The query seems to be correct (the bot fails to create on in ca 4 of 5 cases) and it shows José Aguinelo dos Santos (Q18708565) as the oldest but according to Wikipedia and many sources it's Jeanne Calment. The Wikidata item values for age/birthdate/deathdate and role "oldest human" does not contain any qualifiers like disputed or that it's unconfirmed. I think something should be done. What do you think should be done (i.e. at or mainly at Q18708565)? Prototyperspective (talk) 16:34, 6 January 2025 (UTC)[reply]

Your query is vague "longest-living" could be interpreted as oldest living now, or longest who ever lived. Try asking 2 different and more explicit questions. Vicarage (talk) 16:39, 6 January 2025 (UTC)[reply]
It's intentionally vague as that's how humans ask things. The point in this tool is that it can answer such things despite of that. Moreover, you don't seem to have read the question which is about something different. Prototyperspective (talk) 16:52, 6 January 2025 (UTC)[reply]
To be clearer, this question is about d:Q18708565. Prototyperspective (talk) 16:53, 6 January 2025 (UTC)[reply]
Well, what is the question? Dipsacus fullonum (talk) 11:25, 7 January 2025 (UTC)[reply]
Could something be done at Q18708565 (what do you think would be the right thing to do there)? […] does not contain any qualifiers like disputed or that it's unconfirmed Prototyperspective (talk) 12:03, 7 January 2025 (UTC)[reply]
I don't understand what you mean. Why should something be done with that item? What is the problem? Dipsacus fullonum (talk) 12:10, 7 January 2025 (UTC)[reply]
I'm not going to repeat what I wrote in the original post. If you don't understand it even after my comments making it clearer, then please simply don't reply. Prototyperspective (talk) 12:18, 7 January 2025 (UTC)[reply]
Well, if you won't ask an understandable question, you won't get any answers. That's your loss. But if some SPARQL query doesn't give the desired result, then fix the query instead of talking about an item. Dipsacus fullonum (talk) 12:24, 7 January 2025 (UTC)[reply]
Q: Well, what is the question? A: Could something be done at Q18708565 (what do you think would be the right thing to do there)? [see what I previously wrote:] "[…] does not contain any qualifiers like disputed or that it's unconfirmed" Reply: Well, if you won't ask an understandable question -> obviously you still haven't gotten the point that I'm asking you to please refrain from putting a larger wall of text into this thread if you fail to not understand the very simple question. Thank you. Prototyperspective (talk) 15:16, 7 January 2025 (UTC)[reply]
You don't make yourself more understandable by repeating yourself. The literal but useless answer is "yes, something can be done at Q18708565". But you fail to explain why you want something done at the item, which precludes a useful answer. Dipsacus fullonum (talk) 15:46, 7 January 2025 (UTC)[reply]
This is the question of this thread. The whole point of why I'm asking here. I didn't think repeating things several times to an elementary level is needed so again I asked to please not comment if you fail to understand the question. Prototyperspective (talk) 16:53, 7 January 2025 (UTC)[reply]
Repeating an incomprehensible question is neither necessary nor desired. Instead, please explain yourself so that others can understand what you want. Dipsacus fullonum (talk) 17:34, 7 January 2025 (UTC)[reply]
Add sources or improve your query so it ignores Wikipedia-sourced statements. Sjoerd de Bruin (talk) 19:56, 7 January 2025 (UTC)[reply]
It is not about the query. I already said it's not about the query and the query doesn't use or show Wikipedia-sourced statements. Please don't remove the wrapper template I just added for no reason. Prototyperspective (talk) 19:58, 7 January 2025 (UTC)[reply]
It's disrespectful to others to just hide their comments based on your personal view. Sjoerd de Bruin (talk) 22:12, 7 January 2025 (UTC)[reply]
It's also disrespectful to ask for the question over and over putting a wall of text into a thread even after if the simple question has been rephrased; if you don't understand it that's fine. I don't think it's appropriate to remove the wrapper templates and now the discussion is derailed here even more.
Please stay on topic and so far the only thing that has been said in this wall of text that prevents more users from participating is Add sources (not detailed and not a lot). Please don't make this meta/discussion page useless in frequently adding lots of comments that don't relate to the thread topic, it will become futile to ask about anything here or coordinate anything as a community. Prototyperspective (talk) 23:07, 7 January 2025 (UTC)[reply]
I think the best-quality sources are in Portuguese. There is this in English. Just adding them may not capture that it appears to be disputed and/or not recognized and Jeanne Calment has no ref for 'oldest human' (contradictory) but 4 for year of birth & year of death. Prototyperspective (talk) 20:04, 7 January 2025 (UTC)[reply]
___
For other user seeking to participate in this thread: you don't need to read all of the above. It was questions about what I'm asking. What has been suggested so far by a user is adding sources to the relevant claims.
Here's another thing: Longevity claims#Past has lots of people but Wikidata only has an item with birth and death year for one of these (the one I've linked). Should anything be done there, like creating items for these people too if they don't already exist? Prototyperspective (talk) 23:14, 7 January 2025 (UTC)[reply]
Some already have birth and death dates (including Maria do Carmo Gerônimo (Q1421997) and Swami Kalyandev (Q7653194)) but only with Wikipedia as a source. They are not in the results because the query is for items with subject has role (P2868)=oldest human (Q254917) and they only have supercentenarian (Q1200828) and centenarian (Q2944360). Peter James (talk) 18:22, 8 January 2025 (UTC)[reply]
Ok thanks, it looked like it queried for the calculated age. I guess that should be replaced with instance of: human if anybody was to use or publish this query. If the query was adjusted to show all humans sorted by longest calculated age, it would still show all of these in the same way. This is not about the query but what should be done about the items (I thought it was just 1 item but apparently it's more). Do you have a suggestion other than merely adding sources to the claims? I think they may also need the disputed qualifier for instance. Prototyperspective (talk) 19:18, 8 January 2025 (UTC)[reply]
The thing that should be done is to research sources. If you find sources that disagree we have statement disputed by (P1310) for that. Depending on the available sources, disputed claims can be deprecated. ChristianKl ❪✉❫ 01:25, 9 January 2025 (UTC)[reply]
Thanks, that's all I wanted to know and if there are no other proposals about what to do soon, I think this thread could be marked as solved and archived. However, at least any time soon I'm not going to do what you described so this is also serving as a way to raise awareness about this so somebody else may do something (ie add sources and disputed by claims) to these items. Those sources may already be in the Wikipedia articles (maybe at some point there could be a more automatic addition of sources from the linked Wikipedia article albeit Longevity claims#Past wouldn't be among them and the main location of these). Prototyperspective (talk) 09:24, 9 January 2025 (UTC)[reply]
sourcing circumstances (P1480)=allegedly (Q32188232) is also a useful qualifier for longevity claims. Peter James (talk) 02:27, 10 January 2025 (UTC)[reply]
You can also look at the pages of alleged supercentenarian (Q106991708) how they deprecated statements Difool (talk) 13:34, 10 January 2025 (UTC)[reply]

Wikidata weekly summary #661

[edit]
Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2025-01-06. Missed the previous one? See issue #660

Discussions

Upcoming events

  • Workshop: Lexicography and linguistic sustainability - Mirandese documentation using Wikidata This Portuguese-language workshop takes place Thursday 16 January, 10:00 - 17:00, Room 208, 206 at the Faculty of Letters of the University of Porto.
  • Please submit your proposals for the Data Reuse Days online event until January 12th. See current proposals on the talk page and here's some ideas to inspire you: presentations/demos of tools using Wikidata's data (10mins Lightning Talk presentations), discussions and presentations connecting Wikidata editors with reusers and/or explanations and demos on how to use a specific part of the technical infrastructure to reuse Wikidata's data (APIs, dumps, etc.).
  • Talk to the Search Platform / Query Service Team --January 8, 2025. The Search Platform Team holds monthly meetings to discuss anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CET
  • The next Wikidata+Wikibase office hours will take place on Wednesday, 17:00 UTC, 15th January 2025 (18:00 Berlin time) 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.
  • Wiki Workshop 2025 Announcement and Call for Papers. Submission deadline: March 9, 2025 (23:59 AoE)

Press, articles, blog posts, videos

  • Blogs: (fr) female authors with male pseudonyms, blog post by Le Deuxième Texte including SPARQL queries to find female authors with male pseudonyms.
  • Websites :Global Dementia and Risk Factors, website by 'Students at the Maastricht Science Programme', includes data visualizations of the prevalence and current treatments of dementia across the world. It utilises data extracted as SPARQL Endpoints from Wikidata.
  • Papers
    • Ontology-grounded Automatic Knowledge Graph Construction by LLM under Wikidata schema - This paper proposes an ontology-driven approach to KG construction using LLMs where competency questions guide ontology creation and relation extraction, leveraging Wikidata for semantic consistency. A scalable pipeline minimizes human effort while producing high-quality, interpretable KGs interoperable with Wikidata for knowledge base expansion. By Xiaohan Feng, Xixin Wu & Helen Meng (2024).
    • Knowledge Incorporated Image Question Answering Using Wikidata Repository - Proposes a Visual Question Answering (VQA) model that integrates external knowledge from Wikidata to address complex open-domain questions by combining image, question, and knowledge modalities. Evaluated on the VQAv2 dataset, the model outperforms prior state-of-the-art approaches, demonstrating improved reasoning and accuracy (Koshti et al., 2024).
  • Videos: (arabic) Part 6: SPARQL Demo Session: connecting external services - Sparql SERVICE clause gives access to additional data such as labels via wikibase:label, interaction with MediaWiki APIs using wikibase:mwapi, and integration of data from subgraphs (such as the main graph and the scholarly articles graph). Integration of data from external SPARQL endpoints such as DBpedia.

Tool of the week

  • Wikidata Entity Linker - is a Microsoft Edge browser extension that creates web links for matching inner HTML text based on a regex format of Q\d+ which is the format of a Wikidata Entity ID. (email)

Other Noteworthy Stuff

  • Vacancy: Research Software Engineer / Wikibase-Expert - The Technische Informationsbibliothek (TIB) located in Hannover has a research position open for someone interested in the deployment, administration and maintenance of open source knowledge management software such as Mediawiki, Wikibase and OpenRefine as part of the NFDI4Culture partnership within the OSL.
  • January 1, 2025, marked Public Domain Day, with hundreds of 1929 films entering the public domain. Sandra has shared helpful notes to assist in making these films discoverable via WikiFlix, by adding video files to Wikicommons and Wikidata. Join the effort!

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • The development team is just settling back in after the holidays, so there haven’t been any significant updates yet.

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

General relationship to Wikipedias, tagging for the renderer?

[edit]

During the discussion on Wikidata:Requests for comment/Constraints for Germanies, one side argued about the needs of "their" Wikipedia, while others claimed such measures to be tagging for the renderer, which then was declared "not a policy on Wikidata". Then there's things like string not for label in WikiProject (Q105690472), used to explicitly exclude statements for usage in a Wikipedia and string for label in WikiProject (Q105690470) for the opposite. Since I'm not that experienced in Wikidata, I would like to know more about the general mindset/attitude about this: Is Wikidata just a service for the Wikipedias or is this supposed to be an "independent" project of it's own? Is there any documentation about these kinds of things, maybe also about NPOV, conflict resolution etc.?

Please forgive me, if this is written tendentiously. I really was under the impression, that things like official names of countries or League of Nation memberships would be objective criteria, and therefore I am still a bit amazed, that this created such a conflict. --Flominator (talk) 19:55, 8 January 2025 (UTC)[reply]

Wikidata was started with a key role as being a backend of facts for the infoboxes of Wikipedias, though in practice the editors of the latter are distrustful of outside projects, and takeup has been very slow. WD has grown to be a database of facts used much more widely than the Wikipedia ecosystem, though clearly its quality and comprehensiveness, while better than any rival, has big gaps. Those facts need to be globally accepted, but are still aimed at a early 21st century audience. There seems to be a lot fewer procedures (and less nitpicking) here, partly because facts are less contentious than descriptive text, and with fewer editors and a vast workspace, conflicts are rarer. But as we've seen for the Germanies, its not the facts that are a problem, as the wooly nature of labels like "country", where POV will be an issue. Vicarage (talk) 20:06, 8 January 2025 (UTC)[reply]
The answer is on WD:N, Wikidata is its own project, which means it can have objectives that goes beyond the sole objective of being a Wikipedia backend and has its own policies. But of course serving Wikipedias is one of its main reason for being and admissibility on Wikipedia is a sufficient reason for admissibility on WD of course.
Wikidata has ways to handle conflicting viewpoints by allowing to set different statements with their own sources and ways to describe the disputes, like statement disputed by (P1310) View with SQID or statement supported by (P3680) View with SQID, for example. author  TomT0m / talk page 10:56, 9 January 2025 (UTC)[reply]

Announcement of Request for Comment from WikiProject Personal Pronouns

[edit]

In response to feedback to our previous, now-deprecated proposal in an archived version of Project Chat, WikiProject Personal Pronouns has posted a Request for Comment. This RFC includes our proposed approach to best practices, consistent data modeling, and data cleanup for personal pronouns in Wikidata. We haven't done an RFC before, so if we need to announce this or post about it elsewhere, would someone kindly let us know about the norms or process? --Crystal Yragui, University of Washington Libraries (talk) 21:58, 8 January 2025 (UTC)[reply]

It's generally useful to have some discussions before writing a formal RfC, so that you have a good policy proposal when you open an RfC that can then find approval. One of the issues, I pointed out over there is that Wikibase has no feature to change the datatype from item to lexeme. Datatype changes that go beyond exchanging string and external ID (which are both strings in the database) have never been done in Wikidata's history.
From looking at the issue myself, it seems that a key problem is that there are different kinds of pronouns. Maybe we should have one property for "subjective pronoun" (he,she,they) and another property for (objective pronoun) "him, her, them". Practically, the way to do that would with the problem of mixing different kinds pronouns together in the existing property. ChristianKl ❪✉❫ 17:13, 9 January 2025 (UTC)[reply]
@ChristianKl, Clements.UWLib: The new proposal seems well thought-out to me. They are no longer proposing a datatype change, so perhaps you were reading the wrong page? In any case given this is now an RFC we should probably comment at least on the talk page there now. ArthurPSmith (talk) 20:46, 9 January 2025 (UTC)[reply]

Confused about P31 and P131 for English villages in parishes of same name

[edit]

In England, there are many villages within a parish of the same name.

For example, item Great Bedwyn has P31 (instance of) statements as a village and a civil parish.

  • The complexity is that 'Great Bedwyn village' (GSS code E63005235) is only a subset of the 'Great Bedwyn civil parish' (GSS code E04011723).
  • Item Tottenham House is within 'Great Bedwyn civil parish', but not 'Great Bedwyn village'.
  • Similarly, items Crofton Pumping Station and Crofton Locks are in the hamlet of Crofton which is in the 'Great Bedwyn civil parish' but not the 'Great Bedwyn village'.
    • Crofton hamlet has a wikipedia redirect page, but this does not have an associated wikidata identifier
  • Alternatively, St Mary's Church is within 'Great Bedwyn village' and so also 'Great Bedwyn civil parish'
  • Is it possible to accurately describe the relationships above using a P131 statement with a suitable qualifier?
  • I would presume that the only way to accurately describe the relationships is to have a separate wikidata item for 'Great Bedwyn village' and 'Great Bedwyn civil parish', but would this also mean that separate Wikipedia pages would be needed (even if one was a redirect page etc)

MrTAP (talk) 12:21, 9 January 2025 (UTC)[reply]

I'd agree that we should not be conflating two different entities in one Wikidata item, no matter how closely related, although that rule is often broken. You don't absolutely need a (redirect) Wikipedia page. If this division splits the sitelinks into two groups (because some articles are about the village and others about the parish, then you might want to look into Template:Interwiki extra (Q21286810), which would let you retain the whole list of interwiki links on the Wikipedia article. Bovlb (talk) 15:54, 9 January 2025 (UTC)[reply]
Most parishes are not separate items, or if separate items exist are claimed to be instances of Wikimedia duplicated page (Q17362920). There are a few exceptions such as Stanhope (Q428342)/Stanhope (Q24665841), a large parish with separate Commons categories for village and parish. It's the same for places in many countries; in some the terms for the administrative areas are translated to "village". There is Great Bedwyn (Q24668528) but it is mostly not used; Q995623 is used instead. There is also Crofton (Q21697119); I added a link to the redirect. Peter James (talk) 02:13, 10 January 2025 (UTC)[reply]

Wesley Everest Gravesite (Q131705307)

[edit]

I am trying to avoid an edit war with Peaceray here, but I think he is dead wrong. The only rationale I can see for this edit is if we were to stop using interwiki links to Commons categories at all; I believe we have well over a million of these, and the bulk of them also use Commons category (P373), so it is not considered an unacceptable redundancy. If something else is going on here, I leave it to him to explain what he is up to. It does look like I accidentally created a second instance of P373 here with the same value he had already added, and of course I would have no problem with reverting that actual duplication. - Jmabel (talk) 21:57, 9 January 2025 (UTC)[reply]

It would rather be the inverse in the feature, no more statements and only sitelinks. This doesn't seem to indicate any consensus, i'm not aware of any decision and this could break user scripts, queries and other things. Sjoerd de Bruin (talk) 22:25, 9 January 2025 (UTC)[reply]
It looks like a mistake, as the summary mentions "removing duplicate value". Peter James (talk) 00:00, 10 January 2025 (UTC)[reply]
Hi Jmabel, I think we have a misunderstanding here.
  1. With this edit, I inserted the value of Grave of Wesley Everest for the Commons category (P373) property of Wesley Everest Gravesite (Q131705307)
  2. With this edit, Jmabel inserted a duplicate value of Grave of Wesley Everest for the Commons category (P373) property of Wesley Everest Gravesite (Q131705307)
  3. With this edit, I reverted the duplicate value that Jmabel inserted with this edit summary: Undo revision 2296371805 by Jmabel (talk): User:Jmabel : removing duplicate value as initial value was added with https://www.wikidata.org/w/index.php?title=Q131705307&diff=2296278372&oldid=2296278263&diffmode=source. That URL linked back to edit #1 in this comment.
  4. I am unsure what Peter James was doing with this edit (edit summary: Undo revision 2296372086 by Jmabel (talk)) then this edit (edit summary Undo revision 2296559840 by Peaceray (talk)), but we do seem to be back at the original value of the property, or as {{Data|item=Q131705307|property=P373}} returns, Grave of Wesley Everest.
Now as to Jmabels point, I am in absolute agreement with the reality that Wikidata is the home for interwiki links, which is why I inserted the value for Commons category (P373) in the first place.
Perhaps some of the confusion came from the Commons side of things. Here is my current sequence of editing on Commons & Wikidata regarding creating categories.
  1. I create a new category on Commons.
  2. I create the link to the Commons Category on the corresponding Wikidata item.
  3. I add {{Wikidata infobox|qid=<value>}} to the category even though I know that is will soon not be needed (and that ArndBot will eventually come along & remove the QID) for the following reasons.
    1. Instant gratification
    2. There is a considerable lag to the linkage, & I do not like having a page that I saved showing errors, even if it is only a matter of hours.
    3. In some instances, as a visual justification for other editors, who may wonder why I am creating a category for a single image, such as for Mary Olson Farm.
Just to be clear, my insert of the value for the Commons Category on Wikidata item Wesley Everest Gravesite (Q131705307) occurred at 2025-01-08T18:52:06 & my insertion of the Wikidata Infobox at Grave of Wesley Everest occurred at 2025-01-08T21:33:54, at which time the iterwiki link lag had not subsided.
I hope this clarifies matters. Peaceray (talk) 05:41, 10 January 2025 (UTC)[reply]
@Peaceray: There is no lag on the Commons side if you make an interwiki link on Wikidata (not just a property) point to the Commons category.
You may well have intended your edit to remove my accidental duplicate of the Commons category (P373), but what you removed was the interwiki link. - Jmabel (talk) 06:18, 10 January 2025 (UTC)[reply]
Oh. Sorry about that. I see my error. Mea culpa. I will note that I remember that it did seem to remove the 2nd value from the Commons category property when I viewed it afterward.
One further thing though, I do see Mike Peel's Pi bot does create the interwiki link on a Wikidata item based on the QID in the Commons Wikidata infobox, as with its edit on Bernardine Szold Fritz (Q131492006).
Going forward, I will endeavor to add the Multilingual sites – commons interwiki link at the same time as I am adding the Commons category. Peaceray (talk) 06:46, 10 January 2025 (UTC)[reply]

Google Knowledge Graph ID (P2671) again

[edit]

Former disk: [2], Pinging @Sjoerddebruin, Lockal:

Question was:

How to deal with existing Google Knowledge Graph ID (P2671) entries when changing the name / label of an item? It seems to me that the Google Knowledge Graph ID (P2671) link has the name of the item encoded and does not work any more when the name is changed.

  • do not care (a bot will come along and fix it)
  • delete it
  • fix it (but how?)

By the very construction of the value for Google Knowledge Graph ID (P2671) (To find the Google Knowledge Graph ID, open the page source and search for "/g/XXXX" where XXXXX is the numeric part of the ID. Alternatively, use the share functionality in the sidebar to generate a g.co/kgs/XXXXX short URL, open it and copy the kgmid= parameter from the resulting full URL.) and because the Qid is not present neither in the search string nor in the search results, I think that these links will get stalled as soon as a (wrong) label is changed to another (correct) value. In my case the value of Google Knowledge Graph ID (P2671) was added by User:Lockalbot, who is not active since 2021. BTW, I have no idea how this will work with multilingual labels.

Google Knowledge Graph ID (P2671) needs proper update or deletion, when labels change. This will not work manually (nobody will care, fixing manually is quite tedious).

So how to proceed?

  • Find a bot who cares and updates / deletes after label changes
  • rethink Google Knowledge Graph ID (P2671) and delete it (google search is always an alternative, no lock-in to google search).
  • deprecate label changes, instead create new items

best --Herzi Pinki (talk) 11:02, 10 January 2025 (UTC)[reply]

What item are we talking about? The Machine-Readable Entity IDs resolver could be helpful with this case. Sjoerd de Bruin (talk) 11:11, 10 January 2025 (UTC)[reply]
Huggachköpfe (Q21868106) and this diff: [3]. --Herzi Pinki (talk) 13:06, 10 January 2025 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2296710310"