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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

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

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

For realtime chat rooms about Wikidata, see Wikidata:IRC.
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]

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]

Leap years gregorian dates before Christus

[edit]

Hi, I wanted to type in "29 feb 1437 before christus"^gregorian calendar there https://www.wikidata.org/wiki/Q4115189#P585 It keeps only with 1st march -1437. Is it a bug or am I wrong? (there is no year 0 and if I follow this logic https://astro101.wwu.edu/a101_leapyear.html#:~:text=Leap%20years%20were%20therefore%2045,out%20of%20every%20four%20centuries 1437BC would be a leap year) ? Bouzinac💬✒️💛 07:42, 16 June 2024 (UTC)[reply]

Qualifiers for Indicating Orthography

[edit]

Hi, is there any property to be used as a qualifier for indicating orthographic usage distinctions?

For example, the name of Meinohama (Q11447357) has historical kana orthography (Q1142552) めひのはま and modern kana usage (Q2572881) めいのはま; currently, this is expressed as applies to part (P518)historical kana orthography (Q1142552) and applies to part (P518)modern kana usage (Q2572881) qualifiers for the respective name in kana (P1814) statements. I’d expect there to be a more fitting qualifier than applies to part (P518).

This issue isn’t necessarily specific to Japanese; there are several languages where orthographic conventions have changed over time. In German, for example, some spelling rules (primarily regarding the use of ß vs. ss) were changed some 20–25 years ago (though I don’t know whether there are any items here where both a traditional and a new spelling are represented) and I’ve heard there has been something similar in Danish (regarding aa vs. å). I don’t know whether Norwegian (nynorsk/bokmål) or Greek (dimotiki/katharevousa) are comparable as well. --Data Consolidation Officer (talk) 12:07, 16 June 2024 (UTC)[reply]

I don't know about qualifiers, but for German, if you need to explicitly state that something uses pre-reform orthography, monolingual text statements can use the language code de-1901. For Norwegian, Bokmål is nb and Nynorsk is nn, we don't normally use no. - Nikki (talk) 10:34, 17 June 2024 (UTC)[reply]

list of headers (beta)

[edit]

Tool "list of headers (beta)" is not able to recognise few new language codes like igl, kus, bew and dtp. It also can't recognise language codes like dga, gpe, fat, gur, pcm, fon, guw and blk. All these languages are recognised by released version of tool. Who could fix it? Eurohunter (talk) 12:13, 16 June 2024 (UTC)[reply]

List of all language codes

[edit]

Is there a list of all language codes on Wikidata? I remember there was such a list, but I forgot the name. Eurohunter (talk) 13:27, 16 June 2024 (UTC)[reply]

Since you mentioned tools in the thread above I'm going to assume you specifically want the Wikimedia language codes and not any other code such as ISO 639 ones. To get a guaranteed up to date list of the languages you have to use the API: https://www.wikidata.org/w/api.php?action=query&format=json&meta=languageinfo&formatversion=2&liprop=code%7Cautonym%7Cname Recommend caching that for 24 hours in your tool as the data doesn't change often. Infrastruktur (talk) 14:06, 16 June 2024 (UTC)[reply]
Also see for example:
which returns a list of unconnected articles per language version. M2k~dewiki (talk) 16:57, 16 June 2024 (UTC)[reply]
Wikidata:Project chat/Archive/2024/02#h-List of codes of languages-20240217180000. --Matěj Suchánek (talk) 18:14, 16 June 2024 (UTC)[reply]
@Infrastruktur:, @M2k~dewiki:, @Matěj Suchánek: I'm pretty sure there was another well-formated list of all language codes summed in table at Wikidata or Wikimedia similar to this list. Eurohunter (talk) 21:04, 16 June 2024 (UTC)[reply]
There is Special:SiteMatrix too, but not all languages have wikis. And not all languages are listed e.g. Bokmål (Q25167). Infrastruktur (talk) 21:09, 16 June 2024 (UTC)[reply]
What do you actually want, language code statements on items for languages, languages which have a Wikimedia project, languages with an interface translation, languages supported by Wikidata for labels (or for monolingual text or lexemes, which are separate lists), or something else? - Nikki (talk) 10:12, 17 June 2024 (UTC)[reply]
@Nikki: @Infrastruktur: I remember there was a simple list of all possible Wikidata language codes, including Serbian latin (sr-el) or Serbian cyrylic (sr-ec) etc. Eurohunter (talk) 17:21, 17 June 2024 (UTC)[reply]

Wikidata - ongoing automated

[edit]

Does Wikidata have functionality to allow synching of databases similar to EDI and automated interfaces,

