Wikidata

Wikidata:Project chat/Archive/2021/12

< Wikidata:Project chat‎ | Archive‎ | 2021

Is search including unrelated entries?

I wanted to understand where Deaths in Chelsea was being used. In the search box I entered "Q9218032" and chose "Search for pages containing". These results show hits for:

  1. Deaths in Chelsea
  2. Chelsea
  3. Brentås
  4. Collagen mass in prostatic bed after radical retropubic prostatectomy.

The first two are expected but I can't find anything relating to Q9218032 in either of the last two pages' HTML or RDF triples (from https://www.wikidata.org/wiki/Special:EntityData/Q_nnnn_.rdf)

Thank you. --TFJamMan (talk) 16:51, 3 December 2021 (UTC)

For that type of search, it is easier to open the item and click "what links here" from the side panel (or from the menu if you are using mobile view). If you are using a desktop view, you can turn on a gadget to count the number of pages that link to an item at the top of the "what links here" screen. From Hill To Shore (talk) 18:10, 3 December 2021 (UTC)
For the two erronious search results, the first has a Geoname ID of 9218032 and the other has a Pub Med ID of 9218032. Search is behaving correctly here based on your criteria. From Hill To Shore (talk) 18:15, 3 December 2021 (UTC)
Thank you From Hill To Shore, that all makes sense. Now that you have resolved this discussion for me, do we / can I delete this somehow or is it automatically archived? TFJamMan (talk) 21:07, 3 December 2021 (UTC)
@TFJamMan: You could leave a section alone and it will get archived automatically after a few days. Alternatively, you can add {{Section resolved|1=~~~~}} to ask the bot to archive the section early. From Hill To Shore (talk) 21:18, 3 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. From Hill To Shore (talk) 21:18, 3 December 2021 (UTC)

Wikidata phase 1 regression

Is this is just an impression of mine or has navigating between language version of Wikipedia gotten more complicated recently?

Initially Wikidata was designed to help with interwikis between languages, but it seems the UI in some Wikipedia no longer uses them, thus making it more complicated.

Sample: try to switch from French to fr:Wikidata to en:Wikidata by navigating on Wikipedia.

How could this be corrected? --- Jura 11:47, 2 November 2021 (UTC)

Somebody thought it might be a good idea to move interwiki links to the upper right corner. -- Emu (talk) 12:00, 2 November 2021 (UTC)
The thing is that they are no longer on the page. --- Jura 12:04, 2 November 2021 (UTC)
I've seen more and more wikis having their "interlanguage links" moving from simple links in the left side bar to a "new switch language button". Bouzinac 💬●✒️●💛 12:10, 2 November 2021 (UTC)
It has nothing to do with Wikidata, really, it’s a Mediawiki User Interface design choice, see for example mw:Reading/Web/Desktop_Improvements author  TomT0m / talk page 12:33, 2 November 2021 (UTC)
Interwikis are just the initial usecase for Wikidata at Wikipedia .. --- Jura 12:45, 2 November 2021 (UTC)
TomT0m is right. Wikidata provides the data for the sitelinks but how they are displayed is an entirely separate matter and up to the skin. That is being changed as part of the Desktop Improvements project, which is independent of Wikidata. Lydia Pintscher (WMDE) (talk) 13:50, 2 November 2021 (UTC)
With "Wikidata" in this context, I suppose you mean Wikimedia Germany Development Team. I understand that you personally and your team might not have been involved in this.
Obviously, it's still data from Wikidata this is displayed (or rather no longer displayed) on it's primary usecase: Wikipedia and for which it was developed (by WMDE I guess) and from which it now regresses.
From a user and contributor perspective, it doesn't matter that much who did it and how it happened (WMF/WMDE should be able to sort this out internally), but it's obviously something that needs fixing. --- Jura 16:21, 2 November 2021 (UTC)
A better place to discuss/complain is fr:Discussion_Projet:Amélioration_de_l'interface_par_la_WMF. There has already been discussions about this on frwiki, with not so much complains actually. author  TomT0m / talk page 19:34, 2 November 2021 (UTC)
It's actually unrelated to frwiki. The problem doesn't even affect users of a single wiki at all. --- Jura 08:30, 9 November 2021 (UTC)
The specific page for this exact change is at mw:Reading/Web/Desktop_Improvements/Features/Language_switching. It's not quite clear if the individual wikis have any choice in (eventually) adopting the change. But wikidata has about as much to do with it as it has with the layout Google chooses for the data snippets it extracts. Karl Oblique (talk) 08:23, 16 November 2021 (UTC)
I left a note there, but somehow it's unclear where this point is being discussed. The talk page redirects to a more general one. --- Jura 13:09, 23 November 2021 (UTC)
Seems @Theklan: commented there about frwiki: mw:Talk:Reading/Web/Desktop_Improvements#Impact_on_other_languages_in_France_of_burying_the_interwiki_link_in_the_bottom. --- Jura 13:10, 23 November 2021 (UTC)
Tracked in Phabricator
Task T290480
You can try in Phabricator. I just solved it for Basque Wikipedia here. But the developers are just closed to any critic in this sense, even if they broke the interwiki linking system, the contenttransation link and the buried it in the main page because they didn't ever make a design of how this should fit in the main page. Theklan (talk) 06:36, 24 November 2021 (UTC)
That's just the title page, but minority languages disappear from all articles. --- Jura 20:37, 1 December 2021 (UTC)

[Feedback Requested] Introducing a dedicated section on Wikidata Item pages for classifying properties

Hi all,

We had a lot of conversations about the Wikidata ontology during Wikidata Data Quality Days and WikidataCon. One issue came up again and again: New users unintentionally modifying the Wikidata ontology leads to errors and inconsistency. We would like to get your input about a first step that we propose to improve this situation.

What we are proposing

We are proposing to introduce a dedicated section on Item pages for classifying Properties. This section, named "Classification", will live below the Termbox and above the “Statements” section. The new section will make it more obvious that some Properties are special and modify the ontology. For consistency we will also have this section on Property pages.

This first step will only involve the display of statements after saving. We might consider making deeper changes to the UI and recommendation system at a later time, based on your experience with this change.

Please add your input directly to this ticket so that we can collect all of your thoughts in one place.

If you have any questions please do not hesitate to ask.

Cheers, - Mohammed Sadat (WMDE) (talk) 11:58, 15 November 2021 (UTC)

The proposed section will contain the following properties:
  • P279 (subclass of)
  • P31 (instance of)
  • P361 (part of)
  • P1647 (subproperty of)
Origin: https://www.wikidata.org/wiki/Wikidata:Item_classification
  • P1709 (equivalent class)
  • P3950 (narrower external class)
  • P2888 (exact match)
  • P1382 (partially coincident with)
  • P2670 (has parts of the class)
  • P527 (has part)
  • P3113 (does not have part)
  • P2737 (union of)
  • P2738 (disjoint union of)
  • P2445 (metasubclass of)
  • P1963 (properties for this type)
  • P3176 (uses property)
  • P1889 (different from)
  • P460 (said to be the same as)
  • P2959 (permanent duplicated item)
  • P1269 (facet of)
  • P2860 (cites work)
Sounds good. Above the properties listed in the ticket as "classifying properties". First group seems fine. The second could probably use some improvement. --- Jura 12:17, 15 November 2021 (UTC)
I'm sorry if my questions seem unconstructive. They're not meant that way, and they're genuine questions, not criticism.
As far as I can tell, this proposal is based on the premise that "some Properties are special" "classifying properties" and form "the ontology", as opposed, it seems, to other properties which are not considered to be part of this ontology.
  • I don't think that's reflected in the Wikibase data model, which has at some point made what I assume is a deliberate decision not to special-case even instance of (P31).
  • If it's reflected in the documentation, I haven't been able to find it.
  • As some of the other comments show, it's not immediately obvious to people which properties are special and which ones aren't.
Just to be clear: I'm not asking for a formal, legalistic, or mathematical definition of what makes properties "special". An approximate guideline is quite enough for me (but it should go beyond defining "special" in terms of "the ontology" and vice versa).
But I am asking for that rough-and-ready "I know it when I see it" sense: what makes properties special?
Once we've decided on that, we can create an item Qwhatever representing special properties, mark the special properties as instances of it, and then we can modify the Wikibase software to display properties which are instance of (P31) Qwhatever differently. Is that how the proposed feature would be implemented? Streetmathematician (talk) 15:59, 15 November 2021 (UTC)
@Streetmathematician Thank you for your questions!
Yes, all Properties are equal in the Wikibase data model. This is to allow for a maximum of flexibility and Community control. As a side effect however, this currently means that the Wikidata ontology can only be defined bottom-up (in each Item) and not top down (at a central place). The worst thing about this is that it often happens unintentionally. It is very hard for new editors to wrap their head around what exactly is the right thing to do. It also makes it really difficult for the Community to define and maintain a consistent ontology through all of Wikidata. This in turn makes it really hard to actually use Wikidata’s data in practice. This proposal is trying to make things a little better and to learn from the discussions, without making any fundamental changes for now. This is why in terms of implementing this, we will choose an option that needs minimal developer resources for now (e.g. simply changing the existing configuration setting).
We totally agree that it’s not immediately obvious to people (including us) which properties are special and which ones aren't. That’s natural as there was no need to reach consensus about this until now. But it’s also a major problem because of all the described bad side effects that come with this. To solve this, a clarifying discussion (this call for feedback) and a place to codify the results (the proposed change in UI for now) seem important. So we really hope that we will be able to answer your questions about a useful guideline together in the ticket. - Mohammed Sadat (WMDE) (talk) 11:39, 16 November 2021 (UTC)
Thanks for your response! It didn't quite answer my question, but it did answer enough of it for me to form an opinion on whether it's a good idea to do anything like this without first (discussing and) documenting the fundamental aspects.
Oppose. This proposal is a test balloon for fundamental and far-reaching changes to the Wikidata data model, trading "flexibility and Community control" for benefits which can be achieved less invasively.
The technical solution proposed (hard-code certain properties as "special" in the Wikibase configuration files) is inflexible, inconsistent, and unnecessary.
I strongly support documenting (and, in the process, discussing) policy proposals on "special" statements, then suggesting technical changes based on such if consensus appears stable. Starting with an ad-hoc technical proposal is not how to do that. Streetmathematician (talk) 19:48, 19 November 2021 (UTC)
  • I have some second thoughts on this. Depending on the types of items, would it really be an improvement?
Currently P31 and P279 are already shown above and this can easily be configured.
For items about people (P31=human (Q5)), what would it help to show all those other properties above others? I don't really see that.
Even for items like Tempelhofer Ufer 23–24 (Q15260574), would we want to see has part(s) of the class (P2670)=column (Q4817) above more essentially things? The general tendency is to add these below everything else.
Given the backlog with other layout questions, maybe it's better to spend development time, resources and funds on features actually requested by the Wikimedia community. --- Jura 10:51, 16 November 2021 (UTC)
I agree. Many improvements are expected by the community (not to mention Citoid integration for example). This change do not seem urgent at all. Ayack (talk) 11:30, 17 November 2021 (UTC)

do not follow sitelink redirects when redirect badge is used

Tracked in Phabricator
Task T278962

Redirect pages on Wikimedia projects can still not be connected to Wikidata items as sitelinks even when redirect badge is used. This force users to use an ugly workaround. The last task which I found is here, but existed many tasked before, one of them was initiated on 5 August 2013!

@Ladsgroup, AKlapper (WMF), Lydia Pintscher (WMDE): this is not solved for many years, is there any hope that this will be solve soon given all the importance of this task for all wikipedias? I'm a software developer myself, even though my main language is python, I can try to contribute to this issue. The main problem for me is where can I test my code? I need to set up first a development environment with both Wikibase Client and Wikibase Repository? Or someone will do this issue in the next few months? --Northumber (talk) 14:52, 1 December 2021 (UTC)

Hi, I don't work for WMDE (and Wikidata team) anymore and this is my volunteer account. So I'm not the right person for this discussion. Amir (talk) 15:04, 1 December 2021 (UTC)
Hi, I don't know (or even define) the priorities of the Wikidata team - mw:Bug management/Development prioritization might only provide some general hints. :-/ --89.103.185.228 21:02, 1 December 2021 (UTC)

meeting and list of meetings mixup

At https://www.wikidata.org/w/index.php?title=Q50877551&action=history there seems to be mixup of the two. Can someone kindly unmerged them and revert the corresponding Krbot task. I'd do it myself, but apparently it's preferred that people read about it here and do it themselves. @Congolandia.g:--- Jura 17:49, 1 December 2021 (UTC)

Sorry, but where's the mixup? All the linked articles are lists of the meetings of the European Council... Which ones should be unmerged in your opinion? --Congolandia.g (talk) 17:57, 1 December 2021 (UTC)
IMHO Q2993919 should be (an instance of) a meeting (even if it went on for several days) and not a list of meetings.
Accordingly, this https://www.wikidata.org/w/index.php?title=Q50877551&diff=973600102&oldid=973600044 merger should be undo --- Jura 18:26, 1 December 2021 (UTC)
I see what do you need. So I should undo the merge, but then move the link to the page in French to the list, because it lists the meetings... -Congolandia.g (talk) 19:27, 1 December 2021 (UTC)
Done. Check if it works like you wanted. -Congolandia.g (talk) 19:36, 1 December 2021 (UTC)
Looks ok, but most if not all others on https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere&target=Q1526506&uselang=fr should be changed too. Apparently the Krbot task is too old to be reverted. --- Jura 20:31, 1 December 2021 (UTC)

merging two item is complicated

1. Q1811179 and Q3485434 should be merged because: (a) common sense, the two concepts are both referring to a Fossil Site, using the same depiction; (b) authority suggested so, see [1] (c) ​english wikipedia pages simply redirects

2. none of the item use the official English name (see [1][2]). One redirection was done in English wikipedia[3], but it would be better to stick to official name.

3. conflicting label/descriptions in several language that I'm not familiar. help:Merge is not enough, guess conflict will be resolved using google translate and commons sense.

4. conflicting sitelinks in two items, which one to keep will depends on common sense again.

Hello Dkyd, please remember to sign your posts on discussion pages and the like. Regarding the items you mentioned, they appear to refer to slightly different concepts, i. e. to a group of fossils and to the site of their discovery, respectively. Karl Oblique (talk) 21:39, 30 November 2021 (UTC)
thanks @Karl Oblique, I updated signature.
your suggestion is reasonable, and my investigation shows four different concepts
  • (1.1) Chengjiang Biota (biota, i.e. the flora and fauna of a region), supported by "The Chengjiang Biota, from Yunnan, China, is the most diverse assemblage of Early Cambrian marine fossils known. "[4];
  • (1.2) Maotianshan Shale (fossils group, geological formation) , supported by "The fossil material studied here (Supp. Table 1) comes from the Maotianshan Shale Member of the Yu'anshan Formation" [5]. note that shale and biota are different "The biota of the Burgess Shale appears to be typical of middle Cambrian deposits" [8]
  • (1.3) Chengjiang Fossil Site (a place, a UNESCO World Heritage Site), supported by "The Chengjiang Fossil Site, located in the Province of Yunnan, China, conserves fossil remains which are of exceptional significance. ... The fossils and rocks of the Chengjiang Fossil Site, together, present a complete record of an early Cambrian marine community. ... The Chengjiang Fossil Site is state-owned and protected ..." [2]. criteria viii, "to be outstanding examples representing major stages of earth's history, including the record of life, significant on-going geological processes in the development of landforms, or significant geomorphic or physiographic features;" [6] similarily, "The "Burgess Shale" property, which was previously inscribed on the World Heritage List, is part of the "Canadian Rocky Mountain Parks". " [9]
  • (1.4) The Chengjiang Fossil National Geopark (a poi, national park where the heritage site was protected), supported by "Map showing relationship of the Chengjiang Fossil Site to the Chengjiang Fossil National Geopark" [7]
therefore, several issues to be fixed (looks like there will be a lot of editing effort, so we need to reach some agreement before editing)
  • (2.1) English wikipedia pages corresponding to the two items are linked by redirection, see https://en.wikipedia.org/w/index.php?title=Chengjiang_biota&redirect=no, the question is how many wikipedia pages should we maintain for the above four concepts? should this be treated similar to Q4998607 Burgess Shale type fauna, Q852085 Burgess Shale [8] [9] .
  • (2.2) Note that Q852085 use Property:P1435 to specify Burgess Shale's relation to UNESCO Heritage Site (national park), how to proceed
  • (2.3) Britannica's definition seems mistaken, "Chengjiang fossil site, also called Chengjiang Maotianshan Shales, formation in China containing fossils dating to the Terreneuvian Epoch of the Cambrian Period (541 million to 521 million years ago). " [1]
  • (2.4) further fix wikipedia language sitelinks
  • (2.5) further fix incoming links
references
-- Dkyd (talk) 05:48, 1 December 2021 (UTC)
Yeah, no, you';; have to take it up with the articles on enwiki and hope for someone to do the same on dewiki. Karl Oblique (talk) 03:44, 2 December 2021 (UTC)

L'Hospitalet de Llobregat train station / Rambla Just Oliveras metrostation

Q2536322 is confusing. Most wiki's only describe the metrostation, while others only describe the train station. The two stations are not fysically connected and have different names. Passengers have to go to the street, to change. I suggest that a new item be created for only the train station. L'Hospitalet de Llobregat train station. Smiley.toerist (talk) 10:38, 1 December 2021 (UTC)

There is also Q9303809 used bij the PL wiki.Smiley.toerist (talk) 10:59, 1 December 2021 (UTC)
Metro and railway stations should probably be separated into indiviual items even if passengers would not have to cross the street. Thierry Caro (talk) 17:09, 1 December 2021 (UTC)
OK: Q9303809 becomes the metrostation and Q2536322 the train station.Smiley.toerist (talk) 23:18, 1 December 2021 (UTC)
  Done. Please check the results. There are a few things left over:
  • The creation date for the train station is problably not 1987 (metro extention)
  • I cant read the Korean script, zo I dont know if they refer to the metro or train station.
  • I did not go into the identification codes
  • It would be nice if there are metrostation pictures, but unfortunatly not, so in some wiki's the pictures dont match the text.Smiley.toerist (talk) 10:25, 2 December 2021 (UTC)

items for redirects with subject has role (P2868) = Wikimedia redirect page (Q21528878)

The other I noticed such statements and, as I can't see its use, I added a corresponding constraint at subject has role (P2868) (see Property_talk:P2868). 

SELECT ?item ?itemLabel ?itemDescription ?sls ?sts ?inst ?instLabel
{
	?item wdt:P2868 wd:Q21528878 ; wikibase:sitelinks ?sls ; wikibase:statements ?sts .
    OPTIONAL { ?item wdt:P31 ?inst }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

The question is now what to do with these items, at least with the ones that only link to redirect pages and are instances of "duplicate".

Apparently no other P31 was found, so I suggest we delete these items.

@Fidoez, Paine_Ellsworth: who edited some. --- Jura 12:50, 2 December 2021 (UTC)

Cleaning up some Mites

Hi everyone. https://www.wikidata.org/wiki/Q2441993 and https://www.wikidata.org/wiki/Q19137 are on the same subject. There is an issue with some languages though, with the German https://de.wikipedia.org/wiki/Milben not being linked on the English https://en.wikipedia.org/wiki/Mite, but indeed vice versa.

I wanted to merge the items with the gadget, but it did not let me. I think I am not qualified to continue with this, so I would be grateful if someone with more experience could pick this up. This issue has persisted since at least 2015, since that is when someone else had complained in the 'talk' Section of the english article. -- Banvd (talk) 21:30, 1 December 2021 (UTC)

They're on the same subject, but they are not the same thing. In essence, Q2441993 are a set of organisms commonly called 'mites'. These are asserted to be a subclass of Q19137 'Acari'. Q19137 'Acari' is a formally recognised taxon. A number of wikipedias have articles on both subjects. You can be certain sure that these two items will not ever be merged. It's possible that language wikipedia articles may be linked to the wrong one of the two items; if so, that can be remedied. --Tagishsimon (talk) 21:35, 1 December 2021 (UTC)
mite (Q2441993) is for mites. Acari (Q19137) is for mites and ticks. Nosferattus (talk) 01:40, 3 December 2021 (UTC)

URL update request

At DSSTox substance ID (P3117), could someone take a look at the URLs? Here I've made an update request. -DePiep (talk) 16:08, 2 December 2021 (UTC)

I think you already made the correct change on the property itself. It just takes some time to propagate to each item. --- Jura 16:11, 2 December 2021 (UTC)
OK. Thx. I couldn't get it working so thought better not touch it & ask a more experienced editor :-) -DePiep (talk) 18:59, 2 December 2021 (UTC)

Duplicate item

I am new. I don't know how to merge these two:

Please merge them. -- Perrythwi (talk) 17:48, 8 December 2021 (UTC)

Done. See Help:merge. --Tagishsimon (talk) 17:55, 8 December 2021 (UTC)
This section was archived on a request by: Stang 19:36, 8 December 2021 (UTC)

Low-quality references by Magnus and his bot - can we fix them?

Magnus has for years been producing items with low-quality references - they usually only have reference URL (P854) - see Štefan Leonard Kostelničák (Q109833604) and several hundred more created a few minutes ago. Without stated in (P248) and retrieved (P813), it is very difficult to work with these references or cite them in Wikipedia modules. Is someone willing to take on the task of improving them at least a little bit? It would mean processing some URLs with RegEx (either via queries or with dumps) and then assigning stated in (P248) to them. Assigning retrieved (P813) is likely impossible. Thanks for your thoughts on this, Vojtěch Dostál (talk) 16:52, 30 November 2021 (UTC)

seems to me that getting him to improve his additions is a better use of time. At the very least adding a retrieved date. BrokenSegue (talk) 17:02, 30 November 2021 (UTC)
It seems to me that generally they are better than that. Not sure how a toolforge link ended up in there. Retrieved time might be complicated, as the age of MxM catalogues tends to be unknown. --- Jura 17:23, 30 November 2021 (UTC)
@BrokenSegue Yes that would be best - I've tagged him here and I had also written him about it some time ago on his talk page (Topic:Vit29jh9tlbjpzt3) - but Magnus is of course very busy and hasn't had time to do this. I find it very difficult to ask anything of him, knowing that he is bombarded by requests like this from all sides. Vojtěch Dostál (talk) 17:24, 30 November 2021 (UTC)
The problem is that even if one fixes stuff for others, the person (or bot) will likely add more of the same .. so it's preferable to go to the source and add a cleanup request to Wikidata:Bot_requests. --- Jura 17:30, 30 November 2021 (UTC)
@Jura1 Yeah, but what do you suggest? We can either keep the errors accumulating or try to fix at least some of them ourselves. I could write on Magnus's talk page every day, each time with a different bug request on one of his tools. It's just not possible to do for one person. Vojtěch Dostál (talk) 17:35, 30 November 2021 (UTC)
The sample you mentioned seems to be a bug. If so, the bot should be blocked until it's fixed.
Eventually, we should also try to get all bots up to current standard.
There are a lot of references that could benefit from normalization, but we haven't really developed a nice way to do that. Understandably, bot operators who were up-to-date before don't necessarily want to update their past uploads. --- Jura 17:47, 30 November 2021 (UTC)
I've seen much worse from other bots. I don't want to excuse low quality items but we shouldn't single out Magnus when there are far worse offenders. Gamaliel (talk) 17:38, 30 November 2021 (UTC)
@Gamaliel There are certainly much more serious offenders but few of them are such prolific item creators as him. So any problem, however small, suddenly becomes more visible and more difficult to fix. To tell the truth, I have not seen any other large-dataset bot producing items which merge several URL-only references into one instead of inserting distinct references to each statement. That will be nearly impossible to disentangle - and it's been happening for years so it's likely tens of thousands of statements that we cannot possibly query for using a standard Wikidata Query Service. Vojtěch Dostál (talk) 13:21, 1 December 2021 (UTC)

Replied here, thanks all! --Magnus Manske (talk) 09:01, 3 December 2021 (UTC)

Q17405793 vs Q62627163

What is the difference between racewalker (Q17405793) and pedestrian (Q62627163)? --HarryNº2 (talk) 12:50, 2 December 2021 (UTC)

@Gamaliel: who created pedestrian (Q62627163) - person who engages in pedestrianism, or competitive walking.
I first thought you were asking about pedestrian (Q221488). --- Jura 13:02, 2 December 2021 (UTC)

::I'm afraid I don't know enough about the subject to know if there is a distinction between those two terms. Gamaliel (talk) 15:40, 2 December 2021 (UTC)

@HarryNº2: pedestrian (Q62627163) is the historical term and racewalker (Q17405793) is the modern term (for the modern version of the sport). Nosferattus (talk) 01:45, 3 December 2021 (UTC)
In the meantime I have read the English article about it. Thanks!
It would be nice if someone with sports knowledge could add the related properties. HarryNº2 (talk) 07:49, 3 December 2021 (UTC)

Linking specific plant/animal individuals to their species

Hello, I'm having hard time understanding how specific plants or animals (often long-lived or otherwise famous specimen) are linked to their species. Here are some examples I gathered:

I'm wondering if we can come up with a way of labelling specific animal or plant individuals which will enable us to query for "individual's items" per taxon Vojtěch Dostál (talk) 16:53, 2 December 2021 (UTC)

There are also remarkable tree (Q811534), individual animal (Q26401003) and animal breed (P4743). --- Jura 17:11, 2 December 2021 (UTC)
I notice dog (Q144) has Canis familiaris (Q20717272) and Canis lupus familiaris (Q26972265) as qualifier on its instance of (P31) property. horse (Q726) has a similar qualifier, and is applied to thoroughbred racehorses. In the case of type specimens, e.g. MNHN-IU-2013-916 (Q105565011), subject has role (P2868) is used: Q105565011 § P2868.
An example of an item that is linked:
And one that's not:
--William Avery (talk) 15:39, 3 December 2021 (UTC)
@William Avery Yeah, the examples are numerous and it seems there really is a need for a systematic solution. I'm wondering if this calls for a new property, something like "is taxon" but we could definitely come up with a better name. Let's hear what others think -   WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Vojtěch Dostál (talk) 19:39, 3 December 2021 (UTC)

Global ban for 1Goldberg2

Per the Global bans policy, I’m informing the project of this request for comment: RfC/Global ban for 1Goldberg2. – Mrakia 12:04, 3 December 2021 (UTC)

Creating a dictionary of Urdu on Wiktionary

I want to know whether there is any scope to create Urdu Dictionary on Wiktionary?  – The preceding unsigned comment was added by Hamidnadvi (talk • contribs) at 09:49, 4 December 2021 (UTC).

It already exists: in Urdu itself (Urdu Wiktionary (Q33109216)) and several other languages (Q9107463#sitelinks-wiktionary).
We might even have lexeme here at Wikidata in Urdu. Wikidata:Lexicographical data might help. --- Jura 14:28, 4 December 2021 (UTC)
Indeed, we do have Wikidata lexemes in Hindustani (more information here). Mahir256 (talk) 14:35, 4 December 2021 (UTC)

Spam

Every weekend I spend around an hour deleting just spam items related to Iran. And every week is more than the week before. Do we want to do something about this? One suggestion is that like most large/medium wikis we should require an account for creating item. Does that make sense? Amir (talk) 16:09, 4 December 2021 (UTC)

I'm going to guess the problem is we don't have enough people who speak the langauge. I don't think wikidata has/should have the power to control policies on other wikis. BrokenSegue (talk) 17:10, 4 December 2021 (UTC)
@BrokenSegue ugh. I need to proofread my messages. I meant "we should disallow creation of items but IPs" similar to basically any large wiki. Amir (talk) 20:46, 4 December 2021 (UTC)
I think we are indeed converging to the ban of IP editing. Vandalism is another aspect of the problem.--Ymblanter (talk) 19:38, 4 December 2021 (UTC)
Seems hardly justifiable in my opinion. Among IPs and newcomer accounts (i.e. not yet autoconfirmed), the amount of good edits is by far larger than the number of vandalism acts. We would lose a valuable source of edits. —MisterSynergy (talk) 20:34, 4 December 2021 (UTC)
@MisterSynergy @Ymblanter I don't support banning all of IP edits together but I do support requiring having an account to be able to create pages (including items). This is a low hanging fruit we can have without hurting good edits too much. Amir (talk) 20:47, 4 December 2021 (UTC)
The situation particularly difficult for content related to Iran for some reason. Other admins active in the fields of deletion/patrolling will likely be aware of the problem. However, items are by far not only created by IP users, thus a restriction that disallows item creations by IP users would likely not be very effective. —MisterSynergy (talk) 20:30, 4 December 2021 (UTC)

P106

Hello everyone. In Hebrew Wikipedia we are voting for keeping or removing importing occupation (P106) from Wikidata to Template:Infobox person (Q6249834). Many times the occupation (P106) includs too many occupations which part of them are main occupation/s and part minor occupations and some only hobbies. How I can use the reason for preferred rank (P7452) (which item from the list of Wikidata reasons for preferred rank (Q76637123) is suitable)?
For example Benjamin Franklin (Q34969) have only two main occupations which olready marked as preferred rank. Which qualifier should be added her for reason for preferred rank (P7452) from the list of Wikidata reasons for preferred rank (Q76637123). Geagea (talk) 10:47, 1 December 2021 (UTC)

You should not do any such thing. In general, we do not editorially promote certain occupation values to preferred and keep others normal because there is no source establishing that preferred/normal differentiation, and because although it might be convenient for a handful of applications such as yours, it complicates and frustrates other applications which have a dependency on the same data. There are ways in which Hebrew wiki's template could deal with the situation, such as sampling the occupations, or choosing the most used occupations across wikidata from the set of occupations on a single item. I really cannot overstress the point that your proposal would be a great abuse of wikidata. --Tagishsimon (talk) 13:23, 1 December 2021 (UTC)
@Geagea This is very important, I wonder if the Wikidata community is in favor of enabling such inherently subjective choosing of most important occupation (P106). Actually I'd be in favor of allowing that, because occupation (P106) really is a dumping ground for all sorts of occupations and many of our largest content users including Wikipedias will be interested in just a hand-picked selection of the most importent ones. Vojtěch Dostál (talk) 13:29, 1 December 2021 (UTC)
If the Wikidata community is in favor of enabling such inherently subjective choosing, then it should get in the sea. No question about that. --Tagishsimon (talk) 13:33, 1 December 2021 (UTC)
@Tagishsimon I'm being a devil's advocate here, but... We already allow subjective selection of statements for preferred rank, even if we pretend we're completely objective. Help:Ranking#Preferred rank gives one example - choosing "the result of the most commonly used or scientifically valid method"; isn't that personal choice too? We'd have to be really careful here but this sort of data curation isn't something completely new. Vojtěch Dostál (talk) 13:41, 1 December 2021 (UTC)
Sure, but in effect there's a rational basis for that; and we're talking the difference between one measurement, or another, of the same thing, rather than (from a truthy standpoint) throwing out a whole raft of occupations to make some rudimentary template work. --Tagishsimon (talk) 13:50, 1 December 2021 (UTC)
I don't think it's subjective. wiki projects want to use P106 in the main template of Infobox person. There are main occupation and there are minor. For example it is a ridiculous to add chess player (Q10873124) for Benjamin Franklin (Q34969). Does freemason (Q23305046) is a suitable occupation for Benjamin Franklin or slave owner (Q10076267) or postmaster (Q1416611) All the occupations should be shown in the main Infobox template? Geagea (talk) 13:53, 1 December 2021 (UTC)
I'm sure there is some extremely objective way in which Benjamin Franklin's roles as statesperson (Q372436) and inventor (Q205375) differ from his work as a musician (Q639669), dilettante (Q1225491), chess player (Q10873124), or freemason (Q23305046). The use of that information to consumers of the data, including the wikipedias, is obvious. If the current model does not allow for that, it is flawed and the discussion should be how to fix it: is there, for example, a set of facts that could be added that demonstrate the difference instead of merely asserting the priority? Something like total time spend would work, alas we don't have that data.
In any case I find the reqest entirely reasonable even if it cannot be accommodated and don't quite see the neccessaity for the level of hostility in the response. Karl Oblique (talk) 04:01, 2 December 2021 (UTC)
I do think that sorting the data in P106 serves both:
a. make the data to be used in Wiki projects and in external applications. it's one of Wikidata goals as far as I remember.
b. It's improve the data in Wikidata itself. Few occupations are main (the best would be to research criterias why it's main like Karl Oblique suggested: total time spend) and other simply not the main occupation. Geagea (talk) 10:32, 2 December 2021 (UTC)
You might be looking for professions in the occupation field (a frequent confusion). If so, you should attempt to filter by value type. --- Jura 10:43, 2 December 2021 (UTC)
Capturing heuristics was my first thought upon reading this too. Total time spend is a good one, but obviously hard to accurately source. Another that would be easier to achieve is the number of references supporting a statement (which statistically you'd imagine would prioritise the most relevant). In a way it would be a useful incentive for editors to add plenty of references to the statements they want to appear in infoboxoes. SilentSpike (talk) 11:44, 2 December 2021 (UTC)
See some examples:
someone already prefferd politician (Q82955) for George Washington (Q23).
Nicolaus Copernicus (Q619) was astronomer (Q11063), mathematician (Q170790) and polymath (Q270141). All the rest are included in these occupations or really minor occupations.
Hector Berlioz (Q1151) was mainly composer (Q36834).
I think that usin "Preferred rank" and using reason for preferred rank (P7452) (we need to update list of Wikidata reasons for preferred rank (Q76637123) ofcourse) is needed. The "Preferred rank" seems to be intuitive as used in George Washington (Q23).
I don't think we have a problem with source to "total time spend" as it can conclude in every book that describes the person. But "total time spend" is not the only criteria possible her. Geagea (talk) 23:17, 4 December 2021 (UTC)
I'm not active at Hebrew Wikipedia, but I would advise any project to be highly critical of the data drawn from Wikidata, and allow common sense (local control) to override blind importation of data. Local infoboxes should be modified/customized as appropriate, not Wikidata items. Wikidata items can have enormous amounts of indiscriminate data; usually only a select portion is relevant for any given use. There is no good way to harmonize data usage or priority across different projects, infoboxes, and purposes. Wikidata is messy and primarily for robots. Anything that's intended to be viewed and read by humans should have heavy human oversight and discretion. (And as an aside, I think slave owner (Q10076267) should systematically be moved to social classification (P3716) and discouraged from occupation (P106), similar to enslaved person (Q12773225): while slave trader (Q17769800) is an occupation, slave owner is a social role more akin to owner-occupier (Q4993251).) -Animalparty (talk) 20:01, 1 December 2021 (UTC)

State national guard

I want to show a revolutionary war veteran Samuel Borland I (Q109916105) as a member of their state militia, but it gives an error message as either a military_unit or a military_branch. How should it appear? --RAN (talk) 04:24, 4 December 2021 (UTC)

why Sheikh Asif item is getting delete

Hi i have created an Item with the name of Sheikh Asif before 2 months and it was there and yesterday it was deleted and i try to recreate but i dont know why its getting delete when he have everything.

--Aroojakhan (talk) 08:01, 9 December 2021 (UTC)

I have restored Q109987797 as it appears to have both sources (including Times of India) and identifiers (albeit weakly - only Facebook and Google News), so arguably satisfies notability criterion 2. I recommend that you improve the identifiers. For future reference, the correct venue for an undeletion request is WD:AN. CC @Lymantria. Bovlb (talk) 18:23, 9 December 2021 (UTC)
Has been LTA target. A small interview and facebook + google news are not only weak, they're not independent - info driven by the subject. Lymantria (talk) 20:04, 9 December 2021 (UTC)

Further discussion can take place at Wikidata:Requests_for_deletions#Q109987797. Bovlb (talk) 16:43, 10 December 2021 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Bovlb (talk) 16:43, 10 December 2021 (UTC)

Add NULL ("no value") to Item

How can I add an empty value (shown as "no value") to a property? Does the property has to support it?
The usecase would be that I want to add CIP data sheet (P8886) to 9×23mm Largo (Q2818782). The problem is that there is no CIP data sheet for this ammunition. I still want to add that information though so that it is displayed as "no value". Can I do that and if yes does it work with the default editor or do I have to use QS for that? Thanks for the information! --D-Kuru (talk) 12:36, 10 December 2021 (UTC)

Help:Statements#Unknown_or_no_values attempts to explain it. See Help:QuickStatements if you want to use that. --- Jura 13:00, 10 December 2021 (UTC)
Thanks a lot for the help. For future reference: item|property|somevalue or item|property|novalue --D-Kuru (talk) 16:47, 10 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 17:18, 10 December 2021 (UTC)

Forcing a refresh

Hi. I was wondering if there is a way to update an entity without having to edit it. I've tried both a purge action as well as a nulledit using PWB, but the latter complained with an error message. Neither of those worked. --Infrastruktur (T | C) 21:32, 4 December 2021 (UTC)

Guess I should rephrase that to something that makes sense... Changed the formatter url on some properties. Have to wait for 24 hours after the last of those edits, but then it would be nice if someone of administrator rank could clear the cache on a huge amount of items. The reason I can't do this myself is because it would take an unreasonably long time, several days in fact. --Infrastruktur (T | C) 10:16, 5 December 2021 (UTC)

According to this, I guess I'll have to wait 24 hours before doing a purge. Is there anyone rate-limit exempt that I can ask to undertake a mass-purge on about 66 000 items either tomorrow or a bit later? Edit: It might not be necessary if pages are only cached for 24 hours, but at least on the local wiki I've seen pages cached for way longer than that. --Infrastruktur (T | C) 23:45, 4 December 2021 (UTC)
Nevermind I guess. Had a look at an item that hasn't been edited in a while, and it seems like the changes are propagating nicely now. --Infrastruktur (T | C) 20:00, 5 December 2021 (UTC)

How to stop ongoing vandalism

A serial vandal is active on Wikidata creating non-sense items, but I have no idea how to nominate them for deletion as there is no "Nominate for deletion" button like on the Wikimedia Commons, how can I expose his misinformation? For context, it is the "Musée Annam" global vandal, I reported him at the Wikimedia Commons but there has been no response for over a day and he has been issuing death threats, because I am banned for life from the Meta-Wiki I cần't report him to the stewards so I don't know how to stop his ongoing creation of non-sense items here without locally nominating them for deletion. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 08:00, 5 December 2021 (UTC)

You can simply leave a note at Wikidata:Administrators' noticeboard to report the user. Individual items can be nominated for deletion using the "RequestDeletion" gadget at Special:Preferences#mw-prefsection-gadgets. —MisterSynergy (talk) 08:20, 5 December 2021 (UTC)

Do we need a separate data set for the Greek form of Louis?

Do we need a separate data set for the Greek form of Louis? Or should Louis (Q2897866) and Louis (Q97156058) be merged? --HarryNº2 (talk) 14:17, 5 December 2021 (UTC)

Because writing system (P282) is different, it will be better not to merge them. What will you win merging them? Edoderoo (talk) 16:20, 5 December 2021 (UTC)

Using STR results in "Query timeout limit reached"

I've been using the following query to build minimal working examples because of its simplicity. 

SELECT ?a ?b ?c {
  ?a ?b ?c.
}
LIMIT 1
Try it!

However, when I try the following, I get "Query timeout limit reached". 

SELECT ?a ?b ?c {
  ?a ?b ?c.
  BIND(STR(?a) AS ?a)
}
LIMIT 1
Try it!

Does anybody know why this happens?

@ Rdrg109: Not sure. But I note the SPARQL specification for BIND states "The variable introduced by the BIND clause must not have been used in the group graph pattern up to the point of use in BIND." To the extent I understand what that means, I note that your query seeks to bind the string value of an a priori ?a to ?a. If we bind STR(?a) to something else, the problem seems to go away. So...
SELECT ?a ?b ?c ?z {
  ?a ?b ?c.
  BIND(STR(?a) AS ?z)
}
LIMIT 1
Try it!
--Tagishsimon (talk) 21:12, 5 December 2021 (UTC)
I agree. The code is illegal SPARQL. An assignment using the AS keyword in BIND, SELECT or GROUP BY clauses may never use a variable name already in scope. The SPARQL engine in WDQS doesn't always fail gracefully when handling code with this type of error (phab:T235540), but it is easy solved by correcting the code when you know what the problem is. --Dipsacus fullonum (talk) 05:06, 6 December 2021 (UTC)

New WikiProject Cities

I have created WikiProject Cities due to the current modelling inconsistencies of cities. Resolving these inconsistencies by creating a formal data model is currently being discussed here. Please join the WikiProject and give feedback about the proposed model! Lectrician1 (talk) 05:09, 6 December 2021 (UTC)

References or advertising?

Hello! I found an user (Special:Contributions/Klepisolemure) adding an enormous amount of external references (news sites) on properties like "age", "sex or gender", "instance of", "country", i mean everything. Yeah...its okey.. they are references, but they are all different news articles and only in politicians Qs. I feel this is more like someone trying to do advertising or positioning news in search engines? Not really sure what to think...or do. I think it is better for someone who is not from Argentina to see it (they are all argentinian politicians and news sites). Thanks! Mauricio V. Genta (talk) 06:17, 6 December 2021 (UTC)

Maybe ping @Klepisolemure:? I do not speak Spanish, nor do I know enough about the media landscape to come to a fully-formed opinion. But from checking a few of their additions, it seems they draw from a variety of news media. As long as they aren't all connected by common ownership or similar, it is hard to see how it would even be possible for them personally profit from these references. They even include some references to books with stated in (P248) and a page number. Taken together, I'm quire convinced these edits are made with the best intentions, even though I am not quite as convinced that references for instance of (P31) are necessary, or that references for sex or gender (P21) are would stand up to scrutiny when it ever became controversial and they do not go beyond referring to someone with some pronoun in passing.
Speaking somewhat hypothetically, I'm unsure both of what the policy is and what it should be for the case you suspect: Imagine some reputable news source had the idea to not pay some intern to add their work as references wherever it applies, should we oppose that? What if it's a source somewhat below the NYT in reputation? What if they also fill in some blanks in dates of birth etc. along the way? While a profit motive might be reason for some suspicion, I tend towards the idea that it doesn't matter as long as the work withstands scrutiny. Karl Oblique (talk) 17:21, 6 December 2021 (UTC)
Español:
Hola, no hay ningún fin comercial en las referencias que uso.
Explicaré un poco el contexto de Argentina. Vivimos en un país con mucha corrupción, y los medios de prensa dan información respecto de funcionarios públicos. Al mismo tiempo hay algunos "pseudo-periodistas" que buscan tergiversar muchos datos mediante desinformación.
Así que hace un tiempo me dedico a referenciar con fuentes fiables (diarios nacionales, publicaciones por periodistas, etc), información sobre políticos con interés público.
En resumen, las referencias se usan con la intención de poder vincular a datos fiables sobre los datos que figuran en las entradas.
English:
Hello, there is no commercial purpose in the references I use.
I will explain a little the context of Argenitna. We live in a country with a lot of corruption, and the media give information about public officials. At the same time there are some "pseudo-journalists" who seek to misrepresent a lot of data through disinformation.
So some time ago I used to refer to reliable sources (national newspapers, publications by journalists, etc.), information on politicians with public interest.
In short, the references are used with that intention. Klepisolemure (talk) 18:06, 6 December 2021 (UTC)

IMA Mineral Symbol

I need some help. Property:P10113, format constraint
There are six possibilities. Two letters: galena (Gn), albite (Ab), adamite (Ad), ajoite (Aj). Three letters: calcite (Cal), actinolite (Act), abellaite (Abe), abelsonite (Abl). Four letters: adamsite-(Y) (Ads-Y), aeschynite-(Y) (Aes-Y), agardite-(Y) (Agr-Y), allanite-(Y) (Aln-Y). Five letters: abenakiite-(Ce) (Abk-Ce), adranosite-(Fe) (Arn-Fe), aeschynite-(Ce) (Aes-Ce), agardite-(La) (Agr-La). Six letters: aegirine-augite (Aeg-Aug), alicewilsonite-(YCe) (Aws-YCe). Thx n regards --Chris.urs-o (talk) 12:56, 6 December 2021 (UTC)
It looks a bit more complex according to [1] (source), for example Zhög-2N2S or Ftf-6N'3s. The current format constraint doesn't even handle all of these possibilities as it assumes the symbols are Latin script even though that is incorrect. Dhx1 (talk) 15:21, 6 December 2021 (UTC)

Wikidata weekly summary #497

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • Mismatch Finder: Continued polishing for the first version. Improving the texts and adding loading state. Incorporating feedback from testing.
    • Continued migrating our on-wiki Vue apps to support the new Vue.createMwApp compatibility layer in MediaWiki core (phab:T294465)
    • Continued work on making it possible to define a custom ordering of grammatical features on Lexemes (phab:T232557)
    • Finished work on small tool to show Items recently edited by several accounts to surface current events.

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.

Tool wanted for interwiki-linking subcategories

If a category (on Wikipedia, Wiktionary, Wikisource) has interwiki links between languages, is there any tool to check for missing (or misguided) interwiki links between their subcategories? --LA2 (talk) 21:40, 6 December 2021 (UTC)

Fiak or Falk?

name in native language (P1559) on Peter Falk (Q484881) is Peter Fiak. It is ok or it should be fixed to Peter Falk? --94.247.8.8 17:47, 12 December 2021 (UTC)

I've fixed it. It appears to have been some old vandalism or a test edit by a previous IP user.[2] From Hill To Shore (talk) 17:59, 12 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 18:25, 12 December 2021 (UTC)

items without statements (and sitelinks to Wikipedia)

When working on the list Wikidata:Database_reports/without_claims_by_site/frwiki, a few issues came back (or were identified):

I listed them on the list's talk page at:

They can be interesting for other languages too. --- Jura 23:27, 7 December 2021 (UTC)

Property to link to API

What would be best practice for adding a link to and external RESTful API endpoint of an item? We are about to add the metadata of newsreels of the Israeli Film archive (e.g., Minister of Trade and Industry Visits Aboard New Fishing Vessel at Port of Haifa (Q109887444). The archive also plans to externalize their API and we would have the link to each endpoint in the Wikidata item. Which property is most suitable? external data available at URL (P1325)? described at URL (P973)? Can API endpoint URL (P6269) be used? Appreciate any ideas. Keren - WMIL (talk) 11:40, 8 December 2021 (UTC)

This sounds like it should maybe be a property by itself? That's as long as it is expected that the archive has some stable identifiers that could be used for these links (which would seem like a rather straightforward expectation for digital archives, but I've seen things that have shaken my faith in humanity and/or archives). Now I guess it would then be nice to primarily link to a human-readable format, and I'm not entirely sure if it's possible already or if I just read a discussion on making it possible to have secondary formatter URIs linking to the machine-readable version. At the very least, it would be trivial to add to the property once it's available.
Ideally, if the API is still being planned, it can provide both human- and machine-readable data at the same URI, switching between the two based on the request. If you click on https://www.wikidata.org/wiki/Special:EntityData/Q41621, for example, you'll see the pretty version Haifa (Q41621) (by wikidata standards of pretty). If, however, you ask for a different format, as this line in a Unix shell would do, you'll get the same data in different form:
curl --location -H "Accept: application/json" https://www.wikidata.org/wiki/Special:EntityData/Q41621
-- Karl Oblique (talk) 15:56, 8 December 2021 (UTC)
@Keren - WMIL I would think that API endpoint URL (P6269) is suitable for this, isn't it? Vojtěch Dostál (talk) 17:02, 8 December 2021 (UTC)
API endpoint URL (P6269) is a single URI that would be appropriate for an item for the service itself. It doesn’t work for adding individual URIs on all the items for works in the collection. The idea/difference was also discussed when it was first proposed. Karl Oblique (talk) 19:31, 8 December 2021 (UTC)

Some questions

Hello,

I am a newcomer to this project and I would like to ask some questions where I could not find an answer in the FAQs.

I am interested in Census data for India (districts, Cities, etc.). I have seen that some data are already available here. Who is importing the data and how is it guaranteed that the imported data are correct? These Census data are usually stored in large tables in repositories and it would be much easier to import them in batch mode instead of doing this step by step. Can this be done? Thanks in advance --Furfur (talk) 14:24, 8 December 2021 (UTC)

Check this out: Towns in India (Click the Blue ">" on the left). Or, slightly more useful, As a table
So there's quite a bit of data there, already (and that query doesn't show everything, unfortunately, because the service takes too long to collect it all and it gets interrupted). As to who guarantees that anything is correct? Absolutely nobody! But if you click through to the individual towns and cities, each piece of information should, theoretically, link to a source. As you will see, some actually do. See Special:MyLanguage/Help:Sources for more.
As for batch import: yes, that's how it is done, for the most part. Wikidata:Bots has more information, but be sure to check out and understand Help:Items, or the bot and batch stuff won't make much sense. Anyway: Welcome! Karl Oblique (talk) 15:26, 8 December 2021 (UTC)

ISBN

Do we still have a bot running that formats ISBN number by adding the hyphens, or should I be doing it manually? --RAN (talk) 04:43, 8 December 2021 (UTC)

I checked earlier today and somehow never wrote the actual reply. Anyway: IIRC it showed User:Edoderoobot fixing ISBNs about a week ago. I couldn't quite figure out to find the last time they did so specifically, but any date this side of the presidency of Jimmy Carter (Q2824547) would convince me I don't have to manually look up ISBN formats. Karl Oblique (talk) 16:05, 8 December 2021 (UTC)
  • Thanks! It seems Google Books omits the dashes, which is my main source for them, so I always get the error message, and I am too lazy to learn how the format works. I think a lot of bots are not running every night anymore because of computational congestion making the initial search for new entries run over a minute. --RAN (talk) 23:31, 8 December 2021 (UTC)
Deltabot took care of it, it just took an extra day! --RAN (talk) 20:08, 9 December 2021 (UTC)

Introducing language variant conversion vandalism

Chinese has multiple language variants ("Simplified Chinese" and "Traditional Chinese"), and because of the existence of regional terms (it means the same word has different names in different regions, which is very common in areas such as movie title translation), it is very difficult to present a piece of content to different users live in different region in the most comfortable way. Fortunately, we have something called "language converter" that can present different language variants to users according to their preference settings.

More specifically, there is mainly four kinds of language variants exist called "zh-cn", "zh-tw", "zh-hk" and "zh-sg", corresponding to the Mainland Simplified, Taiwanese Traditional, Hong Kong Traditional, and Singaporean Simplified language variants respectively. Together with "zh-hans" and "zh-hant" (this two are called Simplified Chinese and Traditional Chinese without any regional word conversion), and "zh" which means no variant conversion, this constitutes the multilingual variants of Chinese.

In Wikidata, all language variants listed above can be filled in the label field of an item.

Here, I have to introduce some policies from zhwiki as a background to my proposal. In Chinese Wikipedia, readers can choose their preferred language variant by using the variant conversion tab, which is located in the upper left corner of the page in the vector skin. Thus, if a user makes an edit whose only content is a manual language variant conversion (e.g., 刘邦 to 劉邦), such an action is defined as vandalism. We call such vandal as 繁简破坏 ("Traditional-Simplified conversion vandalism", "language variant conversion vandalism", whatever).

Such a policy does not exist in Wikidata, but the behavior described above is very common, and we could see users from Chinese Wikipedia complain about it at the Chinese version of Project Chat. Here is an example of such kind of vandalism action, it simply modifying the zh variant from Simplified Chinese to Traditional Chinese (vice versa) is not constructive at all, but is in a sense a major pitfall in the edit war. Therefore, I would like to define the meaningless manual conversion of Chinese language variants as described above, or "language variant conversion vandalism", as vandalism in Wikidata, and put it into the policy.

Meanwhile, there is a bot running on the Chinese Wikipedia that automatically rollback the language variant conversion vandalism described above and leaves appropriate warning messages on the talkpage of users involved. Personally, I see the need to introduce a similar bot at Wikidata.

If you have any questions about this proposal, please do not hesitate to ask.

Sincerely, Stang 01:13, 8 December 2021 (UTC)

I don't think such a policy makes sense on Wikidata, because Wikidata doesn't have variant conversion - zh is shown as a mixture of simplified and traditional, so it's understandable that someone would try to make it more consistent. In Wikidata, simplified and traditional have to be entered separately (as zh-hans and zh-hant, respectively), so I think it would make more sense to not use zh at all. - Nikki (talk) 11:43, 8 December 2021 (UTC)
Well, this is fine if it is technically possible, that we disable the modification of zh and only allow the changes of zh-hans and zh-hant. Stang 15:36, 8 December 2021 (UTC)
The UI should show zh-hans + zh-hant to all Chinese users, to make them aware that both fields exist. If they only see one zh field, then they are going to edit back-and-forth, ping-pong style. Or maybe zh-cn + zh-tw + zh-hk + zh-sg? Or all six? Ideally the four regional forms would be left blank and allowed to fall back to zh-hans or zh-hant in most cases.
Policy-wise, why not set a standard that 'zh' should contain both scripts? E.g. "靈活腦學校"@zh-hant; "灵活脑学校"@zh-hans; "靈活腦學校 / 灵活脑学校"@zh.
. ⁓ Pelagic ( messages ) 20:27, 8 December 2021 (UTC)
The idea to set such a standard is pretty reasonable for experienced users/readers but could be confusing to those who just happen to visit Wikidata and try to add something. As for taking zh-hant/hans or zh-cn/hk/tw/sg/my/mo, the latter one is better since zh-tw could be totally different from zh-hk in many situations, though they are both traditional Chinese. Tigerzeng (talk) 21:01, 8 December 2021 (UTC)
You could request at Wikidata:Report_a_technical_problem that "zh" be disabled. BTW, let's avoid calling it "vandalism" on Wikidata. --- Jura 12:02, 10 December 2021 (UTC)
Thanks for advice, I put it here a longer time to gather more suggestions and reach a consensus. Stang 19:46, 10 December 2021 (UTC)

Q110017262

Hello,

First timer here. Can you please clarify why Synspective (Q110017262) has "no label defined" at the top? —Thanks in advance. XavierItzm (talk) 09:04, 10 December 2021 (UTC)

Because no English label is currently stored in the data object. --Gymnicus (talk) 09:07, 10 December 2021 (UTC)

Use of significant place (P7153) in archaeological periods

I used significant place (P7153) to link from an archaeological period to its type site (so Ubaid period (Q245156) has significant place Tell al-'Ubaid (Q1317854), with object has role (P3831) type site (Q3247173). Now, if I wanted to link from Ubaid period to other major (non-type) sites for that period (for example Eridu (Q210065) or Tell Abada (Q56300816), is there another appropriate statement that I could use with P3831? Zoeperkoe (talk) 14:06, 8 December 2021 (UTC)

@Zoeperkoe Wouldn't it generally make more sense to link FROM the specific items such as Eridu (Q210065) TO Ubaid period (Q245156)? I understand the use of significant place (P7153) fpr the type sites but I would go the other way round for all the other archeological sites (there could be hundreds of them). Vojtěch Dostál (talk) 17:00, 8 December 2021 (UTC)
Yes I do that with time period (P2348) > Ubaid period at individual sites but I was wondering whether there's an extra way to highlight really important sites. But maybe "really important" is just too ambiguous and subjective to be modelled. Zoeperkoe (talk) 17:13, 8 December 2021 (UTC)
I would use "significant place" without any qualifiers. - PKM (talk) 01:50, 9 December 2021 (UTC)
@PKM: that would indeed be a possible solution, but P7153 has a requirement that it should not be used without qualifier; hence my question. Zoeperkoe (talk) 07:34, 9 December 2021 (UTC)
Template:Replay to. Ah. Then I would make a new item "representative site" or something similar, and use that. - PKM (talk) 21:36, 10 December 2021 (UTC)
Template:Replay to That's an interesting suggestion. I'll look into it. Thanks! Zoeperkoe (talk) 08:12, 11 December 2021 (UTC)
Looks good. If it's also "named after", named after (P138) could be added too. --- Jura 12:00, 10 December 2021 (UTC)

Social media new link

Hi i am new to wikidata but i am trying to improve myself here so if i made mistake by writing here i apologies for it in advance.

i am from and we have here new social media app call KOO App http://kooapp.com can anyone make statement of it so that we can add koo id to those who have koo profile.

--Aroojakhan (talk) 07:08, 11 December 2021 (UTC)

copyright status of Roger Puta's photos

Roger Puta, Roger Puta (Q91831483), died in 1990. His wikidata page currently incorrectly says his photos are all protected by copyright.

His childhoold friend, and literary heir, Mel Finzer, decided to put all of Puta's extensive collection of photos into the public domain. It is a decision I personally applaud. I'd like wikidata to reflect this decision, but donated to the public domain does not seem to be a choice available. Geo Swan (talk) 17:36, 9 December 2021 (UTC)

Sem-mentor request

Can someone help me add items/or edir existing when required. Like this: https://www.wikidata.org/wiki/Topic:Wlyy1mqhacjg8u9o Greatder (talk) 17:00, 11 December 2021 (UTC)

Q7257361 - PDDC or PDM?

Someone asked on its talk page that this item mixes two concepts which they think they are different, should this item be splitted or not? Liuxinyu970226 (talk) 01:11, 12 December 2021 (UTC)

Manifestation of

See for example: No More Blondes (Q107580865) where IBDB demands "manifestation of", but I cannot find an example where a play has that filled in. Can we remove the restraint that demands its use? --RAN (talk) 01:31, 12 December 2021 (UTC)

Internet Broadway Database production ID (P1218) gives Wikidata property example (P1855) as The Crucible (Q23008456), which then uses manifestation of (P1557) The Crucible (Q1183443). I have not edited in this area of Wikidata before but it looks like it is modeled in the same way that we split books into written work (Q47461344) and version, edition or translation (Q3331189). One represents the creative work, while the other represents an individual production of that work. From Hill To Shore (talk) 14:49, 12 December 2021 (UTC)
After a quick internet search, the "No More Blondes" play appears to have been performed in New York in 1920 and California in 1921.[3] We should have an item to represent the play and then separate items for the New York performances and the California performances (if more details are available for the California performances). The performance items would each have a manifestation of (P1557) statement to point to the item about the play. From Hill To Shore (talk) 18:12, 12 December 2021 (UTC)
  • OK, thanks! How can we make the intention of the use of "manifestation of" more clear for the next time someone encounters it? We have examples for the use of properties but not for qualifiers, can we change that? --RAN (talk) 00:49, 13 December 2021 (UTC)
I have created and linked No More Blondes (Q110088045), which is the general work: a given work (play) can have hundreds or thousands of individual productions and performances around the world. My philosophy is the general should be developed before the specific.

Initial version of Lua access to Lexemes on Bengali and Basque Wiktionaries

Hi everyone,

We’ve been collecting lexicographical data for quite a while now. The first applications are being built on top of it as well. One big remaining wish is to make it possible to access the data in Lexemes also from Wiktionary. We’re enabling it on the first Wiktionaries now.

On December 15th, we’ll enable the initial version of Lua access to lexicographical data on the following wikis:

The Lua interface (i.e. the available functions and methods) is documented at mw:Extension:WikibaseLexeme/Lua (you can see a live example, with links to the relevant template and module, at Beta English Wiktionary: cat). If you have suggestions for improving it (e.g. extra functions that would be useful), feel free to add them to phab:T294637.

Please note that the Lua interface is not stable yet; breaking changes may be made at any time, though usually not without some note on Phabricator first. We recommend not fully relying on this yet. If your wiki would nevertheless like to have Lua access while it is not stable yet, feel free to leave a note at phab:T294159. Otherwise, we hope to stabilize the interface soon, at which point we’ll start enabling this feature on more Wiktionaries. If you're active on another Wiktionary and would like to see the feature enabled, feel free to reach out to us after talking to your community, and we will make sure to include it in the list for future deployments..

Change dispatching, i.e. the automatic updating of local wiki pages when relevant changes on Wikidata are made, as well as integration with recent changes and the watchlist, ought to work; however, usage tracking (i.e. determining which changes on Wikidata affect the local wiki) is not very fine-grained yet: if a local page uses any data from a Lexeme, then any change to the Lexeme on Wikidata will cause the page to be rerendered and that change will be added to the recent changes on the wiki, even if the change is unrelated to the data which the page actually uses. We will improve this at a later point; in the meantime, wikis that heavily use lexicographical data may see “too many” Wikidata entries in their recent changes and watchlists.

We are really happy to beta-test Lua access to Lexemes with you, and we are looking forward to your feedback and bug reports (they can be tracked under phab:T294159 or on the Report a Technical Problem page). We would love to know how you are using Lexemes on Wiktionary, so when you are running your first experiments, feel free to let us know!

Cheers, Lea Lacroix (WMDE) (talk) 14:29, 13 December 2021 (UTC)

Wikidata weekly summary #498

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Next Linked Data for Libraries LD4 Wikidata Affinity Group call: Lightning talks on WikiProject Vanderbilt Fine Arts Gallery, Wikidata use for a site-specific archaeological case study (Dura-Europos, Syria), and round tripping Wikidata into Alma using Alma Refine. Agenda, Dec. 14th.
  • Development
    • Mismatch Finder: Developed a user script to show a notification on an Item if the Mismatch Finder has an unreviewed mismatch for it.
    • Preparing for Lexeme Lua access to be enabled on the first wikis. (phab:T294637, phab:T294159)
    • Continuing work on migrating the termbox to vue3 (phab:T296202)

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.

Searching deleted items

If you've ever been frustrated by the difficulty of finding deleted items (either to request undeletion or to identify recreations), you may be inclined to comment on phab:T297513. Bovlb (talk) 23:33, 10 December 2021 (UTC)

@Bovlb: One perhaps simple way of doing this: have some way of ensuring the deletion requests permanently contain the item name in native language (or any that is filled in). Then the requests themselves can be searched. Is that something Template:Request_for_deletion can be made to do (been a hot minute since I did any template editing)? SilentSpike (talk) 11:45, 11 December 2021 (UTC)
Add some point a development was made for the deletion log to include the item label. Not sure why it's generally not happening. --- Jura 12:13, 11 December 2021 (UTC)
It does not happen always because it is an UI feature. If an admin opens the deletion dialogue regularly from the UI, the item label is pre-filled in the free text field of the deletion form. When the deletion dialogue is opened with the wpReason parameter (as in {{Rfd links}} from WD:RfD), the deletion reason has another default that might not include any labels. Admins can remove or modify the pre-filled deletion reason.
The deletion log can be searched, but this is not very efficient. —MisterSynergy (talk) 13:36, 11 December 2021 (UTC)
So fixing {{Rfd links}} would improve things? --- Jura 17:40, 13 December 2021 (UTC)
Yes, {{Rfd links}} can be changed to include the label in the default deletion summary. Another solution would be adding a new parameter to {{Rfd links}} (and automatically filling it in {{Request for deletion}}) so that the WD:RfD’s archive contains the label (in the state it was at the time the item was nominated for deletion, not the time it was deleted). It’s probably a bit more error-prone (if someone chooses not to use {{subst:request for deletion}}, the label isn’t automatically added), but it provides more visibility as the archives are searchable—which may be a good or a bad thing, I’m not sure. —Tacsipacsi (talk) 19:27, 13 December 2021 (UTC)
I added an edit request there. --- Jura 22:50, 13 December 2021 (UTC)

JHeald railway quiery renders strange gaps

Not sure whether this is an appropriate venue for this question but I am sure there are knowledgeable people here who could be able to help. I am using a quirey written originally by Jheald, url here. I do not understand much of the language, but it starts from one particular railway station on Wikidata (not sure which one) and connects it to all stations which are connected by property P197 "adjacent station" and plots the results on the Wikimedia map (a particular layer of the OpenStreetMap). It basically serves as a guideline for railway fans who are adding these stations by hand (and I hope no bot would ever run to do this, because it would deprive us of this fun). Sometimes, the map shows strange things due to outages, and if I re-run the quiery they move or disappear. However, there is a gap which I can reproduce for three days in a row, between Q4493073 and Q19910696, if you look at the map it is southeast of Moscow (Москва), two-thirds of the way to Ryazan (Рязань). The stations are connected by P197, in fact, I have connected them quite a while ago. Does anybody know what is wrong with these stations on Wikidata? Courtesy ping to @Ludvig14: who found the gap to start with.--Ymblanter (talk) 17:43, 10 December 2021 (UTC)

@Ymblanter: Where is JHeald when you need him? So, the query uses the Gather, Apply and Scatter service, described somewhat here. In essence, it starts - in this example at St Pancras station in London - and follows P197 from station to station, as far as it can go. But, any one station is only selected once by the GAS service, and, in short, that frustrates the line-drawing part of this query, at multiple points in the map, where one GAS path e.g. heading south, meets another GAS path heading north. The report cannot bridge gaps of the sort you spotted b/c both involved stations have already been found by each leg of the GAS path, and so the path does not make the final hop necessary to get the line drawn. There are multiple gaps of this sort across the map. Change the start station and the position of gaps will likely change. There is, in general, nothing wrong with the item data. --Tagishsimon (talk) 18:56, 10 December 2021 (UTC)
I see, that explains it, thanks--Ymblanter (talk) 19:03, 10 December 2021 (UTC).
@Ymblanter: Here is a version of query that shows line segments between all adjacent railway stations. It uses colors dependent on the number of P197 statements each line segment is based on. There are too many stations to cover the whole world so I have limited the map to Russian stations. 
# Based on a query by James Heald
#defaultView:Map
SELECT ?line (COUNT (?line) AS ?layer)
WITH
{
  SELECT DISTINCT ?station
  WHERE
  {
    VALUES ?stationtype { wd:Q55678 wd:Q55488 }
    ?station wdt:P17 wd:Q159 . # In Russia
    ?station wdt:P31 / wdt:P279* ?stationtype . # Instances of railway station
  }
} AS %stations
WHERE
{
  INCLUDE %stations
  ?station wdt:P197 ?next .
  ?station p:P625/psv:P625/wikibase:geoLatitude ?lat1 ;
           p:P625/psv:P625/wikibase:geoLongitude ?lon1 .
  ?next    p:P625/psv:P625/wikibase:geoLatitude ?lat2 ;
           p:P625/psv:P625/wikibase:geoLongitude ?lon2 .
  BIND(STRDT(IF(?lat1 < ?lat2,
                CONCAT('LINESTRING(', STR(?lon1), ' ', STR(?lat1), ',', STR(?lon2), ' ', STR(?lat2), ')'),
                CONCAT('LINESTRING(', STR(?lon2), ' ', STR(?lat2), ',', STR(?lon1), ' ', STR(?lat1), ')')),
             geo:wktLiteral) AS ?line)
}
GROUP BY ?line
Try it!
--Dipsacus fullonum (talk) 18:20, 11 December 2021 (UTC)
Great, thank you very much. Ymblanter (talk) 19:16, 11 December 2021 (UTC)
Ima doubt that ?station wdt:P197/^wdt:P197 ?next . was what was wanted - seems to find stations that have P197 pointers to the P197 object station of the subject ?station. Results in a map in which stations appear to be playing leapfrog. ?station wdt:P197 ?next . might be more conventional? (test query for wdt:P197/^wdt:P197 version, test query for wdt:P197 version) --Tagishsimon (talk) 20:56, 12 December 2021 (UTC)
@Tagishsimon, Ymblanter: Tagishsimon, you are absolutely right. Thank you for noticing this. I intended to write "wdt:P197|^wdt:P197" but somehow the "|" became a "/". The idea was to find both cases where ?station is subject and cases where it is object in the statement. But I guess that is superfluous if all stations are found, so I have now simplified it to just "wdt:P197". But another thing is that looking at the map, I saw unexplained gaps. It seems that the cause is that some places where trains stop are instances of railway station (Q55488) and others are instances of railway stop (Q55678). There seems not to be a common superclass for these (shouldn't there be that?), so I have to test for both. I have updated the query above with these changes, and now it looks more plausible to me (not knowing the Russian railway net). --Dipsacus fullonum (talk) 22:17, 12 December 2021 (UTC)
@Bouzinac: might be interested in sorting out the "some places where trains stop are instances of railway station (Q55488) and others are instances of railway stop (Q55678). There seems not to be a common superclass for these (shouldn't there be that?)" issue - they're currently engaged in fettling railway/tube stations, afaik. --Tagishsimon (talk) 22:48, 12 December 2021 (UTC)
Hi there, I am absolutely no connoisseur of Russian railways (@Michgrig might give his two cents) ; but for the superclass, for instance this template {{Tramway}} uses wdt:P31/wdt:P279* wd:Q548662 with public transport stop (Q548662) as a superclass to help get particular cases amongst the diversity of railways stations. Bouzinac 💬●✒️●💛 11:20, 13 December 2021 (UTC)
@Bouzinac @Ymblanter, this query does not have the mentioned drawback :) Michgrig (talk) 11:51, 13 December 2021 (UTC)
Nice but where is the famous transsiberian (without lines) ? Bouzinac 💬●✒️●💛 11:58, 13 December 2021 (UTC)
I'm in the process of adding items for stations to WD. There are items for only those of them, for which articles exist, I'm adding all of them (where passenger trains go now). So, stations and lines will appear when I add them Michgrig (talk) 12:03, 13 December 2021 (UTC)
As for a common superclass of railway station (Q55488) and railway stop (Q55678), there are two of them: operation point (Q1318558) and entry point (Q228332). Michgrig (talk) 11:54, 13 December 2021 (UTC)
Thanks. But entry point (entry point (Q228332)) is for all public transport, so if you make a map using that class, it could include bus, tram and ferry routes etc. And operation point (operation point (Q1318558)), as I understand it, includes places where trains are not necessarily supposed to stop, like e.g. passing loop (Q784159) or crossover (Q1928330), so a map based on this class will also show too much. I am missing an item specific for railway entry points. --Dipsacus fullonum (talk) 04:50, 14 December 2021 (UTC)
Let us ask @Texaner, because it is they who wrote the query that I mentioned earlier. Maybe they know the answer. Michgrig (talk) 06:22, 14 December 2021 (UTC)
Hi, you could see here hu:Kategóriavita:Magyarország vasútvonalai two more sophisticated query developed for Hungarian railway. But this queries do not works for Russian railways while, it is at last 10 time bigger as Hungarian and there is a time limit for queries. The query on this side is a simplified version. Texaner (talk) 16:20, 14 December 2021 (UTC)
Thanks everyone. I would also say for railways we should only be using railway station, not railway stop, since it is very difficult to define them in a proper way. Specifically in Russia, there are notions of "station" (has a cargo yard) and a "platform" (purely passenger operation), but this is not English, in English they would all be stations, and als we have quite a lot of stations which are currently not in use but will be in use somewhere, and all of this becomes a complete mess.--Ymblanter (talk) 11:56, 13 December 2021 (UTC)

datatype change (string → external-id)

Please note:

and comment there. --- Jura 18:33, 14 December 2021 (UTC)

Unsure, as eggs is not eggs (senses and items)

Hi, I'm new to lexemes. Ei (L6682) has two senses, and each sense has a single item for this sense (P5137): egg as food (Q93189) and egg (Q17147). Then egg (L4775) has one sense with the two items for that sense. How do we decide when two items/concepts are the same or different lexical senses? ⁓ Pelagic ( messages ) 19:28, 14 December 2021 (UTC)

Wikidata:Use common sense? I don't think we need to be fully consistent between languages, but sometimes this sort of comparison might be a good guide. ArthurPSmith (talk) 21:15, 14 December 2021 (UTC)

Inappropriate item

Q108841013 It looks like someone created an item for himself (or worse yet, possibly someone else), among other things giving his phone number and email and giving occupation as "sugar daddy". I presume this should be deleted.

This came up at https://commons.wikimedia.org/w/index.php?title=Commons:Help_desk&oldid=614951925#Question_about_wikidata

If you need my attention please ping me, I'm not watching Wikidata these days. - Jmabel (talk) 18:44, 18 December 2021 (UTC)

  Done; this was obviously a non-notable item. —MisterSynergy (talk) 18:49, 18 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 13:23, 20 December 2021 (UTC)

Sitelink weirdness

Sitelinks are now looking like enwiki and can't be edited without going into the "Set Item sitelink" Special page. That's workable for adding, but not for deleting. Abductive (talk) 19:29, 19 December 2021 (UTC)

That is the normal appearance when you have javascript disabled in your browser. Do you have any security add-ons like "NoScript" installed? From Hill To Shore (talk) 19:34, 19 December 2021 (UTC)
I tried with a different computer, and it seems that Javascript may have been disabled somehow on this one. Thanks. Abductive (talk) 14:32, 20 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Bovlb (talk) 19:01, 20 December 2021 (UTC)

English label of inception (P571)

Hi,

inception (P571) was created in May 2013 as “foundation/creation date”. It was re-labeled “inception” in December 2014 by @Joshbaumgartner:. According to this talk page thread, this was done with little discussion. Many other labels still translate roughly to “data of foundation/creation”.

It seems that this label is confusing (see for example some of the discussion at Wikidata:Property proposal/date of recording). So throwing that here − is “inception” fine as an English label? Should we go back to “foundation/creation”?

Thanks, Jean-Fred (talk) 12:55, 3 December 2021 (UTC)

  Support I agree Germartin1 (talk) 13:37, 3 December 2021 (UTC)
  Support I don't know why "foundation" is in the property name, but anything with "create" in it I support. Lectrician1 (talk) 13:40, 3 December 2021 (UTC)
I assume "date of founding" is what is meant? This is used heavily for organizations and "creation" doesn't seem like quite the right term there. I think a label "date of creation or founding" would work maybe? ArthurPSmith (talk) 18:19, 3 December 2021 (UTC)
(After edit conflict) Foundation in this context has the sense of founding (Q3075355). From Hill To Shore (talk) 18:22, 3 December 2021 (UTC)
  Wait This label 'inception' has been stable for the vast majority of Wikidata's existence and is extremely widely used, both across a large number and variety of items. While there was not a large discussion at the time, it was a word that seemed to cover a large variety of uses for the property while being simple and concise. It is not a bad idea to discuss a potentially better label, but due to the fact that it is so widely used under the current label, we should be extremely careful before changing it, and sure that we are changing it for a very good reason. Josh Baumgartner (talk) 18:58, 10 December 2021 (UTC)
@Joshbaumgartner I mean, what are we waiting for?
"date created" works for all physical (statues, buildings, etc.) and conceptual things (organizations), so it should work in place of "inception".
If there are no objections now, we might as well change it, and see if there are objections afterwards. Lectrician1 (talk) 02:15, 13 December 2021 (UTC)
I would tend to agree with @Joshbaumgartner. This property is used very widely and has been in use for several years under this label. It is likely to be cited in discussions within Wikidata and outside. Changing the label would be disruptive. Fjjulien (talk) 03:13, 15 December 2021 (UTC)
  Oppose There is objection, so no, let's not ram this through, thank you. Josh Baumgartner (talk) 22:25, 14 December 2021 (UTC)

Barcelona

Two weeks ago, @Lopezsuarez: did some edits in the item Barcelona (Q1492):

  1. instance of (P31)municipality of Spain (Q2074737) instead of instance of (P31)municipality of Catalonia (Q33146843) (edit). In the summer, he did the same to other items and I explained to him that the original claim is more precise and needed for properties like IDESCAT territorial code in Catalonia (P4335) (discussion).
  2. Removing capital of (P1376) statements of historical Catalan states (edit).
  3. Adding part of (P361)Barcelona Province (Q81949) (edit).
  4. Adding the Spanish translation of the name to native label (P1705) (edit).
  5. Adding a Spanish translation to nickname (P1449) (edit). I am not sure if translations are in the scope of this property. If so, that would be the unique constructive edit he did.

Some of his edits have been reverted by me, @Infovarius: and @Rodelar:, but it seems that Lopezsuarez is not convinced. I know him from a previous case, that was not solved until community's feedback. So let's see if we can solve this new case. FogueraC (talk) 08:19, 5 December 2021 (UTC)

My claim has been to depoliticize the Barcelona item of editions made by independentists, in which it is claimed that Barcelona was the capital of "a Catalan Republic" in 2017, which is absurd. On the other hand, these pro-independence users try to eliminate any reference to "Spain" and the province of Barcelona. This is incomprehensible. The item must be realistic and neutral, not typical of a political Wikipedia like Wikipedia in Catalan.
However, I have no intention of starting any editing wars. Lopezsuarez (talk) 09:40, 5 December 2021 (UTC)

So I'm only vaguely familiar with the politics here but:

BrokenSegue (talk) 17:15, 5 December 2021 (UTC)

Well, the official languages are not defined at municipal level. Catalan and Occitan are official in all Catalonia, and Spanish is official in all Spain. (If enwiki does not include Occitan, it may be just outdated, as before 2010 it was official only in Val d'Aran). Although this, the native language of Barcelona is Catalan. In fact, the names of municipalities (and other toponyms) are only official in the native language, not in all three languages. That means that the official names of Aranese municipalities are in Occitan and official names of the rest of Catalan municipalities are in Catalan. That is why Spanish translation should not go in native label (P1705). In the case of nickname (P1449), it depends on the scope of the property, whether it includes translations or not. FogueraC (talk) 22:28, 5 December 2021 (UTC)
I don't think it matters how the official language became official (defined locally or imposed from above). If spanish is practically an official language in the locality I think it's fine. BrokenSegue (talk) 00:37, 6 December 2021 (UTC)
What I tried to say is that "oficial language" and "native language" are different things, even in Catalan legislation. Maybe the case of Barcelona is confusing because all three names are the same. So take into account Lleida (Q15090) (es: Lérida, ca: Lleida, oc: Lhèida). Official languages: es, ca, oc. Native language: ca. Official name: Lleida. Or another example, Vielha (Q3347060) (es: Viella, ca: Viella, oc: Vielha). Official languages: es, ca, oc. Native language: oc. Official name: Vielha. I think it is clear that we should not add es and ca in Vielha names properties, or es and oc in Lleida names properties, and nobody has asked this. Barcelona should remain coherent with the rest of Catalan municipalities. FogueraC (talk) 06:09, 6 December 2021 (UTC)
FogueraC, you make a good point that “names in official languages” can be different from “official name”. Is it part of the problem that P1448 has English description “official name of the subject in its official language(s)”? Perhaps for place names we should limit official name (P1448) to names that are gazetted by relevant government bodies. That would be consistent with the aliases “long name” and “legal name”. Ideally it would be supported by a qualifier stated in (P248)official publication &/or statement supported by (P3680)official body ⁓ Pelagic ( messages ) 18:47, 8 December 2021 (UTC)
We could change the description, yes. Maybe deleting "in its official languages" would be enough. FogueraC (talk) 10:55, 15 December 2021 (UTC)

Let me only say that it is very disadvantageous to use subclasses of the official instance of (P31) of each country's municipalities. It strains many country-wide SPARQL queries which would otherwise be easy to conduct, by enforcing the usage of the P31/P279* path. We already know that Barcelona is in Catalonia via P131, is it really necessary to state it again? I prefer using standardized instances, in a way that literary work (Q7725634) has recently been adopted for all types of literary works. Vojtěch Dostál (talk) 13:22, 6 December 2021 (UTC)

Do municipalities in Catalonia have definition in Catalan or Spanish law? I think class definitions like “municipality of Catalonia/Spain” should take that into account. (As distinct from “municipality in Catalonia” which is serviced by the chain of located in the administrative territorial entity (P131) or location (P276).)
If we tried to go global, we would run into the problem that different jurisdictions will have varying definitions of municipality, municipio, city, town, shire, local government area, etc. For example “City of Shoalhaven” isn't a “city” in the normal sense (Nowra (Q1343021) is the regional centre), but City of Shoalhaven (Q820286)instance of (P31)local government areas of New South Wales (Q55558200) is correct. “Baisha” isn't just the town on Baisha island, but also the group of islands which form an administrative township of Taiwan (Q2367508). (Baisha Township (Q712753) doesn't distinguish well between the town proper and the administrative “township”.)
. ⁓ Pelagic ( messages ) 19:32, 8 December 2021 (UTC)

Allowing IP's to add data, not change data

I'm working my way down a list of high-profile paintings and I regularly encounter old vandalism that hasn't been caught. As long as I remember Wikidata has always had vandalism slipping through. I noticed that signal (good edits) to noise (bad edits) for additions by IP's seem to be a lot better compared to changing data. Maybe we should consider IP's only to be able to add data (labels, descriptions, aliases and statements) and not allow IP's to change (or remove) existing data? Multichill (talk) 12:08, 12 December 2021 (UTC)

+1 --- Jura 12:28, 12 December 2021 (UTC)
I would support this--Ymblanter (talk) 13:05, 12 December 2021 (UTC)
So what happens if an IP editor makes a mistake while adding data? —MisterSynergy (talk) 13:10, 12 December 2021 (UTC)
Currently IP's can edit all items. Other end of the scale would be to disable IP editing completely in the item namespace (like we did for properties). This proposal is somewhere in the middle. If enough support exists we can have a look at the details and how to actually implement this. In a simple implementation the software would just look at the previous revision and would block the edit, in a more advanced implementation the software would look at the last revision not by this IP and allow it. Multichill (talk) 14:08, 12 December 2021 (UTC)
I think if we are going to make a decision like this (which I like the premise of), it would be good if we could source some actual statistics on the signal to noise ratio you mention. My only concern with doing this would be: wouldn't vandal IPs just be encouraged to use a new tactic of adding false data? Which could be harder to spot. SilentSpike (talk) 14:39, 12 December 2021 (UTC)
Some data on IP contributions in main (item) namespace (snapshot of the past 30 days):
  • 107,221 edits; of these:
    • 57.5%/61,700 involved statements
    • 11.0%/11,800 descriptions
    • 9.0%/9700 sitelinks
    • 8.6%/9200 labels
    • 4.6%/4900 alias
    • 1.0%/1100 undos
    • 0.4%/400 merge (usually 2-3 edits per merge action)
    • 7.8%/8300 others, including 2900 item creations
  • by patrol status:
    • 67.8%/72,700 are currently unpatrolled
    • 32.2%/34,500 were manually patrolled
  • 17637 different IP addresses were used
    • top 450 IP users (with 36+ edits each) are responsible for half of the total load of 107,221 edits
    • 133 IP users made 100 or more edits
    • contributions from IP editors are surprisingly well pareto distributed
  • Re. "modification of statements": this happened on the order of 20,000 times, but is rather difficult to quantify exactly. "modification of statements" does not only refer to main value changes, but also to all sorts of other things (main values, ranks, snaktypes, qualifiers, references). It is not simple to break this down any further.
I am patrolling quite a lot in recent months and gained a lot of insight, and I can confirm that these numbers, although they are only a snapshot from the past 30 days, are pretty representative for any time period of 30 days within at least the past year or so. IP contributions are relatively stable both in quantity and quality. The clear majority of IP contributions (as well as contributions from not-yet-autoconfirmed newcomers) are good faith, good quality edits that we should not make impossible.
My impression is that we should use the "patrol" function much more, and more editors should engage in this activity. Just calling for an exclusion of IP editors seems like a simple solution, but I think it would hurt the project much more than most of us would expect. —MisterSynergy (talk) 21:30, 12 December 2021 (UTC)
Did you exclude personally thousands of items from IP edits, and not just for modifications, for any addition? --- Jura 21:51, 12 December 2021 (UTC)
I do not understand your comment, so I feel unable to respond. Can you please be more specific? —MisterSynergy (talk) 21:59, 12 December 2021 (UTC)
Before you exclude thousands of items from edits by IPs, IPs could add to these items freely, be it additions and (what is being discussed here: modifications). --- Jura 22:02, 12 December 2021 (UTC)
Still somewhat cryptic, but let me guess: you are referring to the "highly used item" page protection policy that the community opted for in a 2019 RfC, and that my bot implements since March this year with ~30,000 page protections so far.
Let me be clear: we need to separate roles here. I am commenting here as a regular user (i.e. not as admin) with my personal opinion. As I have already stated several times, I am heavily in favor of as few restrictions to IP editing as possible; this also applies to the exclusion of IP editors from property namespace which I do not like. Separated from that, I act in admin capacity, which means that the policy set of this project is my primary guide when doing do. Inevitably, this occasionally means that I have to act in a way that I do not like particularly, but is requested by the community that way. As much as I do not like the "highly used item" page protection policy (I voted against it and would do so again as of today), I have to accept that it is a valid policy and I think it should thus be implemented. That admin-bot is a service to the community, not an expression of my personal support for this policy. —MisterSynergy (talk) 22:16, 12 December 2021 (UTC)
Well, we could have attempted to develop alternatives before proceeding with either protection. --- Jura 22:25, 12 December 2021 (UTC)
There has been plenty of time to attempt modifications during all phases of the implementation, but barely anyone has shown interest. At some point, it is about time to accept its existence.
That said, if you manage to get this policy changed or removed, I would be able to remove all these protections again within one or two days. —MisterSynergy (talk) 22:29, 12 December 2021 (UTC)
Well, once the feature exists, it may be simple.
Can we at least agree that this proposal would be the better alternative for the 30000 items? --- Jura 22:39, 12 December 2021 (UTC)
I do not think that this is a good proposal in any way, so I am inclined not to compare it to other scenarios.
However, if you absolutely want to do this, this proposal would be less restrictive to the 30k items, but more restrictive to all other items. It is simply a personal opinion which one you find worse. —MisterSynergy (talk) 22:53, 12 December 2021 (UTC)
@MisterSynergy: Thanks for the statistics. As for patrolling. A scenario I see quite often is: One or more bad edits by an IP. Another good edit by a bot (sometimes triggered by data missing because of the vandalism) or a regular user doing a good edit. The good edit is marked as patrolled because of users having the autopatrol flag. Will the previous (bad) edit still show up as unpatrolled or not? In other words: Will this vandalism ever be spotted in a structured process? Multichill (talk) 21:51, 13 December 2021 (UTC)
Okay, here’s also some more technical background for those who are interested:
  • The "patrol flag" is a marker that is attached to each and every revision, and it is stored in the recentchanges table (meaning: it exists for 30 days until it disappears completely).
  • Who produces which status?
    • Autoconfirmed+confirmed users can only produce revisions with the "autopatrolled" status;
    • IPs and new registered accounts without the (auto)confirmed status can only produce revisions with the "unpatrolled" status;
    • the "unpatrolled" status can be changed by (auto)confirmed users to "manually patrolled"; this is logged permanently by Mediawiki; this should be done when the revision can stay unmodified as is, or the content has been fixed so that the revision does not harm the Wikidata project or the described entity (or anyone else) in an inappropriate fashion.
    • Mind that the "patrol flag" is inherently revision based. Older revisions keep their (unpatrolled) status if a newer, autopatrolled revision has been made to the same page. The important limit is 30 days when patrol information disappears completely.
  • Why is this important?
    • The patrol status of revisions can be queried, and unpatrolled edits can be selected and reviewed by experienced users. There are a couple of tools which do this, and the web UI also displays unpatrolled revisions differently (although in a rather subtle manner, unfortunately).
    • You can consider the "patrol" function as a tool to coordinate countervandalism activities. Optimally, revisions are only looked at by one or very few experienced editor who are supposed to switch the revision from "unpatrolled" to "manually patrolled" if it is okay as is, or after it has been fixed if needed. "manually patrolled" revisions appear pretty much as "autopatrolled" revisions and are usually removed from the filter tools and thus from the countervandalism backlog so that others will not have to re-evaluate the same revision again.
  • Some more interesting bits:
    • The patrol status does not control content visibility. Every revision regardless of the patrol status is immediately visible (unlike "flagged revisions" at Wikipedia)
    • The act of patrolling a revision does not mean that the edit is endorsed by the patroller in any way. It simply manages the countervandalism backlog queue.
    • Use of "rollback" switches all reverted revisions from "unpatrolled" to "manually patrolled"; use of "undo" or "restore revision" does not. Since many use "undo" (due to a lack of rollback rights), it might be worth to consider easier or even automatic access to the rollback right for experienced editors.
    • Some tools allow further filtering, e.g. "unpatrolled edits involving German labels/descriptions/aliases", or "unpatrolled edits to property P31" only. This way, one can usually patrol much more efficiently, and empty sub-queues of the total workload in a given field. For instance, all unpatrolled revisions involving German labels, descriptions, or aliases are being patrolled for quite a while now (order of 2k–3k cases per month).
    • Generally, the standard toolset for patrolling in the web UI is pretty weak, unfortunately. Some scripts and external tools make patrolling much more efficient.
  • I plan to overhaul Wikidata:Patrol at some point, in order to make that page more useful than it is right now. Much of this information should be included there. Happy to answer questions.
—MisterSynergy (talk) 22:40, 13 December 2021 (UTC)
@MisterSynergy: What tool allows patrols "unpatrolled edits involving German labels/descriptions/aliases"? I would like to do the same for edits involving Danish labels/descriptions/aliases. --Dipsacus fullonum (talk) 16:06, 14 December 2021 (UTC)
@Dipsacus fullonum:
  • reCh (use the filter option "terms" at the top; can patrol from within the tool)
  • speedpatrolling
  • wdpd (not interactive but guides you to the web UI; and updates only every 30 min; but most complete in terms of filtering)
Mind that all revisions that you mark as "patrolled" will disappear forever from the tools, so you can relatively easily clear the backlog for Danish (<100 edits for the past 30 days). —MisterSynergy (talk) 19:44, 14 December 2021 (UTC)
@MisterSynergy: Thanks for the pointers. I have now cleared the backlog for Danish. --Dipsacus fullonum (talk) 22:41, 14 December 2021 (UTC)
  • I am for anything to reduce vandalism, I catch changes to biographies where changes make a person appear to die before they were born, but I will not catch subtle changes. Especially since more language Wikipedias are using infoboxes with info piped directly from WD. --RAN (talk) 00:44, 13 December 2021 (UTC)
+1. Same with vandalism in bio/chem. --SCIdude (talk) 10:07, 13 December 2021 (UTC)
  • Reminds me of Wikidata:Project_chat/Archive/2021/10#Is there a good reason such edits are technically even possible?. --- Jura 12:45, 13 December 2021 (UTC)
  • Do we have any information on the rate at which changes are reverted for each class of user? What about deletion rate for pages created by each class? Bovlb (talk) 23:32, 13 December 2021 (UTC)
    Best we have is counting "mw-reverted" tags on contributions requiring patrol. This is an underestimation since these tags are sometimes missing for some reason, and undetected/unreverted vandalism is not represented as well. Numbers are, again for the past 30 days:
    • Total ratio of reverted IP edits: 5.7% (~6100 in total over 30 days); in comparison, for newcomers (not yet (auto)confirmed registered users) we have a rate of 3.8% (~2500 in total over 30 days)
    • Revert ratios broken down by edit action:
      • IP edits involving claims: 5.2%
      • IP edits involving descriptions: 5.7%
      • IP edits involving sitelinks: 7.9%
      • IP edits involving labels: 5.0%
      • IP edits involving reverts by the IP: 23.4%
      • all possible other actions have small absolute numbers and similar percentages
    —MisterSynergy (talk) 00:44, 14 December 2021 (UTC)
  •   Oppose - I think there is a danger that we will lack more active editors in the future if we do not allow people to start editing and get a feel for it before choosing to create a user account. We risk scaring people away that way before they start. The problem of vandalism from IP users is also not so big that it is a necessary step, and it would hurt the good users much harder than the few vandals who would probably just find other ways to do vandalism. --Dipsacus fullonum (talk) 23:16, 14 December 2021 (UTC)
      Comment so why do you oppose it? It would allow IPs contribute to items that are currently protected. --- Jura 11:23, 15 December 2021 (UTC)
  Oppose The statistics don't back this up. I also think it would just lead to addition of data as a form of vandalism which imo is harder to detect then if someone is changing a statement that has been stable for a long time and/or is referenced. SilentSpike (talk) 19:59, 15 December 2021 (UTC)

Tramways stations split

Hello, given that example and that(see downtown map) , would it be a good practice to split Washington/Central Avenue (Q7972331), even if there will likely be only one enwiki article ? Because putting two different coordinates with a applies to part (P518) qualifyer is horrible, to a query point of view (horribly complexifies queries) Bouzinac 💬●✒️●💛 23:34, 14 December 2021 (UTC)

Commons categories as sitelinks

Tracked in Phabricator
Task T296337

As discussed in phab:T296337, it appears there are a large number of items, not about Wikimedia categories, that are linking to a Wikimedia Commons category in their sitelink. This causes issues downstream. For example, the issue raised in the Phabricator ticket, if you have are using the parser functions to return a formatted value, when that value has a category for a sitelink, the parser function has the effect of categorizes pages into that category rather than displaying a value. I'm sure there are other unexpected outcomes of linking a concept entity to a category page. I think the correct way to do this would be to use topic's main category (P910) instead of the sitelink. People probably do this often because it's a pain to create a new item for the category page before you can add it as a statement value (or they don't know any better). Is this something that could be fixed in an automated way? Some kind of worlkflow such as taking all items that are not instance of (P31)Wikimedia category (Q4167836) and if there is a Commons sitelink with Category:, then remove the offending sitelink and add the Category in P910 instead, first creating an item for the category if required. Dominic (talk) 17:06, 13 December 2021 (UTC)

Or: fix the downstream process. --- Jura 17:37, 13 December 2021 (UTC)
Can you clarify? My understanding is that a Wikidata item about a concept and not Wikimedia category should not use a sitelink to a category page, but only main namespace. For example, Italo Balbo (Q1056) is an instance of a human, not a Wikimedia category, but has a sitelink to c:Category:Italo Balbo. There are many thousands of these. Shouldn't bad data be corrected? Nothing downstream is broken, if it's just wanting the data that would be expected. Dominic (talk) 17:58, 13 December 2021 (UTC)
I am afraid the current consensus it to link items to Commons categories unless there is also a Commons gallery, in which case the item should be linked to the gallery. We were discussing this over many years, and this is not going to change overnight.--Ymblanter (talk) 18:03, 13 December 2021 (UTC)
Wikipedia categories are handled that way. This is different for other projects, such as Commons, Wikisource, etc.
I think it has always been this way. --- Jura 18:04, 13 December 2021 (UTC)
(After edit conflict) @Dominic: In terms of, "Nothing downstream is broken," this is open for debate. While I don't think it has been tested by consensus, Commons editors appear to like the boenefits of linking individual artists (or subjects) to the categories. This allows the Wikidata Infobox template to present data on the individual/subject and complete a number of auto-categorisation functions based on the Wikidata. There may be other problems caused by this approach, as you suggest here, but we can't say that implementing your proposal has zero impact on other users. As with many things on Wikidata, we need consensus on balancing how we structure the data against accommodating our known users of that data. From Hill To Shore (talk) 18:40, 13 December 2021 (UTC)
I can see what you're saying, and I haven't previously been aware of the discussions or common practices in this area, so I'm not necessarily wanting to argue one way or the other. I think what the issue being raised is that Wikidata practice (and maybe consensus) appears to not align in this case with the way the software was actually designed to work. If this is consensus and could documented as Wikidata policy somewhere. The parser function problem is still not a case of something "downstream" being broken, so much as the software behaving as it was designed but not having the expected results because of the way data is input. Technically, this could affect anything that is being linked across namespaces in sitelinks. If that way of inputting data is the preferred way, it may be that the software's behavior needs to change, such as in this parser function's output. But it would be hard for anyone to know that is the case, if this practice is not documented currently. Dominic (talk) 19:13, 13 December 2021 (UTC)
@From Hill To Shore: Just to let you know that the infobox follows category's main topic (P301) back to the main topic item to find the information to display, and also modifies the displayed interwiki links on Commons so they go to the articles rather than categories, so it's not a problem for the infobox - but would create a few million more Wikidata items. Thanks. Mike Peel (talk) 09:53, 14 December 2021 (UTC)
  • Commons categories should be linked to respective concepts in Wikidata. That is usually Commons category → regular Wikidata item that is not about category. I see no reason to create thousands of useless WD items with only Commons cat sitelinks in it. Wostr (talk) 18:36, 13 December 2021 (UTC)
  • Creating a category item just for Commons is not generally permitted, by Wikidata:Notability. Ghouston (talk) 10:32, 14 December 2021 (UTC)
    Can we perhaps allow an item merely about Commons category Category:XYZ only if they have a corresponding non-category item about XYZ connected with category's main topic (P301)? I believe a major reason why items merely about Commons categories are discouraged is because there are loads of orthogonal categories in the form of "Xs in Y (country, city, etc)" which seem highly redundant when the same can be expressed as an intersection two categories. The condition above would exclude most of such instances. This doesn't solve everything, but I think it will help make things a bit clearer. --whym (talk) 11:32, 14 December 2021 (UTC)
    There are also thousands of items where WP article probably never will be created, but Commonscat exists. It sounds me as bad idea to duplicate items for these objects only because some data purity, even if there are Wikinews which mess categories between articles too. JAn Dudík (talk) 07:44, 16 December 2021 (UTC)
    I think I was not clear enough in my previous comment, but my intent was to require a WP article (or maybe Wikiquote article) as a prerequisite to accept a Commons-Category item. Without a main item to connect to with category's main topic (P301) first, the category would not be able to have a separate Wikidata item. whym (talk) 14:05, 16 December 2021 (UTC)
  • As someone, who over the years has added thousands of Commons category sitelinks to WD items, I'd just like to support some of the views already expressed above. Firstly, it does make the process of adding this marvelous universal Wikidata-based infobox on Commons much smoother and easier. And more importantly, I couldn't agree more with Wostr - there is no point in creating millions of new WD items just for such categories. Powerek38 (talk) 08:10, 16 December 2021 (UTC)

Are the WikidataCon talks notable?

I'm asking this because I would like to contribute by adding structured data to all talks presented in all versions of WikidataCon (i.e. 2017, 2019 and 2021). To do this, I would create a Wikidata item for each talk, but before starting I want to make sure that they don't go against the notability guidelines so that they don't get deleted.

The motivation for doing this is that with structured data, these talks can be more discoverable and thus, useful to the community. In addition to that, we could generate some tables such as the one presented at Wikidata:WikidataCon 2021/Documentation/List of sessions using SPARQL.

I first thought that instead of creating a Wikidata item for each talk, the structured data would be stored in the recording of each talk published in Commons using Structured Data on Commons. However, this is not possible because there are some talks that have a dedicated page in Wikidata (example example example). This implies that a sitelink is needed and, as far as I know, files in Commons can't have sitelinks.

PS: This is not entirely related to this topic: I've started a Modeling page for conference talks in Commons.

Rdrg109 (talk) 04:01, 16 December 2021 (UTC)

It seems to me that this was done before and then deleted for lack of notability.
I think it would be good have items about papers presented there or, if presentation media (slides or videos) are available for these.
Mere "shared notes" or "chat protocols" might be better stored somewhere in Wikidata namespace, as done for the recent Wikidata quality days. --- Jura 11:15, 16 December 2021 (UTC)

Wikidata page needs name change

I have discovered that Wikipedia (German and English), Wikimedia Commons and Wikidata all have titles for the artist Hans Hartmann-McLean mis-spelled as Hartmann-MacLean. (There is evidence in old books available on GoogleBooks™ that it is spelled ...McLean, and the Commons CategoryːSignatures of Sculptors from Germany has two (2) examples of the artist's own signature spelled "McLean". That's pretty good evidence.) The problem for me is that, while I can edit the text of the Wikipedia/Wikidata pages, I can't change the titles. Can someone point me to instructions on how to do this? (When I need to change the name of a Commons Category, I just create a new Category with the correct title, then move text and images into the new one, then put a SPEEDYDELETE tag on the old one. Is that how it's done for Wikipedia and Wikidata?) Seauton (talk) 18:34, 16 December 2021 (UTC)

I assumed you're talking about Hans Hartmann-McLean (Q1580041). Normally I'd say that you should go ahead and edit the labels at the top of the page, but first I think you ought to have the name changed at the English and German Wikipedias first. See en:Wikipedia:Moving_a_page and (I hope) de:Hilfe:Seite verschieben. Also, if you have not already, you should consult commons:Commons:Rename a category. Cheers, Bovlb (talk)
One important point to note is that Wikidata labels must reflect the spellings given by authorities/reliable sources. If you have found some sources that give one spelling and we have other sources that give an alternative spelling, then both spellings must appear in the labels. There may be debate on which is the primary label and which is the alias but all sourced labels must be retained. From Hill To Shore (talk) 19:00, 16 December 2021 (UTC)

Missing sitelinks

Article was created in October 2020 at PLWP but no one connected it until now AMZ Bóbr-3 (Q110156331). How many is there such missing sitelinks and why? Why they can't be connected automatically after for example 1 or 3 months? Eurohunter (talk) 20:49, 16 December 2021 (UTC)

WD relies on volunteers to do this work, either using bots, or manually. There's no central plan, and no backstop if bots or humans don't get around to making the link. Here is a chart of the number of unlinked PLWP articles over time. The last bot run on PLWP looks like it was in July 2020, so it's arguable that that WP needs a little more love. --Tagishsimon (talk) 00:08, 17 December 2021 (UTC)

Non-notable events

The British tennis player Emma Roducanu recently withdrew from a tournament because she had contracted Covid-19. Given that there is a very high probablility that she will recover fully, is it necessary to log this as a "medical condition", or do we only log "medical conditions" that have a marked and/or permanent effect on people's lives. Martinvl (talk) 22:04, 15 December 2021 (UTC)

@Martinvl: As far as I know, a statement medical condition (P1050)COVID-19 (Q84263196) can be used on data objects of people who have had the disease and this can also be proven with a source. Famous examples include: Bill Maher (Q489), Usain Bolt (Q1189) and Albert II, Prince of Monaco (Q3910) --Gymnicus (talk) 17:15, 16 December 2021 (UTC)
Remember to add "Point_in_time=" --RAN (talk) 06:33, 17 December 2021 (UTC)

Company item creation

Hi i am really thankful to everyone for there support and guidance i actually have created one item and now i want to attach his company with the profile can i use personal references in his company item if company name is mentioned in the news article.

--Aroojakhan (talk) 06:38, 17 December 2021 (UTC)

Lists embedded in Wikipedia articles

If we have a stand alone list of position holders in Wikipedia, we can link to from Wikidata. What do we do when the list is embedded in article, and not stand alone? I am working on "position=Prefect of the Vatican Library" and their is a list embedded in the article on the wikipedia:Vatican Library, how would I show it? --RAN (talk) 07:12, 17 December 2021 (UTC)

As with many things here, there is no consistency. There are cases where we have created separate items for the position and a "list of" and there are cases where an individual editor dislikes that method of modelling and merges the two without discussion. I hate to be a cynic but I have given up on working on position items as it is a waste of my time to do work that will be undone on a whim. From Hill To Shore (talk) 12:04, 17 December 2021 (UTC)
And they take a tremendous amount of work! The one nice thing is that Wikidata does some math on the dates and finds errors in the original data at Wikipedia. I don't think I have worked on one yet that didn't have a minor date error, I gave up fixing the list of popes, for that very reason. --RAN (talk) 19:03, 17 December 2021 (UTC)

Jews vs. Jewish People

At Jewish people (Q7325) someone switched away from our longstanding name of "Jewish People" to "Jews", I would like to change it back so it is consistent with the other entries in this category. --RAN (talk) 19:09, 22 December 2021 (UTC)

I've changed it back. -- The Anome (talk) 19:22, 22 December 2021 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 12:19, 23 December 2021 (UTC)

Reference coordinate location as own work

Hello, I was wondering how to reference coordinate location data that I measured myself or possibly somebody else, without publishing it in a scientific paper or the like? Help:Sources only lists publications as valid sources for Wikidata data. But while there are loads of items without coordinate location (or with faulty or imprecise one), with very many of them it is unlikely that they will ever feature in a publication, let alone in one with their GPS position. On the other hand, Wikidata editors could just go there and record the GPS position. But how would this be documented here? --Cephyr~commonswiki (talk) 00:18, 14 December 2021 (UTC)

@Cephyr~commonswiki: I suppose one could use a determination method (P459) qualifier (not a reference) with value something like GPS navigation device (Q1486497). It's a little bit but not quite like posting an image to Commons where there's a clear copyright owner etc. Hmm, not sure. ArthurPSmith (talk) 00:44, 14 December 2021 (UTC)
One of way of sidestepping the question would be to add the coordinates to OpenStreetMaps first, then refer to that with OpenStreetMap relation ID (P402). While that's a bit cumbersome, it does have the added benefit of potentially reaching a larger audience.
That doesn't quite get at the heart of the question, which may just be a can of worms. Recording such data is what some people, somewhere, may call original research. Wikidata doesn't have a policy on that, except that the policy to encourage the use of references implies a certain aversion to. Then again, actually going to some place and reading a measurement of an actual device is closer to the original sense of "research" than what the term usually refers to, which is "I saw it on Youtube".
I feel the following would adequately describe the situation while also being more trustworthy than 9x % of current coordinates, which have no reference or just imported from Wikimedia project (P143). I somewhat fear, however, that just using the term may trigger some expressions of concerns that a synonym wouldn't.
coordinate location
  some value edit


add value

Karl Oblique (talk) 15:22, 14 December 2021 (UTC)

@ArthurPSmith: Thank you. The issue would be the same with other measurements like length, height (P2048), mass etc. Do I understand this right that there is no agreed on procedure? I could not find anything, but maybe I was not looking in the right places? --Cephyr~commonswiki (talk) 12:31, 14 December 2021 (UTC)

Well, I'm not aware of an agreed-on procedure for this! Karl Oblique's suggestion above seems like a good solution for this though. ArthurPSmith (talk) 16:58, 14 December 2021 (UTC)
There is an abundance of map sources available, so the coordinates of very many geolocatable objects are capable of being referenced by citing a map. I'm doing this, methodically, for Scottish objects (e.g. diff). Equally, possibly, the UK is spoilt by having OS maps which go down to house level & smaller; clearly not the case for all countries. So if no map source, then per ArthurPSmith. --Tagishsimon (talk) 14:17, 14 December 2021 (UTC)
Thanks for the suggestion, Karl Oblique.
Tagishsimon, I thought about using maps or publicly available aerial imagery to get coordinates or even length and width, but as far as I understand, this would get one in trouble with database rights of the maps/ aerial image used. E.g. I am reading "due to copyright incompatibility issues it is not possible to import coordinates from OpenStreetMap to Wikidata" here. This must be the same with any map or aerial image that is not licenced more compatibly than Openstreetmap, I suppose. Cephyr~commonswiki (talk) 11:00, 16 December 2021 (UTC)
It's a bit of a legal quagmire. What is, I believe, undisputed is that it's fine to use OSM data on a case-by-case basis, based on its license. Independent of that, such use is legal in all jurisdictions and even for non-free maps, because geocoordinates are facts of nature, not creative works, and therefore not covered by copyright law.
Then, there are Database rights, which is a concept only recognized in the EU. There's a legal opinion by Wikimedia that isn't too helpful but seems to come down on the side of caution. But in cases where the contributor and the database in question are not from the EU, deferring to that law may be overly cautious. It is also time-limited to 15 years, which may apply in some cases. Karl Oblique (talk) 20:33, 16 December 2021 (UTC)
So going forward we can include original research directly?
If so, one might want to update Wikidata:Introduction. --- Jura 18:36, 14 December 2021 (UTC)
See! This is what I meant when I feared that “just using the term may trigger some expressions of concerns that a synonym wouldn't. Karl Oblique (talk) 18:32, 15 December 2021 (UTC)
I don't believe original research belongs in Wikidata (since, as you point out, Wikidata should really be a knowledge base of referenced statements -- even deprecated incorrect ones if there's a reference). Perhaps we should establish clearer policy on this. SilentSpike (talk) 20:03, 15 December 2021 (UTC)
I wasn't necessarily arguing for it. But in the case of coordinate location (P625) we have an abundance of statements with no references at all. I suspect quite a few of them were added in the way I sometimes fix them: by moving a point on a map until it points at the center of some structure with the same label as the item. Is that original research? Does leaving the house and reading two floating-point numbers of your GPS receiver constitute something entirely different? What if it's not a GPS receiver but a mobile phone, and I add the location in passing, while looking up what wikidata has to say about the monument I'm looking at?
Part of the issue are two different definitions of "original research", neither of which has much to do with actual research, and only one of them is "original", but not in the positive sense. The latter is enwiki's, where it's a euphemism for the idiosyncratic ideas that a community of its size sometimes comes up with according to the monkey-typewriter-hypothesis. I believe that adding coordinate locations in the way describe above to be meaningfully different, although I remain undecided if such data is desirable or not. Karl Oblique (talk) 20:54, 16 December 2021 (UTC)
@Karl Oblique: In the case of using a map, I would think that would be sourced (in theory, in practice our statements don't generally do this) to the map since it was produced by some agent and the coordinate is being derived from their work (which could: be wrong, be produced via inaccurate processes, be under copyright such as many OS maps). I've spent a bit of time editing OSM and this concept already applies and is in use there, generally edits are sourced to the aerial imagery (or other source) that was used to produce geometry in a coordinate system (whether point, line or polygon).
As for the case of personally measuring a GPS coordinate. I'm currently unsure what to think, but the process of using a map seems preferable to me since there is a clear notable source. SilentSpike (talk) 13:11, 18 December 2021 (UTC)

start time within the first century

For example Q725585: position held / start time: 87 CE, but it is 87. It is not possible to add the date 87, because system changes it to 87 BC. It seems system is doing this for all dates within the first century. --Goldzahn (talk) 21:40, 16 December 2021 (UTC)

I don't see the problem. There is the year 87 BC/BCE and there is the year 87 AD/CE. On this item all the years are recorded in CE, which you seem to be saying is correct. Is there something I am missing here? From Hill To Shore (talk) 21:58, 16 December 2021 (UTC)
Does CE mean after the year 0? At least in german it is v.u.Z.. Maybe just the v.u.Z. should not be there? V.u.Z means "vor unserer Zeitrechnung" and that is before the year 0. Maybe this is a translation problem, because there is no word in german for the time between the year 0 and 100, as it seems to be in english. Sorry, Im german. Goldzahn (talk) 17:01, 17 December 2021 (UTC)
Sorry, I should have pointed to the items. CE means Common Era (Q208141), which in English is anything after 0. BCE means year BC (Q29964144), which in English is anything before 0. If there are slightly different concepts between languages, we may need to consider how the concepts are represented. From Hill To Shore (talk) 17:12, 17 December 2021 (UTC)
I have created before common era (Q110166141) to fix this.[4][5] From Hill To Shore (talk) 21:27, 17 December 2021 (UTC)
If I recall this correctly, "CE" was added a few weeks ago, as single or two digit years frequently got confused with years in recent centuries. --- Jura 22:07, 17 December 2021 (UTC)
maybe the translatuon for CE should be "n. Ch." or "nach Christus" or "after Christus" then? But, N.u.Z. is more neutral, i think. I wonder if more langugages have this problem? Goldzahn (talk) 22:17, 17 December 2021 (UTC)
It's possible to change it at MediaWiki:Wikibase-time-precision-CE/de. Just add a protected edit request to its talk page.
CE is commonly known as a sign for appliances ;) --- Jura 22:23, 17 December 2021 (UTC)
done. Goldzahn (talk) 22:42, 17 December 2021 (UTC)
It seems this error is in all the german dialect wikipedias. Ich have added some request and wrote at one request that there are more. --Goldzahn (talk) 08:27, 18 December 2021 (UTC)
(after edit conflict) Please see the new section below called Language problems with common era/before common era calendar. I've tried to fix some of the language errors on Common Era (Q208141) but I will be making guesses from this point on in trying to split the conflation. If whoever added the new label to the dates was relying on this item, we may have several languages with incorrect date labels. From Hill To Shore (talk) 22:24, 17 December 2021 (UTC)

Language problems with common era/before common era calendar

Following the discussion above, it appears that our item on Common Era (Q208141) contains conflations in more than one language. From my limited experience with multiple languages, these appear to be split into three:

  1. Some of the language entries talk about the concept of the calendar after point 0 with Christian references removed,
  2. the German entry talked about the concept of the calendar before the point 0 with Christian references removed,
  3. the Latin entry (and I think some others) talk about the concept of the whole calendar without Christian references both before and after point 0.

This presents a significant problem as this concept seems to have led to confusion with setting dates in statements across Wikidata. Per the example given in the topic above, Aulus Bucius Lappius Maximus (Q725585) was giving dates in the English language as CE (common era = after point 0) but dates in the German language as v. u. Z. (before the common era = before point 0). I have tried to fix the items for some of the languages but I am not sure how the labels are being fed into the date statements; can someone with a German view of the items please check if Aulus Bucius Lappius Maximus (Q725585) is now showing dates as N.u.Z. (after year/point 0)?
I have made a start of splitting the conflated item into three parts:

  1. Common Era (Q208141) for the calendar after point 0.
  2. before common era (Q110166141) for the concept of the calendar before point 0.
  3. common era calendar (Q110166296) for the concept of the whole calendar before and after point 0.

There are other items existing for similar concepts but they often have the Christian elements included; this set of items have to cover the concept of the non-Christian version of the calendar. There may be ways to consolidate these concepts with existing items but I think it is best to split the conflated item into its separate concepts first. Looking through the labels on Common Era (Q208141), I think the Norwegian language has aliases for both before and after point 0. Other languages may be the same. Can anyone assist with untangling this problem? From Hill To Shore (talk) 22:19, 17 December 2021 (UTC)

It should be noted that in the traditional Julian calendar, there was no Year Zero, though there appears to be a "point zero" which occured at midnight between the last day of 1 BC and the first day of 1 AD. Since all European calendars are based on the Julian Calendar as modified by Dionysius Exiguus, where does the concept of "Year 0" come from? Martinvl (talk) 22:52, 17 December 2021 (UTC)
Sorry, I'd originally described it as "Year/Point 0" but then corrected myself prior to posting and used only "Point 0." However you seem to have spotted the one reference I failed to remove. I have now struck it out. From Hill To Shore (talk) 22:57, 17 December 2021 (UTC)

Move a Wikidata item?

How do I "move" Canis lupus variabilis? It points to the Wikipedia article en:Canis variabilis, which used to be at :en:Canis lupus variabilis (see the requested move at en:Talk:Canis variabilis). The corresponding Wikidata item needs to move as well, as it's generating an incorrect "Taxon identifiers" navbar at the bottom of en:Canis mosbachensis. {{Taxonbar|from1=Q20644616|from2=Q20720126}} – if I can't fix the Wikidata then I'll have to remove the {{Taxonbar}} to fix Wikipedia. – Wbm1058 (talk) 13:44, 18 December 2021 (UTC)

I would think that just changing the label of Canis mosbachensis variabilis (Q20720126) to Canis mosbachensis subsp. variabilis would resolve the issue. Is that what you mean with "move"? --SCIdude (talk) 15:22, 18 December 2021 (UTC)
Thanks, well yes THIS "EDIT" was something I didn't realize I could do. So much easier than moving pages around creating redirects etc etc. -- it's like {{DISPLAYTITLE}} that actually works; lots of editors think that works on the English wiki for anything, not just cosmetic changes.
But that didn't solve the problem. I see there's also a "taxon name" that needs changed, and when I try to change that:
"Warning: The value for taxon name (P225) in this (or any) item shouldn't be changed (except for spelling corrections). If a taxonomic paper or book introduces a name change, create a new item for the new name (if needed) and add a statement with taxon synonym (P1420) to that item."
So not sure how this should be fixed. I believe that's what happened here. A name change. The previous name that once was "correct" is now considered to be "incorrect". We should show readers the "correct name". Wbm1058 (talk) 15:56, 18 December 2021 (UTC)
Then a new item with the new name needs to be created (or alternatively one for the old name). Let me do that. --SCIdude (talk) 17:59, 18 December 2021 (UTC)
RE: Canis mosbachensis variabilis (Q20720126) – en:Canis mosbachensis variabilis is still a red link. Canis mosbachensis says: "In 2018, a study proposed that Canis variabilis should be recognized as Canis mosbachensis variabilis, an east Eurasian subspecies of the west Eurasian Canis mosbachensis. The difference is that C. m. variabilis possesses a shorter nasal bone and a slight variation in the ridge of the first upper molar tooth." – Wbm1058 (talk) 18:19, 18 December 2021 (UTC)
That WP has only a redlink holds for most WD items. --SCIdude (talk) 18:31, 18 December 2021 (UTC)
@Wbm1058 :  It will be easier if we adopt appropriate wording : Let’s say that on wikipedia we « rename » articles, on Wikidata we can « move » an article/sitelink from an item to another item, and on items we can « change the label ».
In the case of a taxon, if it’s just a new name but the taxon is identical, you should just have to change the sitelink associated to the correct item. author  TomT0m / talk page 16:01, 18 December 2021 (UTC)
"if it's a new name but the new name is identical"? Say what? If it's new, it's different, and if it's different then it's not identical. What's a "sitelink"? What is the "correct item"? I'm lost; you're talking greek. Except that "moving" a page on Wikipedia is the technique used to rename it. I get that concept, of course. Wbm1058 (talk) 16:50, 18 December 2021 (UTC)
@Wbm1058 One of Wikidata usage is to manage the links between the different linguistic versions of wikipedia. To manage that, each wikipedia or wikimedia project can put one and only one of its pages on one item. This page is called a « sitelink ». For example for the item Paris (Q90)      we have on frwiki the sitelink fr:Paris and on enwiki en:Paris.
What we usually call « moving a sitelink » on Wikidata, thanks to the gadget Move (Q108311250) is to take a sitelink (say fr:Paris on Paris (Q90)      ) and putting the page on another item instead (say Universe (Q1)) — just for the example, it would actually not make any sense to actually do that in this case). Such an operation might require to first delete the frwiki sitelink on Universe (Q1) because there is already one.
Now for the « correct » item. Each item is supposed to identify a thing in the real world. If the item stands for the taxon, the stuffs identified are the organisms that this taxon regroups. You created an item for those animals already. The Wikidata items plays on Wikidata the same role that taxon names plays in biological taxonomy, they refer to a description of a certain group of organism and serve as an identifier for them. That’s why you get the warning message « the value for taxon name … » : it is usually bad to change the taxon name because you might make confuse the stuffs refers to (on Wikidata if stuffs are confused it might be a good idea to ask for the deletion of the item), and that’s not suppose to happen : on wikidata or in taxonomy what an identifier refers to should not change, identifiers are supposed to be stable. But if the taxon author himself chose to change the name of the taxon without changing what it refers to, if the taxon has not been published for example, it might be the exception that make it OK to do that. author  TomT0m / talk page 17:27, 18 December 2021 (UTC)
Thanks for the detailed answer. I'm going to try walking through it slower and start by asking a couple questions before I move on to the rest of it. Is it OK for a a « sitelink » to point to a redirect on the other site, or should it always point to an article? I suppose a redirect is OK because the Canis variabilis article was merged into another article, so a « sitelink » that used to point to an article now points to a redirect. Then there is the question of double redirects. On English Wikipedia double redirects are always bypassed; is it OK for a « sitelink » to be a double redirect? Noting that the English wiki has a template for tracking avoided double redirects. Wbm1058 (talk) 18:06, 18 December 2021 (UTC)
Both redirects and sitelinks are possible. The creation of redirects is, unfortunately, complicated by a bug that is unresolved despite many complaints. --SCIdude (talk) 18:17, 18 December 2021 (UTC)
It’s not totally a bug, see
Tracked in Phabricator
Task T278962
 : it was intended in the beginning of the project that redirects would not be really possible. author  TomT0m / talk page 18:32, 18 December 2021 (UTC)

Creating new Wikidata items for all Commons categories

Hi all. I've started Wikidata:Requests for comment/Creating new Wikidata items for all Commons categories as the next step with syncing Commons and Wikidata - please have a look and comment there! Thanks. Mike Peel (talk) 22:51, 18 December 2021 (UTC)

Could a new constraint help dealing with conflation issues?

It is frequent for items automatically created from Wikipedia articles to conflate conceptually distinct P31 values. In the performing arts and in the GLAM domains, the most common cases are items stated to be instances of both a building (Q41176) and an organization (Q43229). As these items are enriched with more statements and identifiers, it becomes very difficult to distinguish which statements or identifiers refer to which entity. For example, an inception (P571) statement could refer either to the date when an organization was founded or to the date when construction for a building began.

This problem has been documented in the Wikiproject Performing arts. It was brought up multiple times during workshops with the international performing arts community - in order to raise awareness of the issue and to reduce its occurence - but to no avail. For each conflated item that is manually and painfully disentangled, another conflated item is created.

This problem was discussed at WikidataCon 2021 during a session entitled "How can we prevent conflictual P31 values?", which I facilitated along with Simon Villeneuve. 39 Wikimedians participated in the discussion and all attested of experiencing this problem in their respective field.

Over the course of the discussion, @Ahoerstemeier: brought to our attention the Wikipedia article covering multiple topics (Q21484471) class. This class makes it possible to flag a conflation issue, to keep a single interwiki link, and to use main subject (P921) to point Wikidata users to all distinct items described in the Wikipedia article (as an example, see left and right (Q542952). This is an elegant and somewhat efficient solution : among other things, it does raise awareness of the issue. However, this solution requires manual intervention (oftentimes, after conflation has already occurred). Besides, this solution is of no use for occurrences of conflation that doesn't originate from Wikipedias.

By the end of the discussion, there was growing consensus among participants that a new kind of value-type constraint was needed to trigger a warning when conceptually distinct classes are stated as P31 values in the same item. This constraint could follow this kind of logic: constraint violation if ?item wdt:P31/wdt:P279 wd:Y AND wdt:P31/wdt:P279 wd:Z - where Y and Z are conceptually distinct classes that shouldn't be instantiated on on the same item. For the particular challenge cited above, the constraint should be triggered if item X is an instance of BOTH building (Q41176) (and subclasses of) AND organization (Q43229) (and subclasses of).

  Question 1. Do others agree that such a constraint would reduce the occurrences of conflation?

  Question 2. How difficult would it be to implement from a technical and operational point of view? @Emu: pointed out that individual constraints would need to be created for each dyad of conceptually distinct classes.

  Question 3. Are there other solutions that should be considered (in addition or in place of the proposed constraint)?

Note: If you are unfamiliar with Wikidata constraints, please check the Property constraints portal.

Fjjulien (talk) 15:05, 27 November 2021 (UTC)

  • It sounds theoretically appealing, so it's frequently proposed by people who rarely contribute to Wikidata.
Depending on the field, it's not clear if there are a lot of benefits for Wikidata itself. We might just end up creating countless additional, hard to maintain items: a few for each operating or owning organization, one for every building part hosting the organization.
Wikipedia articles might still end up being linked from one consolidating most of that.
Projects where this is an issue generally have specialized queries to monitor it. Does yours? --- Jura 15:22, 27 November 2021 (UTC)
The WikiProject does have multiple queries to monitor the issue, at WikiProject_Performing_arts/Data_structure/Data_modelling_issues. The most important query (https://w.wiki/4U3h) however often times out. As far as I know, no member of the Wikiproject has kept records of these query results over time. Fjjulien (talk) 04:09, 29 November 2021 (UTC)
In response to: "We might just end up creating countless additional, hard to maintain items: a few for each operating or owning organization, one for every building part hosting the organization."
The goal of the WikiProject Performing arts community isn't to create distinct organization and venue items just for the sake of stating operator or owner relationships. In the performing arts, both the organization item and the building item fulfill distinct structural needs - beyond the operator or owner relationships. The organization that operates a building often acts as a producer and/or a presenter of performing arts productions. And then, those productions have representations (i.e. performances) that take place in venues. Those representations can take place in the venue operated by the organization, and they can also take place in other venues: a producing company can go on tour; a presenting organization may choose to present performances in different venues in order to reach different audiences. The WikiProject performing arts community's goal is to be able to represent accurately all of these core activities of the performing arts value chain. And in order to do achieve this goal, we need external IDs to be attached to distinct organization and venue items. Fjjulien (talk) 04:37, 29 November 2021 (UTC)
It seems to be meet that your problem statement conflates several questions and isn't directly focused on the problem you are facing.
Ideally, your project would create a series of Listeria reports or complex constraints with the queries you developed. Any constraint, model etc, requires contributors to follow up on it. A constraint isn't magically solving it for you. --- Jura 10:04, 2 December 2021 (UTC)
@Fjjulien: You wrote "The most important query (https://w.wiki/4U3h) however often times out". You could have asked in Wikidata:Request a query for help with optimization so it doesn't timeout. Try this version instead: https://w.wiki/4WV$ --Dipsacus fullonum (talk) 06:26, 6 December 2021 (UTC)
  Thank you. @Dipsacus fullonum. I wasn't aware of such means of optimizing a query. Much appreciated! Fjjulien (talk) 02:02, 7 December 2021 (UTC)
@Jura1 I don't understand how the listeria tool could help us with the problem at hand. Are you suggesting we should use Listeria to generate an up-to-date list of the 4,000 items that conflate organizations and venues? How would this get us any closer to a solution? Fjjulien (talk) 02:16, 7 December 2021 (UTC)
If the project has a backlog of 4000 items - a project I believe was even cofinanced by WMF - it would at some point have to deal with these and then use the available tools to monitor the situation.
Obviously, if your project just determined it has a conflation issue and isn't really working on it, it isn't a good idea to spend more foundation resources on it. Eventually someone has to work on WP Performing Arts and the developers wont be doing that. --- Jura 22:27, 7 December 2021 (UTC)
@Jura1 I do not remember having said or suggested that a constraint would magically solve the problem for us. This is isn't a constructive comment. Fjjulien (talk) 02:22, 7 December 2021 (UTC)
Maybe you can explain how you used the current options and still ended up with a backlog of 4000 items on performing arts and how the constraint would change that. --- Jura 22:28, 7 December 2021 (UTC)
@Jura1:Tes commentaires désobligeants n'aident pas à améliorer la situation. Au contraire, tu décourages les gens à s'y mettre.
Moi, je crois comprendre ce que tu veux communiquer. Mais ici, tu as affaire à des personnes relativement nouvelles sur Wikidata qui ont constaté un problème et qui tentent de trouver des solutions. Ces problèmes, antérieurs à leur arrivée, n'auraient pas été mis en lumière si elles n'avaient pas investi un certain temps à réfléchir à comment mieux lier leur milieu avec Wikidata. Ce n'est pas en les traitant de médiocres ou en insinuant qu'elles utilisent mal des fonds accordés par la WMF qu'on va améliorer la situation. Alors si tu es incapable d'être constructif, de grâce, abstient toi.
De notre côté, nous allons continuer à mieux cerner la problématique et nous relancerons la discussion sur le sujet en 2022. Simon Villeneuve (talk) 20:54, 9 December 2021 (UTC)
@Simon Villeneuve, please attempt to discuss the project and issue at hand. Personally, I find it normal the WMF grantees are expected to provide an account of the work they did as part of the grant.
To qualify yourself and a few other participants as "personnes relativement nouvelles sur Wikidata" and thus unable to deliver on the grants proposal seems odd at least. Maybe WMF should be more rigorous when assessing such grant proposals.
Given the question wasn't addressed, I take it as an answer that actually no attempt was made to work on the 4000 items. --- Jura 11:05, 10 December 2021 (UTC)
Many efforts have been made to disentangle these conflated items, especially by Flemish participants. And plans are being laid out to scale up these efforts, including a datathon in April 2022. Fjjulien (talk) 03:27, 20 December 2021 (UTC)
Grantees should indeed be expected to provide reports. I fully agree with you on this point. And, just to get the records straight, we did submit our final report by the deadline and this report was deemed satisfactory by the WMF. Fjjulien (talk) 03:36, 20 December 2021 (UTC)
  • Ghouston asked some interesting questions about it at Wikidata:Project_chat/Archive/2019/11#Restaurants_etc.. --- Jura 16:14, 27 November 2021 (UTC)
    @Jura1:   Thank you. This is an interesting discussion. The analogy between eating places/restaurants and performing arts buildings/organizations seems correct. Yet, this discussion appears to be concerned primarily with conceptual exactitude. The goal pursued by the performing arts community isn't just conceptual correctness for conceptual correctness's sake. We need distinct items to meet distinct structural needs for representing core performing arts activities. Perhaps I missed something, but I don't understand how this other discussion informs this one. Fjjulien (talk) 04:44, 30 November 2021 (UTC)
    Maybe you should try to formulate your problem statement more closer to your usecase. --- Jura 10:00, 2 December 2021 (UTC)
    @Jura1 There isn't a single use case. In fact, we identified 21 usage scenarios in A Linked Digital Future for the Performing Arts (Q107034002) and more than 70 user stories in the Performing Arts Information Representation Community Group. The vast majority of these usage scenarios / stories involve technical uses cases that do require organizations and building to be modelled as distinct entities. Fjjulien (talk) 02:30, 7 December 2021 (UTC)
    Maybe you could try to summarize it in a way that excludes restaurants and more closely focus on the topic(s) you are interested in ? --- Jura 22:30, 7 December 2021 (UTC)
  • I don't know about the constraint proposal, that does sound like it could be useful. However, on buildings vs organizations - for the most part I would think that the vast majority of buildings are less notable than the organizations that use them, so perhaps we could generally advise that if there's only one item it should be about the organization. Wikidata is not the place to store information about every building in the world. ArthurPSmith (talk) 16:28, 27 November 2021 (UTC)
    I agree that not every building is necessary for Wikidata – that’s especially true for many of the more recent businesses. This doesn’t hold true for many (or indeed most) buildings that host GLAM institutions. That was the main focus of the session. Emu (talk) 20:20, 27 November 2021 (UTC)
    I agree with Emu. GLAM and performing arts buildings are public places. Information about these buildings is likely to be used by quite a range of stakeholders, beyond the GLAM sector: municipalities, tourism associations, visitors, etc. Wikidata is the perfect place to make information about these buildings reusable by all stakeholders. Fjjulien (talk) 04:43, 29 November 2021 (UTC)
I believe it might be more efficient, and immediately possible, to do this with just regular property constraints? If I'm not mistaken, Help:Property_constraints_portal/Conflicts_with could be used to to exclude items with organization-specific properties (legal form (P1454) etc) from also having instance of (P31)building (Q41176) and vice-versa. Karl Oblique (talk) 20:27, 27 November 2021 (UTC)
@Karl Oblique It is indeed a solution that participants in the WikiProject Performing arts have considered. The problem is that defining/exclusive properties - that can only relate to either the organization or the building - have a low level of completeness (i.e. they are not used very often). For example legal form (P1454) is only stated on 98 of 6780 theatrical troupe (Q742421) items (see the query: https://w.wiki/4UDd). That's hardly more than 1%. Now, there are 60 performing arts building (Q57660343) that have a legal form (and on which we could signal a "Conflicts_with" constraint violation, which is significant considering how seldom legal form is stated), but they only represent 2.2% of 2790 items conflating performing arts building and performing arts group (Q105815710) (see the query: https://w.wiki/4UDq). Unless we can identify a defining/exclusive property that is used on a larger proportion of conflated items, I'm afraid this solution would do little to improve the situation. Fjjulien (talk) 14:36, 29 November 2021 (UTC)
@Karl Oblique Further to my previous reply, I would like to flag that there are a few building properties that are used on a greater number of items, and which might be used as "Conflicts with" properties to trigger warnings on conflated items. These include: date of official opening (P1619) (stated in 5474 performing arts buildings items, 131 of which are conflated items), architect (P84) (4303, 111), and heritage designation (P1435) (4164, 62). These would be better contenders for testing the effectiveness of the "Conflicts with" constraint as a solution to reduce conflation.
List of properties used on performing arts building items: https://w.wiki/4UET.
List of properties used on conflated items: https://w.wiki/4UEb. Fjjulien (talk) 15:27, 29 November 2021 (UTC)
  • Is it really so bad for an item to represent a building and an organization? I mean yes it is suboptimal but what practical problems does it create? BrokenSegue (talk) 03:48, 28 November 2021 (UTC)
    @BrokenSegue: That depends on the use case. It doesn’t really matter in cases where Wikidata is nothing more than a glorified interwiki linking base. It’s more problematic in other cases:
      Thank you. @Emu Fjjulien (talk) 04:13, 30 November 2021 (UTC)
    @BrokenSegue Please see my reply to @Jura1 above, in which I explain the kind of use cases that require distinct organization and building items. A live performance is the outcome of several interactions between various agents. It can take place in a given building, and then the same production can go on tour. You can't hope to represent all of these relationships accurately with conflated items. Fjjulien (talk) 04:52, 29 November 2021 (UTC)
  • @Fjjulien: OWL has such constructs at the class level: owl:AllDisjointClasses, owl:disjointWith. WD currently has disjoint union of (P2738) (see P2738#P1855 for an example of use), this is to be used at a parent class all of whose children are disjoint.
    • This is a more systematic way of expressing such constraints, rather than the point-to-point "Conflicts_with" suggested by @Karl Oblique:
    • A new constraint to enforce disjoint union of (P2738) would need to be added.
    • However, in line with what @Jura1: said, I'm afraid that will create a huge number of violations and people will be inclined to ignore them.
    • You are ontologically correct to say "a building is not the organization owning/headquartered there", and there are many other examples eg "a research grant is not the project that it funds", "a port is not the city where it's located", etc. But when you ask the proponent "ok then, please go ahead and make a second item for each violation of your rule", they go mum ;-)
    • So it's not so much about flagging such conceptual problems, it's the data engineering effort needed to overcome them. --Vladimir Alexiev (talk) 08:28, 28 November 2021 (UTC)
    @Vladimir Alexiev: Thanks a lot for pointing out the notion of class disjointness in OWL. That's precisely what we would need to signal occurrences of conflation between performing arts buildings and performing arts organizations in Wikidata. I'm however unclear about how disjoint union of (P2738) could help: performing arts buildings and performing arts organizations do not have the same parent class. I would appreciate more detailed explanations about this solution. Fjjulien (talk) 04:00, 30 November 2021 (UTC)
    @Vladimir Alexiev: I should clarify that my performing arts (and GLAM) colleagues and I aren't making a fuss just for ontological correctness. As I answered to @Jura1 above, performing arts building items and performing arts organization items are meant to serve distinct structural needs within the performing arts ontology. Unless we find a means of reducing occurrences of conflation, we will add messy data production data over messy organization and venue data. Fjjulien (talk) 04:10, 30 November 2021 (UTC)
    Excellent! Then make dual entities in your domain, and use existing tools (eg Listeria over SPARQL) to make lists of problems to be fixed.
    I'm just doubtful such disjointness is feasible for the wide WD. Cheers! Vladimir Alexiev (talk) 16:47, 3 December 2021 (UTC)
  • I want to point out to another, perhaps more productive manifestation of this problem: how to tell Mix-n-Match what classes of items to use when matching against a catalog (external dataset). That's easy for Person datasets (eg Getty ULAN), but hard for conceptual ones (eg Getty AAT) because you can't easily distinguish instances (eg Picasso) from classes (eg painter, expressionist) and limit only to the latter --Vladimir Alexiev (talk) 08:28, 28 November 2021 (UTC)
  • I agree we have a conflation issue in the performing arts and a constraint signal would be useful, for 'educating' contributors who have systematically done such conflation and for easing the fix. We should go for this! --Joalpe (talk) 11:34, 9 December 2021 (UTC)
This conflation is also found for entries on churches. We have the congregation, the building and the cemetery, each with their own inceptions. --RAN (talk) 04:03, 12 December 2021 (UTC)
  • Museums as a class have been modeled inconsistently in Wikidata. The discussion page for museum (Q33506) includes some of the same arguments for and against splitting organizations from buildings made in this discussion; however the consensus within the Wikidata:WikiProject_Museums community seems to be that museum buildings and museum organizations should be separate. Museum is a bit of a complicated case, as unlike in performing arts organizations as discussed by Fjjulien, many if not most items lack a P31 value for building (Q41176) or museum building (Q24699794); however the items with a P31 of museum (Q33506) tend to include properties that obviously belong to a building – such as architect (P84) – alongside properties that belong to an organization – such as director / manager (P1037) or a list of notable items in a collection (owner of (P1830)). Museum items can run into the same problems with inception (P571) of the organization versus the building, and as with performing arts organizations, may occupy a series of buildings over the history of the organization, or the institution may administer more than one building. Therefore the conflation @Fjjulien has pointed out occurs *within* the concept “museum” itself, which as stated in one discussion page, can conceptually mean both organization and building in the understanding of many people, as is reflected in the conflicting subclass of (P279) statements attached to museum (Q33506). Some editors have separated the organization from the building, creating records for both but the majority appear to have not (yet?) been separated. WatsonAmy (talk) 17:00, 14 December 2021 (UTC)
    You are right, @WatsonAmy. The museum (Q33506) class item is itself quite conflated:
    This conflation would need to be discussed (inside and/or outside of Wikidata) and resolved by the museum community. Once consensus is reached (and it looks as though you are pretty much there already), you could deprecate the statements that create conflation, and add the qualifier statement reason for deprecated rank (P2241)conflation (Q14946528). First things first: 1) achieve have conceptual clarity in the class hierarchy; 2) Then, sort out P31 statements in named entities items.
    By the way, we are still sorting out a few conflated class items in the performing arts domain. It's a slow process, but it's worth the effort.   Fjjulien (talk) 04:59, 15 December 2021 (UTC)

One more complication - often organization have headquarters in buiding which was build specially for this organization and was founded in the same time. And articles on WP are usually about both. JAn Dudík (talk) 07:32, 16 December 2021 (UTC)

Further to this discussion, the Data Modelling Issues page of the WikiProject Performing arts was updated to include:

  • additional documentation of issues reported in this discussion; and,
  • more detailed instructions on how to manage external identifiers and interwiki links when disentangling conflated items.
Maintenance tasks will also soon be updated. Fjjulien (talk) 01:54, 7 January 2022 (UTC)

moveClaim.js promoted to gadget

Early Christmas present courtesy of @Nikki : The brilliant userscript MoveClaim.js by @Matěj Suchánek and @User:Melderick has now been promoted to Special:Gadgets . Also thanks to @SilentSpike for suggesting it in the first place, and anyone else involved.

Background: Wikidata:Project chat/Archive/2021/11

Moebeus (talk) 16:19, 17 December 2021 (UTC)

Thank you to all involved. Thierry Caro (talk) 08:34, 19 December 2021 (UTC)
Thanks! --Epìdosis 08:47, 19 December 2021 (UTC)
@Nikki, Moebeus: Could you update the wikilink in the editsummary? It still points to the redirected page. Thanks, --Epìdosis 18:29, 19 December 2021 (UTC)
If it's something I can help with I'll gladly do it, but I'm not sure I understand - what edit summary? Moebeus (talk) 22:54, 19 December 2021 (UTC)
  Done --Matěj Suchánek (talk) 10:07, 20 December 2021 (UTC)
Wow! That's a great piece of news. Recently I came across the necessity to split wrongly merged items and was wondering if there was such a script that would simplify the transferring of claims. Michgrig (talk) 06:37, 20 December 2021 (UTC)

Modelling archaeological periods

I'm using part of (P361)/has part(s) (P527) to model archaeological periods and their subperiods (so Early Dynastic period (Q716742) has part Early Dynastic III (Q109386511), and Early Dynastic III has part Early Dynastic IIIb (Q110209565)) and I'm using follows (P155)/followed by (P156) to model their chronological order (so Early Dynastic period (Q716742) followed by (P156) Akkad period (Q419594). Since Early Dynastic IIIb (ED IIIb) is the final subperiod of Early Dynastic III (ED III), and ED III is the final subperiod of ED, should ED III and ED IIIb each also get a statement followed by Akkadian period, or is it enough to mention this just at ED III? (just to clarify, Early Dynastic and Akkad period are on the same level, so to speak, in that they are not really considered subperiods of anything) Zoeperkoe (talk) 12:21, 20 December 2021 (UTC)

Wikidata weekly summary #499

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • Due to the winter holidays, the development team is taking a break and no deployment is happening for Wikidata at the moment. Happy holidays, everyone :)

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.

Blazegraph failure playbook

As many of you know, there is a risk of Blazegraph, Wikidata Query Service’s backend, catastrophically failing before we are able to properly scale the service.

Thus, it is important for us to have a playbook for what actions we will take in the event of such a disaster, as well as making that playbook transparently available.

This Blazegraph failure playbook is now available, and we welcome you to take a look at it, though we hope to never use it.

--MPham (WMF) (talk) 10:00, 10 December 2021 (UTC)

Thanks for doing it. It is reassuring that the question was analyzed and a plan made. --- Jura 11:08, 10 December 2021 (UTC)
This is quite excellent. Thanks to all involved for the thorough analysis. I am now wondering what percentage of the 1% of queries touching the scholarly literature are made as part of efforts to add more items from that domain. Making up 40% of all data, the costs (real-, opportunity-, and as annoyances) must be substantial. Judging these efforts will obviously depend almost entirely on one’s use of that data. But, speaking for myself, I wouldn’t terribly mind if activity shifted to less insular domains. Books come to mind as a closely related subject that sees drastically lower coverage, even though it might have more potential for usefulness both within wd (as references) and outside (goodreads, openlibrary etc) Karl Oblique (talk) 15:12, 11 December 2021 (UTC)
Just echoing other replies here, good to see this and many thanks to the WDQS analyst (AKhatun) for her work! SilentSpike (talk) 15:53, 11 December 2021 (UTC)
The scholarly articles in Wikidata are terribly outdated. Almost none of my favourite articles and researchers have a place in Wikidata. Luckily I have installed Blazegraph myself and now I can enjoy personalized Wikidata experience using ontology from Wikidata. --Midleading (talk) 09:42, 14 December 2021 (UTC)
@MPham (WMF): Thanks for letting us know. Regarding the investigation of a replacement, I see phab:T206560, but is there somewhere else that the information is being gathered or discussed? Thanks, Bovlb (talk) 03:53, 21 December 2021 (UTC)
While we have been collecting feedback in that phab ticket, and doing a lot of analysis on the Wikidata graph and queries, the formal process of determining a suitable replacement for Blazegraph will be starting in the new calendar year. I appreciate the reminder to make sure that we have as much transparency and communication channels for that discussion as possible, and will provide another update when the process kicks off with more details. --MPham (WMF) (talk) 09:37, 21 December 2021 (UTC)

Language differences

One of country of citizenship (P27) on Karolina Protsenko (Q91313507) is Ukraine (Q212). Why name in native language (P1559) and languages spoken, written or signed (P1412) is reported as Russian (Q7737) and not Ukrainian (Q8798)? --151.95.221.205 19:21, 21 December 2021 (UTC)

Do you imply that every Ukrainian citizen has the Ukrainian as the mothertongue? This is patently wrong.--Ymblanter (talk) 20:03, 21 December 2021 (UTC)
Even according to uk:Російська_мова_в_Україні, at least 30% of Ukrainian nationals speak Russian as their native language. According to the subject’s Facebook page, she speaks Russian and English. I think it’s a safe bet that English isn’t her native language, hence Russian. Is there any reason not to believe her? -- Emu (talk) 23:28, 21 December 2021 (UTC)

Aisin Gioro (Q934262) vs Aisin Gioro (Q110227053)

Can you please take a look at it Aisin Gioro (Q934262) vs Aisin Gioro (Q110227053). Thanks. --HarryNº2 (talk) 08:19, 22 December 2021 (UTC)

@HarryNº2 Hello, I just split this item into the two you are linking. One is for a family and one for a surname. Is there a problem? Vojtěch Dostál (talk) 08:44, 22 December 2021 (UTC)
A big problem, you messed everything up, it can't stay that way. Somebody with knowledge of the Chinese language has to come up and clean up properly. I can only ask you for the future to refrain from doing things that you have no idea about and to ask for help here in the forum beforehand. --HarryNº2 (talk) 08:56, 22 December 2021 (UTC)

Entities that change names

What's the best way of dealing with entities that change names? For example Manchester United were formed as Newton Heath LYR Football Club in 1878 and didn't adopt the current name until 1902. Apart from listing the original name as an alias there doesn't seem to be a property to use to list former names and hence add qualifiers. Nthep (talk) 13:23, 22 December 2021 (UTC)

Add official name (P1448) with relevant qualifiers for each name. From Hill To Shore (talk) 14:07, 22 December 2021 (UTC)

A sub-class for media and/or medium

Hello,

I've been looking for a root sub-class that could be used to group together all types of media. An example of how this root sub-class would be: 

 - media (our root sub-class)
   - print
     - newspaper
     - book
     - ...
   - broadcasting
     - television
     - radio
     - movie
   - internet
     - podcast
     - ...

The closest thing I've found is https://www.wikidata.org/wiki/Q340169 but the items associated with Q340169 don't quite match with the above intent with instance associations like: 

 - SMS
 - Internet Relay Chat
 - Ethernet
 - etc.

any help would be greatly appreciated.  – The preceding unsigned comment was added by Erichosick (talk • contribs) at 01:44, 17 November 2021 (UTC).

Granularity of local information

The article of de:Rinnen (Gemeinde Berwang) says in its first line, that it is about a village ("Dorf"), a locality ("Fraktion") and a cadastral community ("Katastralgemeinde"), but in fact it is all about the village - the further text describes the village only. The locality and the cadastral community are mentioned in the infobox with its population and its area.

And now the problem: the locality of Rinnen consists of the village of Rinnen and a few houses called Rauth, the cadastral community of Rinnen consists of the locality of Rinnen (with Rauth included) and the small locality of Brand. The article seems to unite village, locality and cadastral community und does not elaborate that village, locality and cadastral community are distinct things and nested within the other.

How can I handle this in Rinnen (Q1353899), when I want to put values for population and for area into this item - the population for the locality and the area for the cadastral community, because the village itself has no statistical or surveying data.

Should I modify its item like Rohrbach an der Teich (Q701702) and put all together or should I split this item into subitems like Erlsberg (Q67288493) - this is a model User:Emu suggests. The original article puts all together. Creating multiple items is exact but may be hair-splitting. Most articles about villages cover "multiple topics" and I think the WD item should pool all information in a pragmatic way as the articles do. --Maincomb (talk) 15:23, 14 December 2021 (UTC)

  Info Forum shopping of WD:Forum#Ortschaft_und_Gemarkung --Emu (talk) 16:03, 14 December 2021 (UTC)
FYI Wikipedia article covering multiple topics (Q21484471). 2A01:CB14:D52:1200:44C6:F07B:3E17:F78 20:35, 14 December 2021 (UTC)
  • I'd opt for the more general between "village" and "locality" if they aren't identical. It may or may not be practical to distinguish between the two anyways. So items may be about both. It's also possible that dewiki articles mostly follow one type. I know this doesn't answer your question directly.
Cadastral communities seem to be like electoral districts: they have a single purpose. If they aren't identical with other layers, territory overlaps (P3179) may be useful for them. Possibly you might want to create a new property for them, similar to associated electoral district (P7938). --- Jura 10:44, 15 December 2021 (UTC)
Cadastral communities are districts used for land registration purposes. They fully cover Austria, never crossing municipality lines. I don’t think we need new properties for that.
There are cases where municipalities only have one cadastral community and only one village – in those cases a single item might suffice. In other cases, a cadastral community and a village share a name but other villages might lie in the same cadastral community. Maincomb wants to pack all of them into one item, avoiding Wikipedia article covering multiple topics (Q21484471). I repeatedly told them that this isn’t how Wikidata works. They disagree.
It might be interesting to know that a similar problem plagued WikiProject Austria in de.wp for years, resulting in endless discussions and a block (or ban, I don’t really understand every detail of this conflict). Emu (talk) 13:21, 15 December 2021 (UTC)
Most articles intend to be about villages or hamlets but Official Bodies deliver statistical information for localities and cadastral communities. So we have the scheme village = locality = cadastral community for an oeconym where all works fine. And then there are many cases with (village + single house) = locality = cadastral community where we have an article about the village and combine it with statistical information about the locality and the cadastral community. We describe the special situation of the single house within the article. When it comes to wikidata, we need an WD item that covers common aspects of the article so we can access them (population, area ...). A composition like Erlsberg (Q67288493) is not applicable, because it does not model the relation between locality an cadastral community, it just summarizes other items. Apart from this wikidata/wikipedia has no mechanism to access data from subitems and sub-sub-items. So a good structure for Wikidata might not be useful for Wikipedia and vice versa.
The issue ends up in some cases like villages+hamlets+houses = some localities = cadastral community or villages+hamlets+houses = some cadastral communities = locality where we tend to create articles for cadastral communities or localities. --Maincomb (talk) 16:22, 15 December 2021 (UTC)
Maincomb wrote: "How can I handle this in Rinnen (Q1353899), when I want to put values for population and for area into this item - the population for the locality and the area for the cadastral community, because the village itself has no statistical or surveying data." I would suggest using the qualifiers "sourcing circumstances (P1480) [applies to locality]" and "sourcing circumstances (P1480) [applies to cadastral community]". --Dipsacus fullonum (talk) 17:28, 15 December 2021 (UTC)
I just did this with Rinnen (Q1353899) and it seems to be fine. (The box only accepts "locality" instead of "applies to locality", but this is a minor problem.) --Maincomb (talk) 18:59, 15 December 2021 (UTC)
That’s not how sourcing circumstances (P1480) should be used as evidenced by the exclamation mark next to the statement. I believe you meant applies to part (P518) but that doesn’t solve the problem of conflation in Wikidata. Emu (talk) 21:52, 15 December 2021 (UTC)
Not really convinced by that either nor by the use of Q21484471). I still like may initial suggestions.
I may be mistaken, but are there any elements in [6] beyond the ID and its mention in the intro that refer to the cadastral municipality? --- Jura 22:24, 15 December 2021 (UTC)
The exclamation mark is there because sourcing circumstances (P1480) has no property constraint called "applies to locality". But everybody can add this constraint. (I just put "upcoming music video" in the field an the exclamation mark disappeared.) IMHO this can be part of a solution.
In de:Rinnen (Gemeinde Berwang), the area within the infobox is about the cadastral community (Text: "Fläche d. KG = 11,55 km²"). --Maincomb (talk) 22:33, 15 December 2021 (UTC)
So it's 2 statements. I don't find that sufficient to determine the topic of the article. --- Jura 22:38, 15 December 2021 (UTC)
The article doesn’t really make that much sense anyway. The infobox suggests that 102 live on 11,55 km². That’s not the case as the 50 or so inhabitants of Brand also live on those 11,55 km². Emu (talk) 22:43, 15 December 2021 (UTC)
Apart from this we have a lot of data about housing (houses/gardens/leisure areas...), land use (fields/meadows/forests...) etc for cadastral communities, but this is not included in the small article of Rinnen and it depends on the author, what to put in. The infobox is already prepared for "number of houses" but all failed because of maintenance - therefore we would need wikidata.
The infobox says: "population of locality" (="Einwohner der Ortschaft") and "area of cadastral community" (="Fläche d. KG"), so it is correct: 102 inhabitants live in this locality and the size of this cadastral community is 11 km². One cannot mix up two different types of units. This infobox was developed and modified over years, it is used in thousands of articles and should not be discussed in wikidata. (The infobox is really good, it can be used for any case below municipalities. For villages that are neither locality nor cadastral community, the infobox is used like in de:Prasdorf (Gemeinde Blindenmarkt).) --Maincomb (talk) 00:04, 16 December 2021 (UTC)
What about using based on (P144) as I did with Rinnen (Q1353899)? --Maincomb (talk) 09:50, 16 December 2021 (UTC)
If there is much data involved, it might be preferable to always create separate items for cadastral municipalities. These can then be linked from localities, fractions, villages, municipalities, etc.
Wikipedias can then use the data in their infoboxes as they prefer. For clarity's sake, Wikipedia editors might want to have a separate infobox on the cadastral municipality anyways. --- Jura 10:49, 16 December 2021 (UTC)
BTW, reminds me of Wikidata:Property proposal/numéro de parcelle --- Jura 12:28, 16 December 2021 (UTC)
The source for cadastral data is [7] with a lot of data nobody is interested in, like number and size of cemeteries for each cadastral community. I suppose that the "number of houses" or the "built-up area" will be used soon and maybe as time series, because there are data from 1979 till now.
For WP articles, it is easy to access values in the dedicated WD item, it is hard to access values in foreign items and IMHO impossible to access connected items via linkage. So Erlsberg (Q67288493) may be nice in some cases, but how to access data in its subitems? I cannot find an example for this. --Maincomb (talk) 14:45, 16 December 2021 (UTC)
As I have said before: It’s maybe not a really good idea to use questionable workarounds to overcome (perceived) technical limitations. And it’s not like I really want items like Erlsberg (Q67288493) but if this sort of conflated article is what a project (in this case you and your sock) prefers, so be it. Emu (talk) 15:43, 16 December 2021 (UTC)
Personally, I'd link the article to Q109839533 and there located in statistical territorial entity (P8138) (or another property) could be used to fill the infobox on the article.
This even though bar:Erlsberg has a large part about the cadastral municipality.
All these articles don't strike me as a good use of Q21484471, as there is a strong topical link between the parts. --- Jura 17:58, 16 December 2021 (UTC)
I agree with Emu that this sort of conflation of several objects is not desirable. Attempts were made in "Czech" Wikidata to conflate a mountain and its eponymous protected natural reserve, a municipality with its eponymous central part (core municipal part with the same name as the municipality in the Czech Republic (Q56398194)), etc, but it always ends as terrible items which heavily rely on applies to part (P518) to be able to say anything at all.Vojtěch Dostál (talk) 08:56, 17 December 2021 (UTC)
This problem occurs, when grown areas (=villages) do not match with statistical units (=localities) and this happens very often. I think, real conflation is, when we put a village and a mountain into one article because of a similar name. Here, we are talking about villages and their theoretical approach by official bodies. This sort of "light conflation" always happens in fine granular situations.
There is a strong topical link bewteen items and although bar:Erlsberg has a large part of cadastral information, it intends to be about the village. I guess that there will never be articles about Erlsberg-locality and Erlsberg-cadastral community. We are talking of about 50% of all cases, where a village does not match exactly with its locality or its cadastral community, because of one or some single houses or hamlets or localities. (There are about 7800 cadastral communities in Austria and only about 100 cases, where WP editors made articles for cadastral communities e.g. where there is no village/hamlet/house within. Same with localities, there are about 17000 localities and about 100 special cases. And there are about 50.000 human settlements where most of them will never get an article.)
In Austria, there are articles like de:Oberschlierbach (Gemeinde Oberschlierbach) - this is the central part of the municipality of de:Oberschlierbach. And its item Q57232538 is not complete, it should be at least "instance of human settlement". --Maincomb (talk) 11:19, 17 December 2021 (UTC)

@Emu: Yes, we discussed this several times and I never got your solution. Nearly all WPs have a single article for local objects, there is nearly no distinction. Here is the example of de:Walchshausen, a village with two localities within two municipalities, see Walchshausen (Q1259103), Walchshausen (Q110243119) and Walchshausen (Q110243123). Does this model work for you? --Maincomb (talk) 20:29, 22 December 2021 (UTC)

Is it stated or inferred?

I am having a disagreement with @Gamaliel: over the use of stated in (P248) for information that I interpret as inferred from the source, but which Gamaliel interprets as stated in the source.

The instance is one of a potentially large set of edits based on the contents of "The Library of the World's Best Literature". Specifically, on this edit, the claim is made that the source "states" that Aeschylus (Q40939) is a writer (Q36180). However, on looking at the source [8], I find that it "states" "Æschylus (es'ki-lus). The greatest of the Greek dramatists;..." [9].

It says "dramatist", not "writer". When I broached the issue with Gamaliel, I received the reply "I share your view that we should not make inferences from sources. A Library Of The World's Best Literature is a 30 volume work. The biographies in the are from 2 volumes of that work called "The Reader’s Dictionary of Authors", thus I concluded that A Library Of The World's Best Literature is directly stating that every person contained within those biographical volumes is an author."

Since Gamaliel is concluding this fact from information not in the actual entry, I see that as an inference. Gamaliel disagrees.

Feedback from the community is appreciated. --EncycloPetey (talk) 00:17, 20 December 2021 (UTC)

playwright (Q214917) AKA "dramatist" is <subclass of> "writer". I don't see inference here. - PKM (talk) 00:57, 20 December 2021 (UTC)
The ancient dramatists we know by name were writers, as they wrote their dramas down. Those who didn't write their dramas down are forgotten to history. This is a non-issue. From Hill To Shore (talk) 01:03, 20 December 2021 (UTC)
@From Hill To Shore: You seem to have misunderstood the issue. It is not a question of whether dramatists were writers, but whether this is an instance of information stated in or inferred from the source, as pointed out in the title of this thread. --EncycloPetey (talk) 04:41, 20 December 2021 (UTC)
No misunderstanding at all. It is stated that he was an ancient dramatist and we know his name. The ancient dramatists that we know the names of wrote their dramas down. Ergo, it is stated that he is a writer. As I said, it is a non-issue. We do not need to see the words, "he was a writer," if we have a source stating he was a subclass of writer.
It is like having a modern source saying, "He was in the Lancashire Fusiliers" and we then use that as supporting evidence that a subject was part of the British Army. The words "British Army" do not appear in the source but it is stated that he was in a unit that was part of the army. No inferrence is required. From Hill To Shore (talk) 09:00, 20 December 2021 (UTC)
Wouldn't it be prudent to give a citation, at least in some cases? Which property for that? --SCIdude (talk) 17:23, 21 December 2021 (UTC)
I would add a reference for any new statements. In this case "stated in" works, as a reference stating a subclass also supports the larger class. Whether you would want to choose the imprecise statement over the precise one is a separate question. All we were asked here was whether the reference could be said to state the larger class. From Hill To Shore (talk) 09:44, 22 December 2021 (UTC)
In the case you use as an example, the broader description is positively useful, as it will be more recognizable. What is the advantage of identifying a dramatist as a writer, which loses some information with the generality? "in the British army" carries some precision; but "writer" in the sense that "he wrote stuff down" carries no such precision when "dramatist" is far more useful. --02:31, 22 December 2021 (UTC)  – The preceding unsigned comment was added by EncycloPetey (talk • contribs) at 02:31, 22 December 2021 (UTC).
Your original question was whether the source states he was in the larger class and the answer to that is yes; not only does the source say he was a dramatist but also that there are several of his written works still surviving today. The source also supports him being in the more precise subclass of playwright. Personally, I would choose the more precise subclass over the larger class. From Hill To Shore (talk) 09:44, 22 December 2021 (UTC)
Indeed, and my original question is the important one for purposes of this discussion. --EncycloPetey (talk) 20:14, 22 December 2021 (UTC)

WDQS State of the Union, Dec 2021

Hi all, I'm trying to make sure we keep everyone updated with WDQS progress. Here is the latest State of the Union.

Have a great end of 2021, and we'll see you next year! MPham (WMF) (talk) 17:54, 22 December 2021 (UTC)

Q85409163 National Museum of Anthropology edit history

Something very odd is going in in this edit history. A swarm of editors appears to have descended and added and removed myriad items. Is this vandalism? Timtrent (talk) 12:15, 22 December 2021 (UTC)

It suggests it is a test item, yet this is, surely, an odd usage. There must be test areas that can be used? Timtrent (talk) 12:18, 22 December 2021 (UTC)
Yes there is for example Q4115189. --LydiaPintscher (talk) 17:00, 22 December 2021 (UTC)
There is no difference between them. They are both live items marked as being reserved for testing purposes. From Hill To Shore (talk) 17:12, 22 December 2021 (UTC)
So for us mere humans, easily confused, shouldn't it be clearly distinguished as different from (P1889) --> National Museum of Anthropology (Q524249)? A simple search yields other test items with the same label (Q85409310, Q85408938, Q85409446, etc.), all referring to abstract/test representations of Q524249. -Animalparty (talk) 19:05, 22 December 2021 (UTC)
What appears to me to be most appropriate is to create or publicise a discrete area of Wikidata that is used for tests, familiarisation, etc, and to forbid this bizarre usage of highly similar real life items for testing and/or educational purposes. It pollutes the data. Timtrent (talk) 00:04, 23 December 2021 (UTC)
@Animalparty: There is no need for the attitude. We are all "mere humans." Timtrent asked if there were specific test areas outside of the live environment and LydiaPintscher pointed to another live item used for testing. I merely replied to say that both the live items were effectively identical. I have no knowledge of how testing environments have been set up and I have no special wisdom to share to resolve any confusion that you feel. From Hill To Shore (talk) 00:39, 23 December 2021 (UTC)

Mutually exclusive "instance of"s

Hello! I'm wondering if there is an established way, or best practice, to properly label situations where an item would be one of two "instance of (P31)" items, but could never be both. I thought perhaps that labelling them both "nature of statement (P5102): sometimes (Q110143752)" might be sufficient, but I no longer feel that works well. Thoughts or ideas? — Huntster (t @ c) 05:13, 17 December 2021 (UTC)

Not quite clear what your use case is. Could you illustrate with a worked example? You have a subject, it could be one (and only one) of two things, but you're unable to say which of these two things it is? Seems odd. --Tagishsimon (talk) 05:23, 17 December 2021 (UTC)
Tagishsimon: Sorry for being unclear, and I said "instance of" rather than "subclass of", though this could apply to either. As an example, right now manufacturer (Q13235160) is a subclass of person or organization (Q106559804), which in turn is only a subclass of agent (Q24229398). person (Q215627) and organization (Q43229) need to go between manufacturer (Q13235160) and person or organization (Q106559804), but I need a way to show that, while both can be true, only one of these applies at any given time. I cannot find a good way to do this. Honestly, I don't think person or organization (Q106559804) should have been created as I feel it complicates more than it solves, but I suppose we're past the turning point now. (sigh, I still feel like I'm being unclear, and I apologize.) — Huntster (t @ c) 05:46, 17 December 2021 (UTC)
Mmm. Okay, I see the problem area, and admit the higher levels of many of WDs ontologies are sketchy or broken. Not sure I agree that the items and class hierarchy you point to are an instance of the problem. A manufacturer seems indeed be 'a person or an organisation' which set is a subclass of an agent - 'individual and identifiable entity capable of performing actions' (think that should be 'individual or identifiable entity...", or, some better and less ambiguous description). Agent seems to have impeccable credentials, such as http://xmlns.com/foaf/spec/#term_Agent and https://id.loc.gov/ontologies/bibframe/Agent.rdf . So I'm not finding anything in the manufacturer to agent graph to object to. Equally, I'm not sure, right now, where and how to link the concept of 'person' or of 'organisation' to person or organization (Q106559804), and nor am I convinced by the values in https://www.wikidata.org/wiki/Q106559804#P1269 . I am fairly sure that 'person' and 'organisation' should not be found between manufacturer and person or organization (Q106559804).
I can see where I think you're going; the suggestion that manufacturer should be a subclass of 'person' and a subclass of 'organisation', but both qualified such that it is clear that an instance of a manufacturer can only be a subclass of one or other of them, and is not to be considered as a subclass of both. This would not be how subclasses work on WD now, to my (limited) knowledge; I know of no appropriate qualifier value which would support the concept. I can't come up with a strenuous objection to your suggestion that this sort of thing should be supported; will be interesting to hear what others more awake and/or thoughtful than me, right now, make of it. --Tagishsimon (talk) 06:21, 17 December 2021 (UTC)
If you make agent a set of two, containing person and organization, then any instance or subclass of agent is either person or organization, no? --SCIdude (talk) 16:30, 17 December 2021 (UTC)
Not by my understanding. Absent any further qualifiers, in that circumstance, any instance or subclass of agent is both a person and an organization. Instances and subclasses do not get to pick and choose which attributes of the class they inherit; and that's really the nub of the issue Huntster is raising, as I understand it. --Tagishsimon (talk) 22:19, 17 December 2021 (UTC)
Yes, this is exactly the problem. If there are no qualifiers/similar, then it has to be interpreted as the item being instances or subclasses of both items. — Huntster (t @ c) 06:12, 19 December 2021 (UTC)
There is disjoint union of (P2738)   to state that a set of classes share no instance together.
Some example of usage, good or bad, on given name (Q202444)      or on physical object (Q223557)     . The statement is used to generate queries on the talkpage thanks to {{Item documentation}}, see Talk:Q202444 for example.
(the query finds results on the name example but on the physical objects it timeouts) author  TomT0m / talk page 10:18, 18 December 2021 (UTC)
I can see where disjoint union of (P2738) might be useful for some things, but I don't think it would have value in this instance. Child items need to inherit person (Q215627) or organization (Q43229) for constraint purposes, etc., but if they are placed under disjoint union of (P2738) they won't.
That said, I wonder if excluding (P1011) could be used? For example, person (Q215627)excluding (P1011)organization (Q43229) and organization (Q43229)excluding (P1011)person (Q215627)? (pinging Tagishsimon, SCIdude, TomT0m) — Huntster (t @ c) 06:32, 19 December 2021 (UTC)
@Huntster It works at least with person or organization (Q106559804). An example of person or organization is either a person or an organisation.
Now the parent class tree of « person or organisation » is cleaned-up. author  TomT0m / talk page 09:43, 19 December 2021 (UTC)
TomT0m, it works in theory, but not in application. See, for example, all the warnings at Grumman (Q463261). At current, all the various constraints we have are geared solely around Instance of and Subclass of. Those warnings are popping up because manufacturer (Q13235160) is no longer associated with organization (Q43229). This is not something isolated to just the Grumman item, but will be found with virtually anything with dependencies on organization (Q43229) and who knows what other items. I'm simply focused on person or organization (Q106559804) as an example of a much wider issue.
Could disjoint union of (P2738) start being included in our constraint system? Probably, but it would take a pretty significant effort that's honestly beyond my knowledge. — Huntster (t @ c) 16:27, 19 December 2021 (UTC)
@Huntster: As far as I can tell, Special:Diff/1547249834 fixed the warnings on Grumman (Q463261) by explicitly affirming that it's a enterprise (Q6881511). The current constraint model basically requires every instance of manufacturer (Q18244268) to have such a statement (or a similar one involving person (Q215627)). If that's inconvenient, then I'd suggest undoing this merge of manufacturer (Q18244268) into manufacturer (Q13235160) and creating a companion "manufacturing company" item that's a subclass of manufacturer (Q18244268). Then Grumman (Q463261) can be simply an instance of a "manufacturing company" without impacting any manufacturer-people. Minh Nguyễn 💬 09:11, 23 December 2021 (UTC)

Unknown date of death

Hi, although this has probably been discussed here before, I haven't found any information. How can it be written that the date of death is unknown? The problem is that in local infoboxes (Romanian Wikipedia for example) age is counted continuously.--Kun Kipcsak (talk) 09:13, 21 December 2021 (UTC)

Take a look at this. https://www.wikidata.org/wiki/Help:Dates#Inexact_dates Popperipopp (talk) 09:27, 21 December 2021 (UTC)
Maybe it should stop calculating age beyond a some limit. People older than 100 generally have "centenarian" set. No human born before a determinable year is still alive. Please don't fill Wikidata with unknown claims merely because of something that should be fixed in the infobox. --- Jura 12:03, 21 December 2021 (UTC)
Thanks to everyone for the answers! The idea of accuracy is relatively good in some cases.--Kun Kipcsak (talk) 11:51, 24 December 2021 (UTC)

Custom Wikidata query service without limits for complex queries?

Sometimes, I run into a time-out no matter how I optimize a query. Would it make sense to have a custom Wikidata Query Service for very time-demanding queries (such as those involving scientific papers)? The possibility was documented by Addshore two years ago. Queries would probably not be run in parallel, but only by the maintainers, after a vetting process to optimize the proposed queries. Would this make sense for some of you or it is simpler to download and process dumps directly? Vojtěch Dostál (talk) 12:43, 21 December 2021 (UTC)

There are a couple of ideas around, for instance in phab:T179879 (Provide a 5-minute timeout in WDQS for trusted users using OAuth). Those center around the idea that WDQS could have an authentication system that would allow users to log in and have same query quota that they could use beyond 1min-timeouts. However, I don't think that anyone is really working on this right now.
Setting up an own WDQS instance is likely beyond the capabilities of most users since one needs powerful hardware and a lot of expertise. If you want to process the dump directly, I recommend to consider doing this on Toolforge or other WMF infrastructure, as you would not have to download the entire thing to your machine. wikitech:Help:Toolforge/Dumps provides some related information. —MisterSynergy (talk) 13:02, 21 December 2021 (UTC)
The idea was to have one instance shared by several power users, as Harej suggests below :). Vojtěch Dostál (talk) 15:45, 21 December 2021 (UTC)
Hello Vojtěch Dostál, I operate a parallel query service with a timeout of 10 minutes. I am looking for an initial set of users, with my focus being on research queries and bot (but not tools, apps, or general public usage). Harej (talk) 15:25, 21 December 2021 (UTC)
@Harej Sounds great! I've run into several queries like that in my recent attempt to connect more Commons categories to Wikidata items. Some domains such as surnames or taxa seem just too big for some sort of queries. Vojtěch Dostál (talk) 15:48, 21 December 2021 (UTC)
+1, my bot have many timeout queries related to {{Autofix}} processing. Currently bot uses dumps for timeout queries. But dumps are outdated always. It is nice to have additional service for processing hard queries. — Ivan A. Krestinin (talk) 15:57, 24 December 2021 (UTC)
@Harej I want to be your friend just to have access to your service :-D —Ismael Olea (talk) 17:20, 24 December 2021 (UTC)

Introducing a parent class for sources of information

Currently for properties which can take a value which is some source of information (prime example being "stated in" for sourcing) it seems we rely on adding multiple classes to the constraint (e.g. version, edition, translation or database or podcast, etc.). This indicates to me that we are missing a common parent class that such classes are inheriting the property of being usable for sourcing from - which would be useful for constraining properties as well as for reference in discussion of modelling in this area.

I've started a discussion on this at Property_talk:P248#Improving_the_model_of_allowed_value_types. Not currently feeling bold enough to just make the change so seeking input (please reply there). --SilentSpike (talk) 20:21, 24 December 2021 (UTC)

One error

There is one page: User:Infovarius/taxonomy. On the end of this page, there is green box with name: Tree of Homo sapiens. After click on Expand on it's right, there is only one line (human) - therefore, it seems to be corrupted.

The problem lies with the wrong item. Instead of part: items=Q5 it should be: items=Q15978631.

Can someone fix it? 149.156.172.74 09:36, 30 December 2021 (UTC)

Ahh… well - I had some problem to add him an info; maybe this: @Infovarius: will help. 149.156.172.74 13:22, 30 December 2021 (UTC)

This section was archived on a request by: please use the user talk page --- Jura 20:00, 30 December 2021 (UTC)

Wrong constraint in P750

I don't want to delete or edit a constraint without any discussion, but I think that having contemporary constraint (Q25796498) in distributed by (P750) is wrong. To understand the problem, please take a look at 'Allo 'Allo! (Q425628) as an example. This is a pretty old TV series, which is now being distributed via streaming, in this case Netflix (Q907311). Now this constraint essentially means that streaming platforms should not (at least according to Wikidata logic) distribute content older than the streaming platform itself. It is obviously absurd and I don't think it requires much further reasoning. Powerek38 (talk) 20:42, 25 December 2021 (UTC)

Thanks for raising this. There are at least three ways to resolve this, so some consideration is needed. The first option would be to alter the source item to model that it has been redistributed and set that in a way to bypass the constraint (I am not sure how we would do that but that is still an option). The second option would be to model only the original distribution and retain the constraint; we then add this one item as an exception to the constraint. The third option is as you have proposed; to model only the original distribution and remove the constraint. From Hill To Shore (talk) 21:49, 25 December 2021 (UTC)
  • Something may stream on Netflix for a contractual period of as little as 6 months. We shouldn't be tracking that ephemeral information, unless Netflix buys the series outright. There are several services that track streaming by crawling through their catalogues and updating daily. See this service for example. --RAN (talk) 20:57, 26 December 2021 (UTC)

Space telescopes and observatories

Help me understand:

What property should be for the main space organization (NASA, ESA, CSA)? What should be the property for Flight Center, Science Institute? Kurono (talk) 09:51, 26 December 2021 (UTC)

  Notified participants of WikiProject Space may be interested in this discussion SilentSpike (talk) 12:35, 26 December 2021 (UTC)
If the agencies involved in a spacecraft mission don't actually operate the spacecraft themselves, then they should be listed under "funder", and the organizations (be it part of an agency or a separate entity) that actually operate the spacecraft should be listed under "operator". In the case of JWST, the agencies involved might operate the telescope themselves alongside STScI once in the final destination, although it would be better to wait for the telescope reaching the destination. In the case of HST, the agencies involved don't really operate the telescope themselves, the actual operators are GSFC (a NASA organization) and STScI. In the case of Hipparcos, ESA does operate the spacecraft. --Soumya-8974 (he) (talk • contribs) 13:16, 26 December 2021 (UTC)
Just as Soumya says. I've fleshed out James Webb with appropriate funders, manufacturers, and operators, and expanded Hubble a little bit as well. Thanks for bringing this to our attention, Kurono! — Huntster (t @ c) 21:09, 26 December 2021 (UTC)

removing unreferenced ethnicity rather than finding a reference

https://quickstatements.toolforge.org/#/batch/72172 is removing ethnicities if unsourced, where did we agree to do this? Wouldn't it be better to ask editors to help source the statement rather than remove them? --RAN (talk) 20:41, 20 December 2021 (UTC)

We have done this before, at least on a smaller scale, as well as with some of the other problematic properties. If you ask editors to improve the situation, they won’t do anything—unless you remove the claims in question. Also mind that if you want to add sources to such a claim, you can easily undo the removal and add the source subsequently. —MisterSynergy (talk) 21:17, 20 December 2021 (UTC)
It is expected that you ping involved users - in this case @Karl Oblique: - when you bring their work to be discussed on this page. The requirement for sources for ethnicity is well known. The corollary for unreferenced statements is their deletion. Herding cats does not work. --Tagishsimon (talk) 21:47, 20 December 2021 (UTC)
Thanks for the ping, Tagishsimon!
Copy from the edit group discussion (where I was asked to contact the users first):
The constraint isn't particular new, and it is highlighted (IN (rather rare) ALL-CAPS) in the descriptions for most languages. The has been a discussion here that received positive feedback, included a plan to carry through with a one-month timeline, which is now two months old. That discussion was also linked on the property discussion page, among many other discussions of the problem. I don't see a method to inform each individual editor. Or, in a slightly different light, removing these statements is the best method I can think of to get in touch with them. They are free to re-add the statements with sources, which, practically speaking, is done in exactly the same way as adding sources to existing statements would be. Karl Oblique (talk) 21:57, 20 December 2021 (UTC)
Let's not pretend this is excatly the same process. Unsourced statements are not ideal, but they still provide that information and make the items discoverable and more useful. With that information missing from 20K items, editors working with those kinds of items may not even be able to find these items and know they exist to add the appropriate sources. I understand your frustration in that you proceeded in good faith and with public discussions, but a number of editors who work with these items regularly are now telling you that we had no idea that this discussion even existed, and it's clear now there isn't consensus for wholesale removal. Gamaliel (talk) 18:28, 21 December 2021 (UTC)
@RAN, MisterSynergy, Karl Oblique: I agree with RAN, looking at the data it's seems mostly correct, and I don't see how a value like a "Albanians" or "African Americans" is controversial, it would be better to try find errors with smart queries instead of just removing all, Karl Oblique started even removing statements with reference. Germartin1 (talk) 08:21, 21 December 2021 (UTC)
I don’t know about Albanians and African Americans but judging from my watchlist, removing those unsourced claims overall improved data quality. Some revisionist claims like Adalbert Stifter (Q168542)ethnic group (P172)Sudeten Germans (Q663389) were removed but it’s mostly misguided conjecture and anachronistic reasoning. It’s hard to find any possible use case for those claims anyway. Emu (talk) 13:04, 21 December 2021 (UTC
I originally opened a discussion at edit groups before I noticed this one. I'll repeat what I said there: I am deeply concerned about this edit batch, which is removing ethnicity statements from the items of African-American individuals. I understand the concern for proper sourcing, but there are many unsourced statements on Wikidata and it is a work in progress. Much of the work I do on Wikidata involves discovering and improving items on underrepresented groups in the United States, and removing the ethnicity statement from twenty thousand Americans significantly impacts that work. I would respectfully ask Karl Oblique to reconsider wholesale removal of this information from the database. Gamaliel (talk) 13:34, 21 December 2021 (UTC)
Agree with @Gamaliel. I just re-added the ethnicity statements (with sourcing) to three Black individuals on my watchlist, two of whom are specifically known for working on Black issues, but I suppose a bot wouldn't know that. Funcrunch (talk) 16:00, 21 December 2021 (UTC)
That’s great but a cynic might conclude that this bot action prompted you to provide a reference that otherwise may have never been entered, so Karl Oblique’s actions are beneficial to the project after all … Emu (talk) 16:54, 21 December 2021 (UTC)
Only because I had these items on my watchlist, which I don't check very often. And immediately got a notice that it was insufficient to source theses claims to the English Wikipedia, so I have to spend more of my volunteer time adding specific sources to long-standing entries that are already well-sourced as African-American on that project. Funcrunch (talk) 16:59, 21 December 2021 (UTC)
There are already a number of items incorrectly tagged as African-American, such as Matthew Barzun (Q5566787).--GZWDer (talk) 13:44, 21 December 2021 (UTC)
Agree with @Gamaliel. At the very least a discussion and a warning would be useful.--Heathart (talk) 18:07, 21 December 2021 (UTC)

This is again problem because of property, which combines nationality and ethnicity (problematic translations). Many of removed statements were true, but probably not ethnicity. When someone was bon in Xstan and speaks Xstanish and his parents were from gemany too, he is Xstanic. But is this ethnicity? is this nationality? This is cultural identity? JAn Dudík (talk) 07:01, 22 December 2021 (UTC)

Yes, this property is a mess. That’s because the concept of ethnic groups is messy, just read the Wikipedia articles on the concept in three random languages. That’s precisely why the English description of ethnic group (P172) demands an unusual high burden of proof and that’s precisely why we shouldn’t allow statements that aren’t sourced beyond reasonable doubt. -- Emu (talk) 12:47, 22 December 2021 (UTC)
I agree with the removal of these unsourced statements. The removal will not change how many ethnic minorities are represented on Wikidata. Yes, any lists based on the statement become shorter, but this is more than offset by the fact that they become more credible. A list based on sourceless data is not good. --Dipsacus fullonum (talk) 12:01, 24 December 2021 (UTC)
If ethnic minorities are not findable or described as such in wikidata, then functionally, there are now twenty thousand fewer of them represented in Wikidata. Gamaliel (talk) 14:16, 24 December 2021 (UTC)
And so what? I see no problem with that. There have items because they are notable, not because of their ethnicity. --Dipsacus fullonum (talk) 15:06, 24 December 2021 (UTC)
As described above, many people doing a lot of work involving increasing representation of notable individuals from underrepresented groups, so nice of you to glibly dismiss that work with "and so what?" Gamaliel (talk) 15:14, 24 December 2021 (UTC)
I don't dismiss work to represent any people. Any who is notable can be represented on Wikidata. If somebody care about their ethnicity (I personally don't), they can state it with a reliable source. But I think it may be felt degrading if you absolutely have to state ethnicity for some people. It may seem that what they have accomplished or who they are, is not important in itself, but that they are included to represent a particular group of people. --Dipsacus fullonum (talk) 15:41, 24 December 2021 (UTC)

This discussion has gone on for some time and it's clear there is not consensus for the removal of this information, so I have undone the edit group. Gamaliel (talk) 19:15, 26 December 2021 (UTC)

@Gamaliel: Which specific measures will you take to ensure that those statements (that, again, require the highest burden of proof we have here on Wikidata) will have solid references in the near future? --Emu (talk) 12:31, 27 December 2021 (UTC)

Use of Google Maps as a reference

I see that the coordinates in BA-099 (Q1294662) are sourced to "Google Maps". Surely this is incompatible with Wikidata's licensing terms? -- The Anome (talk) 14:33, 22 December 2021 (UTC)

In Wikipedia this is a common practice.--GZWDer (talk) 14:44, 22 December 2021 (UTC)
@GZWDer: Using online mapping sources to check the manual picking of a representative point seems to me to be an act that is compatible with CC0, since the creative choice of the exact representative point is the point-picker's, not a map provider's, and can be independently verified across multiple map providers; copying a point to six decimal places of accuracy is surely just copying from Google's database, which risks database rights problems. Otherwise, we could simply copy wholesale from OpenStreetMap, something which is not permitted for exactly that reason. -- The Anome (talk) 14:53, 22 December 2021 (UTC)
Google Maps now provides many more digits than is appropriate for, well, anything. For example, right-clicking and selecting yields 41.89858234133879, 12.476821228042832 for the Pantheon. It appears that Wikidata's coordinate inputs are set up to best deal with Degrees, Minutes, Seconds, D°M'S", and if further precision is wanted, D°M'S.s", where additional digits are added to the arcseconds figures. Please round appropriately. Abductive (talk) 15:11, 22 December 2021 (UTC)
I agree with Abductive, but my point is that this is mostly a problem with sourcing, not excess precision (although the excess precision is revealing of direct copying). If you chase up the Google Maps link for that entity, you get the exact value that was entered into the entity, to six decimal places: -12.2701519,-37.8785375 from Google, -12.270152, -37.878538 from Wikidata. -- The Anome (talk) 15:15, 22 December 2021 (UTC)
Correct. Now, if you actually search Google for the Pantheon, it gives 41.8986108,12.4768729 in their link to Google Maps. Copying directly from that would seem to me to be a bit more problematic. Abductive (talk) 15:22, 22 December 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

And the Wikidata value for the Pantheon, imported from nlwiki, is 41.898561, 12.47685, which is clearly not taken from Google, so that's fine. -- The Anome (talk) 16:02, 22 December 2021 (UTC)

Exactly. The reason why I'm raising this is that I'm about to do a lot of transwiki integration between Wikidata and enwiki, and I'd like to ensure that data points were either crowdsourced data imported from Wikipedia (which are not creative works, and thus copyright does not apply, and for which the WMF would presumably be the only entity capable of asserting database rights, and would be happy to CC0 those away), or copied directly from CC0-license-compliant sources. Data copied directly from Google Maps is definitely not kosher, and I'd prefer not to have it here on Wikidata. -- The Anome (talk) 15:31, 22 December 2021 (UTC)

You say it's a licensing issue, but which license is violated? Especially the world surely now bothers me. Edoderoo (talk) 08:00, 24 December 2021 (UTC)
@Edoderoo: The issue here is Google's (or any other map providers') database rights. The problem isn't that a license is potentially being violated, but that there is no license to use this information. This is not good, because it makes a nonsense of Wikidata's CC0 licensing; you can't disclaim rights you don't have the right to disclaim. -- The Anome (talk) 02:28, 27 December 2021 (UTC)
It works the other way around. One can't claim rights for something that isn't copyrightable. Since individual information by itself is not copyrightable, you are free to copy it.
A database (or any "substantial" part of it) as a compilation of information at the same time may enjoy some form of copyrightability depending on the circumstances, so wholesale or systematic imports may not be allowed by a copyright license. —MisterSynergy (talk) 07:08, 27 December 2021 (UTC)
I already was afraid that a problem that does not exist needed to be solved. I know the Wikimedia Foundation has a good legal department that you can contact at legal wikimedia.org that can help you with solving this issue. That might make more sense then trying to convince others here that we really need to take action. Edoderoo (talk) 07:54, 27 December 2021 (UTC)
Please don't patronise me. I'm very aware that location data is not copyrightable, as you can see from my earlier comment. It's the casual acceptance of verbatim copying from databases that is concerning. -- The Anome (talk) 10:28, 27 December 2021 (UTC)

Wikidata weekly summary #500

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • Open request for adminship: Ameisenigel (RfP scheduled to end after 27 December 2021 15:57 UTC)
  • Tool of the week
    • Articles created by country of citizenship : a javascript notebook which looks at the distribution of articles created by a user by country of citizenship (P27). It uses Wikidata's API through wikibase-sdk library.
  • Development
    • Due to the winter holidays, the development team is taking a break and no deployment is happening for Wikidata at the moment.

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.

Mass-replacing descriptions

Hi, is there a tool, preferably in JS, that helps mass editing item descriptions from A to B? NguoiDungKhongDinhDanh 20:52, 30 December 2021 (UTC)

QuickStatements can overwrite descriptions, but you'd need to select the items first. --- Jura 11:27, 31 December 2021 (UTC)
Thanks! NguoiDungKhongDinhDanh 10:37, 2 January 2022 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 12:14, 2 January 2022 (UTC)

Is it undesirable to state country (P17) and located in the administrative territorial entity (P131) under place of birth (P19) and place of death (P20)?

With this processing, the information was removed en masse.

The national borders change over the centuries, especially in Europe, Latin America, etc. Local boundaries, city limits, administrative districts, etc. also shift every few years. Such information is not always in the data set. place of birth (P19) and place of death (P20) has therefore under property constraint → allowed qualifiers constraint → country (P17) and located in the administrative territorial entity (P131). In addition, Commons, for example, evaluates this in the info boxes. Especially in info boxes of athletes, the information country (P17) and located in the administrative territorial entity (P131) from Wikidata is often used, especially in smaller Wikipedias. We are no exception because of New York, as some write New York (e.g. FrenchWP) and some New York City. In the info box, the difference becomes clear by adding country (P17) or located in the administrative territorial entity (P131). In addition, people do not have fast internet everywhere in the world. E.g. the New York City (Q60) site is huge and takes a long time to build. And then the information is hidden somewhere or not available at all. New York (Q1384) and New York City (Q60) did not always belong to the United States, see History of New York. The history of European cities and states is even more changeable. Therefore, it is not always clear when who was born in which state. This information requires a lot of research. The indication of country of citizenship (P27) is not helpful in this case because some people were born or died there, but did not have the nationality. In the German-language Wikipedia, this information is explicitly requested in personal articles even in the personal data, see Hilfe:Personendaten#Verwendung. I would therefore like to ask you to undo the processing by the bot. --HarryNº2 (talk) 17:58, 23 December 2021 (UTC)

ping the operator of the bot @Putnik:. looks to me that bot task wasn't approved. The edit text said "Remove administrative entity qualifiers that can be obtained from the target item" but I wonder if it actually checked this before deleting for many of the items this isn't true (e.g. [10]). BrokenSegue (talk) 18:21, 23 December 2021 (UTC)
Wikidata has enough data to display the correct administrative units for any desired date without any additional qualifiers. The problem stated by the topic author does not relate at all to the quality of the data, but to not good enough tools for displaying them. You can open Russian version or Abdülmecid I (Q174772), and it shows correct city name and country using Wikidata. You can look at the bot's code, it removed only those qualifiers, without which it is possible to build the same chain of administrative units. There is a fairly clear consensus that qualifiers are not needed in such cases, and the question of removing them has been raised several times, e. g. here two years ago. So this is a long process of data cleansing, and the bot edits this spring were only a small part of it. —putnik 18:56, 23 December 2021 (UTC)
I think we once had a bot that added such qualifiers and eventually it got blocked, possibly for the same reason. --- Jura 18:35, 23 December 2021 (UTC)
A bot can hardly do the job. Adding this requires a lot of research, as it is not always clear when which city belonged to which territory over the centuries. If, for example, a hospital or a street is entered as the place of birth, it is even more difficult. But especially in this case, the specification of country (P17) and located in the administrative territorial entity (P131) is necessary to inform the reader and to feed the info box in the Wikimedia projects. --HarryNº2 (talk) 18:55, 23 December 2021 (UTC)
I don't think the bot had added incorrect data.
BTW, the infobox at fr:Pieter_Stuyvesant seems to figure it out without qualifiers at Q161536#P20. --- Jura 19:01, 23 December 2021 (UTC)
No wonder, it also takes a lot of work to research things like that, when at the time of his birth and death New York City belonged to which located in the administrative territorial entity (P131) and country (P17). --HarryNº2 (talk) 19:10, 23 December 2021 (UTC)
Maybe Query Service should have function that does it. --- Jura 19:16, 23 December 2021 (UTC)
Perhaps this may still be the case for New York, but unfortunately this does not work in many smaller cities and towns due to a lack of data. --HarryNº2 (talk) 19:27, 23 December 2021 (UTC)
@Jura1: Of course, I would be delighted if you could create such a query. I like to try them out. --HarryNº2 (talk) 19:37, 23 December 2021 (UTC)
Function, not query, like SERVICE wikibase:label { } --- Jura 19:40, 23 December 2021 (UTC)
Do not understand what you mean. But I can already tell you that this cannot work, especially with a view to Europe and its content in data sets on cities and municipalities, especially if they are or were near a border. --HarryNº2 (talk) 20:04, 23 December 2021 (UTC)
It seems to me to be nonsense to append qualifiers of P17 and P131 to place of birth or death. The values should already be found in the item to which the property statement points; and where there have been sovereignty and administative changes over long periods of time, the values in the linked item should be qualified by start and end dates. To my view, appending qualifiers of P17 and P131 to place of birth or death is an indicator that the user does not understand, at a fairly fundamental level, what wikidata is :( --Tagishsimon (talk) 19:12, 23 December 2021 (UTC)
In order to always extract the state and administrative unit from the data records, this would also have to be specified in all place articles, which is seldom the case. --HarryNº2 (talk) 19:20, 23 December 2021 (UTC)
In place of birth (P19) and place of death (P20) it says: "most specific known (e.g. city instead of country, or hospital instead of city) birth location of a person, animal or fictional character." This also includes, for example, when someone was born at Xyz Street no. 31 in Berlin on February 28, 1947, to which district the street belonged, to which city (East or West Berlin), and to which country (American, British, French or Soviet sector) or still to the German Reich or already to Western Germany or to the GDR? It's not that simple at all. If you remove this information in some records, other users start doing the same, regardless of the actual circumstances. --HarryNº2 (talk) 20:26, 23 December 2021 (UTC)
1) You are offering an edge case as an example. In such cases, qualifiers can of course be used, but their percentage is extremely small. But in general, qualifiers introduce a lot more errors. Even if you look at those elements where qualifiers are specified now, for most of them, removing qualifiers will improve the correctness of the administrative unit chain.
2) If the place item does not have the correct located in the administrative territorial entity (P131) or country (P17) for the required period, then adding them does not take much longer than specifying qualifiers for the place of birth/death property. But this data can then be reused for other items about people, in contrast to qualifiers, which are useless outside the person item. —putnik 21:00, 23 December 2021 (UTC)
So unfortunately it doesn't work. E.g. in the data set on Germany, the users of the different Wikipedas argue about when Germany was German Reich, or NS-Germany, Kaiserreich, Weimar Republic, etc. Therefore, it is much easier to make the information about the person concerned directly in the data set. The same applies to Austria-Hungary, for example, when which part of the country was administered by which government. It takes a lot more work to argue for months with the users of the individual Wikipedia than to enter the exact data for a German or Austrian person. --HarryNº2 (talk) 21:17, 23 December 2021 (UTC)
I agree that sometimes it doesn't work, but I don't really see how one would know when editing the place of birth on a person item, but not when editing the item about the location.
Still like my suggestion above. --- Jura 09:45, 28 December 2021 (UTC)
I agree with Tagishsimon here. These qualifiers are seldom useful. If you want to specify Soviet sector of Berlin, use East Berlin (Q56037) directly. New items can ouf course be created for sectors of West Berlin. Vojtěch Dostál (talk) 16:03, 24 December 2021 (UTC)
They are sometimes useful. Do you want to create a new item for each cities in Province of Massachusetts Bay (Q2079909), such as one for "Boston in Province of Massachusetts Bay"? (Boston (Q100) have country (P17)=Province of Massachusetts Bay (Q2079909), but 1. Province of Massachusetts Bay (Q2079909) is not a country and 2. Boston was in Massachusetts Bay Colony (Q1191350) too)--GZWDer (talk) 16:13, 24 December 2021 (UTC)

