Wikidata:Project chat

(Redirected from Wikidata:Project Chat)

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 or the Telegram groups.
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 2023/02.


Fixing incorrect merge of publishing conceptsEdit

Previously we had the concept of "publication in German copyright law" under publication in German copyright law (Q15852766) and "publishing - process of production and dissemination of literature, music, or information" publishing (Q3972943). The former appears to be about a specific concept in German law for the very moment of publication. The latter was about the broader concept of publishing as it applies to the whole world. These were then merged on 6 November 2022 by User:DerMaxdorfer.[1] We are now left with an item that says the concept of publishing for the entire world is based solely on German law. This is clearly a mistake but I'd like a second opinion on how to fix it. Using the principles of managing conflations, if this was a recent merge we would reverse it and if it is a longer term merge we would have to manually split the concepts into two new items and deleted the conflated item. Do we think this is recent enough to just reverse the merge? From Hill To Shore (talk) 23:17, 22 January 2023 (UTC)

Based on this diff, I would restore the pre-merge versions of both items and then re-apply the handful of recent edits. PKM (talk) 00:41, 23 January 2023 (UTC)
I merged the two items because of the chaos in the linking of Wikipedia articles in different language versions and I did my best to connect always those articles that describe the same topic. To be honest, I didn't care enough about the statements already existing in the different Wikidata items, otherways I would have deleted some the statements dealing exclusively with the German copyright law. In my opinion the German term doesn't need an own item. The description as "publication in German copyright law" in publication in German copyright law (Q15852766) is a mistranslation/misinterpretation of the original German description added here. Originally, this German definition translates as "in the German copyright law: moment, in which a work is made available to the public" and should probably only make aware of the fact that the word could have slightly different definitions in other languages even if it means the same thing.
To make it more clear: There is no specific concept called "publication" in German copyright law. The German copyright law (§ 6.1) only has its own short paragraph defining from which day to count the copyright rules we all know from Commons or Wikisource. That one sentence translates as: "A work is (= counts as) published, when it is made available for the public with consent of the authorised entity." In my eyes this sentence doesn't create something different from the one thing that is internationally called "publication" – but that can of course be seen differently. Therefore I have two possible solutions:
1.) Leave everything as it is.
2.) Re-create the item about the defined instant of time at which a work of art, literature etc. is counted as published in the German copyright law. But that item can only refer to the already cited §6.1 UrhG, not to any Japanese or Dutch terms as previously mentioned in the Wikidata item.
Please let me know which solution you choose so that I can at least arrange the German Wikipedia articles according to the new arrangement of the Wikidata items. --DerMaxdorfer (talk) 06:17, 23 January 2023 (UTC)
@DerMaxdorfer: I've split the two items into publishing (Q3972943) and publication in German copyright law (Q15852766). To perform the split I had to move the dewiki link to publication in German copyright law (Q15852766). If you think it sits better under publishing (Q3972943) then you are free to move it, without merging. While merging may be the simplest way for you to get your site links in the right place, you need to consider carefully the concepts of the two Wikidata items first and decide if you are going to cause damage. In this case you transformed an item about the global concept of publishing into a German concept of publishing. When in doubt, ask at the Project Chat, especially when you are dealing with fundamental concepts linked from thousands of other Wikidata items. If you think publication in German copyright law (Q15852766) is not needed, you are welcome to request deletion of that item (It has no references and the only ID is a Google Knowledge Graph ID). From Hill To Shore (talk) 11:11, 28 January 2023 (UTC)
I know, I know. But most national copyright laws will have some short regulations concerning the publishing of a book. That's why I found it strange to handle the German law as a special case needing its own Wikidata item. However, that is not important enough for me to discuss it that painstaikingly, especially as I assume that you know the Wikidata rules better than I do... Thanks for your work and best regards, DerMaxdorfer (talk) 11:24, 28 January 2023 (UTC)

Junk items. last report.Edit

even though i dont give a fuck about junk on wikidata, i'll report this one last time. (previous reports: Wikidata:Project_chat/Archive/2022/12#IP_user_creating_lots_of_items_for_commons-only_cats Wikidata:Administrators'_noticeboard/Archive/2023/01#Report_concerning_User:G6zLZz2cEPKdEXB.)

