Jump to content

Wikidata:Project chat

Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata

Edit

Latest label removals gone wrong?

Hi, @JnpoJuwan removed all 'Wikidata' labels from Wikidata (Q2013) and instead added a default label 'for all languages' (this is a new wikibase feature). In effect, only a few languages now have their own special label. I don't mind this but... my default language settings are Czech and I am now getting a Slovak label 'Wikiúdaje' as the item name on top of the Wikidata item page. Can this be customized so that the first preferred item label to display on top of the page is the 'default' version of the label? Vojtěch Dostál (talk) 19:54, 8 December 2024 (UTC)[reply]

@Vojtěch Dostál oh dear, that is something weird. I do not have enough experience in the technical aspects of Wikidata, so please ping other users who are more knowledgable. JnpoJuwan (talk) 20:46, 8 December 2024 (UTC)[reply]
Similarly, removing the English label from an American company like this made third-party reusers of the data showing raw Qids. Sure, they should perhaps update to fall back to mul, but I think it is reasonable to expect a label in the language of the item even if it is the same as mul. I suggest restoring all those labels (and always keeping one would help us track why the mul one was chosen). Ainali (talk) 09:33, 9 December 2024 (UTC)[reply]
The point of having "mul" is that we can save store space by not needing to save a label in every language. ChristianKl ❪✉❫ 15:20, 14 December 2024 (UTC)[reply]
I know. My point is that we should keep it in exactly one (1) language beyond mul, not every other label. That could still remove hundreds of labels. Ainali (talk) 21:07, 14 December 2024 (UTC)[reply]
MediaWiki fallback chains
The Slovak label is presented due to MediaWiki language fallback chains where Slovak and Czech fall back on each other and only after that to the default label (mul). To my understanding these are defined for the whole MediaWiki software and not specifically for Wikidata. In most cases this fallback makes sense (e.g. if there is no Czech label for a person who's native name is writen in non-Latin characters, it makes more sense to present the Slovak translitterated label than the non-Latin default label) but in some cases like with Wikidata (Q2013) it may lead to unwanted results. I think a simple solution for these rare cases would be the best: just add a Czech label "Wikidata" to override the Slovak label and maybe add a short comment to the talk page explaining the reason for this action. Samoasambia ✎ 21:06, 8 December 2024 (UTC)[reply]
@Samoasambia Yes, I thought it's something like that, but shouldn't we set the fallback in a way that it first falls back on the default mul label, and only then on the Slovak label? Vojtěch Dostál (talk) 08:31, 9 December 2024 (UTC)[reply]
That sounds problematic when two linked languages are much closer to each other than mul, say those with different alphabets to mul. I'm not sure they've thought about this, the chain idea was new to me. Vicarage (talk) 08:42, 9 December 2024 (UTC)[reply]
We discussed whether the mul fallback should come before or after the final, implicit en fallback (and decided that it should be mul before en – except for languages that explicitly fall back to en, such as en-gb), but I don’t remember if we even considered putting mul before the language’s explicit fallbacks… to me that sounds like a strange idea. If the mul label has to be overridden in Slovak, then clearly it’s not suitable for all languages (which is fine, that’s why it can be overridden) – why should Wikibase assume that Czech speakers would be better served by the mul label than by the Slovak label, when MediaWiki says that Czech messages should normally fall back to Slovak translations (and vice versa) before English?
In the case of Q2013, I think the Czech label should not have been removed: labels should only be removed in favor of mul if that doesn’t change the displayed label, and in this case it did cause a change. If the removal was done by a bot, I’d say the bot code has to take the fallback chains into account (available in the API, by the way), though in this case it looks like it was actually done manually. Lucas Werkmeister (WMDE) (talk) 10:44, 9 December 2024 (UTC)[reply]
@Lucas Werkmeister (WMDE) All right, that sounds like a long-term solution. Let's not remove labels if the fallback chains cause Wikidata to display a different string. Vojtěch Dostál (talk) 11:13, 9 December 2024 (UTC)[reply]

Don't remove labels, we don't have any consensus for doing so and breaks stuff. Multichill (talk) 21:23, 9 December 2024 (UTC)[reply]

@LiMrBot by @LiMr seems to be doing that too, perhaps a proper bot request should be started for that instead. Vojtěch Dostál (talk) 10:58, 10 December 2024 (UTC)[reply]
a proper bot would be very appreciated. if the unintended errors by mul are patched, please request that! JnpoJuwan (talk) 11:14, 10 December 2024 (UTC)[reply]
A proper bot, or just a proper discussion and policy on this in general, even if it changes again in the future. I expect currently many integrations and tools, and data reuse by data reusers will be broken if labels in know and or expected languages are removed in any mass way or at any speed. Not to mention the issues it has and will cause with bot, scripts and people adding data. And even more so as 99% of all other wikibases do not have this code yet. ·addshore· talk to me! 16:12, 10 December 2024 (UTC)[reply]
I would note though that labels were also mass-added in many instances by bots (for example, for disambiguation pages), and there is nothing wrong with removing those. stjn[ru] 00:33, 21 December 2024 (UTC)[reply]

SPARQL helper agent

Hello All,

A kind reminder, Stanford recently trained a new online agent to assist SPARQL creation. It translates user-submitted natural language questions into SPARQL queries and results from Wikidata.

It doesn't do much others things like generalist agents.

Still, as for SPARQL ist quite handy. Go try it out. Yug (talk) 10:27, 11 December 2024 (UTC)[reply]

Also, we currently advertise the query builder a lot. Maybe pointing to this agent would be more accessible for SPARQL beginners. Yug (talk) 10:27, 11 December 2024 (UTC)[reply]
Not bad, but adding labels would be more meaningful to this tool Bouzinac 💬●✒️●💛 17:42, 17 December 2024 (UTC)[reply]

statement „point in time“ with academic year

Dear all,
I would like to add Q131237471 to this former Rome Prize fellow's data object. He was a fellow in the academic year 1913/1914. At the time being, there is no way to add this kind of statement (year1/year2). I could add only 1913, but this would be not true. I added 2 qualifiers of „point in time“, but that's also not correct. Does anybody of you have a solution for this problem? -- Kaethe17 (Villa Massimo 24) (talk) 11:09, 11 December 2024 (UTC)[reply]

Use time period (P2348) for academic years, point in time (P585) can be used for the ceremony date. Sjoerd de Bruin (talk) 13:56, 11 December 2024 (UTC)[reply]
I just tried that, but the little black flag appears saying: „time period is not a valid qualifier for award received“. I understand that usually prizes are awarded at a defined point in time. This award, the Rome Prize (Q131237471), consists of being able to spend the academic year „year1/year2“ in Rome. Otherwise, there is no ceremony. So, should I still use time period (P2348)? Kaethe17 (Villa Massimo 24) (talk) 14:23, 11 December 2024 (UTC)[reply]
@Kaethe17 (Villa Massimo 24)
Generally, if you know when an event starts and stops, using start time (P580) and end time (P582) is better than using point in time (P585). point in time (P585) exists for those cases where you know that something was true at a specific time but don't know either the start time (P580) or end time (P582). ChristianKl ❪✉❫ 14:31, 14 December 2024 (UTC)[reply]
I'd use point in time (P585) if the precision I was quoting would otherwise have start time (P580) and end time (P582) being the same value, ie 1913-1913 Vicarage (talk) 14:35, 14 December 2024 (UTC)[reply]
Thank you, ChristianKl and Vicarage, that works. I'll now „just“ have to prepare detailed data (right month of start & end time, otherwise it'll be always January in the results.). If the Rome Prize is awarded for the single year n, I would use start time (P580) (month x of year n) and end time (P582) (month y of year n). --Kaethe17 (Villa Massimo 24) (talk) 17:20, 15 December 2024 (UTC)[reply]