Use of located in the administrative territorial entity (P131) versus partially coincident with (P1382) for multi-parent administrative territorial entity (Q56061)

In the United States, there are hundreds of municipalities that fall within multiple counties -- see list of U.S. cities in multiple counties (Q6600884). Looking back, it appears this scenario was discussed in relation to Atlanta (Q23556) in February 2020. Around that time, Atlanta (Q23556) was updated to add applies to part (P518) qualifiers to pre-existing located in the administrative territorial entity (P131) claims, so I assume that was what was recognized as the consensus at that time.

At some point earlier this year, the description for located in the administrative territorial entity (P131) was updated, with it now stating to "Use P1382 if the item falls only partially into the administrative entity." Since I couldn't find any discussion concerning this change, I wanted to see if the current description reflects the actual consensus, or if this sentence should be removed (and possibly replaced with something like "add P518 as a qualifier if the item falls only partially into the administrative entity.")

This is possibly a separate discussion, but I thought I'd bring it up simultaneously to see how it should be handled. In some jurisdictions, like Ohio (Q1397), it is possible for a single municipality to have parts where the closest parent administrative territorial entity (Q56061) is at one level (like a township, or even a paper township (Q7132722)), and parts where it is at another level (such as county), even though the whole municipality would also fall within one or more of the same counties. Given the discussion above about using multiple levels (Is it undesirable to state country (P17) and located in the administrative territorial entity (P131) under place of birth (P19) and place of death (P20)?), would this cause issues, or would it be better just to keep everything at one level (like county) in these cases? --GeoMac (talk) 00:16, 27 December 2021 (UTC), edited 19:51, 27 December 2021 (UTC)

