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

Wikidata:Project chat: Difference between revisions

From Wikidata
Jump to navigation Jump to search
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
Undid revision 2185377398 by Wüstenspringmaus (talk)
Tags: Undo Reverted
m Reverted edits by 212.200.181.52 (talk) to last revision by Wüstenspringmaus
Tag: Rollback
Line 386: Line 386:


:Stop. Now it work again... curious. Sorry for disturbing [[User:AnBuKu|AnBuKu]] ([[User talk:AnBuKu|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:22, 20 June 2024 (UTC)
:Stop. Now it work again... curious. Sorry for disturbing [[User:AnBuKu|AnBuKu]] ([[User talk:AnBuKu|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:22, 20 June 2024 (UTC)

== [[User:نوفاك اتشمان|نوفاك اتشمان]] ==
Jebem li ti sve živo. Pička li ti materina smrdljiva. --[[Special:Contributions/212.200.65.224|212.200.65.224]] 07:50, 21 June 2024 (UTC)

Revision as of 10:50, 21 June 2024

Edit

narrowing scopes of field of work

If an organisation studies fortifications in Germany, we can use field of work (P101) fortification (Q324326), but should Germany be a applies to jurisdiction (P1001) for the organisation, or have P101 qualifiers location (P276) or even located in the administrative territorial entity (P131). Or should Germany be a field of work (P101) itself? I've seen all of these used. My preference is a location (P276) qualifier.

Also asked at https://www.wikidata.org/wiki/Property_talk:P101 Vicarage (talk) 08:39, 14 June 2024 (UTC)[reply]

Oauth not working for quick statements

I know QS has seen some problems lately and I have seen this before but it seems persistent over 2 days now. Receiving a 403 error on login, no matter what browser. QS itself shows the home screen (which is also not always the case these days). Anyone else seeing this? I suppose I will just wait it out until it works again, as per usual, but I am hoping there might be some quick fix I was unaware of. Thx in advance Jane023 (talk) 09:31, 14 June 2024 (UTC)[reply]

I'm experiencing the same issue from I least yesterday.
I opened https://github.com/magnusmanske/quickstatements/issues/55 a few minutes ago. Maybe you can add some useful information there - and the fact that I'm not the only user experiencing this problem may be an useful piece of information for mantainers.
A quick fix would be great, but in https://www.wikidata.org/w/index.php?hidebots=1&hidecategorization=1&tagfilter=OAuth+CID%3A+1776&limit=500&days=7&title=Special:RecentChanges&urlversion=2 it seems that all editions are from a batch started two days ago. Pere prlpz (talk) 10:05, 14 June 2024 (UTC)[reply]
Solved https://github.com/magnusmanske/quickstatements/issues/55
Now it works for me. Pere prlpz (talk) 10:10, 14 June 2024 (UTC)[reply]
Thanks! It's fixed now for me too. Jane023 (talk) 11:28, 14 June 2024 (UTC)[reply]

Removal of ISNI by admin

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

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

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 science fiction writer and humorist (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]

Multiple constraint violations - identifiers of Abraham added to Ibrahim

https://www.wikidata.org/w/index.php?title=Q1768161&action=history&offset=20240616155553%7C1873416190&limit=100

@Epìdosis: you said you work on "slow cleaning of single-value constraint violations of ISNI (P213);" - maybe you are also interested on other types of Property:P213 constraint violations? Friedrich Kettler (talk) 18:06, 15 June 2024 (UTC)[reply]

Yes, I'm interested also in unique-value constraint violations of ISNI for humans; I usually work on Property talk:P213/Duplicates/humans when I have time. For Ibrahim (Q1768161), I have removed some IDs (including ISNI) which pertained to Abraham (Q9181) and not specifically to it. Thanks, Epìdosis 20:45, 15 June 2024 (UTC)[reply]

Leap years gregorian dates before Christus

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

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)

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

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

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

Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-06-17.

Discussions

Events

  • Looking ahead
    • Lexico Days 2024 is coming up. June 28 - 30, there will be a packed programme of presentations, discussions and workshops on Lexicographical data. This is an online event.
    • Wikidata Workshop for Botanists at the XX Intl. Botanical Congress, July 21 - 27, 2024, Madrid, Spain.

Press, articles, blog posts, videos

Tool of the week

Other Noteworthy Stuff

Newest properties and property proposals to review

You can comment on all open property proposals! Did you know?

Development

  • EntitySchemas: We are preparing for the rollout of the new datatype to link to EntitySchemas in statements.
  • Wikibase REST API:
    • We are continuing the work on the route for modifying an Item (phab:T342993)
    • We are working on improving errors and error messages in the API
  • Query Service UI: We fixed a bug. The example dialog was empty and not showing any examples (phab:T366871)
  • We changed the datatype of two Properties to external ID as requested (phab:T367174)

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

Anything to add? Please share! :)

Steam Deck unsupported games

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 CommanderKefir 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 Odjob16 Oduci Poslovitch Rampagingcarrot RampantSpirit Santer Sight Contamination SuperUltraHardCoreGamer - Joined to add things about Steam Deck verified/playable titles. Skills: Basic editing. thgiex Tomodachi94 VGPaleontologist Wd-Ryan WikiSyn YotaMoteuchi Athayahisyam

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

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

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

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]

Competence is required issue for prolific editor

I'm a little frightened to see that Буквы (talk • contribs • logs) 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

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

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

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]

Biological sequence

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

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]

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

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) 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]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2185378949"