these users, and possibly other accounts/ip that i didnt find out, have created hundreds of junk items ( https://xtools.wmflabs.org/pages/www.wikidata.org/G6zLZz2cEPKdEXB https://xtools.wmflabs.org/pages/www.wikidata.org/218.102.0.123 ) that link to granular commons cats that dont need an item, e.g. Q116298299 Q116298452. RZuo (talk) 12:41, 24 January 2023 (UTC)

  all deleted. Thanks for notifying @RZuo! Let we know if you discover another IPs/users. Estopedist1 (talk) 18:59, 24 January 2023 (UTC)
@Estopedist1: We have the same behaviour from the user at User talk:218.102.0.44 with large scale creation of bare items with only a Commons category site link. The pattern of edits (and similar ip) appears to indicate it is the same editor. From Hill To Shore (talk) 04:23, 25 January 2023 (UTC)
I spoke with them as shown in that talk. They were definitely operating a bot without approval but it seems they now understand not to do that. I'll go through and nuke the old items. BrokenSegue (talk) 05:42, 25 January 2023 (UTC)
also User:42.200.150.136 there's probably more too. BrokenSegue (talk) 06:05, 25 January 2023 (UTC)
@Estopedist1, From Hill To Shore, BrokenSegue:
another one here: Special:Contributions/219.78.39.49.
since on User talk:218.102.0.44 s/he claimed s/he would stop on 13 January, but 219.78.39.49 is obviously the same person doing the same thing on 25 jan, i suggest an immediate block from now on is proper. RZuo (talk) 08:30, 28 January 2023 (UTC)
also, c:Special:Contributions/Yrellag is the same user. RZuo (talk) 09:37, 28 January 2023 (UTC)
@RZuo wow, this is exceptionally productive user. Some items are good ones also, e.g. Q115954976 and Q115954956. Due to editing after warning, range block is set for 218.102.0.0/25 Estopedist1 (talk) 15:47, 28 January 2023 (UTC)
@Estopedist1: a handful of them are alright, but you have to make too much effort in order to sieve them out.
since s/he has moved on to new ip, maybe 219.78.39.49/25 should be also blocked? RZuo (talk) 15:59, 28 January 2023 (UTC)
if you make so much garbage you can't complain if we accidentally delete some good pages. I'm going to delete them all. BrokenSegue (talk) 17:23, 28 January 2023 (UTC)
Special:Contributions/182.239.87.228 3 more here. XD
bus route Q115972959 is ok. RZuo (talk) 19:02, 28 January 2023 (UTC)
also, i think, to prevent these kinds of spam happening, maybe a bot should be set up to detect "newly registered users / ip creating more than x items in y days"? like more than 20 items in 2 days? having a bot-generated report and spot checking it might be useful in detecting such spam. RZuo (talk) 16:02, 28 January 2023 (UTC)
@RZuo definitely a good idea, but our goal probably should be to restrict items creations and items merging by anonyms. E.g. in Commons, anonyms cannot upload files Estopedist1 (talk) 07:09, 29 January 2023 (UTC)

According to my intuition all those aren't really grounds to deprecate the statement. Should we remove them and bring the related statement to normal rank? ChristianKl❫ 18:44, 26 January 2023 (UTC)

Yes, they're very poor. The definition of deprecated rank is very simple, but again and again people misuse it as a bin in which to put things they don't like. Per Help:Ranking The deprecated rank is used for statements that are known to include errors (i.e. data produced by flawed measurement processes, inaccurate statements) or that represent outdated knowledge (i.e. information that was never correct, but was at some point thought to be). In the case of statements with poor referencing, the options are 1) to remove the statement 2) add a better reference 3) leave the damn thing alone. WD users must always act under the maxim caveat lector, let the reader beware; unreferenced and poorly referenced statements are suboptional but more often than not, still useful.
As none of these three are reasons for deprecation, I think the three items should be deleted and the rank on statements using them brought back to normal. --Tagishsimon (talk) 18:59, 26 January 2023 (UTC)
yeah they are bad BrokenSegue (talk) 19:12, 26 January 2023 (UTC)
There's a similar issue with uncitedness (Q2492572). ChristianKl❫ 16:18, 27 January 2023 (UTC)
@ChristianKl: I agree those are insufficient as reasons for deprecation. They might serve a purpose as scoring criteria when evaluating relative "completeness" of items (say, to help identify model items), but we don't have such a system yet.
Now, is there a canonical list of valid reasons for deprecation somewhere, and is there a procedure for amending it? I have seen the list of a dozen "useful" examples at Help:Deprecation#Reason for deprecation (plus a query that might list 750 "reasons" currently used if it didn't time out), some 80+ reasons listed at has part(s) (P527) of list of Wikidata reasons for deprecation (Q52105174), and finally a table Help:Deprecation/List of Reasons for Deprecation with 319 items that are defined as instance of (P31) Wikibase reason for deprecated rank (Q27949697), whether right or wrong (the table includes those mentioned by you above). None of these lists look particularly authoritative to me. Can this situation be improved somehow? I have made a few suggestions at Help talk:Deprecation but I don't know if that is the appropriate forum. --SM5POR (talk) 21:17, 1 February 2023 (UTC)
@SM5POR: Here's a reworked version of the query - https://w.wiki/6HeA --Tagishsimon (talk) 21:23, 1 February 2023 (UTC)
@Tagishsimon: Thanks for the optimization, and it strengthens my point that this list of 751 reasons still can't be considered authoritative, because the most common reason used turns out to be marking inconsistent with the registered/official identifier/name (Q108180274), as it's used on 371171 different statements. That's apparently a robot running around deprecating the titles of scientific articles which it has itself set a few milliseconds earlier!
As the purpose of the deprecation mechanism is to help other editors find out what statements are invalid and should not be repeated, who is going to learn anything from this?
I may be wrong though; I'm just extrapolating from what I think I'm seeing. --SM5POR (talk) 23:18, 1 February 2023 (UTC)
@SM5POR:There is not an authoritative list. Users are, by & large, welcome to coin new reasons anytime they come across a circumstance not covered by any of the existing reasons. However it is certainly the case that a) many statements are deprecated for incorrect reasons and b) some 'reason for deprecated rank' values are inappropriate.. So wherever a deprecation, and/or a reason for deprecated rank, falls outside the deprecation policy set out in Help:Ranking, those would be errors that should be corrected. Then c) some items having a P31 of 'reason for deprecation', per the original post, should not exist since they are not valid reasons for deprecation. Meanwhile marking inconsistent with the registered/official identifier/name (Q108180274) looks to me like it's probably a valid reason for deprecation. I don't know the ins & outs, but a title is being deprecated and a different title enstated at normal rank ... I suspect from the examples I've looked at that there is an error in source A being depecated on the basis of a value in source B. --Tagishsimon (talk) 23:31, 1 February 2023 (UTC)
By design we don't have an authoritative list. Users should be able to express whatever reasons they have in mind. Using items in this way allows them to be translated and users of different language to understand the reason which wouldn't be the case if we would allow users to describe the reasons in free text. On the other hand, it's good to have processes to correct mistaken uses of deprecation.
There are two things to list. One is the reasons tagged with as reasons for deprecation and the other is the constraint violations that don't use any of them. I create the list for the items that are tagged that way so that it can be watched and when there are new items, those can be more immediately dealt with. ChristianKl❫ 16:03, 2 February 2023 (UTC)
@Kanashimi: can you tell us why your bot uses deprecation in this way? ChristianKl❫ 15:54, 2 February 2023 (UTC)
These articles are non-English scientific papers. However, the source of the information I have obtained is in English only, not in the original language. So I think I should add a lower grade for them. Kanashimi (talk) 00:30, 3 February 2023 (UTC)
@Kanashimi: Thus the English-language references may be secondary sources, kind of. But deprecating the title is in effect the lowest possible grade you can give to a statement, short of deleting it. At the same time, Wikidata is full of completely non-sourced claims at normal rank. Surely a secondary/translated source is better than no source at all, don't you think?
If you have multiple sources to the same claim (or slightly different ones, such as one title in the original language and a translated one in square brackets), you could promote the primary/original source by giving that claim a preferred rank instead. --SM5POR (talk) 09:40, 3 February 2023 (UTC)
So it looks like I can just skip the step of lowering the ranking? Kanashimi (talk) 10:34, 3 February 2023 (UTC)
@Kanashimi: I think so, yes. Deprecation should be the exception, when something is actually wrong. --SM5POR (talk) 11:53, 3 February 2023 (UTC)
However, I see the example here. Maybe we need to modify this example as well? Kanashimi (talk) 12:02, 3 February 2023 (UTC)
@Kanashimi, @VIGNERON en résidence: I wasn't aware of that constraint. According to the edit history it was added in December 2018 among a number of format constraints, but many of them have since been deprecated, this one in September 2022. See Property talk:P1476#Constraint prohibiting '[' and ']' should be deprecated or modified for the specific reason why. And don't bother editing the deprecated constraint as it may confuse other editors as to why it was deprecated.
Also, the point of that constraint was to promote the title in its original language, but I don't recall seeing the Russian titles at all on the articles your robot was processing. In any case, I think deprecation is too severe as a response to a translated title (it may well be the title of a published translation of the work, unless that is supposed to have an item of its own). Better to give the original title preferred rank, if you can add that one. --SM5POR (talk) 14:46, 3 February 2023 (UTC)
I deprecated this constraint after this discussion [[Property_talk:P1476#Constraint_prohibiting_'['_and_']'_should_be_deprecated_or_modified]] (@Wostr:) as it wrongly assumed that a title beggining with [ is incorrect (it is rare but it's not). But indeed this constraint is also wrong about ranks (it's also no how it works). I'm wondering if we shouldn't just delete it. Cheers, VIGNERON en résidence (talk) 15:37, 3 February 2023 (UTC)
@VIGNERON en résidence: Considering all the work that seems to have gone into crafting those constraints, it would be pity to throw it all away (and then risk repeating it) just because we don't use them anymore. I wrote an incompatible with best current practice (Q116654895) reason for deprecation and added it to the constraint statement. It should be useful on other outdated constraint, usage example, model item or recommendation property statements as well, and will be easier to apply (especially when translated) than rewriting all those clarifications in multiple languages. Now, if we could have the editor interfaces make the reason for deprecated rank (P2241) stand out in bold or something to overshadow the deprecated text...
Progress is not solely based on an unbroken chain of recognized successful innovations, but even more so on uncountable (and indeed uncounted) mistakes, failures and utter disasters. "Those who forget history are doomed to repeat it." --SM5POR (talk) 17:24, 3 February 2023 (UTC)

Linked Data Fragments predicate for labels, aliases, sitelinks?Edit

I'm using the LDF endpoint (https://query.wikidata.org/bigdata/ldf) for querying backlinks, but I cannot find any references for how to query labels, aliases & sitelinks through LDF. Is it even possible? I would like to avoid SPARQL. The manual (https://www.mediawiki.org/wiki/Special:MyLanguage/Wikidata_Query_Service/User_Manual#Linked_Data_Fragments_endpoint) doesn't mention it. Whatever the answer, it would be great if the manual was updated to reflect it. ProbabilityCollapse (talk) 20:14, 26 January 2023 (UTC)

The predicate for label is rdfs:label, for description schema:description and for alias, skos:altLabel ... not sure if that helps or not. See https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Entity_representation --Tagishsimon (talk) 20:19, 26 January 2023 (UTC)
Thanks for the reply. It does certainly help with labels, descriptions and aliases. Still unsure about sitelinks, which was my main use case. There's an http://wikiba.se/ontology#sitelinks property, but that only seems to indicate the amount of sitelinks, not their actual values. ProbabilityCollapse (talk) 20:47, 26 January 2023 (UTC)
@ProbabilityCollapse: So here the ?article (URI of a wikipedia/wikimedia page) is the subject of a triple; predicate is schema:about and object is ?item. These are the three triples typically employed when dealing with sitelinks ... ?sitelink is the article title:
In more detail: https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Sitelinks --Tagishsimon (talk) 23:51, 26 January 2023 (UTC)
Thank you! Took a bit of playing around with the queries, but I think I get it now: Sitelinks are stored as subject=wikipedia-page and object=wikidata-entity. ProbabilityCollapse (talk) 09:46, 28 January 2023 (UTC)
Excellent; yes, you have it. --Tagishsimon (talk) 14:24, 28 January 2023 (UTC)

Is ToolForge having problems or technical difficulties? Eugen Rochko (Q64876086) data Toolforge bypassEdit

I had opened a discussion topic for Mastodon address (P4033) with proof of data not always going through Toolforge, ie. George Takei (Q110154) data(related to his Mastodon address (P4033)) does not go through Toolforge and resolves a 404 error when linking to his Mastodon address.

Eugen Rochko (Q64876086) the founder of Mastodon itself's Mastodon Address does not resolve on Wikidata. :) this is just too puzzling for me. I found this edit where the rank for "Formatter URL"/"URL Formatter" had been changed from preferred to normal in this edit for the property of Mastodon address (P4033).

Does changing "Formatter URL" rank priority somehow affect if some data of Mastodon address (P4033) will or will not go through Toolforge or does Toolforge have technical difficulties because there is also a very hard puzzle to crack where Taylor Lorenz (Q89135464) Mastodon Address resolves fine through Toolforge without a problem! This makes no sense to all. If an expert can explain to me what's going on I think I'm gonna learn something new today! Mastodeas (talk) 16:24, 27 January 2023 (UTC)

yes the formatter rank decides which formatter is used. it's probably mostly a caching issue and the priority. BrokenSegue (talk) 17:03, 27 January 2023 (UTC)

Better explanation about "sitelink to redirect" neededEdit

when adding a link manually, the given link Help:Sitelinks doesnt say anything about the difference between sitelink to redirect and intentional sitelink to redirect. something more accessible is needed. RZuo (talk) 17:06, 27 January 2023 (UTC)

@RZuo: It looks like the help page has been updated since your post here, does this address your concerns? See also Wikidata:Sitelinks to redirects which is linked from Help:Sitelinks and goes into more detail on your question. ArthurPSmith (talk) 17:09, 30 January 2023 (UTC)
thx. before your message i didnt find out Wikidata:Sitelinks to redirects at all. i only found the brief descriptions on items Q70893996 and Q70894304. RZuo (talk) 17:17, 30 January 2023 (UTC)

Time capsulesEdit

Hello! What are the best properties for date of creation, date to be opened and content/objects included in time capsules? Example: Philco time capsule (Q116447516). Thanks. Emijrp (talk) 21:04, 27 January 2023 (UTC)

Maybe significant event (P793) with an appropriate value and a point in time (P585) qualifier for the dates. contains (P4330) for the contents? --Tagishsimon (talk) 21:20, 27 January 2023 (UTC)
Nice, I created date of enclosure (Q116457511) and date of opening (Q116457521). Example. Emijrp (talk) 09:38, 28 January 2023 (UTC)
Good work, Emijrp; but I feel the organisers may have bought too strongly into the notion of the everlasting qualities of LaserDisc (Q273309). "Its content was created to last 500 years" versus w:en:LaserDisc#Laser_rot :(. --Tagishsimon (talk) 14:23, 28 January 2023 (UTC)
Yeah, maybe... Fortunately there are hundreds of different time capsules all over the world. I am using the same properties for messages in bottles too, like Message in a bottle by James Ritchie and John Grieve (Q116458197). Emijrp (talk) 15:05, 28 January 2023 (UTC)

Is no quorum valid reason for closing property proposals?Edit

@DannyS712: Closed more than 50 property proposals as "no support for creation of this property". Some of them are reopened by either the proposer or other users. I do not want to argue those with still no consensus to create with reasonable amount of input (including those with valid objection); but for those received no comments with no one opposing, a property proposal at least indicates a need for a property for someone (the proposer), so I think a better solution is to accept them by default after one month without objection. Having a property is seldom positively harmful, especially identifier properties.--GZWDer (talk) 04:56, 28 January 2023 (UTC)

I think properties need community support, and while a external identifier might be harmless, we need a strong case for ontological ones, lest we get overlapping or too niche ones. One person can rarely see the implications of their idea. Vicarage (talk) 05:22, 28 January 2023 (UTC)
I strongly agree. General properties should not be created willy-nilly or else Wikidata becomes a unsustainable mess. I believe it's the property creator's job to think of reasons against the proposal and have them addressed. This is the reason the property creator role exists in the first place.
I think identifiers are more of a judgement call, as long as there are no unanswered objections, there are over ~100 entries and the creator believes it's useful you could still create it, as the proposer and creator have implicit votes too. I also think it's better to eventually close proposals rather than having them open indefinitely, Speaking of which, when do property creators usually decide to close a proposal? Infrastruktur (talk) 08:57, 28 January 2023 (UTC)
Many requests above receive no comments at all, let alone objections. For identifiers, I tend to accept them after one month. GZWDer (talk) 11:12, 28 January 2023 (UTC)
Most property proposals today are identifiers (as are most of closed one I concern). For those, the standard may be more lenient as redundancy is hardly a concern (though there are still concern like copyright, stability or spam). For properties in other datatypes (especially item), it may be beneficial to leave the request a bit longer to solicit enough inputs.--GZWDer (talk) 05:39, 28 January 2023 (UTC)
If there's been months with no comment then I don't know if we should create the property. I personally would leave them to sit but this does create a big backlog. I don't think the burden of relisting is that big a deal. That said if there's support (even minimal) I don't think we should close it as declined. Going over most of the closed proposals I'm mostly fine with them. Closing property requests is a thankless task so I don't want to even appear to be snapping at someone for doing a good deed. BrokenSegue (talk) 05:58, 28 January 2023 (UTC)
I'm not fine with closure of many requests like this one. (Many of) such stale proposals frustrate users who want to propose (and use) new properties.--GZWDer (talk) 14:33, 28 January 2023 (UTC)
again I agree that I wouldn't do this. but if your proposal doesn't get any comments in a couple months and you don't solicit comment from e.g. here then it doesn't seem super productive to leave it up. Maybe we should just decide that, say, 3 months is the point where if you don't have any comments it's considered dead. BrokenSegue (talk) 17:53, 28 January 2023 (UTC)
DannyS712 closed some proposals with that reason which were open for less than a month. I don't think lack of support is a valid reason for closing properties at that stage. I think it can make sense for property proposal older than six months.
I don't think there should be automatic approval for ID properties. ChristianKl❫ 14:08, 28 January 2023 (UTC)
Currently property proposals are already so many that proposal pages hits template limit and can not transclude all proposals. (And this make relisting useless.) Many proposals are ill attended (reviewed by few users), and this make them worse.--GZWDer (talk) 14:26, 28 January 2023 (UTC)
Most property proposals are made with minimum effort. If someone doesn't get any attention for their external ID property, that's often a sign that the person making the proposal put in little effort to make the proposal accessible.
It's the role of the person making the proposal to explain why it's valuable to have that property and provide the relevant information to understand why it's important. If a property proposal doesn't do that for any reader of it that's a sign that it's lower quality than the average property we create. ChristianKl❫ 15:40, 28 January 2023 (UTC)

Two identical items, but "impossible" to mergeEdit

Q600310 and Q22064645 are about the same city in Brazil, Mogi-Mirim. However, it's "impossible" to merge them, because Q22064645 has two articles linked to it, in the Ceb and in the SV Wikipedias. The main problem is Q600310 also has articles for the same city in the Ceb and in the SV Wikipedia. As far as I can tell, these two Wikipedias have two different articles for the same city. The two articles in each of these two Wikipedias were created by a bot, Lsjbot. What we do? Merge the article in these WPs and then the items here or what? Kacamata (talk) 01:25, 29 January 2023 (UTC)

These two items look like they're about different - but related - things. Often there are separate items for a settlement and a municipality that covers the settlement. I don't know enough about Brazilian local government structure or the ceb and sv wikis' policies on these matters, but my first reaction would be that the items should not be merged but that the items should link to each other, probably by using located in the administrative territorial entity (P131) on the settlement pointing to the municipality. For a similar example from the UK, see Manchester (Q18125) (city) and Manchester (Q21525592) (district) --M2Ys4U (talk) 01:42, 29 January 2023 (UTC)
(EC)In this case, cebwiki is drawing a distinction between a city of 78k people - https://ceb.wikipedia.org/wiki/Mogi_Mirim_(lungsod_sa_Brasil) - and a municipality of 86k people - https://ceb.wikipedia.org/wiki/Mogi-Mirim . Cebwiki's city article is linked to Q600310, which for WD is the municipality item. Cenwiki's municipality article is linked to Q22064645 which for WD is a human settlement item.
So at the least, the sitelinks for Ceb (and probably SV) should be swapped around.
It's unclear how the Ceb and SV articles were put together, but on the face of it a source (reliable?) draws the city / municipality distinction. So the choices seem to be, fix the WD items (swap the sitelinks, tweak the P131 on the city item). Or redirect the Ceb and SV city articles into the Ceb and SV municipality articles, and merge on WD. There has been a very great deal of pruning of duplicate-ish articles on (iirc) SV, fwiw. Equally, there is some distinct content in the two Ceb articles which ideally would be properly merged, not lost.
tbh, sorting it out at the WD end looks to me like the simpler option. --Tagishsimon (talk) 01:53, 29 January 2023 (UTC)
Those items come from a bot that used the geonames database. See https://www.wikidata.org/wiki/Wikidata:WikiProject_Territorial_Entities/Geonames_and_CebWiki for more information. ChristianKl❫ 03:39, 29 January 2023 (UTC)

natural locality vs administrative divisionEdit

In this section I want to point out that natural localities, i.e. human settlement (such as city) and administrative divisions are two distinct things. For example:

Comparison of city and administrative division
Natural city Administrative division
Tokyo (Q7473516) - In Chinese Wikipedia, a (board-concept) article describing the natural city of Tokyo, settled since (at least) 1457 Tokyo (Q1490) - Tokyo Metropolis, found 1943
Paris (Q90) - a city populated since BC Departments of Paris (1968-2018), then a territorial collectivity
New York City (Q60) - settled 1624 City of Greater New York (Q5123708) - since 1898
Beijing - a city settled before 1000 BC Beijing (Q956) - direct-administrated municipality since 1949; In Chinese Wikipedia, the article is explicitly named after the administrative division
Lagos (Q8673) - a natural city Lagos city government dissolved in 1967. Currently there are no individual administrative division of any sort for Lagos.

They are distinct in many ways:

  1. Administrative divisions may be created or dissolved, but it make no effect on the actual city (unless it is abandoned). Obviously an administrative division (if exist) may be found much later than the actual city.
  2. The border of an administrative division is usually well defined, but the border of a city or town can have multiple definitions (contiguous urban area, metropolitan area, both of them are also not well defined).
  3. A locality can only be a small part of administrative division ("The municipality of Chongqing, China, whose administrative area is around the size of Austria, has the largest population for a city proper. However, more than 70% of its residents live in rural areas."), but can also extended beyond the administrative division.

However, In most databases or sources (but not GeoNames), we does not differ these two. They should ideally be split, but splitting (most of) each city to two items will strongly confuse data users.--GZWDer (talk) 22:46, 29 January 2023 (UTC)

You've made this part of an existing topic, I think you wanted it to be a new topic. This area is a can of worms, as people think in terms of the natural names and boundaries of places, not the administrative boundaries (and clumsy names to combine 2 names in one organisation). But if you care about political hieracy, then you need items that make their purpose clear, so Orpington (Q123977) where I live was part of Bromley Rural District (Q4973696) until 1935, then Orpington Urban District (Q15264364), part of Kent (Q67479626) (but not Kent (Q23298)) until 1965, now part of London Borough of Bromley (Q208201), in Greater London (Q23306), London (Q23939248), which is not London (Q84). Clear as mud, but there is no way we want each settlement to record its political history, boundaries are fluid, and we don't record them anyway, so the only thing really worth recording is the current state of affairs, and then accept that people will say my house is in Orpington, not the Farnborough and Crofton (Q56295126) electoral ward which is the true bottom of the tree. I think the prospects of making a plan in this area, and then getting people to follow it are very remote. Vicarage (talk) 00:10, 30 January 2023 (UTC)
All Japanese city names in Japanese are modern administrative division names, so P571 is set after 1888. This often results in "Contemporary" violations of historical figures. Therefore, it seems necessary to have two entries, one for modern place names and one for historical place names. In English, both names would be the same. Afaz (talk) 02:20, 30 January 2023 (UTC)
Changing names are hard to handle, how would you say the Prince Regent visited Constantinople? When we say X is a Y, there is an implicit assumption that the author meant it for a range of dates, with the names as valid in the range. To extract the information we really need a query of the form "tell me about X's relation with Y at date Z", but not by coding dates in the relation, as some have by quoting country changes for border towns, but by extracting them from X and Y. This is a problem for ships, which could be solved by using official name (P1448) and dates, but coding the information and getting good queries is a big burden on the user. A possible solution would be for Wikibase to have date qualifiers for labels, and SPARQL to provide ?itemLabel(1925), but this would be a lot of work. And continuity is important, some argue a ship with a new name or purpose is a new ship, I'd argue that tracing the history of the hull that matters, and the same applies to places. Vicarage (talk) 09:54, 30 January 2023 (UTC)

imageEdit

How will i add an image to an item Bright0708 (talk) 07:17, 29 January 2023 (UTC)

Bright0708 An appropriately licensed free image -- either in the public domain (no copyright whatsoever) or with a free license (such as CC-BY) -- needs to first be present on Wikimedia Commons. Some more info is at Wikidata:Tours/Images. Image or no image, strive to ensure that the item satisfies one or more of Wikidata's notability criteria. -Animalparty (talk) 07:34, 29 January 2023 (UTC)

AI authorshipEdit

If the subject of an item was generated by ChatGPT, Midjourney, Stable Diffusion or similar should the AI program be listed as the author? Or the human who entered the prompts? Trade (talk) 18:49, 29 January 2023 (UTC)

maybe both with a qualifier? though pretty sure that violates a constraint BrokenSegue (talk) 19:11, 29 January 2023 (UTC)
Rather than author (P50) I think fabrication method (P2079) might be more applicable in these cases. Ainali (talk) 19:18, 29 January 2023 (UTC)
What would the value of fabrication method (P2079) be? The item of the AI program used or something specific? Trade (talk) 21:47, 29 January 2023 (UTC)
What if an AI enters its own prompt into another AI? -wd-Ryan (Talk/Edits) 20:32, 29 January 2023 (UTC)
Why should we have such items, references... ? --Succu (talk) 20:54, 29 January 2023 (UTC)
then list both in the fabrication method? BrokenSegue (talk) 20:54, 29 January 2023 (UTC)

I would need some help on test.wikidata.org to understand how Mastodon address (P4033) works or be allowed(limited time?) to experiment myselfEdit

Do you mind if I experiment some on test.wikidata.org in order to understand how and why Mastodon address (P4033) creates broken Mastodon links? Can you tell me who to get in touch with to ask for permissions for a few weeks to experiment there so that my edits don't just suddenly get wiped now as I'm editing? Who am I to tell if somebody decides that my edits are pointless and decide to wipe everything I've done so far? Though I have a genuine worry that this is way over my head but I won't know that until I've tried to the best of my ability.

Do I need to apply that I'm doing this as a 'little project' anywhere? test.wikidata.org does not have a project chat or community portal like Wikidata. So far I've been allowed to create new items and new properties so there is no real technical measure that is stopping me from experimenting.

Perhaps I don't need to ask anyone for permission and I can just experiment? I'm trying to copy how Mastodon address (P4033) works on test.wikidata.org and I'm saying this so that you can decide for yourselves if this is futile, if this is not what test.wikidata.org was designed for or some other insight I don't know about. That will probably save me a lot of time. Mastodeas (talk) 00:39, 30 January 2023 (UTC)

you don't need permission to test on test.wikidata.org. just play around there. BrokenSegue (talk) 07:09, 30 January 2023 (UTC)

Rock that disappeared, p31=?Edit

an item is about a big rock at a place. the rock has disappeared because of land reclamation. p31=? RZuo (talk) 09:11, 30 January 2023 (UTC)

To describe things in the past, create all the usual properties, but add dissolved, abolished or demolished date (P576) to indicate it has ceased to exist and a significant event (P793) to describe both the reason and date Vicarage (talk) 09:40, 30 January 2023 (UTC)
most precise date i can find is "19th century". how to input this for Hoi Yan Sek (Q11150367)? RZuo (talk) 13:45, 30 January 2023 (UTC)
You can just write "19th century" in all properties that are about dates. ChristianKl❫ 13:50, 30 January 2023 (UTC)
@RZuo I've updated Hoi Yan Sek (Q11150367) to show an example of how to specify date precision of "19th century". Dhx1 (talk) 16:06, 30 January 2023 (UTC)
thx a lot. i wrote 19th century and it said "malformed". wikidata should be more clever to understand this common notation. RZuo (talk) 16:09, 30 January 2023 (UTC)

Japanese adjective modelingEdit

Moved to Lexicographical data

Wikidata weekly summary #557Edit

Last call to vote on revised UCoC enforcement guidelines!Edit

Hi all,

A friendly and final reminder that the voting period for the revised Universal Code of Conduct Enforcement Guidelines closes tomorrow, Tuesday, 31 January at 23:59:59 UTC.

The UCoC supports Wikimedia’s equity objectives and commitment to ensuring a welcoming, diverse movement, and it applies to all members of our communities. Voting is an opportunity for you to be a part of deciding how we uphold this commitment to our community and each other!

To vote, visit the voter information page on Meta-wiki, which outlines how to participate using SecurePoll.

Many thanks for your interest and participation in the UCoC!

On behalf of the UCoC Project Team, JPBeland-WMF (talk) 21:32, 30 January 2023 (UTC)

Hello all,
The vote on the Universal Code of Conduct Enforcement Guidelines is now closed. The results will now be counted and scrutinized to ensure that only eligible votes are included. Results will be published on Meta and other movement forums as soon as they become available, as well as information on future steps. Thank you to all who participated in the voting process, and who have contributed to the drafting of Guidelines.
On behalf of the UCoC Project Team,
JPBeland-WMF (talk) 21:48, 1 February 2023 (UTC)

Generic property-proposal page is overflowingEdit

We currently have so many open Generic property proposals that not all of them are being transcluded into the overview page (because of some Mediawiki limit, I guess). A few of the proposals seem to be ready or withdrawn, though. What is the mechanism for moving those on/elsewhere? ―BlaueBlüte (talk) 22:38, 30 January 2023 (UTC)

If there are proposal that don't really belong there like authority control properties you can manually copy them over to the place where they belong. ChristianKl❫ 23:14, 30 January 2023 (UTC)
  Done Moved some proposals; diffs: [2] [3] [4]
BlaueBlüte (talk) 19:07, 31 January 2023 (UTC)

scientific or scholarly articles identifiers access restriction status (P7228) or online access status (P6954)Edit

for scientific or scholarly articles, ex: doi, pmid, etc.. which should i prefer: access restriction status (P7228) or online access status (P6954)? —Gunyam (talk) 07:21, 31 January 2023 (UTC)

I believe both properties may be applicable. online access status (P6954) is a subproperty of access restriction status (P7228). A work may be publicly accessible (denoted with access restriction status (P7228)) by visiting a physical library building holding the work. However the same work may not available online (denoted with online access status (P6954)). I've made some property updates to hopefully clear up the distinction between both properties. Dhx1 (talk) 00:07, 1 February 2023 (UTC)

Arthur Edward Wade and Arthur Edwin WadeEdit

I've made a page about Arthur Edward Wade in Wikipedia and there's now a Wikidata item for him (Q116505152). However, I've now realised he is undoubtedly the same man as Arthur Edwin Wade who is in Wikispecies and Wikidata (Q21388511). Same birth & death years, lichenologists, same part of the world, Edwin often a short-form of Edward. He must have been referred to as Edwin somewhere, but I havn't come across that usage yet. How do I get them all matched up, and his alternate second names noted. (I can do a redirect in Wikipedia but how does it work in Wikidata and Wikispecies?) MerielGJones (talk) 10:14, 31 January 2023 (UTC)

@MerielGJones: On WD, the solution is a merge - see Help:Merge#Gadget. I've done that for this instance, leaving Arthur Edwin Wade (Q21388511). Wikispecies has only one record for him, which is pointed to from his WD item. So other than considering Q21388511#P735 - his given names - WD's probably good. --Tagishsimon (talk) 10:22, 31 January 2023 (UTC)

Mixed mine and villageEdit

Drmno (Q3039540) not sure what is going on here Mateusz Konieczny (talk) 10:29, 31 January 2023 (UTC)

A user, Djordje110795, changed its meaning from village to coal mine in 2019. I've rolled it back. --Tagishsimon (talk) 10:40, 31 January 2023 (UTC)
Oh thanks - somehow I got confused and forgot that I should start from history checking Mateusz Konieczny (talk) 11:19, 31 January 2023 (UTC)

AbuseFilter/64 catching lots of cjk editsEdit

briefly looking at Special:AbuseFilter/64, i guess it didnt consider cjk chars? might not be a big issue, but the filter should be improved. RZuo (talk) 11:43, 31 January 2023 (UTC)

Allyshaleonard wrecking havoc (again)Edit

Allyshaleonard (talkcontribslogs) from MoMA is running OpenRefine again and not avoiding any possible duplicate. She is even creating items from the last run a 2nd time: Q115636727 Q116519325

The discussion from 3rd of January notes, that the doesn't reply to criticism on her talk page. Since then she hasn't answered any of the 4 questions.

The edits have the potential to fill Property talk:P214/Duplicates/humans and therefore better end quickly.-- Sharaban K (talk) 14:13, 31 January 2023 (UTC)

Hello Sharaban K.
I am a current fellow at MoMA and currently having technical difficulties with open refine. Things that are uploaded should not have been since the upload was incomplete.
I am currently working on resolving this issue.
I also see the note to change instances from individual to human and are doing so. My current leader at MoMA is still working to learn OpenRefine together and it has been a learning process. Any help you give is of course very welcome and I appreciate your patience as we resolve this issue Allyshaleonard (talk) 14:28, 31 January 2023 (UTC)
This is my first day back in office after a long break. I apologize for the occurrences and lack of response. Currently working to resolve all issues/comments and appreciate your patience in the meantime Allyshaleonard (talk) 14:32, 31 January 2023 (UTC)
To be honest, these were not even supposed to be uploaded to Wikibase yet as there were "technical difficulties" in OpenRefine, where the upload did not complete - hence the multiple uploads on the backend without knowing. I am currently resolving this issue and will be removing duplicates/merging. Allyshaleonard (talk) 14:37, 31 January 2023 (UTC)
UPDATE: all OpenRefine upload batches have been requested for reverse/deletion.
The instance of human has been added to the schema and everything will be reconciled again to avoid duplicates. Once all is deleted, we will give it another shot to meet all standards and merges.
I appreciate your patience. Allyshaleonard (talk) 15:31, 31 January 2023 (UTC)
same-topic discussion also at Wikidata:Administrators'_noticeboard#Please_Delete_Incorrect_Work_-_Deletion_Request_Made Estopedist1 (talk) 20:51, 31 January 2023 (UTC)

Collapsing property navboxesEdit

See proposal in Wikidata talk:Property navboxes#Collapsing the navboxes. --Epìdosis 15:43, 31 January 2023 (UTC)

Has the Smithsonian online information removed DOB and Place of birthEdit

I am trying to update the entry for https://www.wikidata.org/wiki/Q108744366 Kathy Caraccio in preparation of writing an article. It looks like SAAM, (as well as Nat Gallary) has removed DoB from their online information https://americanart.si.edu/artist/kathy-caraccio-6318 I noticed this change a few days ago, but attributed it to some front end updates. Does anyone on this notice board have any information about this? It looks like ti is just for living artists. Thanks for any insight. WomenArtistUpdates (talk) 17:05, 31 January 2023 (UTC)

After further investigation, it looks like I was working on a master printer where the data isn't in SAAM's database. Too obscure. Plenty of birth years on living artists. Sorry for the interruption. Best, WomenArtistUpdates (talk) 21:25, 31 January 2023 (UTC)

Change English labels from “scope” to “usage” (or similar) in constraint lingoEdit

To me, “scope” doesn’t sound quite right in the English labels for property scope (P5314) and property scope constraint (Q53869507). See proposals Property_talk:P5314#Proposal_to_change_English_label_to_stress_‘usage’ and Talk:Q53869507#Proposal_to_change_English_label_to_stress_‘usage’ to change “scope” to something that evokes the, as I find, more fitting notion of ‘usage’. ChristianKl
ArthurPSmith
d1g
JakobVoss
Jura
Jsamwrites
MisterSynergy
Harshrathod50
Wildly boy
ZI Jony
Ederporto
99of9
Danrok
Eihel
Emw
Fralambert
GZWDer
Ivan A. Krestinin
Jonathan Groß
Joshbaumgartner
Kolja21
Kristbaum
MSGJ
Mattflaschen
MichaelSchoenitzer
Nightwish62
Pablo Busatto
Paperoastro
PinkAmpersand
Srittau
Thierry Caro
Tobias1984
Vennor
Yellowcard
Ivanhercaz
Tinker Bell
Bodhisattwa
Iwan.Aucamp
Cunme
NAH
Gnoeee
The-erinaceous-one
-akko
Mathieu Kappler
Dhx1
Lectrician1
Daniel Mietchen
Luca.favorido
wd-Ryan
Amadalvarez
  Notified participants of WikiProject PropertiesBlaueBlüte (talk) 06:40, 1 February 2023 (UTC)

I am fine with the re-wording if it helps clarify things. Maybe for me, 'scope' is not a problem, but neither is 'usage', so I have no objection. Josh Baumgartner (talk) 06:45, 1 February 2023 (UTC)
or we could be the most clear and call it "entity types this property is allowed on" Lectrician1 (talk) 07:42, 1 February 2023 (UTC)
Hello BlaueBlüte  , I'll let native English speakers decide, but if there's a problem with comprehension, why not name the property more explicitly, as @Lectrician1: writes. ―Eihel (talk) 07:58, 1 February 2023 (UTC)
Ah, @Lectrician1, this might just be proving my point that “scope” can be misleading, since property scope constraint (Q53869507) and property scope (P5314) aren’t about what entity types a property is allowed on, but about whether it’s allowed as main value (Q54828448), as qualifier (Q54828449) or as reference (Q54828450). (An ‘allowed entity type’, on the other hand, is specified via allowed-entity-types constraint (Q52004125) in conjunction with item of property constraint (P2305).) ―BlaueBlüte (talk) 07:59, 1 February 2023 (UTC)
I agree with @BlaueBlüte on both comments, keeping as an alias, though, for tutorial reasons. Cheers, Ederporto (talk) 08:09, 1 February 2023 (UTC)
oh great. i get them mixed up Lectrician1 (talk) 08:16, 1 February 2023 (UTC)
Agreed with "entity types this property is allowed on". Neither "property scope" or "property usage" explain what the property is intended to be used for. Dhx1 (talk) 04:15, 3 February 2023 (UTC)

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Salgo60
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
cdo256
Epìdosis
Dhx1
99of9
Mathieu Kappler
Lectrician1
SM5POR
  Notified participants of WikiProject property constraints ChristianKl❫ 15:27, 1 February 2023 (UTC)

  • I agree "usage" is likely better. - PKM (talk) 22:33, 1 February 2023 (UTC)
  • FWIW: in projects like English Wiktionary "usage" can mean a description of actual practice, not allowed or permitted or recommend, just "here's what people are actually doing", even if it's considered bad form. OR "usage" can mean recommended practice, best practice. I'm not sure whether this information helps, but "usage" does have two very different meanings in English. --EncycloPetey (talk) 04:49, 3 February 2023 (UTC)

Property:P7966 & Property:P7967Edit

URLs used in Wikidata for P:P7966 and P:P7967 are dead

For NetBSD package (P7966), the formatter URL to use is https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/$1

Genium. 09:12, Feb 1, 2023 (UTC+01:00)

Big rollback needed for German municipalitiesEdit

I was very busy the last days to properly represent the German municipalities in Wikidata (see also User:Jobu0101/Verwaltungsaufbau Deutschlands for the project). Now some IP destoyed part of my work: 2003:C6:F72E:A4BD:9C73:8879:1498:B871. Is it possible to undo all his edits in a single click? Jobu0101 (talk) 09:22, 1 February 2023 (UTC)

Could we get to the bottom of the issue? One of the disputed P31s is described as "municipality with market privileges in Germany" and the other as "municipality without town privileges in Germany". 1) can a municipality be both of these 2) is there a source - we're dealing with unreferenced statements. --Tagishsimon (talk) 11:30, 1 February 2023 (UTC)
This is a very complicated topic because Germany is a federal state which consists of sixteen states with different rules for each state. In Bavaria (one of the states) there is the concept of having municipalities with market privileges (see de:Liste der Märkte in Bayern). Some municipalities in Bavaria have this privilege others do not. In some other state there are similar concepts also called "market", however they mean something different. Luckely, there is one global concept in Germany which applies to every municipality. Either it is a "Stadt" or it is not. I try to represent this in Wikidata by non-urban municipality of Germany (Q116457956) and urban municipality of Germany (Q42744322) (see also de:Gemeinde (Deutschland) and de:Liste der Städte in Deutschland). To answer your questions:
1) Yes, a municipality can be both: non-urban and a market. Historically however, the concept of a market is much older than Germany in its current administrative form.
2) Sources are provided in the German Wikipedia articles I linked above.
There is much more to explain, feel free to ask, if you want to go deepter into that topic. --Jobu0101 (talk) 14:38, 1 February 2023 (UTC)
Why is one instance marked as preferred in items such as Scheidegg (Q505440)? Is market municipality of Germany (Q100341898) somehow more true than non-urban municipality of Germany (Q116457956) there? I always find the ranks on P31 quite suspicious.
Anyway, a look into the history suggests that there has been one wave of edits by the IP approximately one week ago. Did you contact the IP back then to discuss the issue? Vojtěch Dostál (talk) 14:46, 1 February 2023 (UTC)
No, I did not. The problems with IPs is that they change so quickly so that usually you can't address the person sitting behind the IP. About your rank issue: Sure, market municipality of Germany (Q100341898) and non-urban municipality of Germany (Q116457956) should get ranked of the same level if the object is currently both. We have cases where this changes. Then of course only the current state should be ranked highest and the other one should obtain a qualifier with end time (P582). --Jobu0101 (talk) 14:53, 1 February 2023 (UTC)
Some IPs change quickly others don't. In Germany, most people have dynamic IPs that change every day because ISPs historically wanted to upsell the feature of having a stable IP to people who run their own server and need a stable IP for that. In the US it's more common to have stable IPs where you can actually talk to people and ban IPs to remove a persons ability to access a site. The IP in question is a German one. ChristianKl❫ 15:25, 1 February 2023 (UTC)
I just contacted the IP. --Jobu0101 (talk) 15:56, 1 February 2023 (UTC)
It is completely impossible to communicate with anyone behind an IPv6. Unless steps are taken on the ISP end to make the Interface ID stable, the Interface ID will change rapidly and unpredictably. A person/device with the same /64 but a differing Interface ID is 99% of the time the same person, with an altogether new and unconnected User Talk page. If a person's IPv6 has changed sufficiently that they no longer see their old User Talk, there is no way for us to sustain a conversation or even notify such a user of anything. Worse yet, it is similarly impossible to aggregate these User Talk pages for admins or vandal fighters to examine an audit trail of discussion or warnings during block decisions.
WMF is working on privacy enhancements that appear to rely more on browser/device fingerprinting rather than IP addresses to identify editors. So until that day comes, we will simply need to bring all IPv6 issues before admin noticeboards rather than vainly attempting to engage the user who will never hear us. (The same issues apply to all mobile users regardless of IPv4/IPv6.) Elizium23 (talk) 18:00, 1 February 2023 (UTC)