I will remind about the property proposal Wikidata:Property proposal/hierarchy switch from the beginning of 2020 intended as a qualifier to located in the administrative territorial entity (P131) to state what the next higher administrative level is when more than one is possible. --Dipsacus fullonum (talk) 09:12, 28 December 2021 (UTC)

Upcoming Call for Feedback about the Board of Trustees elections

You can find this message translated into additional languages on Meta-wiki.
More languages • Please help translate to your language

The Board of Trustees is preparing a call for feedback about the upcoming Board Elections, from January 7 - February 10, 2022.

While details will be finalized the week before the call, we have confirmed at least two questions that will be asked during this call for feedback:

  • What is the best way to ensure fair representation of emerging communities among the Board?
  • What involvement should candidates have during the election?

While additional questions may be added, the Movement Strategy and Governance team wants to provide time for community members and affiliates to consider and prepare ideas on the confirmed questions before the call opens. We apologize for not having a complete list of questions at this time. The list of questions should only grow by one or two questions. The intention is to not overwhelm the community with requests, but provide notice and welcome feedback on these important questions.

Do you want to help organize local conversation during this Call?

Contact the Movement Strategy and Governance team on Meta, on Telegram, or via email at msg wikimedia.org.

Reach out if you have any questions or concerns. The Movement Strategy and Governance team will be minimally staffed until January 3. Please excuse any delayed response during this time. We also recognize some community members and affiliates are offline during the December holidays. We apologize if our message has reached you while you are on holiday.