How to quickly see items that are a subclass?

For example, when viewing or querying cannibalism (Q44595), it would show cannibalism in animals (Q908508) and cannibalism in Africa (Q124758790).

A way to conveniently and quickly (easily so even for people new to the site) items that are a subclass of the current item would be quite useful both for the Web UI and any queries like those of the Listeria bot. Maybe this is already possible or if not there already is a proposal somewhere to add such functionality. To be clear, I'm not referring to some search query or sparql query but when it comes to the Web UI either a button or something that can be expanded to load the items directly on the page with a click. Prototyperspective (talk) 11:29, 11 December 2024 (UTC)[reply]

Maybe this relateditems (Q102435390)? It's a gadget. RVA2869 (talk) 13:07, 11 December 2024 (UTC)[reply]
Thanks, however after enabling the gadget I don't see any button on the item pages. The documentation of the gadget consists of one sentence This gadget displays related items on an item page. so that's not helpful either. How to use it? Moreover, if that enables that it's still only a gadget but I think this would a be useful as a default functionality (e.g. also for people new to the site as a key way why Wikidata and its subclasses item organization can be useful). Prototyperspective (talk) 13:42, 11 December 2024 (UTC)[reply]
@Prototyperspective If you have it enabled, then a “show derived statements” button should appear at the bottom of the page. RVA2869 (talk) 14:44, 11 December 2024 (UTC)[reply]
Okay I've suspected it may be that but that button disappears when the page is loaded. I saw it a few times before it disappeared, maybe it's because of some other gadget that hides it. Prototyperspective (talk) 14:50, 11 December 2024 (UTC)[reply]
Now I see the button after disabling the WikidataComplete script. It's an interesting gadget but it doesn't show items that have [subclass of this item] set. Prototyperspective (talk) 14:55, 11 December 2024 (UTC)[reply]
M2k~dewiki (talk) 13:54, 12 December 2024 (UTC)[reply]
Thank you! The first link is a separate site but I'm looking for something that I can directly see in the item with just a click. It also seems to require specifying things so this isn't accessible, e.g. to people new to the site or not interested in a subject enough to spend a minute just to see some related items. (Btw it rotates and I don't know how to make it stand still.)
I can't use the tool of the second link and the its site of the third link is down.
The fourth link is interesting and probably a tool that's too unknown/underused but it doesn't show subclasses of this item but only the other way around. Same for fifth link (I'm looking for the other way around). Lastly for the sixth link it's the same tool and I'm looking for something that's accessible in the sense of directly integrated/able into the item page and seeable with one or two quick clicks. I was kind of surprised that this isn't yet possible on Wikidata given how you can navigate categories on Wikipedia and the mw:Extension:CategoryTree to see subclasses directly on the page without even leaving the page. Prototyperspective (talk) 16:08, 12 December 2024 (UTC)[reply]
I have something like that for a limited set of items with my User:Jean-Frédéric/ExLudo: on video game genre (Q659563) items, the subgenres are displayed, two-level deep (as defined via P279) − see File:Wikidata user-script ExLudo.js example - genres.png. You might be able to do something like that (but I guess for some things it would be a loooong list). Jean-Fred (talk) 15:48, 19 December 2024 (UTC)[reply]

Real property attribution to a person

Hello everyone!

Could you pls advise me which Wikidata property to use for real property attribution to a person? A person is in several sanctions lists. David Osipov (talk) 10:37, 12 December 2024 (UTC)[reply]

I'm having a little trouble understanding what you are asking. Could you give a more specific example? Bovlb (talk) 18:30, 12 December 2024 (UTC)[reply]
Sure, sorry. So, I've created Q131388164 this entry of a sanctioned by the US and other countries person. I was thinking of how to properly list his assets (real property) like an apartment, a car, plots. I've used Property:P1830 to indicated this, but it requires inverse statements, so it seems to a really good chose for my case. David Osipov (talk) 18:46, 12 December 2024 (UTC)[reply]
Yes, you should not be adding classes as things owned, as it is intended for individual items. For example, it's not true to say that they own Jeep Wrangler (Q1353305), as I believe they only own one instance of that class. Clearly we don't want to be reifying everyone's cars, so I don't think we have a good way to represent this kind of information.
Your original question got me thinking about how we handle "being on a sanctions list". I couldn't find anyone represented as being on Specially Designated Nationals and Blocked Persons List (Q15848109), for example. penalty (P1596) doesn't seem quite right for that, and there are probably all sorts of flavours of "being on the list". We do have OpenSanctions ID (P10632) which is probably a better way to pull in that information, as it is potentially very dynamic and nuanced Bovlb (talk) 19:06, 12 December 2024 (UTC)[reply]
It's interesting you mention that. I'm actually collaborating with OpenSanctions, and we've noticed that data from official sources isn't always accurate and can be slow to update. This is a good example of how local knowledge can be crucial. Because I know Georgian, I was able to research Kharazishvili beyond the initial US sanctions data. I found errors in his address, details about his car, three land plots (with their cadastral numbers and coordinates), and that he had sold his stake in a company before the sanctions. I even found details about his son and his personal ID number. All of this more complete information is now on Wikidata, but due to property limitations on the Wikidata side, they were only able to propagate a limited part of it.
How do we deal with this situation? Should I propose additional properties? David Osipov (talk) 21:03, 12 December 2024 (UTC)[reply]
You need to be careful in recording too much personal information for someone, even if they are a nasty piece of work. Recording a car number plate makes attacks easier. Now this might be the intention of some groups, but its not something WD can support. Vicarage (talk) 21:55, 12 December 2024 (UTC)[reply]
Sure, I'll be careful here, I'm just inputting info available to public. My stance is if someone violates human rights (this person even accepted it himself in live stream), he/she must be ready for a backlash. I accept I'm too biased here, because it's all happening in my country right now. David Osipov (talk) 07:22, 13 December 2024 (UTC)[reply]
See Wikidata:Living_people#Statements_that_may_violate_privacy, but even for the (in)famous, not anything goes, and WD does not want to attract the attention of their personal protection teams. Vicarage (talk) 08:00, 13 December 2024 (UTC)[reply]
Basically doXing someone with a history of violence under a full name, what could possibly go wrong, huh? Should you regret this, ask an administrator to hide specific revisions. Infrastruktur (talk) 20:27, 13 December 2024 (UTC)[reply]
You could propose a new property, but I predict that there won't be a lot of support for a "subject owns instance of class" property. Bovlb (talk) 23:06, 12 December 2024 (UTC)[reply]
Let me try :) David Osipov (talk) 07:22, 13 December 2024 (UTC)[reply]
We have a living people policy that discourages doxing people. Even when doxing oligarchs, lobbyists or other classes of problematic people can be a public good, out policies currently don't have expections for that. I think it would be possible to write an expection for people who are on official sanctions list or are Politically Exposed Persons into our living people policy but we currently do not have such a policy. ChristianKl ❪✉❫ 15:07, 14 December 2024 (UTC)[reply]

Why is Christianity low on the list when inputting "Christianity"?

This is a question about using the web interface with English set as the current language.

On any item, when I add the property religion or worldview (P140), if I type "Christianity" into the property value, I see the following list (in order) as suggested values:

  1. Methodism (Q33203)
  2. Reformed Christianity (Q101849)
  3. Presbyterianism (Q178169)
  4. Protestantism (Q23540)
  5. Christianity (Q5043)
  6. history of Christianity (Q235329)

Questions:

  1. Why is Christianity so far down the list? Is it because these other items are more commonly used for this property, or are more widely linked on Wikidata?
  2. Why are these other items shown at all? I would expect to see an alternative label in parentheses to the right of the primary label. Indeed, for the last item, history of Christianity (Q235329) I see "history of Christianity (Christianity history)". Yet I don't see an alternative label starting with "Christianity" for these first items, so why are they displayed when I type "Christianity"?

Daask (talk) 17:07, 12 December 2024 (UTC)[reply]

The way the completion list works is a bit of mystery to most of us, and I can never find any documentation on it.
You might get a better response by asking at Wikidata:Report a technical problem. Bovlb (talk) 19:10, 12 December 2024 (UTC)[reply]
@Daask I can't reproduce what you are describing. The suggestions you mention appear BEFORE anything is typed and they are suggested based on constraint provides suggestions for manual input (Q99460987) at Property:P140. After I type "Christianity", all these suggestions are replaced by search result suggestions. Vojtěch Dostál (talk) 06:21, 19 December 2024 (UTC)[reply]
@Vojtěch Dostál: Interesting. This isn't a fluke for me. I have consistently seen this same list in the same order for at least several months, if not years. Before I type in "Christianity", Methodism (Q33203) appears way down the list. I wonder what could be causing me to experience this and not you?
That said, I think you helped me figure out what is likely causing the problem. It seems the suggester lists all items for constraint provides suggestions for manual input (Q99460987) before other search results. That makes sense. Perhaps the suggester is somehow recognizing that those items in the constraint provides suggestions for manual input (Q99460987) list are related to Christianity (Q5043), even if "Christianity" isn't in their label, and therefore is including them in the suggestions list even if their label isn't otherwise a match. Daask (talk) 20:47, 19 December 2024 (UTC)[reply]

Wikimedia commons categories missing from Wikidata

I went to use https://commons.wikimedia.org/wiki/Category:Maps_of_Fort_Sumter and was surprised it didn't have a WD entry, so I created it, Category:Maps of Fort Sumter (Q131440644), but it seems generally that these minor commons categories aren't on WD, eg https://commons.wikimedia.org/wiki/Category:Postcards_of_Fort_Sumter. I was expecting them to be created automatically, even if needed people here to provide the category combines topics (P971) values of map and Fort Sumter (Q737517) so the latter could use it with category for maps or plans (P7867) (or more generally finding all related categories with category combines topics (P971) in a query)

I struggled to find Commons category statistics, but they had 7.3m categories 5 years ago, and we only have 5.5m Wikimedia category (Q4167836) here now, so there is a big gap.

Do these minor category entries really need to be created by hand? Vicarage (talk) 09:14, 14 December 2024 (UTC)[reply]

No, often they are not meant to be created at all, cf. WD:N #1.4: "Category items with a sitelink only to Wikimedia Commons are not permitted, unless either a) there is a corresponding main item which has a sitelink to a Commons gallery or b) the item is used in a Commons-related statement, such as category for pictures taken with this camera (P2033)." --Dorades (talk) 11:05, 14 December 2024 (UTC)[reply]
Thanks, I'll make sure when adding them there is a relevant category combines topics (P971) and category for maps or plans (P7867) pairing. Vicarage (talk) 12:49, 14 December 2024 (UTC)[reply]
I don't think that category combines topics (P971) and category for maps or plans (P7867) will make category items notable (except for the cases mentioned in WD:N #1.4 as quoted above). --Dorades (talk) 20:42, 14 December 2024 (UTC)[reply]
I thought that was exactly the 1.4 case. It replicates existing usage, we'll see if anyone challenges them. Vicarage (talk) 21:00, 14 December 2024 (UTC)[reply]

Add label in your language

I don't know if it's a good idea and how many people will read it, but add label in your language at and (Q12364761). Eurohunter (talk) 13:11, 14 December 2024 (UTC)[reply]

✓ Done (eo, fr) CasteloBrancomsg 17:45, 14 December 2024 (UTC)[reply]
Should this not be a lexeme instead of an item? RabbitFromMars (talk) 12:16, 16 December 2024 (UTC)[reply]
Ideally, there should be a Wikidata lexeme for every language. This item serves as "the meaning" for those lexemes. Notice that there are also some Wikipedia pages on the matter. --Matěj Suchánek (talk) 18:22, 16 December 2024 (UTC)[reply]
@RabbitFromMars: @Matěj Suchánek: There are articles in two languages and probably there could be a few redirects. Eurohunter (talk) 21:17, 17 December 2024 (UTC)[reply]

Q19629916

This item's VIAF ID seems refers to an unrelated modern person. GZWDer (talk) 17:41, 15 December 2024 (UTC)[reply]

Wikidata weekly summary #658

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2024-12-16. Missed the previous one? See issue #657

Discussions

  • New requests for permissions/Bot: PWSBot - Task(s): Is a selfmade chatbot to answer factual questions as part of a final research project for educational purposes.
  • Closed request for permissions/Bot: CarbonBot - Withdrawn by submitter

Events Upcoming events:

  • Next Linked Data for Libraries LD4 Wikidata Affinity Group session (Attn: Please fill out Pre-Participation Survey!) 17 December 2024: We have our next LD4 Wikidata Affinity Group Session on Tuesday, 17 December 2024 at 9 am PT / 12 pm ET / 17:00 UTC / 6 pm CET (Time zone converter) Wikimedian Mahir Morshed is leading a series of four sessions focused on lexicographical data in Wikidata. We are looking forward to learning more about these Wikibase entities! If you anticipate attending the workshop sessions, please fill out a brief survey linked from our Series Etherpad to help us prepare relevant materials for you. Sessions will be held on November 5, November 19, December 3, and December 17, 2024 at our regular time of 9am PT / 12pm ET / 17:00 UTC / 6pm CET. Event page
  • 2025 Wikimedia Hackathon - register now

Press, articles, blog posts, videos

Tool of the week

  • Tabular Online Validator - checks if SPARQL query results conform to a provided schema by validating data and highlighting potential errors, such as missing properties, invalid values, or too many values, with the option to refine the schema if issues arise. (A major update to the current ShEx validator that is expected to get integrated into the existing validator soon)
  • CAT🐈: Overview if references: looking at references for a set of Wikidata items

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • Wikibase REST API: We prototyped search support for the REST API and would like your feedback on it.
  • Property Suggestions: We updated the underlying data so you should have more up-to-date suggestions again when making new statements.
  • EntitySchemas: We continued the work on making it possible to search for EntitySchemas by their label and aliases when linking to them in a statement.
  • Query Service: We are investigating if we can do something about the issue where not all edgeLabels are shown on a graph visualisation (phab:T381857) and if there are any alternatives to the library used for the graph builder in the Query Service (phab:T381764)
  • Under the hood: We are optimizing the server setup for the term store to accommodate its growth (phab:T351802)

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

Number of episodes - Data bloat and vandalism

Related to Property:P1113 :

@Back ache: you updated the item https://www.wikidata.org/w/index.php?title=Q96410964&diff=prev&oldid=2287274954 - thank you!

@William Graham: you vandalized by removing the most accurate information https://www.wikidata.org/w/index.php?title=Q96410964&diff=prev&oldid=2287274954

And spammed old information into the item https://www.wikidata.org/w/index.php?title=Q96410964&diff=2287306926&oldid=2287282040 - do you plan to store 498 statements for "Number of episodes"? Number of episodes (talk) 18:46, 16 December 2024 (UTC)[reply]

@Number of episodes Good faith attempts to improve the project are not vandalism. You are a new account whose only edit so far is to come here and throw mud. You may have a reasonable point to make here, but this is not a good way to get support. Bovlb (talk) 19:42, 16 December 2024 (UTC)[reply]
@Bovlb My best guess is that @Number of episodes is a sock puppet of a LTA who is upset that I identified the last 5 or 6 of their sockpuppet accounts. See meta:User talk:EPIC#Question regarding block of User:Q131029980. The LTA has a pattern of creating throwaway accounts named after the topic they plan to edit/stir up drama over. The pattern in account name is repeated here. William Graham (talk) 00:52, 17 December 2024 (UTC)[reply]
And they're blocked, so I think we're done here. Bovlb (talk) 03:39, 17 December 2024 (UTC)[reply]

Google Knowledge Graph ID (P2671)

How to deal with existing Google Knowledge Graph ID (P2671) entries when changing the name 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?)