@Vojtěch Dostál: By the way: Edits of this form have taking place a few times already. A very annoying thing. If it was a logged in user, one could talk to him. Unfortunately, those edits are performed by an IP (each time another one). However, this time the situation is a bit different. Before my introduction of the item non-urban municipality of Germany (Q116457956) the item municipality of Germany (Q262166) was used and I understand the thought process of those people: Namely, market municipality of Germany (Q100341898) is a subclass of municipality of Germany (Q262166). However, there are still good reaons to use both. Nevertheless, now with the new item the situation has changed and the subclass argument does not work anymore (and if it would, I have still good reasons for the other solution). --Jobu0101 (talk) 16:02, 1 February 2023 (UTC)

So once again: Can somebody please undo the edits of 2003:C6:F72E:A4BD:9C73:8879:1498:B871? --Jobu0101 (talk) 22:04, 1 February 2023 (UTC)

I have blocked Special:Contributions/2003:C6:F700:0:0:0:0:0/40 from editing main namespace for 6 months, and left a link to this discussion so that the IP user can participate here. There is topically similar activity from this range for years, and it does not seem to be obvious vandalism to me so a discussion involving all editors seems appropriate.
If we find that these removals should be undone (or the IP editor remains silent), I have a script to revert their actions relatively easily using undo or rollback. —MisterSynergy (talk) 00:04, 2 February 2023 (UTC)
@MisterSynergy: Thanks a lot. It would be really kind if you would run your script to do so. If I note similar edits in future I let you know. --Jobu0101 (talk) 09:23, 2 February 2023 (UTC)