Best,

Movement Strategy and Governance --YKo (WMF) (talk) 05:28, 28 December 2021 (UTC)

Proposed bot for fixing statement ranking when updated information is added

You are invited to join the discussion at Wikidata:Bot requests#Request to have a bot fix statement ranking when updated information is added (2021-12-28). Cheers, {{u|Sdkb}} talk 05:30, 28 December 2021 (UTC)

English labels as labels for (all) other languages for scholarly articles

Given the ongoing issues with WQS, I suggest we restrict the addition of English labels as labels for other languages for any item with instance of (P31) = scholarly article (Q13442814), i.e. the English label shouldn't be copied over.

This avoids that we would get >30 million labels in 200 to 300 additional languages --- Jura 21:06, 22 December 2021 (UTC)

I concur, but isn't that a bit of a stopgap measure though? As the server techs pointed out, storage isn't really the issue, only the size of the graph, and they've already proposed deleting the scholarly article section out of the graph. I wonder how much that part is queried though, compared to direct retrievals and elasticsearch, chances are you won't miss it, although if queries are dropped, it will have to be replaced with a service that offers hashed lookups of DOI, PMID etc. identifiers to QIDs, since indexed search is too inexact. --Infrastruktur (talk) 11:18, 23 December 2021 (UTC) 
The deletion will only take place if WQS is about to fail. In the meantime, we can be more or less disciplined about the available capacity.
I don't quite see the difference you make between storage and size. Another 6 or 9 billion triples would be in both.
I doubt there are any uses for these labels. Not sure about the inner workings of WQS, but if you want the English label, I think one ends up check every other label for the same language, at least if it isn't the first one found. --- Jura 16:30, 23 December 2021 (UTC)
Apologies. What I meant is that, if it is possible to remove data trees from the graph, what's stopping anyone from doing the same for labels? It will have the same result, namely limiting the size of the graph. Permanent storage is cheap and plentiful, so it doesn't really matter how much one stores into Wikidata, but I'm guessing the graph depends on the amount of main memory on one or more server, which will be limited. --Infrastruktur (talk) 17:08, 23 December 2021 (UTC)
One could also leave out references. I am guessing that will save a metric sh*t-ton of space. Any user interested in references would then simply have to retrieve the data for the entity they are interested in manually. Infrastruktur (talk) 17:43, 23 December 2021 (UTC)
I think this should not happen unless we have mul labels.--GZWDer (talk) 16:47, 23 December 2021 (UTC)
Any reason in particular to burden WQS with 6 or 9 billion additional triples? --- Jura 16:59, 23 December 2021 (UTC)
I agree that having "mul" labels is the best solution, and I hope that they will come soon; in the meanwhile, this proposal seems perfectly reasonable to me. --Epìdosis 17:08, 23 December 2021 (UTC)
Doesn't native label (P1705) serve the need for any foreign articles? Infrastruktur (talk) 17:20, 23 December 2021 (UTC)
Just pointing out not all scholarly article titles (generally in here as labels) are in English, and some come with both an English and another language version of the title, so removing non-English labels would mean losing some information in those cases. But I agree there's little point duplicating an English title to other language labels. What about descriptions though? ArthurPSmith (talk) 17:53, 23 December 2021 (UTC)
Descriptions: different predicate -> different topic ;)
BTW, non-English labels/titles wouldn't be effected. However, it is already an error we sometimes see that the English translation (of a title in French by pubmed, e.g.) is copied over to the French label (replace "French" with any other language). BTW, title (P1476) should provide what's needed to cite the article. --- Jura 18:11, 23 December 2021 (UTC)
Dumb automatically translated descriptions should be nuked as soon as conveniently possible, as there are other ways of preserving the original title for foreign articles. Infrastruktur (talk) 18:33, 23 December 2021 (UTC)