best --Herzi Pinki (talk) 19:32, 16 December 2024 (UTC)[reply]

AFAIK it's not connected to the names and should update at their side at some point. Sjoerd de Bruin (talk) 22:29, 16 December 2024 (UTC)[reply]
I changed the name 5 days ago [1], still Google Knowledge Graph ID (P2671) resolves to the old name. best --Herzi Pinki (talk) 15:13, 21 December 2024 (UTC)[reply]
We don't have any knowledge of how often Google updates their data, that is out of our reach. Sjoerd de Bruin (talk) 15:28, 21 December 2024 (UTC)[reply]

criminal mega gang (Q107974746)

I was recently reviewing "Tren de Aragua" (Q84959729) and noticed that the item "criminal mega gang" (Q107974746) was only being used, not "criminal organization" (Q1788992). It looks like the term "criminal mega gang" (Spanish: "megabanda criminal") is only directed towards international Venezuelan gangs.

After looking at some similar items, would "criminal mega gang" be more synonymous to the typical "criminal organization" (Q1788992) or would it be more similar to the item "mafia" (Q18550)? If it is synonymous with the former than the latter, should we merge the two items or delete the item "criminal mega gang" (Q107974746)? Thank you! WMrapids (talk) 21:38, 16 December 2024 (UTC)[reply]