Bigbossfarin Galaktos Labant M2k~dewiki Mathieu Kappler PantherStrix Wiljes jobu0101  Notified participants of WikiProject GermanyVojtěch Dostál (talk) 16:32, 2 February 2023 (UTC)

@MisterSynergy: Would you or shall I do it myself? --Jobu0101 (talk) 00:42, 4 February 2023 (UTC)

GPT-3: Earth is part of HappinessEdit

### Text:
Earth is the third planet from the Sun and home to all known life.
While large volumes of water can be found throughout the Solar System, only Earth sustains liquid surface water. 
Approximately 70.8% of Earth's surface is made up of the ocean, dwarfing Earth's polar ice, lakes, and rivers. 
### N3 triples using Wikidata entities:
Q2 P31 Q3504248
Q2 P527 Q42762   (comment: preset, GPT-3 continuation follows)
Q2 P361 Q8
Q2 P361 Q8
Q2 P361 Q8
...

Wouldn't it be nice if this worked? SCIdude (talk) 17:20, 1 February 2023 (UTC)

might want to look at https://github.com/varunshenoy/GraphGPT I'm also working on using deep learning to construct wikidata items. See for example User:BrokenSegue/Psychiq BrokenSegue (talk) 17:53, 1 February 2023 (UTC)
also you can play with it at https://wikidata-game.toolforge.org/distributed/#game=84 BrokenSegue (talk) 17:55, 1 February 2023 (UTC)
Excellent! SCIdude (talk) 08:06, 2 February 2023 (UTC)
It's really good. I didn't have to press "no" to any of the suggestions — Martin (MSGJ · talk) 12:43, 2 February 2023 (UTC)