Displaced urban squares

 
the old square

A lot of urban squares are renamed in their history. However in the case of Q109660546 the name was reused for a square in an other location. It could be that the old square no longer existed after te war. I think it is more logical to use to separate items: one for the old square and one for the new one. It could be integrated in one item, with two locations qualified with a year date, but it is complicated. I already get a warning sign in the SD of the picture. There is a specific Commons category for the old square: Commons:Category:Historical images of place Carnot (Rouen)Smiley.toerist (talk) 11:51, 24 December 2021 (UTC)

PS: the location of the old square is 49 hour, 26 min, 09.58 sec North: 1 hour, 5 min, 25.46 sec East. Is there no handy conversion tool? My Google is on classical settings.Smiley.toerist (talk) 11:56, 24 December 2021 (UTC)
Google maps usually provide both sets of coordinates, but if it does not work for you you can you for example this one.--Ymblanter (talk) 20:34, 24 December 2021 (UTC)
It does not as work as it converts to digital hours, while I need only in arc seconds with hours and minutes specified. I now succeded by trying different values and seeing the results on the map. Squares dont have to be superprecise anyway. I used the crosssection of two roads. Two values are now present with qualifiers.Smiley.toerist (talk) 11:58, 25 December 2021 (UTC)

Property for the location of origin of a food