Properties for Wikiversity pages

Is there any manual on which properites are recomended for Wikiversity pages? Juandev (talk) 12:01, 17 December 2024 (UTC)[reply]

Guidelines for duplicate images on items

Hi, I just saw a comment of @FDo64: on frwiki related to some problems of duplication on images on Infoboxes.

The problem seems to be that the same image is used in several images properties : the main one and some specific properties.

I remember we discussed the possibility to discriminate the kind of image through a qualifier of some generic image property as on option to avoid to deal with the complexity of multiple image kinds, but this is not what happened maybe unfortunately

datas
Qlever finds

The question is "have we guidelines to deal with this".

It seems from the previous example that there may be a cleanup to do anyway as people might not really notice the difference between logo image (P154) View with SQID and seal image (P158) View with SQID.

This is a preliminary discussion that we might want to promote to an RfC author  TomT0m / talk page 12:28, 17 December 2024 (UTC)[reply]

I know for age of sail warships, the only image we have of them is one of their design plans, so it common to have the same thing for image (P18) and image of design plans (P3311). Photographs are not available of course, and paintings have their own issues, so its better than nothing, and it would be clumsy to provide an different design image just get round a duplication issue. I expect this kind of thing is common across the board, and using COALESCE in the query to pick the best image is the way to go. Vicarage (talk) 13:04, 17 December 2024 (UTC)[reply]
I think this should be handled in infoboxes regardless of what we do in Wikidata. If someone wants to show a second image but only if it's different, then they shouldn't assume that the second image will always be different. - Nikki (talk) Nikki (talk) 09:12, 18 December 2024 (UTC)[reply]