Ancient Egyptian for the "Language (mandatory)" seems impossibleEdit

I'm unable to add "Tutankhaten" as Tutankhamon (Q12154)'s birth name because I can't figure out how to use either "Middle Egyptian language" or "Late Egyptian language" or even just "Egyptian language" as qualifiers. This is very frustrating.StarTrekker (talk) 01:00, 2 February 2023 (UTC)

Disclaimer: I know next to nothing about ancient egypt or language. Language tags on Wikidata doesn't seem to include ancient egyptian. I would use birth name (P1477) and the language code "mul" with qualifer language of work or name (P407) and the Q-item for the language here, and feel free to make a guess as to which language to specify. Chronologically it's probably middle egyptian, but I'm guessing "egyptian" acts as a macro-language, in the same way that "norwegian" is a macro-language for the written forms "Bokmål" and "Nynorsk" as well as referring to the various spoken dialects. In other words "egyptian" is the safer choice. Infrastruktur (talk) 13:29, 2 February 2023 (UTC)
Edit: I just noticed "und" and "mis" language-tags are available. I think "mis" would be more correct than "mul" here. Infrastruktur (talk) 14:53, 2 February 2023 (UTC)
@Infrastruktur: Thank you.StarTrekker (talk) 18:36, 2 February 2023 (UTC)