I want to store the following information in Wikidata, but I don't know what property to use. The quote was retrieved from this article. It is about turrón de Alicante (Q3995784).

Turrón is born in Spain, in the province of Alicante, in the 15th century.

I know "Turrón is born in Spain" can be stored with turrón de Alicante (Q3995784)country of origin (P495)Spain (Q29). My question is: What property should I use for stating that turrón de Alicante (Q3995784) was originated in Alicante (Q11959)?

Rdrg109 (talk) 13:53, 27 December 2021 (UTC) (please ping on reply)

indigenous to (P2341) should work for both. --- Jura 10:42, 28 December 2021 (UTC)

Documentation of the WikidataCon 2021

Hello all,

If you are interested in learning more about how we organized the WikidataCon 2021, the formats, tools and methods we used for the online conference, and the lessons we learned from this experience, the event organizers published a documentation page available on Meta.

We also published the results of the participants survey, where you can discover some interesting statistics about the conference participants, and the highlights of feedback sent by the respondents.

Finally, we are in the process of uploading the video recordings of Day 2 & 3 sessions on Youtube ; you can find the links on this list, and also sorted by tracks in these playlists. We will provide English subtitles on a selection of videos, that will be published later in January. If you're interested in helping us in this documentation effort, for example by transferring the videos on Commons or providing subtitles and translations, feel free to coordinate on the talk page.