Request for Feedback on Automating Human Lifespan Updates

I recently submitted a request for a bot to automate the process of updating human lifespans in our database, but it hasn’t received much feedback so far. I’m reaching out again to gather thoughts and suggestions from the community.

Currently, keeping human lifespans up-to-date is a tedious task, and many descriptions still don’t reflect the accurate lifespan of individuals after their passing. Automating this prevents mistakes during it manually and for us to flag and resolve discrepancies.

Additionally, I’d like to propose future data maintenance tasks that could further benefit the community (ideas are welcome!). However, for this to move forward, my bot flag request needs to be approved so I can submit further proposals.

Any feedback, suggestions, or support you can offer on this request is appreciated. Iamcarbon (talk) 20:50, 17 December 2024 (UTC)[reply]

nameGuzzlerOption.js

How to use nameGuzzlerOption.js? I don't see any button. Eurohunter (talk) 21:18, 17 December 2024 (UTC)[reply]

I can be found by the names:
  • VIP's-Labels (en)
  • Etiquetas VIP (es)
  • Libellé de VIP (fr)
  • VIP-Bezeichnungen (de)
in the left navigation; also see User:Jitrixis/nameGuzzler.js -> title M2k~dewiki (talk) 17:47, 18 December 2024 (UTC)[reply]
When click on the ...VIP... link you get a popup like in the screenshot at d:Q23727110 M2k~dewiki (talk) 17:49, 18 December 2024 (UTC)[reply]