Help:Monolingual text languages --Bean49 (talk) 21:15, 2 February 2023 (UTC)

allowed to add commons categoryEdit

when i try to add Category:Asura on Asura (Q624083) it shows "The link commonswiki:Category:Asura is already used by Item Q28747950. You may remove it from Category:Asura (moth) (Q28747950) if it does not belong there or merge the Items if they are about the exact same topic. If the situation is more complex, please see Help:Sitelinks.". how do i proceed? —Gunyam (talk) 02:33, 2 February 2023 (UTC)

you've stepped in a messy conflict on wikidata. the short answer is that a page can be linked only to one item. In this case it's already linked to an item for the category. So instead what you can do is link it via the property Commons category (P373). This is already the case for this item so there's nothing to be done. 2601:647:5F01:F510:F0BF:4467:2C58:BA9A 06:17, 2 February 2023 (UTC)
If you make sure that topic's main category (P910) is set (which it is), then the sister project links should work properly — Martin (MSGJ · talk) 12:45, 2 February 2023 (UTC)

Should I retire User:BorkedBot's Twitter tasks?Edit

Given the news that the free Twitter API will soon be shut off it looks like User:BorkedBot's tasks to 1) populate the Twitter user numeric ID (P6552) (And a few related properties) and 2) the social media follower counts on Twitter will stop working. As far as I know nobody is actually relying on this data (though I think it's cool to have). Not doing the former task will cause constraint violations. It's possible I could continue to have it work via scraping but my guess is they will start trying to restrict that given their desire for money. If it's some nominal amount of money ($10/yr) should I just pay it? In preparation I'm rerunning the import of social media follower counts now. BrokenSegue (talk) 15:34, 2 February 2023 (UTC)