Thanks a lot to everyone involved in preparing these documents! If you have any additional questions, feel free to write directly on this talk page or to info wikidatacon.org. Lea Lacroix (WMDE) (talk) 14:09, 28 December 2021 (UTC)

Specify segment of a Youtube video as a reference

I'm adding some information to the Wikidata item of a film that has been published in Youtube by one of the cast members. At the beginning of the video, scrolling text with details of the movie is presented. I want to use one of the sentences presented there as a reference to an statement.

Specifically, the sentence (in spanish) I want to use is presented from 00:00:11 to 00:00:29

Fue rodada totalmente en escenarios naturales, en Cuzco y Lima, Perú ...

its translation in English is

It was entirely recorded in natural landscapes of Cuzco and Lima, Peru.

I would store that information as it follows, but I don't know how to specify the segment in the Youtube video where the sentence is presented. Any ideas?

filming location
  Lima edit
1 reference
reference URL https://www.youtube.com/watch?v=Mn8WH3eidd8
retrieved 28 December 2021
which property? <<state that it is from 00:00:11 to 00:00:29>>
add reference
  Cuzco edit
1 reference
reference URL https://www.youtube.com/watch?v=Mn8WH3eidd8
retrieved 28 December 2021
which property? <<state that it is from 00:00:11 to 00:00:29>>
add reference