The "JudaicaLink person (GND) ID" (Property:P13183) is placed at the end of the external ID section, but should be placed after "DDB person (GND) ID" (Property:P13049). Example: Q9554#P13183 - Q9554#P13049. Jousep Bernhard (talk) 01:42, 18 December 2024 (UTC)[reply]

@Bovlb could you adjust the placement? AFAICS the other GND-based IDs are all placed together, see the item for Martin Luther Q9554#P227, which has GND and then four derived ones. Jousep Bernhard (talk) 01:51, 18 December 2024 (UTC)[reply]
Hmm. According to MediaWiki:Wikibase-SortedProperties#VIAF_source_IDs_ordered_by_VIAF_code, "VIAF source IDs" should be "ordered by VIAF code". I'm not sure what the VIAF code is for any of these properties. Bovlb (talk) 05:58, 18 December 2024 (UTC)[reply]
@Bovlb Thank you for the information. "JudaicaLink person (GND) ID" is not a VIAF source ID. The VIAF source ID here is the GND ID, the placement of which should not be changed. "JudaicaLink person (GND) ID" is an ID re-using the GND ID. The GND-re-using IDs are placed after the GND ID sorted by PID.
The order there is:
__________________________________________________
# P227 (GND ID)
# P7902 (Deutsche Biographie (GND) ID)
# P1710 (Sächsische Biografie (GND) ID)
# P9964 (Kalliope-Verbund (GND) ID)
# P13049 (DDB person (GND) ID)
# P13183 (JudaicaLink person (GND) ID) // NEW
__________________________________________________
Jousep Bernhard (talk) 09:17, 18 December 2024 (UTC)[reply]
✓ Done Bovlb (talk) 16:51, 18 December 2024 (UTC)[reply]

Creating second statement with the same property and value but with different qualifiers

I've been using QuickStatements to add described by source (P1343) with pairs of URL (P2699) and title (P1476) qualifiers. But I can't use it to add a second described by source (P1343) with a different pair of qualifiers as you'd want if a subject is described at 2 places at the same source (eg the 2 sides of the Battle of Antietam (Q719252)). Help:QuickStatements#Limitations states it cannot 'add a second statement with the same property and value but with different qualifiers, since additional qualifiers will be added to the first statement'. Is there another way of doing this automatically? Vicarage (talk) 10:51, 18 December 2024 (UTC)[reply]