I would certainly discourage paying anything -- if the (deeply unreliable) current owner of Twitter wants the promotion of updated data on Wikidata, he can operate (and pay) for it himself. I think letting it die is fine; make sure to update the various relevant pages to mark them as "deprecated because the platform stopped being sensible" or some such. JesseW (talk) 03:27, 3 February 2023 (UTC)

best practice for the representation of quantitative data and their metadataEdit

I would appreciate some help in figuring out how to best represent quantitative data records on WikiData taxon pages. I mean things like average body mass or minimum/maximum body length for organisms with a particular sex & life stage. We have looked around for examples on WikiData taxon pages but couldn't find anything that had the metadata we're looking for. After looking around and trying different things, we've created a preliminary example of a body length data record using sex or gender for sex, biological phase for life stage, and property constraint for the statistical method. However, we're getting a property scope constraint warning for the biological phase metadata record and a one-of constraint warning for the statistical method metadata. So this is clearly not the way to do it. Can somebody please advise on how to properly represent these metadata using WikiData properties?


Sylverfysh (talk) 18:01, 2 February 2023 (UTC)

Unsourced, and apparently wrong, data from a Wikipedia articleEdit

We've just had a query at the English Wikipedia help desk from an editor claiming to be Peppino D'Agostino and complaining that his age is showing as 72 when it should be 66. I checked the English WP article and found no birthdate or age in it, and said so, directing him to Google. But another editor pointed out that Google may well have got the date 1951 from Q3899403, where it was imported from it-wiki, having been inserted by an IP in 2011 with no source. Looking at w:it:Peppino D'Agostino, I see that the date was updated to 1957a couple of weeks ago, still unsourced. Of course, the WD item was not updated accordingly, so I've just updated it. But this is clearly not satisfactory: it seems odd that it should have been imported from WP in the first place, particularly without checking for a source. WP is not regarded as reliable by WP: why should it be by WD? So I started posting this to ask how we handle it. Then I realised a further complication: the original post on the help desk claims that his DoB is 1956, not 1957 (again, we have no guarantee that this is D'Agostino). I thought I would edit the item again, and remove the reference; but it objects to a DoB without a reference (reasonably) so I reverted myself.

I guess the easiest thing is to remove the DoB from the item entirely. Is that the proper way to handle it? ColinFine (talk) 19:40, 2 February 2023 (UTC)

@ ColinFine: Probably a good time to read Wikidata:Living_people#Statements_likely_to_be_challenged. Removal seems wise. BrokenSegue (talk) 21:31, 2 February 2023 (UTC)
Thanks. He has now provided a reference, so I have corrected the date and added the reference. I've never done referencing on WD before, so I'd be grateful if somebody would check that what I've done is satisfactory. Q3899403. ColinFine (talk) 21:56, 2 February 2023 (UTC)

list of items where subclass trees is clearly brokenEdit

In theory wikidata has a structured ontology so you can check what given item represents - is it a specific tree? Group of trees? Taxon? Event? Human? Mathematical term?

Sadly, Wikidata is currently quite unreliable for that purpose. For example, many things that are not events at all - are anyway indirectly classified as events. I was unaware that subclass tree is so borked when I tried using it. In effect I accidentally created detector of invalid subclass tress on Wikidata (while trying to create something else).


For example Hasso Plattner Institute (Q884105) is an event, according to Wikidata ontology. See how Wikidata classifies it:

en: public–private partnership (government service or private business venture which is funded and operated through a partnership of government and one or more private sector companies) [5]

en: funding (act of providing resources) [6]
en: income (consumption and savings opportunity gained by an entity within a specified timeframe) [7]
en: increase (enlargement or increase of an entity; increase in size, number, value, or strength; an amount by which a quantity is increased) [8]
en: occurrence (occurrence of a fact or object in space-time; instantiation of a property in an object) [9] this was unexpected here as it indicates an event !


User:Mateusz Konieczny/failing testcases has many such cases, more than I can process. If anyone is interested in fixing such broken classifications then help is welcome. And maybe if that tool exists anyway then maybe such report may be useful to someone?

(I post such cases to this page, I post limited number of cases to Wikidata talk:WikiProject Ontology and no more than once a year I post about this list to Wikidata:Project chat - let me know if that is too much and I should not post about it)

Mateusz Konieczny (talk) 21:39, 2 February 2023 (UTC)

I can't stop recommending this paper: https://www.semantic-web-journal.net/system/files/swj3337.pdf and the tool they made https://atilioa.github.io/WikidataAntiPatternAnalyzer/ BrokenSegue (talk) 23:01, 2 February 2023 (UTC)
Being simultaneously instance and subclass of another entity seems not ideal, but at least for my use case would not result in outright false data Mateusz Konieczny (talk) 23:25, 2 February 2023 (UTC)
true BrokenSegue (talk) 23:41, 2 February 2023 (UTC)
I've now fixed this particular mess (it was the incorrect presence of "occurrence" on "merge"). But your broader point is still very well made. I think the main thing that would help with this is if such errors were highlighted directly in the interface, at the time that the incorrect changes are made, and they required an extra confirmation. That wouldn't address all the existing problems, but it would at least decrease the speed at which new problems are introduced. I don't know how difficult it would be to add that feature. JesseW (talk) 03:34, 3 February 2023 (UTC)
Partial problem is that changing item can affect thousands or millions of items below it in subclass hierarchy - creating thousands or millions of violations at once. No idea how to do handle that live. Mateusz Konieczny (talk) 07:09, 3 February 2023 (UTC)
The warning could come up when toggling any item between being an event and not being an event, and other similar pairs. That wouldn't require checking further down the tree, just alerting editors that they should be sure of what they are doing. JesseW (talk) 15:46, 3 February 2023 (UTC)