add value


Rdrg109 (talk) 15:15, 28 December 2021 (UTC)

If these are stated in the film itself then references are not needed since it is self-evident. See Help:Sources#When_to_source_a_statement SilentSpike (talk) 15:36, 28 December 2021 (UTC)
  • In contrast to information about the creator of a work you can not expect this kind of information (filming location) to be indicated in the front matter or credit section of a work. It is not self-evident that this kind of information is taken directly from the film and not from an internet discussion or an article about the film. Missing sources do not imply that the information comes from the work itself but only that the contributor did not give sources. So giving the film as a source is still useful to make it explicit that this is the source - it makes it definitely easier to verify the claim or judge its reliability. - Valentina.Anitnelav (talk) 18:21, 28 December 2021 (UTC)
For YouTube videos, you can insert a time stamp into the url (the "share" button on YouTube's desktop website should give you a menue when you can insert a time stamp. The functionality to generate time-stamped URLs is not currently available in their smart phone apps). Using that url as your reference will take people to the exact moment you wish them to see. From Hill To Shore (talk) 17:58, 28 December 2021 (UTC)

list of Wikidata reasons for deprecation (Q52105174) and deprecated homepages

I'm trying to find an appropriate value for reason for deprecated rank (P2241) as a qualifier of official website (P856) on J. D. Crowe (Q1332971), but none of the values listed on list of Wikidata reasons for deprecation (Q52105174) to be appropriate. redirection error (Q104653273) and expired domain (Q1384499) seem close but not quite right. Is there a guideline on this? AleatoryPonderings (talk) 21:05, 28 December 2021 (UTC)

Did you read the English description of the property?
  • official website (P856): URL of the official page of an item (current or former). Usage: If a listed URL no longer points to the official website, do not remove it, but see the "Hijacked or dead websites" section of the Talk page
Adding an "end date" qualifier and keeping normal rank is consistent with Help:Ranking --- Jura 21:22, 28 December 2021 (UTC)
There is no new entry; this website seems to have just expired. I wasn't trying to remove the old website, just give it a deprecated rank with the appropriate description. AleatoryPonderings (talk) 21:28, 28 December 2021 (UTC)
If so, you could add a "no value" statement in preferred rank. --- Jura 21:30, 28 December 2021 (UTC)
But they key point is, AleatoryPonderings, that the URL of the expired website should NOT be given a deprecated rank. Deprecated is for values which are not and never were true. Where a value was true, but is no longer true, it should have normal rank, and a preferred rank statement should describe the current sitation; including, as Jura suggests, <no value> if there is no current website. Meanwhile in the situation that you do have something to deprecate (or prefer) and there is not a good reason value, then make a new reason value. In the event it transpires that the reason value already existed in different words, it can be merged later. --Tagishsimon (talk) 21:49, 28 December 2021 (UTC)
Just to point out (I see this kind of thing often), but redirection error (Q104653273) and expired domain (Q1384499) do not look like valid reasons for deprecation to me. Can anyone give me a use case for this that does not violate valid use of deprecation rank? Furthermore, the latter has a wiki link to a page which presumably isn't describing a Wikidata reason for deprecation. SilentSpike (talk) 22:12, 28 December 2021 (UTC)
I am not going to defend those items but I think we are storing up a significant problem for the future by retaining redundant URLs as live links. Anyone could come along and register an expired domain, meaning that links that are dead today can point to an infected malware site tomorrow. Ideally we should have a method to retain the URL as plain text rather than a link when the website has moved or closed down. From Hill To Shore (talk) 22:33, 28 December 2021 (UTC)
most listed reasons for deprecation are wrong and the item shouldn't be deprecated in my experience. BrokenSegue (talk) 02:50, 29 December 2021 (UTC)

Community Wishlist Survey 2022 is coming. Help us!

The Community Wishlist Survey 2022 starts in less than two weeks (Monday 10 January 2022, 18:00 UTC). We, the team organizing the Survey, need your help.

Translate important messages Promote the Survey

Among anyone and everyone you know who has an account on wiki.

Promote the Survey on social media, via instant messaging apps, in other groups and chats, in your WikiProject, Wikimedia affiliate - wherever contributors with registered accounts may be.

Only you can make the difference

How many people will hear and read about the Survey in their language? How many will decide to participate? Will there be enough of you to vote for a change you would like to see? It all depends on you, volunteers.

Why are we asking?

  • We have improved the documentation. It's friendlier and easier to use. This will mean little if it's only in English.
  • Thousands of volunteers haven't participated in the Survey yet. We'd like to improve that, too. Three years ago, 1387 people participated. Last year, there were 1773 of them. We hope that in the upcoming edition, there will be even more. You are better than us in contacting Wikimedians outside of wikis. We have prepared some images to share. More to come.

What is the Community Wishlist Survey?

 

It's an annual survey that allows contributors to the Wikimedia projects to propose and vote for tools and platform improvements. Long years of experience in editing or technical skills are not required.

Thanks, and be safe and successful in 2022! SGrabarczuk (WMF) (talk) 03:15, 29 December 2021 (UTC)

Should the description of a person include year of birth and death, if applicable?

Q42: English writer and humorist or English writer and humorist (1952-2001)? Is there a binding convention on this? Thanks, --Polarlys (talk) 13:27, 25 December 2021 (UTC)

Not really, see Help:Description. As a general rule, descriptions should only include basic information and leave the rest to statements. But:
  1. There are cases where adding this kind of information is indeed helpful or even necessary such as persons with the same label, same citizenship and same occupation.
  2. Some people feel otherwise and do like to include life dates (some simply because they like descriptions with life dates better, others because it helps with their preferred mode of entering data into Wikidata such as QuickStatements). As a general rule, it’s not a very good idea to start edit wars about those kind of questions.
I personally think that life dates generally cause all sorts of problems and try to limit them to edge cases (#1). This is especially true for my field of expertise where people have all sorts of questionable birthdays (and sometimes dates of death). -- Emu (talk) 13:49, 25 December 2021 (UTC)
As someone who has added sitelinks to tens of thousands of wikipedia biography articles, necessitating matching WP information with WD labels and descriptions, I cannot overstate how useful is having DoB & DoD in the description. It's by now fairly rare to find a name on WP for which there are not several, sometimes many tens, of name string matches on WD. Descriptions are meant to disambiguate one item from another; for people, DoB and Dod are *very* good ways of doing this; amongst the best ways.
Ambuiguity and uncertainty about DoB and Dod can be handled in the description, using c., or exceptionally by omitting thoroughly uncertain dates.
DoB & DoD are also, to my mind, part of a very conventional way of describing a person within a huge collection such as WD - English writer and humorist (1952-2001) - and although the description field is not designed to describe the person, the field's values are used by all sorts of applications when presenting wikidata as a description; and I cannot see why we would not wish to format person descriptions in a consistent fashion including, where available and reliable, country of citizenship (broadly construed), occupation or key notable attribute, dates (DoB, DoD, floruit). --Tagishsimon (talk) 22:56, 25 December 2021 (UTC)
But isn’t that a display issue that should be addressed by software instead of duplicating information in free text fields? Auto descriptions of Mix’n’Match work pretty well for matching. -- Emu (talk) 12:29, 26 December 2021 (UTC)
  • Sometimes I am confused by the dates in parenthesis, at first glance, when they come after the description: "Bob Smith, Mayor of City (1952-2000)" because it looks like his term as mayor. If it was to appear in an encyclopedia it would appear as ""Bob Smith (1952-2000), Mayor of City". Also some people are disambiguated by their spouse, so we have "Bob Smith, husband of Jane Doe (1952-2000)" where it looks like it is her birth and death dates. At some time in the future these will have to be dealt with. --RAN (talk) 21:04, 26 December 2021 (UTC)
Polarlys already explained one of the reasons why. From the referenced page: "the concept represented by the item is defined by the statements, not the description." Regardless, third-party developers can fetch whatever Wikidata has to present the data that's relevant to their purpose. There are more reasons not to add all those other things, but that would be getting off-topic. To Richard's point, I've noticed the same problem: Some of these blind additions create, rather than reduce, ambiguity. —Ringbang (talk) 19:38, 30 December 2021 (UTC)
@Polarlys: I am also fundamentally in the opinion of Emu that one does not necessarily need the life data in the descriptions, because they are mentioned in the further course of the database object in the statements and are also documented there. Nevertheless, there are of course cases in which the specification of the life data is useful and perhaps also necessary. It is the case with the descriptions of the database objects that they must be unique in interaction with the label of the data object. As an example for such a case, I would mention the two data objects Vanessa Fischer (Q21031618) and Vanessa Fischer (Q24008287). In order for the German descriptions to be unique in interaction with the labels of the data objects, the year of birth must be specified, as can be seen from the two descriptions “deutsche Fußballspielerin, geboren 1998” and “deutsche Fußballspielerin, geboren 1997”. In the example you mentioned Douglas Adams (Q42) I do not see this as necessary, which is why I am clearly against adding the life data in the description. --Gymnicus (talk) 08:30, 26 December 2021 (UTC)
It absolutely should be included per Tagishsimon. Dates of birth and death have been a standard method of disambiguation for centuries and we should continue that usage here. Gamaliel (talk) 19:17, 26 December 2021 (UTC)

Thank you for your input on the subject. In the majority of examples I've come across, the life dates seem to have been added not to distinguish between people with the same names and the same activities or similar, but because of the preference of the contributor. There are accounts that do nothing but add life data to the description. Here a binding statement would be helpful, when such additions are meaningful and when redundant (and thus not desired). --Polarlys (talk) 20:12, 26 December 2021 (UTC)

Partially due to the importation of large genealogical databases, we have a lot of entries where little is known of the subject beyond their birth and death dates (and even then there are many cases where even those details are not known). Rather than leave a blank entry in the label, it is preferred to include the birth and death dates (or evern floruit dates). This helps editors to match new information to existing entries or even identify duplicated items for merging. As more statements are added to an item, I'd expect the quality of the label to improve. Normally we would include an occupation or position of an individual, if they are known. From Hill To Shore (talk) 21:06, 26 December 2021 (UTC)
  • In general yes, at least for deceased people. It's not really efficient to wait for an item for the second person with the same name to be created and continuously update descriptions. In most fields, lifespan is used to identify people --- Jura 09:42, 28 December 2021 (UTC)

  Info Although I don’t believe that there is consensus, Quesotiotyo has started to mass-change descriptions, see batch 72710. --Emu (talk) 10:36, 30 December 2021 (UTC)

For clarity's sake: I had begun enhancing descriptions before this discussion arose, not as a result of it. --Quesotiotyo (talk) 15:05, 30 December 2021 (UTC)
  • It seems to vary from one language to the another. Thanks to a bot, Dutch always had them (and this helps with search), but German seems to exclude years in general (for whatever reason, see Help:Description/de#Personen). For Italian, there was recently a discussion (see Wikidata:Bar/Archive/2021/11#Descrizioni_in_italiano_per_elementi_di_persone). In English, they are quite frequent and Help:Description#Guidelines_for_descriptions_in_English doesn't disallow them. --- Jura 12:31, 30 December 2021 (UTC)
  • Personally I always add birth and death years, whenever known. In Italian I effectively started the discussion mentioned by Jura, which found consensus for this practice. I think having the dates in descriptions, besides being very important in the case of homonyms, can be useful also in general in order to give the reader an immediate impression of the epoch of the person described; having dates in descriptions is also a standard practice in authority files. Anyway, some larger discussion about this practice, in order to advice or discourage it in given situations, is probably useful in order to standardise a bit more the present situation, which is mostly characterised as said before by the preferences of single users; of course this topic could also be treated as a "display issue that should be addressed by software", and in fact I think it will be need to be discussed again when we will have multilingual descriptions based on statements, hopefully soon: will they display birth/death years or not? --Epìdosis 13:10, 30 December 2021 (UTC)

  Oppose. I oppose this mass-edit for several reasons, some of which User:Emu mentioned above and on Quesotiotyo's talk page:

  1. It assumes that dates are accurate and valid on the basis of unreliable criteria.
  2. It hardcodes dates in a particular calendar system and in a specific format.
  3. In some contexts, the added dates create ambiguity where there was none (as in RAN's examples above).
  4. Systematically hardcoding dates in the description field may give the impression that they have been verified.
  5. Unnecessary duplication of data creates maintenance problems.
  6. This mass-edit seems to go against the spirit of Help:Description. Data belongs in statements; the purpose of the description field is disambiguation. In many cases, these dates aren't needed for disambiguation.

@Quesotiotyo: I appreciate that you tried to establish selection criteria to make the edits safer, but the criteria are far from foolproof. I also wouldn't want an editor to hesitate adding a contradictory date as a statement because they assumed that your date in the description is correct. In any case, I think editors should add disambiguation dates only when necessary, and never blindly. —Ringbang (talk) 19:38, 30 December 2021 (UTC)

Responding to your points (though this should cover most of the ones brought up by others as well):
  1. There is no assumption that any date is accurate or valid; it is simply a reflection of data that is already present on the item.
  2. The same calendar system is used as with the DOB/DOD properties -- why would it not? As for the format, using only the years should provide enough information for disambiguation purposes for virtually any item; month or day precision could be added for any edge cases (this also avoids any confusion over MM-DD-YYYY vs. DD-MM-YYYY).
  3. There should be no ambiguity so long as "(XXXX-XXXX)" appearing at the end of the description is standardized to represent that item's lifespan; I will seek out and correct any items for which this is not true.
  4. There is no intent to represent or hardcode anything as verified any more than the rest of the description or the date properties already do (which is to say, not at all -- Wikidata does not serve that purpose).
  5. This is not duplication of data; a person's lifespan is not contained within a single property, is not easily searchable, and does not appear in the search box, search results, nor in tools such as OpenRefine and PetScan that automatically display descriptions. There should not be any maintenance necessary for most items; it would be simple to detect and correct any instance where the description and DOB/DOD statements no longer agree in the rare occasion when that happens.
  6. As has been stated by several other users above, birth and death dates are incredibly useful for disambiguation purposes. No, not every single name is shared by multiple people, but that is the case far more often than not, and since one cannot prove that it isn't, 'tis better to assume that it is.
Also, I fail to see how an editor would assume that a date in the description is any more correct that the existing DOB/DOD statement itself. I have full confidence in Wikidata contributors to understand what is being represented and not be so easily stymied.
To your last sentence, a good majority of all descriptions on Wikidata items were automatically generated. Before running any such batch, I always filter the data in several ways to remove any anomalies in order to decrease the chances of making a mistake. I make no promises that every single edit I perform is completely correct, but I do know that any errors that sneak in are far outweighed by the positive additions that mass-editing tools allow to me contribute in surplus of what I would be able to do by hand alone. I also do a lot of work rooting out such errors made by others (and sometimes even myself) and fixing them to help offset any that I have made.
Please do let me know here or at my talk page if you have any other questions or concerns.
--Quesotiotyo (talk) 21:23, 30 December 2021 (UTC)
  • I can see a new, good faith editor might edit a description to fix a birth year when they notice an error in it, but not edit the corresponding statement because they don't know how to do that, probably not even noticing the existence of the statement down the screen. Would the bot propagate the fix to the statement, or revert the fix (because they "should" edit the statement), or report it as inconsistency and let other users review? whym (talk) 08:24, 31 December 2021 (UTC)

To come back to my initial question, the topic seems to be decided now: Q42 (Douglas Adams, English writer and humorist can now be distinguished). It is surprising that, on the one hand, no convention is established on such issues for years and, on the other hand, a single user creates facts during the ongoing discussion within days. --Polarlys (talk) 01:10, 1 January 2022 (UTC)

Now he can more easily be differentiated from any other English writer and humorist named "Douglas Adams". --Quesotiotyo (talk) 02:14, 1 January 2022 (UTC)

  Oppose. I don't oppose the use in particular cases (where there's need to disambiguate or it's hard to make a better description) but mass edits of this form seem like a waste. If a mass edit of thousands and thousands of edits were proposed I would want to see it go through the bot approval process because it's easy to do wrong. BrokenSegue (talk) 02:44, 1 January 2022 (UTC)

  Info The batches keep on going, a request on Wikidata:Administrators'_noticeboard#User:Quesotiotyo hasn’t been picked up by another admin yet (I can’t do it lest I should be accused of conflict of interest). I’m starting to think that our process of conflict-solving is broken in this case. We as a community are effectively sending out the messeage that you can do whatever you like, unless it’s blatant vandalism, nobody will stop you. --Emu (talk) 10:30, 1 January 2022 (UTC)

I'm generally supportive of the changes, I think it will help some matching and disambiguation processes. --99of9 (talk) 14:50, 1 January 2022 (UTC)

  • I am generally supportive as well. For what it's worth, I would almost always tend to include the dates when writing descriptions; it's a widespread convention, and while it may not be strictly necessary in all cases, it's often simpler to just include them rather than fiddle around to determine whether they need to be or not. I think the use of "multiple" occupations is potentially more of an over-description issue than the dates (eg "English writer and humorist" - why not just "English writer"?).
Going back to the original question, I would strongly oppose any binding convention that says "always have dates" or "never have dates", or "only have dates if we have two items with the same label", or whatever it might be. A hard rule here is just going to cause trouble in future. Andrew Gray (talk) 18:31, 3 January 2022 (UTC)
  • I think the simplest solution is the switch from "American watercolorist (1866-1944)" to "(1866-1944) American watercolorist" so the the top of Wikidata reads: " Helen Nicolay (1866-1944) American watercolorist". It would match the standard for encyclopedias and Wikipedia. This would eliminates the confusion with dates of service such as "John Smith; Mayor of Smithtown (1866-1944)", it would now read "John Smith (1866-1944) Mayor of Smithtown". "John Smith; husband of Jane Doe (1866-1944)" would now read "John Smith (1866-1944) husband of Jane Doe". The switch is very simple. --RAN (talk) 22:20, 8 January 2022 (UTC)

Editing requests from a blocked user

Because I am still locked, I cannot edit data objects. Nevertheless, I keep seeing errors or missing data, which I actually want to report or add. So that these edits are done anyway, I open this area here so that I can ask that these edits be carried out by another user who is not blocked. --Gymnicus (talk) 18:57, 11 December 2021 (UTC)

Wouldn't we be helping you block evade? I don't really see the logic of the block if you just end up filling project chat with edit requests. --- Jura 19:20, 11 December 2021 (UTC)
@Jura1: You shouldn't ask me that question. Nikki has only blocked me from editing data objects, properties and lexemes so that I cannot delete references. But it also goes hand in hand with the fact that I can no longer improve the data objects. Since Bovlb also refused my request for unlocking despite a clear promise from me for reasons that I cannot explain, this is currently my only possibility to influence the improvement of data objects. I don't know whether this is in the interests of the administrators. You have to ask they that. --Gymnicus (talk) 19:45, 11 December 2021 (UTC)
@Gymnicus: It sounds as though you are blaming the administrators who have blocked you for preventing your edits rather than acknowledging your own actions which have led to the block in the first place and directly speak against your desire to "improve the data objects". From a glance at your talk page I think you should consider the most recent comment where it seems you may have a possibility to be unblocked if willing to make some commitments.
On a related note, I'm concerned that you have been granted property creator rights because your actions make me question your judgement and ability to be objective (something needed when weighing consensus for creation). --SilentSpike (talk) 21:37, 11 December 2021 (UTC)
Unlike English Wikipedia, I don't think Wikidata has an explicit policy against proxying edits for a blocked user. Nevertheless, I don't think this would be a good precedent, especially as you have a path to unblocking that you have chosen not to take. Bovlb (talk) 18:23, 12 December 2021 (UTC)
“Unlike English Wikipedia, I don't think Wikidata has an explicit policy against proxying edits for a blocked user.” – I have no idea what you're getting at. But I'm not really interested in that either. I have my account here and I now use it as I am allowed to use it by the administrators' decisions. That means that I can currently only give suggestions for improvement, which unfortunately have not yet really been implemented.
“[...] especially as you have a path to unblocking that you have chosen not to take.” – You know we disagree there. I do not have to or had to, as one would like to say, accept your offer, as I have already said the same thing through my offer. You saw it differently and then that's the way it is now. --Gymnicus (talk) 20:21, 16 December 2021 (UTC)
Our purpose is produce a database of information. If it has become neccessary to block a person, but they can make useful contributions via a third party who will vetting and taking responsibility for such submissions, then in my view they should be allowed to do so as in the short term this will benefit the project and in the long term provide them with a means of "rehabilitation". For the record, I am blocked from the English Wikipedia and I have been disgusted by the high-handed action that certain administrators took in bending and abusing the Wikipedia rules with a total disregard of any real-world issues.
I would therefore be more than happy for any blocked editor to have a single area where they can make constructive suggestions. Martinvl (talk) 21:39, 17 December 2021 (UTC)
@Martinvl: Such an individual page would certainly be a very good idea in cases like mine and I would also support the idea. --Gymnicus (talk) 19:50, 23 December 2021 (UTC)
"In cases like [yours]." I am not sure why you see yourself as somehow special here. I don't remember interacting with you before but reading through your talk page, it is clear the continued block is your own choice. You refuse to acknowledge what you did wrong or accept the generous proposal some of the administrators offered you to be unblocked. Giving you an area for you to evade the consequences of your block seems like it is enabling you to avoid dealing with the core problem. This is a solution in search of a problem that doesn't exist. From Hill To Shore (talk) 20:12, 23 December 2021 (UTC)
@From Hill To Shore: You are quite right - I do not believe that we have interacted before. You suggested me of trying to evade my block. If you are talking about this posting, the background is that some years prior to that message being posted, a Wikipedian with whom I had worked and who was in good standing in Wikipedia had died. Somebody posted a note concerning his death on his home page but that went unnoticed. His death was certainly not recorded at en:Wikipedia:Deceased Wikipedians. When I noticed this, I went to our local library and was able to get an authoritative reference about his death from en:Ancestry.com a package to which I had free access at our public library. I offered to share this information with whoever might be willing to add the deceased Wikiepdian's name to the WP:RIP page. What I got in thanks was that tirade by User:JBW. Do you understand why I used the word "disgusted"? Martinvl (talk) 22:25, 23 December 2021 (UTC)
@Martinvl: Sorry but I think you have misunderstood as I was replying to Gymnicus (you will note I was quoting their statement of "cases like mine"). The issue with Gymnicus is that they have been offered a route to get themselves unblocked if they acknowledge the original problem and promise not to repeat it. Their requests here for someone to make edits for them rather than deal with the problem causing the block is what I am opposed to. They should either get themselves unblocked and resume editing or stay blocked and not expect their edits to be processed. For your own case, I don't really know anything about it and I can't provide comment. From Hill To Shore (talk) 22:37, 23 December 2021 (UTC)
@From Hill To Shore:
“I am not sure why you see yourself as somehow special here.” – Then you probably know more users who were only blocked for three namespaces, like me. I myself only know blocks where you are blocked for all namespaces and then maybe you can edit your own discussion page. Nonetheless, that doesn't change my statement “in cases like mine”, because with this statement I just wanted to say that I think the idea of Martinvl is good in a case like mine, where you only has been blocked for the namespaces data object, lexeme and property. The statement was never there to portray me or my block as something special, but rather the statement was only there to indicate what kind of block I think the idea is good for. For what you interpret into my statement, I can not do anything.
“Giving you an area for you to evade the consequences of your block seems like it is enabling you to avoid dealing with the core problem.” – It's interesting that you blame me for not addressing the core issue. Of course, I'm dealing with the core problem. I have been planning an opinion for a long time, whereby the consensus that has arisen due to non-existent rules on sources is dissolved by clear rules on sources. Before this opinion picture can start, however, a larger discussion on the topic will probably start again after Christmas here in the project chat, so that the opinion picture can start in the new year.
“This is a solution in search of a problem that doesn't exist.” – That may be your assessment of this section and also of Martinvl's idea. At the moment it also seems that my suggestions are of no use here because they have not yet been implemented. But that's not my problem in that sense, but rather an indictment for Wikidata, at least one could interpret it that way. On my last unlock request, I said exactly what Bovlb wanted from my point of view. But he saw it differently. I can still make a third unlock request today or maybe tomorrow with similar content to the second unlock request and then we will see whether I will be unlocked. --Gymnicus (talk) 08:41, 24 December 2021 (UTC)
  • Can this please be moved to a user page instead of hijacking project chat? --SilentSpike (talk) 12:13, 2 January 2022 (UTC)
    yes. @Gymnicus: please move this content to a user page so as to stop spamming the general project chat. BrokenSegue (talk) 17:36, 4 January 2022 (UTC)
    @SilentSpike, BrokenSegue: First of all, I don't see this as spamming or hijacking the project chat. Because what am I spamming here? According to the Duden, spam is the following: “unerwünschte massenhaft per E-Mail oder auf ähnlichem Wege versandte Nachrichten” (english: “unwanted masses of messages sent by e-mail or similar channels”) – In relation to this particular case, spam can perhaps be defined as "unwanted bulk edits". If for you as an administrator, BrokenSegue, edits in which suggestions for improvement of data objects are mentioned are spam, then I am a little concerned, I have to admit. Because with these suggestions, Wikidata, or rather the said data objects, is made better. Spam would go exactly the other way. In my opinion, one cannot speak of capturing the project chat because there is currently no special room for such a matter. From my point of view, the project chat is the first point of contact. Nevertheless, as I have already written above, I have nothing against a separate area for my concern. But I think a user page is the wrong place for something like that, because it is not “publicly” visible. But I don't mind if my request is moved to a “public” page that can be viewed quickly and easily. --Gymnicus (talk) 18:10, 4 January 2022 (UTC)
    There are millions of good edits to be made to wikidata. Enumerating them here is unhelpful and disruptive. Please find a different place to put these. I suggested a user space page because it seems most likely nobody will spend time incorporating these particular fixes and you will have to wait until you get unbanned. But if you want to create it the Wikidata namespace I suppose that's fine. This page is for project chat. BrokenSegue (talk) 18:25, 4 January 2022 (UTC)
    @BrokenSegue: “This page is for project chat.” – I agree! This is the project chat here and where does it say that this matter doesn't belong here? Nowhere. That is why I have no obligation to look for another place for this concern. But you, as the one who doesn't want this here, should suggest a way and this can then be discussed here. --Gymnicus (talk) 18:58, 4 January 2022 (UTC)
    A user page is perfectly publicly visible and the right place for a user to document their requests. Project chat is for project chat, if you keep updating this post it will stay here indefinitely - thus hijacking the page for your own intentions. SilentSpike (talk) 18:57, 4 January 2022 (UTC)
    @SilentSpike: It may be that a user page is also in principle public. But it is difficult to find and that is exactly the point. If these suggested edits are to be moved, they must or should be moved to a page that is easy to find. --Gymnicus (talk) 19:06, 4 January 2022 (UTC)
    It is disruptive to have this continually-edited section here, especially when it doesn't seem to be of much general interest. Let's go ahead and move these to, say, User:Gymnicus/Edit requests. To make this page more visible, we can add {{Edit request}} to the top,. That way it will be visible to anyone working on the Category:Wikidata protected edit requests backlog. In the event that Gymnicus's current partial block is upgraded to a full block, we can deactivate the template. Bovlb (talk) 20:51, 4 January 2022 (UTC)

This section has been moved to User:Gymnicus/Edit requests. Do not restore its contents here. Mahir256 (talk) 21:25, 5 January 2022 (UTC)

@Mahir256: I agree with the proposal by Bovlb and would have implemented it. But not in the radical way you do. I do not agree with this procedure either and that is why I have undone your deletion of the section here. The processing suggestions belong on the page suggested by Bovlb. But the side has nothing to do with this discussion here itself. That's why I will remove the discussion from there during the day or during the week, see when I have time, and expand the page as I see fit. The discussion logically belongs here because it was held here. In addition, from my point of view, the previously proposed edits also belong here. Of course, these will then also be transferred to the page suggested by Bovbl. --Gymnicus (talk) 08:10, 6 January 2022 (UTC)

This section has been moved to User:Gymnicus/Edit requests. Do not attempt to restore its contents to this page further. Mahir256 (talk) 22:10, 6 January 2022 (UTC)

@Mahir256, Bovlb: I repeat again, this discussion doesn't belong in my username space, it belongs here in the project chat. That's why I reopened the discussion here. In contrast to January 6, 2022, I did not put the processing requests here again. These do not necessarily have to be archived here. I also set the archiving block so that this section will be archived as soon as possible. --Gymnicus (talk) 01:16, 29 January 2022 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Gymnicus (talk) 01:16, 29 January 2022 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2021/12&oldid=1618874716"