@Vicarage OpenRefine has three matching modes (https://openrefine.org/docs/manual/wikibase/schema-alignment#matching-strategy); perhaps one of them would be suitable for you? Vojtěch Dostál (talk) 06:14, 19 December 2024 (UTC)[reply]
Wikibase-CLI using the add-claim command in batch mode would be an option. Infrastruktur (talk) 19:28, 19 December 2024 (UTC)[reply]

Anachronisms. Sort of …

I created today a template on frwiki that generates a link to histropedia with all the items with articles on frwiki with "date" or "begin data" / end date". This gives links like these :

It's a bit slow for countries with a lot of articles like the USA, but it works (not all the time).

Anyway do we agree that items with "begin date" with a value beforre year -1000 like these one https://w.wiki/CTQg should definitively have no country (P17) View with SQID statement for sure and that we should mass remove them ? Maybe we could find another property to link geological entities to where they are relevant / found geographically now ? author  TomT0m / talk page 17:15, 18 December 2024 (UTC)[reply]

A good first step might be to deprecate the country statements with a reason for deprecated rank (P2241) with value contemporary constraint issue (Q74557669) or similar. Then create queries on those deprecated statements as part of a cleanup project. Can you link to some items that contain anachronistic statements so I can better understand your concerns? William Graham (talk) 18:46, 18 December 2024 (UTC)[reply]
@William Graham Just click on the query above or this one with labels, items with begin dates < -1000 and a "country" statement. For example Q17640515, a geological era 66 millions ago, with country (P17) View with SQID "France", which does not make any sense.
I'm not sure the deprecation step is needed as it seems mainly automated imports from enwiki as a source, from infoboxes, without checking, or anachronisms. author  TomT0m / talk page 20:00, 18 December 2024 (UTC)[reply]
I don't read French and the interface on that website is very confusing to me. William Graham (talk) 20:07, 18 December 2024 (UTC)[reply]
@William Graham The query is on the query service, I did not mean one of the queries I posted initially, there are links in my comments (the blue one).
Anyway, I translated one of a query with not a lot of items : timeline of articles on enwiki (by their titles) which are about north Korea or North Korea participated in I chose the country because there are not much articles, so it should be easier to understand (and the query is fast). Drag and drop to move the timeline before/after (or click on the arrow buttons). Zoom in/out (or click on the magnifier) on the with the mousewheel to change the scale and get more details about a period of time. More article should appear and the time scale should get shorter. The articles are prioritized, the more sitelinks their items have, the earlier they shows.
But it's not very convenient when there are articles with like "66 millions years ago" because the initial zooming is at a geological scale, so to get to relevant information you have to go to present time and zoom a lot, which can be indeed very confusing. The ticks "event category" on the left let you filter event types, a bit, guessed by the query. clicking on "event category" itself let you chose by type of sport, for sports events, instead. author  TomT0m / talk page 20:27, 18 December 2024 (UTC)[reply]
EDIT: Query corrected, sorry, made some typos when adapting to english correctly. author  TomT0m / talk page 20:30, 18 December 2024 (UTC)[reply]
Why not replace country (P17) with located in the present-day administrative territorial entity (P3842)? I had a long argument with people about Wikidata:Requests for comment/Current or contemporary location and country for events. I think country (P17) should have a strong contemporary constraint imposed, but its a huge task as its been so abused, and my opposition were intractable. Vicarage (talk) 22:40, 18 December 2024 (UTC)[reply]
Yes that should be a good solution in some cases. Not sure about the geological eras however, as this could mean "we can find rocks/sols created at the time on the country". author  TomT0m / talk page 15:07, 19 December 2024 (UTC)[reply]

Hej. I am looking for help to set an intervikilink between da:Sulfo ([2]) and en:Alkylbenzene sulfonate ([3]) and the for other sisters in wikipedia. Me attempts causes just fail and error. Best regards RAL1028 (talk) 17:38, 18 December 2024 (UTC)[reply]

It ought to be possible to merge these, but I note that one is a product (Q2424752) and the other structural class of chemical entities (Q47154513), and these sound like disjoint classes. Bovlb (talk) 18:23, 18 December 2024 (UTC)[reply]
That is the trouble: I don't get it, I can't fix it. --RAL1028 (talk) 20:15, 18 December 2024 (UTC)[reply]
A Wikipedia article can be linked only to a single Wikidata item at a time. So to enable interwiki linking, either alkylbenzene sulfonates (Q55095989) and Sulfo (Q12337666) would have to merged or alternatively sitelinks to redirects should be used. I added da:Alkylbenzensulfonat to alkylbenzene sulfonates (Q55095989), so now the other Wikipedias do link to the Danish Wikipedia (but not the other way around). Samoasambia ✎ 21:01, 18 December 2024 (UTC)[reply]

Could use some help setting up a schema

This is my first time setting up a schema within Wikidata and could use some help. It concerns Wikidata:Schema proposals/virtual tour I myself am not sure which properties I should add and which value/qualifiers I should use for certain properties. Through Wikidata:Requests for comment/Schema virtual tour, I have already tried to get help but without success for now. Could one of you help me create the schedule for the virtual tour? Brechtd (talk) 11:34, 19 December 2024 (UTC)[reply]

iTunes genre items

Hello, is Textbooks > Engineering > Computer Science (Q110593679) correct modelling suitable for Wikidata? From my point of view, this concept should just be merged to computer science (Q21198). Instances of iTunes Textbooks genre (Q110592261) do not belong to Wikidata, it's a bit as if we'd be making items for Amazon product categories. For example, we don't create items which are instance of 'Quota Topic', instead, we add the Quora topic ID (P3417) to normal items. Ping @Germartin1, creator of the item. Vojtěch Dostál (talk) 14:54, 19 December 2024 (UTC)[reply]

 Support. author  TomT0m / talk page 15:05, 19 December 2024 (UTC)[reply]
I don't see a reason for these types of items to exist. Ideally topics and genres would have sales platform agnostic items only of the last tuple (i.e. "computer science"). William Graham (talk) 15:42, 19 December 2024 (UTC)[reply]

Merge Sailor Moon video game pages

Hi, Sailor Moon (Q30314507) and list of Sailor Moon video games (Q291058) should be merged. They talk about the same thing. Edo999 (talk) 15:02, 19 December 2024 (UTC)[reply]

A topic (the Sailor Moon game series) and a Wikimedia list item (list of Sailor Moon video games) are distinct concepts. One item sitelinks to encyclopedic prose articles on the topic and the other item sitelinks to Wikipedia list pages. I don't think that they should be merged. William Graham (talk) 15:30, 19 December 2024 (UTC)[reply]

Penalty score

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]