The functionality I am used to is that there is

  • At Origin : a trigger job waiting for a change, and creates a change
  • Data cleansing - rules, error handling
  • Mapping- a mapping tool of Origin to Target, reuse of maps from the same system, mapping version, envelopes with sequence numbers,
  • Transmission - path, passwords, encryption, confirmation of receipt, checksums
  • At Target - transmission triggers upload into target, error checking
  • Error checking that database matches

Wakelamp (talk) 03:22, 17 June 2024 (UTC)[reply]

Weekly Summary #632

[edit]

Steam Deck unsupported games

[edit]

Are you ok with if I started adding unsupported (Q117413406) to Steam games?

I need a tool or something that will help me to not see unsupported Steam Deck games in this query:

https://query.wikidata.org/querybuilder/?uselang=en&query=%7B%22conditions%22%3A%5B%7B%22propertyId%22%3A%22P1733%22%2C%22propertyDataType%22%3A%22external-id%22%2C%22propertyValueRelation%22%3A%22regardless-of-value%22%2C%22referenceRelation%22%3A%22regardless%22%2C%22value%22%3A%22%22%2C%22subclasses%22%3Afalse%2C%22conditionRelation%22%3Anull%2C%22negate%22%3Afalse%7D%2C%7B%22propertyId%22%3A%22P8956%22%2C%22propertyDataType%22%3A%22wikibase-item%22%2C%22propertyValueRelation%22%3A%22regardless-of-value%22%2C%22referenceRelation%22%3A%22regardless%22%2C%22value%22%3A%22%22%2C%22subclasses%22%3Atrue%2C%22conditionRelation%22%3A%22and%22%2C%22negate%22%3Atrue%7D%5D%2C%22limit%22%3A100%2C%22useLimit%22%3Atrue%2C%22omitLabels%22%3Afalse%7D

If this is ok, then I'd also add to my query and without compatible with matching unsupported (Q117413406). Now about games that don't feature a Steam Deck tag at all on their steam page, I don't know how I would deal with that. Tips welcome. SuperUltraHardCoreGamer (talk) 20:37, 17 June 2024 (UTC)[reply]

What Wikidata property are you using? — Martin (MSGJ · talk) 21:14, 17 June 2024 (UTC)[reply]
I'm not using a value in my query, although I figure that I need to use the Steam Deck (Q107542665) value and then also add a qualifier, but I don't know if the Query Builder supports qualifiers. SuperUltraHardCoreGamer (talk) 21:19, 17 June 2024 (UTC)[reply]
It sounds like you want to use compatible with (P8956) property to indicate a game is not compatible with some hardware. That seems like a very poor model. William Graham (talk) 21:17, 17 June 2024 (UTC)[reply]
Well, do you consider yourself an expert in the field? I need all the help I can get. You own perhaps a Nintendo Switch, Steam Deck, a lot of similar hardware? SuperUltraHardCoreGamer (talk) 21:20, 17 June 2024 (UTC)[reply]
If my guess of your intended modeling is correct (you still haven't explained it well), then that it would create a situation where people doing a basic query for compatible with some hardware (i.e. Steam Deck) would get a bunch of values that weren't compatible -- the exact opposite of what they were querying for. William Graham (talk) 21:27, 17 June 2024 (UTC)[reply]
I don't understand what you are saying but I'm here to edit and contribute. I think that's what I'm doing. I'm taking from your response you wouldn't like "unsupported" being added so I'll refrain from that. Hope this is what you want. I got what I wanted from my interaction with you and thank you for providing a response. SuperUltraHardCoreGamer (talk) 10:29, 18 June 2024 (UTC)[reply]
being an expert here has very little to do with owning a console. BrokenSegue (talk) 02:41, 18 June 2024 (UTC)[reply]
Yes, I realized the error of my argument. I think that I will continue with more edits and less talking. My final conclusion is that the topic of whether unsupported (Q117413406) should be added or not, there is no easy solution to that. Perhaps even the existence of the Steam Deck rating system itself is seen as problematic. I am thankful that I got a better idea about whether to add unsupported or not to items. I think at this stage adding them, an editor would have to be very sure about what they are doing. I'll continue with adding playable and verified to games and I will not add unsupported games to any item and I hope that this is considered a contribution. I still feel welcome to edit here. If someone would still like to discuss anything please do so only if you think it will help me to improve things. SuperUltraHardCoreGamer (talk) 10:41, 18 June 2024 (UTC)[reply]
applsdev Arlo Barnes BugWarp Coloradohusky CptViraj Cupkake4Yoshi Cwf97 Cynde Moya Danrok Datumizer Dexxor Diggr Dispenser Dollarsign8 DoublePendulumAttractor EdoAug Edolusill Eniehack Facenapalm Floyd-out FullyAwesome Harshrathod50 Jean-Frédéric Keplersj Kirilloparma Lewis Hulbert LotsofTheories Macocobovi Macrike Master Of Ninja Matthias M. Metafire18 Nicereddy Nw520 Odjob16 Oduci Poslovitch Rampagingcarrot RampantSpirit Santer Sight Contamination thgiex Tomodachi94 VGPaleontologist Wd-Ryan WikiSyn YotaMoteuchi

Notified participants of WikiProject Video games

Thank you for bringing this up. Unfortunately for games that are not compatible with Steam Deck there is no accurate modeling yet, although there has been an attempt to create a property that is not suitable in this case as it would be too specific, however there are some participants (including myself) who wouldn't mind to reopen proposal for the inverse property. Regards Kirilloparma (talk) 02:20, 18 June 2024 (UTC)[reply]

[BREAKING Change Announcement] Upcoming Changes to Wikibase: new EntitySchema data type

[edit]

Hi everyone,

This is a breaking change announcement relevant for some Wikibase API users.

What is Changing?

On 2 July 2024, we will enable the EntitySchema data type on Wikidata, and we expect the community to create the first properties with that data type and start using them in statements shortly afterwards. This means that there will be values with the data value type wikibase-entityid containing an EntitySchema ID (with "entity-type": "entity-schema" in the JSON value). However, EntitySchema is not yet a full-featured Wikibase entity type; it is our intention to eventually make it work like other entity types (Item, Property, etc.), but at the moment, using EntitySchema in e.g. the wbgetentities API or Special:EntityData does not work.

Who is Affected?

Code which assumes that IDs found in wikibase-entityid data values can be used with other Wikibase entity APIs may need adjusting.

Other Wikibases instances besides Wikidata are not affected unless they also use the EntitySchema extension and set $wgEntitySchemaEnableDatatype = true.

What You Need to Do

If your code works with statements of arbitrary data types, and looks up entities referenced in values with the data value type wikibase-entityid, you probably want to check that the entity-type is not entity-schema before proceeding. (Note that, if your goal is to display the value, you can instead use the wbformatvalue API for any data type.)

If you use the wbformatvalue API, you should make sure that you also specify the datatype or property parameter (depending on which information you have available; note that specifying both parameters at once is an error). Without this information, not all values can be formatted correctly; in particular, trying to format an EntitySchema value without specifying the datatype or property will result in an error (“An illegal set of parameters have been used”). (Specifying the datatype or property parameter for wbformatvalue has always been advisable, and necessary for some other data value types, but this is the first time it becomes relevant for wikibase-entityid data values.)

As previously announced, the new data type is already enabled on Test Wikidata, so you can try out the behaviour there. (An example item on Test Wikidata with a statement linking to an EntitySchema is human.) If you have any questions or concerns about this change, please don’t hesitate to reach out to us in this ticket (T332157).

Cheers, Lydia Pintscher (WMDE) (talk) 09:23, 18 June 2024 (UTC)[reply]

Lexicodays: sign up and contribute to the program

[edit]

Hello all,

As a reminder, the Lexicodays 2024, online event dedicated to Lexicographical Data on Wikidata, will take place on June 28, 29 and 30, with sessions replicated in different languages and at different times across time zones.

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.

We also remind you that you can contribute to the program until June 20th by adding a proposal to the talk page. You’ll find more information here. We are particularly interested in introductions to Lexicographical Data in different languages, and discussions run by community members on how to improve modelling and documentation in a specific language. You can also present tools or Lexeme usecases.

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! Lea Lacroix (WMDE) (talk) 10:27, 18 June 2024 (UTC)[reply]

Double check Q76357807 and Q26857651

[edit]

John Gordon (Q76357807) and John Gordon (Q26857651) seem to be about the same person and should probably merged. I want a second opinion though, since my proof is an identifier I have applied myself and approximate date of birth. Could someone check it for me? Darellur (talk) 12:28, 18 June 2024 (UTC)[reply]

I merged the items; Q76357807 (based on https://www.thepeerage.com/p70972.htm#i709713) and Q26857651 (based on https://www.historyofparliamentonline.org/volume/1754-1790/member/gordon-sir-john-1707-83) describe the same person. Peter James (talk) 21:13, 19 June 2024 (UTC)[reply]
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Matěj Suchánek (talk) 12:21, 22 June 2024 (UTC)[reply]

Competence is required issue for prolific editor

[edit]

I'm a little frightened to see that Буквы (talkcontribslogs) has over 40,000 edits here, as I find many of their edits to be counterproductive. Issues include use of very poor references, adding links via YouTube video ID (P1651) and URL (P2699) inappropriately to items, linking to copyright violations, and confusing the basic membership properties. I'm hoping someone here has the capability to mentor this user and/or review their edit history. Daask (talk) 12:35, 18 June 2024 (UTC)[reply]

Ignoring feedback given on their talk page suggests they are un-mentorable. Infrastruktur (talk) 14:36, 18 June 2024 (UTC)[reply]
not responding to feedback is blockable imo. BrokenSegue (talk) 18:06, 18 June 2024 (UTC)[reply]
Reading their page makes me think an indef block is needed. Ymblanter (talk) 18:36, 18 June 2024 (UTC)[reply]
Well, since they have no prior blocks at least they deserve a warning, so I left a stern one on their talk page. Let's just keep an eye on them for now. Infrastruktur (talk) 06:16, 19 June 2024 (UTC)[reply]

Translated books

[edit]

Should Q126720414 and The Problem of Pain (Q4179147) be merged? It's the same book, just translated into different languages. WhatamIdoing (talk) 15:25, 18 June 2024 (UTC)[reply]

No, the items should not be merged. Wikidata have separate items for the various translations and editions of books. You can see one of the items is an edition or translation of (P629) of the other. One item is instance of written work and the other is instance of version, edition or translation. Infrastruktur (talk) 15:30, 18 June 2024 (UTC)[reply]
Thanks. WhatamIdoing (talk) 15:45, 18 June 2024 (UTC)[reply]

Get all values of a Wikidata property from page history

[edit]

I would like a list of all all values that have every been set for a particular property on a particular entity, specifically Property:P4861#P1630. Is there a query or a tool that can retrieve this information so I don't need to dig through the page history of P4861? This seems like a useful tool to create if not... 15:44, 18 June 2024 (UTC) Daask (talk) 15:44, 18 June 2024 (UTC)[reply]

There is a poor man's solution to this. Pressing Ctrl+F on the page history enter "P1630" and make sure "Highlight all" is checked. Values from edit comments might be truncated but at least they aren't hard to retrieve. Infrastruktur (talk) 12:49, 19 June 2024 (UTC)[reply]

Slow menu

[edit]

Why is whole menu working so slow at Wikidata today? Eurohunter (talk) 18:38, 18 June 2024 (UTC)[reply]

What menu? --Matěj Suchánek (talk) 05:47, 19 June 2024 (UTC)[reply]
@Matěj Suchánek: Whole page loadings but It's okey now. Eurohunter (talk) 17:52, 20 June 2024 (UTC)[reply]
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Matěj Suchánek (talk) 12:21, 22 June 2024 (UTC)[reply]

Biological sequence

[edit]

Hello everyone,

I am doing some work on inner consistency on Wikidata. One of the items that created the most issues about disjointness was biological sequences. I invite anyone interested to join that conversation here: Talk:Q3511065

Also, I don't know much about different communities on Wikidata, so I would love it if you could forward this to relevant communities. Thanks! Egezort (talk) 07:04, 19 June 2024 (UTC)[reply]

@Egezort: I don't know anything about this specific item, but in general if you want to significantly change an item's meaning (or clarify a meaning that may be ambiguous) it would be good practice to "ping" those who have made edits to the item, and at least a sampling of those who have created objects that reference the item (see "What links here" for a list). Also if any Wikiprojects are relevant - in this case perhaps there are some related to genes or other biological entities - they should be contacted. ArthurPSmith (talk) 21:19, 19 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]

Special:Preferences -> Internationalisation -> Set a local exception for this global preference.

[edit]

Until now, I could chose/change standard languages (here: English, German, American English and Alemannic). I had to change/replace American English and Alemannic with every new login (!) with languages (French and Italian) what I prefer for working beside of German and English. Annoying, but so what. Now I can't make this replacement anymore. Does anybody has the same or a similar problem?

Working with FF 115.12.0esr AnBuKu (talk) _Internationalisation_->_Set_a_local_exception_for_this_gl" class="ext-discussiontools-init-timestamplink">19:21, 20 June 2024 (UTC)[reply]

Stop. Now it work again... curious. Sorry for disturbing AnBuKu (talk) 19:22, 20 June 2024 (UTC)[reply]
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Matěj Suchánek (talk) _Internationalisation_->_Set_a_local_exception_for_this_gl" class="ext-discussiontools-init-timestamplink">12:20, 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 (talkcontribslogs) 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]

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
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]