Possible interaction restriction

Kind regards. Given previous and lengthy cross-wiki disputes between User:WMrapids and I, as well as interaction restrictions in some cases, I wanted to ask about the possibility about endorsing one here. Whether this would be voluntary or not, I don't know. Kind regards, NoonIcarus (talk) 19:27, 19 December 2024 (UTC)[reply]

I will agree to an interaction ban if this is possible. Apologies for the interaction on one of the items, I forgot that you had made it! WMrapids (talk) 03:53, 20 December 2024 (UTC)[reply]

Fallback language view

in the current Wikidata editor, fallbacks should be more obvious when viewed in editor mode. firstly, the fallback languages should be more easily accessible when viewing the page in other languages which fallback to it. take for example, viewing Wikidata in Brazilian Portuguese (pt-br): it by default fallbacks to Portuguese (pt), but the view it shows currently is:

  • Brazilian Portuguese
  • English
  • Translingual
  • (other languages with codes between a–p) ...
  • Portuguese
  • (other languages) ...

secondly, when a description or alias falls back to another language, it should likely be shown in grey (as currently happens for labels). without these, it makes it harder for multilingual editors to check what falls back to what and how to fix these. Juwan (talk) 14:56, 20 December 2024 (UTC)[reply]

Font for translingual text

the current font for the translingual (mul) labels and aliases does not match the defaults for a given user. I have all my defaults as Noto fonts and translingual shows up as a jarring Arial. some users have implemented some personal fixes but this should ideally be implemented globally. Juwan (talk) 14:59, 20 December 2024 (UTC)[reply]

Default values for non-Latin names

regarding the default values for all languages, how should names in non-Latin scripts be managed? currently, I have been setting the most common Latin transcription as the main label and other transcriptions and the original script as aliases. I am sure that other people may disagree, so I wish to ask for comment. Juwan (talk) 21:52, 20 December 2024 (UTC)[reply]

The help page says for people: "Use the name in native language and native script as the default value". Please do not add Latin transcriptions as mul labels for persons whose native language name is non-Latin. Samoasambia ✎ 22:19, 20 December 2024 (UTC)[reply]
@Samoasambia my mistake! I have overlooked that, I will correct that going forth. I assume that transcriptions should be fine in the alises, however, right? asking as you reverted those edits at Zhu Xi (Q9397). Juwan (talk) 22:26, 20 December 2024 (UTC)[reply]
I don't think we have any consensus about non-native mul aliases of people, and that's why I would avoid making any large changes for now. The only point of aliases is to help items to be found with different search queries, and for search it does not matter in which language the alias is in. Also, mass removal of non-mul labels is discouraged as it may cause some issues in some languages, see: this earlier discussion. Samoasambia ✎ 22:40, 20 December 2024 (UTC)[reply]
@Samoasambia I was part of the previous discussion, so I got familiar with that. for right now, I wish to gather more consensus on how to continue with the translingual values. as you have more knowledge than me, would you mind starting a larger discussion (or RFC) about this? cheers! Juwan (talk) 22:47, 20 December 2024 (UTC)[reply]
Since there will be minor differences in latin transcriptions would that not defeat the purpose of putting them in the mul aliases? Instead would it not be proper for each transcription to go to their language's aliases? Infrastruktur (talk) 23:20, 20 December 2024 (UTC)[reply]
@Infrastruktur transcriptions are supposed to be for the given language, not in any another language. the differences come from there existing different systems. pinyin and Wade-Giles are both transcription systems for Mandarin Chinese and both are commonly used (typically pinyin for newer subjects and WG for older ones). unless, you are suggesting adding Latin transcription to the Chinese fields. Juwan (talk) 23:41, 20 December 2024 (UTC)[reply]
I suggest adding transcriptions to the translingual fields as these may be more easily edited by others and trickle down to other languages automatically. so instead of having them all in the English field and many copies in other languages, they are stored more centrally.
to connect back to the start of this thread, if there was a consensus to add Latin script to the label, this would also permit using up less space for most languages using Latin script, as names are typically just transcribed and shared between langauges. Juwan (talk) 23:47, 20 December 2024 (UTC)[reply]
The current guidance seems to be slightly bad on this point. Only Latin languages have a uniformity between in them in how certain names are rendered. Even Cyrillic, which is mostly used in the former Soviet Union, has a lot of differences, especially for non-Russian names. It doesn’t make sense to tie this exclusively to native language/script, since for most of names in non-Latin languages, they are not going to be multi-language labels. stjn[ru] 00:36, 21 December 2024 (UTC)[reply]
 Agreed with this. Juwan (talk) 03:32, 21 December 2024 (UTC)[reply]

Luigi Mangione (Q131411648)

It's rather pointless to have an item about this person if editors keep statements related to the killing without explanation. Can we at least discuss it before removing statements? Trade (talk) 01:23, 21 December 2024 (UTC)[reply]

Most people will probably not read the talk page, only thing that helps is reverting or protecting the item. Sjoerd de Bruin (talk) 12:22, 21 December 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2290151839"