Wikidata:Project chat/Archive/2021/02

Elections: Q615255 Two-round system and Q104704378 Scrutin uninominal majoritaire à deux tours

Tried to add a French link and got a confused mess which is more than I feel like unscrambling right now. We've got:

  • Q615255 Two-round system, with with de/fr/en/es/it/pt/ru and many more
  • Q104704378 Scrutin uninominal majoritaire à deux tours, with fr/it/ru only

In reality, w:fr:Scrutin uninominal majoritaire à deux tours describes the two-round system, and w:fr:Ballottage (politique) has an unclear topic but appears to be about the second of the two rounds only. However, other links that are cognates of the French word, like w:it:Ballottaggio, describe the two-round system.

It looks to me like w:fr:Scrutin uninominal majoritaire à deux tours should be connected to Q615255 instead, but that leaves it & ru with entries in both locations, and where to put w:fr:Ballottage (politique) and I can't deal with this right now. Mathglot (talk) 02:36, 1 February 2021 (UTC)

Elections: Q615255 Two-round system and Q104704378 Scrutin uninominal majoritaire à deux tours

Tried to add a French link and got a confused mess which is more than I feel like unscrambling right now. We've got:

  • Q615255 Two-round system, with with de/fr/en/es/it/pt/ru and many more
  • Q104704378 Scrutin uninominal majoritaire à deux tours, with fr/it/ru only

In reality, w:fr:Scrutin uninominal majoritaire à deux tours describes the two-round system, and w:fr:Ballottage (politique) has an unclear topic but appears to be about the second of the two rounds only. However, other links that are cognates of the French word, like w:it:Ballottaggio, describe the two-round system.

It looks to me like w:fr:Scrutin uninominal majoritaire à deux tours should be connected to Q615255 instead, but that leaves it & ru with entries in both locations, and where to put w:fr:Ballottage (politique) and I can't deal with this right now. Mathglot (talk) 02:36, 1 February 2021 (UTC)

Qualifier to use for two official websites

Does it make sense to use the qualifier applies to part (P518) with the Qid for a university department when a professor has academic appointments in more than one department and therefore has two or more official websites? I'm looking for the best way to overcome the constraint violation on official websites. For a real life example: Phillip Thurtle (Q105086473). Have a look at the official website statement in that item. https://history.washington.edu/people/phillip-thurtle is his website in the UW Department of History and https://chid.washington.edu/people/phillip-thurtle is his website in the UW Department of Comparative History of Ideas. Does "applies to part" work as a qualifier, or is there something better that I should use? UWashPrincipalCataloger (talk) 21:52, 30 January 2021 (UTC)

@UWashPrincipalCataloger: I think applies to part (P518) is almost exclusively used as a qualifier. And yeah I think your examples are reasonable ways to include multiple official websites. You could also consider applies to jurisdiction (P1001) or intended public (P2360) or publisher (P123). BrokenSegue (talk) 22:25, 30 January 2021 (UTC)
Thanks @BrokenSegue:. The description of applies to jurisdiction (P1001) implies that this is only used for political jurisdictions. Is it really ok to use it with any kind of organization? Right now it seems to be limited to geographic places/political jurisdictions. All of the examples in the property are for places. UWashPrincipalCataloger (talk) 00:43, 1 February 2021 (UTC)
@UWashPrincipalCataloger: yeah I think it's only ok for jurisdictions. It's probably not the right choice but none of them really fit perfectly. Probably publisher is the closest. Or you can just include multiple websites. BrokenSegue (talk) 00:58, 1 February 2021 (UTC)
What we really need is just a qualifier property for "applies to". That would be generic and perfect for many situations. UWashPrincipalCataloger (talk) 01:01, 1 February 2021 (UTC)
@UWashPrincipalCataloger: Perhaps, of (P642)? BrokenSegue (talk) 01:32, 1 February 2021 (UTC)
Yes, I ended up changing my qualifier to that. It already had the alias "applies to". UWashPrincipalCataloger (talk) 07:02, 1 February 2021 (UTC)

Wikidata weekly summary #453

Dustin Diamond working on the show "The Game"

Pooch Hall just posted on Instagram that Dustin Diamond worked on the television show "The Game" with him. Someone may want to look into this and verify the year(s), episode number etc. Since this man has just passed, I think it's important to get the totality of his life work correct. "The Game" is not currently listed on Wikepedia in his body of work.  – The preceding unsigned comment was added by 2601:2C0:C301:47C0:A40B:E22:839D:7616 (talk • contribs).

You can try adding it to Wikipedia if you want. According to IMDB, he appeared on one episode as himself: https://www.imdb.com/title/tt2165108/fullcredits. Wikidata doesn't currently have items for the episodes of the series. Ghouston (talk) 01:16, 2 February 2021 (UTC)

Wikidata weekly summary #453

Dustin Diamond working on the show "The Game"

Pooch Hall just posted on Instagram that Dustin Diamond worked on the television show "The Game" with him. Someone may want to look into this and verify the year(s), episode number etc. Since this man has just passed, I think it's important to get the totality of his life work correct. "The Game" is not currently listed on Wikepedia in his body of work.  – The preceding unsigned comment was added by 2601:2C0:C301:47C0:A40B:E22:839D:7616 (talk • contribs).

You can try adding it to Wikipedia if you want. According to IMDB, he appeared on one episode as himself: https://www.imdb.com/title/tt2165108/fullcredits. Wikidata doesn't currently have items for the episodes of the series. Ghouston (talk) 01:16, 2 February 2021 (UTC)

Showcase Queries

Some time ago I began a discussion about the idea of creating a new community award/recognition - for "Showcase Queries". This would be process to identify, praise, and share to the world Wikidata's true superpower: the combination of statements from many different items – the ability uncover knowledge spread across the database.

People seemed generally supportive of the concept so I wrote a proposed description and criteria for this award at Wikidata:Showcase Queries.

Various people have given feedback on the proposal on the talkpage but, ultimately, it's an abstract idea that needs real-world testing to turn from a nice idea into a community process. And so, User:Joalpe and User:Ederporto have been kind to make a formal proposal - using the draft criteria - as a request to be recognised as the first "showcase query"! You can see their nomination here: Wikidata:Showcase Queries/List of people killed by and disappeared during the Brazilian military dictatorship.

This is, therefore, a "test-case" for the proposed community recognition. A practical example for everyone to discuss, whether:

  1. the proposed award is a good idea,
  2. the criteria are appropriate, and
  3. this specific nomination meets those criteria.

If there is a consensus to support all three of these points, we could recognise the first 'official' showcase query and then create a proper nomination template etc for future nominations.
I do not think there is any official process we have to make a proposal like this, other than to test it. So, I ask you all to please comment on the talkpage of the award proposal, and on the specific nomination page. I am open to suggestions for how people would recommend moving this suggestion from idea to reality (e.g. should I publish this as a Wikidata:Requests for comment)? Wittylama (talk) 11:59, 31 January 2021 (UTC)

  • Maybe you could give a few sample queries you think meet the criteria. Supposedly you have had some in mind when writing this. --- Jura 12:16, 31 January 2021 (UTC)
    • Please see the query and associated nomination document that I provided in the above message. Wittylama (talk) 12:41, 31 January 2021 (UTC)
      • I meant queries you had in mind when writing the "showcase query" page. The nomination seems to be posterior. --- Jura 12:58, 31 January 2021 (UTC)
        • I did not have a list of pre-existing queries which I wanted to get recognition for. I assume many people have a query they’re particularly fond of, that they’ve put a lot of effort into curating, that they would like to nominate. And, at least at the outset while there is no precedents, it would be a debate between whether the criteria should adjust to suit the nomination, or the nomination should adjust to suit the criteria. Hence this first test-case nomination - it’s an example where we ought to debate the appropriateness/applicability of both the query and the criteria. Wittylama (talk) 13:08, 31 January 2021 (UTC)
          • I didn't ask if you had queries you wanted to get recognition for, but if there were some you had in mind when writing it. Maybe they only partially fulfill the criteria you wrote down. Supposedly, you didn't write it without any basis in actually existing or working queries. --- Jura 13:13, 31 January 2021 (UTC)
  • @Wittylama: I like this idea, and the specific proposal seems great. However, I'm wondering if a showcase query should have such specific output - in this case it looks like it's specially formatted for input into a Portuguese Wikipedia page. Maybe output should be a little more generic or flexible for showcase queries? Other than that, I agree it's an excellent well-documented example query that should meet "showcase" level criteria. ArthurPSmith (talk) 18:56, 1 February 2021 (UTC)
    • thanks for the support ArthurPSmith. The question you raise is exactly the kind of thing that I would hope the community should determine over the course of reviewing nominations over the years. As has occurred in English Wikipedia featured article discussions (and probably other languages too) the criteria tend to become more stringently applied over the years... Wittylama (talk) 18:02, 2 February 2021 (UTC)

2 Questions

I am a newbie in the Wikidata project and I just discovered the potential of Wikidata a few days ago when I was creating the still missing articles about the japanese nengo in the german Wikipedia project.

Unfortunately I started adding Wikidata information (label and description) to the nengo articles before I read the Wikidata manuals and I guess now that I made a mistake. The description I added looks like "Japanische Ära year bis year". I learned that 1. the description label should start with a small character and 2. that the year should not be part of the description label. Should I change the description manually or can this be done automatically? It's around 100 articles so far.

Since several years I am collecting data about Japanese writers. The list is far from beeing perfect but it consists of around 1000 entries and contains the year of completion / publishing, the name of the author (Romaji and Kanji), the title of the work (Romaji and Kanji and translation if available), small description of the work (content, No. of volumes). The entries range from the very first work, the Kojiki, until 2007. It is based on a list of a Japanese literature dictionary. In case this list is useful for wikipedia, is it possible to import the data and use it like the sample timeline done in the Historiopedia? -- Elmo rainy day (talk) 12:39, 31 January 2021 (UTC)

Wikidata:Forum might be the better place to ask about the best way to write descriptions in German. Use or not of caps is language specific. Help:Description/de can differ from Help:Description.
For time periods, I don't really see a problem with the inclusion of years. --- Jura 13:02, 31 January 2021 (UTC)
Hello & Welcome. The minor mistake regarding capitalisation is rather easy to make in this case, because the English descriptions all start with with a capitalised "Japanese"–nationalities being among the few categories that are capitalised in English but not German.
Anyway, I took the liberty to fix the capitalisation and also used your descriptions to add missing start time (P580) and end time (P582) statements. Using the dates, I linked consecutive eras with follows (P155) and followed by (P156). There's a tool called Quckstatements for mass-editing that allowed doing this in just a few minutes. But don't despair if that looks complicated–the manual part you've already been doing is the more valuable work exactly because it cannot be automated.
Anyway, this is a query showing all eras, sorted by start date, with their respective links to previous and next era: Query. It looks fairly complete, with a few missed connections where dates didn't quite agree.
Regarding the data you've collected: well, that's one of those "more complicated" cases. There is a tool called OpenRefine that allows doing such imports using a graphical user interface. It's pretty cool and only slightly buggy and it helps with the main difficulty, which is matching the data you have to data already existing in Wikidata. Have a look and see if that might work for you. If not, feel free to post on my talk page and we'll figure something out. Matthias Winkelmann (talk) 23:30, 31 January 2021 (UTC)
thanks for your detailed answers and for fixing the issue regarding capitalisation. I think the quickstatement and the SPRQL sourcecode is pretty well understandable and a good sample to dive into the matter. I already started to check the OpenRefine tool. This will take a few days, but I will come back to you for sure. Much appreciated -- Elmo rainy day (talk) 20:41, 2 February 2021 (UTC)

New development roadmap for Wikidata and Wikibase for 2021

Hi everyone,

I’m excited to announce the new roadmap of the Wikidata development team for Wikidata and Wikibase for the year 2021!

In 2021 we will continue developments to increase data quality and trust in Wikidata. Among the initiatives are to find more ways for people to find biases and gaps in the data and compare Wikidata’s data against other databases to find mismatches. We will also finish up the work from last year on a visual query builder to simplify querying.

We will be releasing the first version of the new REST API to make it easier for 3rd-party developers to build applications using data from Wikidata.

We will also work on making interface improvements for lexicographical data to make it more usable and attractive for contributors.

On the Wikibase side of things, we will officially release the lightweight, first version of Wikidata-Wikibase Federation that allows accessing remote Wikidata properties in a custom Wikibase instance. We will then develop and release an enhanced version of this feature after incorporating feedback from users.

We will also:

  • Implement a new release strategy and infrastructure for Wikibase packages and create user documentation for the Wikibase Docker update process
  • Investigate how to give Wikibase admins the option to change certain configuration options through a UI without directly editing localsettings.php.
  • Develop a web service for users to instantly create a temporary Wikibase sandbox so they can quickly and easily evaluate if the software is a fit for their project.
  • Continue to collaborate with OPEN!NEXT to provide support for partners including setting up of Wikibase instances, data modeling, maintenance, and API development.

The most up-to-date versions of the roadmap can be found here:

You can click on the different items to see further information, like a description or planned start date.

In addition, we’re also presenting status updates on what was achieved for each of the 2020 goals.

Please note that the roadmap only presents the main projects that the development team will work on during 2021. Critical and ongoing tasks (e.g. maintenance of the software and fixing pressing bugs) are not mentioned in the roadmap, but will be included in the workflow over the year. The roadmap is based on estimations and will evolve during the year. The roadmap does not contain events we are attending or organizing.

If you have any questions or feedback, feel free to add them on this talk page.

Cheers,

-Mohammed Sadat (WMDE) (talk) 16:41, 2 February 2021 (UTC)

  • I don't think the Wikidata roadmap is good.
We have no need for filtering for current events. We want to patrol all edits by new users regardless of whether they are about current events or older events. It would be better to invest into making patrolling in general easier. Instead of building tools for data quality that have a good chance being unused implementing https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata#Anti-vandalism_tools_for_Wikidata and giving better tools for vandalism fighting would be a better use of development resources.
The same goes for Curious Facts. We already have plenty of lists of constraint violations that provide this kind of facts. I would expect that in most cases it's more interesting to focus on a particular constraint and fix up statements that fit a pattern then to look into random curious facts (and violations).
As far as goes finding gaps and biases goes, what the "most important gaps and biases" is subjective. In a data user cares about a certain type of data, they care about the gaps and biases in that data and might be motivated to work on gaps or biases in the area on which they are focusing. I would expect that a tool that's not focused on the needs of a particular data user will produce lists that are largely ignored.
Getting good feedback loops with large data reusers would obviously be great. Is likely a hard task to get right. It needs both happen in a way that's compatible with the needs of the data reusers and hopefully won't produce a flood of vandalism/low quality edits. I would expect that here it's important to have UX people speak with data reusers, make proposals and present those to the Wikidata community before implementing the changes.
It's sad to see nothing about Wikidata reuse in Wikimedia in the roadmap. Seeing how Wikidata items get used in Wikimedia projects would be an important feature both to motivate people to care about improving an item, feeling good about their work having effects on other Wikimedia projects and preventing Wikidata items that get used elsewhere from getting deleted. Allowing Inverse statement to be loaded via Lua would be another useful step for integration in other Wikimedia projects.
It's also sad that none of the points from the last Community Wishlist made it into the roadmap. In particular revamping datetime would be a good project as there were two issues on the wishlist with a lot of support votes and the related long-standing issue of missing a duration datatype is in the same ballpark.
As far as Wikibase is concerned I think the work on federalization is good. Looking to provide Wikibase as a service and doing market research also seem like good ideas. ChristianKl23:19, 2 February 2021 (UTC)
I'm very much looking forward to the new Wikidata REST API and I think the Query Builder has a lot of potential :) And as a data reuser (I run https://vglist.co), I'm definitely interested in how the feedback loops could be improved and in any projects that would improve data quality in Wikidata. Nicereddy (talk) 01:37, 3 February 2021 (UTC)

Pre-discuss a property proposal

Is there a place where I can pre-discuss a property proposal? Or shall I just write it as a Wikidata:Property proposal? -DePiep (talk) 19:00, 2 February 2021 (UTC)

OK thanks. (I'll unfollow this page -- so ping me for news). -DePiep (talk) 22:15, 2 February 2021 (UTC)

Q88860637 et Q90909248

Bonjour. Q88860637 et Q90909248 sont le même article en français. Il faut lier cet article en français avec les deux autres en espagnol, en anglais. Je ne suis pas compétent pour tout remettre en ordre. Merci d'avance. Bien cordialement. AntonyB (talk) 20:56, 2 February 2021 (UTC)

One is about the UK recurring event - Clap for our Carers (Q88860637), the other about the general/international recurring event applause for health workers during Covid-19 outbreak (Q90909248). I have made the UK item a subclass of the international. They should not be merged. Sitelinks are on appropriate items. All is good. --Tagishsimon (talk) 21:02, 2 February 2021 (UTC)

New development roadmap for Wikidata and Wikibase for 2021

Hi everyone,

I’m excited to announce the new roadmap of the Wikidata development team for Wikidata and Wikibase for the year 2021!

In 2021 we will continue developments to increase data quality and trust in Wikidata. Among the initiatives are to find more ways for people to find biases and gaps in the data and compare Wikidata’s data against other databases to find mismatches. We will also finish up the work from last year on a visual query builder to simplify querying.

We will be releasing the first version of the new REST API to make it easier for 3rd-party developers to build applications using data from Wikidata.

We will also work on making interface improvements for lexicographical data to make it more usable and attractive for contributors.

On the Wikibase side of things, we will officially release the lightweight, first version of Wikidata-Wikibase Federation that allows accessing remote Wikidata properties in a custom Wikibase instance. We will then develop and release an enhanced version of this feature after incorporating feedback from users.

We will also:

  • Implement a new release strategy and infrastructure for Wikibase packages and create user documentation for the Wikibase Docker update process
  • Investigate how to give Wikibase admins the option to change certain configuration options through a UI without directly editing localsettings.php.
  • Develop a web service for users to instantly create a temporary Wikibase sandbox so they can quickly and easily evaluate if the software is a fit for their project.
  • Continue to collaborate with OPEN!NEXT to provide support for partners including setting up of Wikibase instances, data modeling, maintenance, and API development.

The most up-to-date versions of the roadmap can be found here:

You can click on the different items to see further information, like a description or planned start date.

In addition, we’re also presenting status updates on what was achieved for each of the 2020 goals.

Please note that the roadmap only presents the main projects that the development team will work on during 2021. Critical and ongoing tasks (e.g. maintenance of the software and fixing pressing bugs) are not mentioned in the roadmap, but will be included in the workflow over the year. The roadmap is based on estimations and will evolve during the year. The roadmap does not contain events we are attending or organizing.

If you have any questions or feedback, feel free to add them on this talk page.

Cheers,

-Mohammed Sadat (WMDE) (talk) 16:41, 2 February 2021 (UTC)

  • I don't think the Wikidata roadmap is good.
We have no need for filtering for current events. We want to patrol all edits by new users regardless of whether they are about current events or older events. It would be better to invest into making patrolling in general easier. Instead of building tools for data quality that have a good chance being unused implementing https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata#Anti-vandalism_tools_for_Wikidata and giving better tools for vandalism fighting would be a better use of development resources.
The same goes for Curious Facts. We already have plenty of lists of constraint violations that provide this kind of facts. I would expect that in most cases it's more interesting to focus on a particular constraint and fix up statements that fit a pattern then to look into random curious facts (and violations).
As far as goes finding gaps and biases goes, what the "most important gaps and biases" is subjective. In a data user cares about a certain type of data, they care about the gaps and biases in that data and might be motivated to work on gaps or biases in the area on which they are focusing. I would expect that a tool that's not focused on the needs of a particular data user will produce lists that are largely ignored.
Getting good feedback loops with large data reusers would obviously be great. Is likely a hard task to get right. It needs both happen in a way that's compatible with the needs of the data reusers and hopefully won't produce a flood of vandalism/low quality edits. I would expect that here it's important to have UX people speak with data reusers, make proposals and present those to the Wikidata community before implementing the changes.
It's sad to see nothing about Wikidata reuse in Wikimedia in the roadmap. Seeing how Wikidata items get used in Wikimedia projects would be an important feature both to motivate people to care about improving an item, feeling good about their work having effects on other Wikimedia projects and preventing Wikidata items that get used elsewhere from getting deleted. Allowing Inverse statement to be loaded via Lua would be another useful step for integration in other Wikimedia projects.
It's also sad that none of the points from the last Community Wishlist made it into the roadmap. In particular revamping datetime would be a good project as there were two issues on the wishlist with a lot of support votes and the related long-standing issue of missing a duration datatype is in the same ballpark.
As far as Wikibase is concerned I think the work on federalization is good. Looking to provide Wikibase as a service and doing market research also seem like good ideas. ChristianKl23:19, 2 February 2021 (UTC)
I'm very much looking forward to the new Wikidata REST API and I think the Query Builder has a lot of potential :) And as a data reuser (I run https://vglist.co), I'm definitely interested in how the feedback loops could be improved and in any projects that would improve data quality in Wikidata. Nicereddy (talk) 01:37, 3 February 2021 (UTC)

Pre-discuss a property proposal

Is there a place where I can pre-discuss a property proposal? Or shall I just write it as a Wikidata:Property proposal? -DePiep (talk) 19:00, 2 February 2021 (UTC)

OK thanks. (I'll unfollow this page -- so ping me for news). -DePiep (talk) 22:15, 2 February 2021 (UTC)

Q88860637 et Q90909248

Bonjour. Q88860637 et Q90909248 sont le même article en français. Il faut lier cet article en français avec les deux autres en espagnol, en anglais. Je ne suis pas compétent pour tout remettre en ordre. Merci d'avance. Bien cordialement. AntonyB (talk) 20:56, 2 February 2021 (UTC)

One is about the UK recurring event - Clap for our Carers (Q88860637), the other about the general/international recurring event applause for health workers during Covid-19 outbreak (Q90909248). I have made the UK item a subclass of the international. They should not be merged. Sitelinks are on appropriate items. All is good. --Tagishsimon (talk) 21:02, 2 February 2021 (UTC)

Internal links to property anchors

It seems I keep seeing links like

  • [[Property:P279#P31]]

look like

Something that generally only happens in edit summaries. Tests:

Is it just me or some change in the code? Tests here seem ok. --- Jura 11:00, 30 January 2021 (UTC)

In the usual page view, older version of the page and in edit preview, I can see what the link is supposed to be.
When I display a diff of this page, I can see something like what edit summary or {{P}} would produce. Maybe it's a bug? --Matěj Suchánek (talk) 09:33, 3 February 2021 (UTC)

Help needed: Wikinews date categories

Every news article on Wikinews is normally added to a date category on Wikinews based on the publication date of an article.

Until earlier this year, the situation (for about 10 years) was that all date categories are added to the date category item on Wikidata, while other Wikinews categories are added to the item about that subject. This difference exists as there are also date pages on various Wikinews wikis that are added to the date items on Wikidata.

Example date item: January 1, 2019 (Q57316168) + example category item: Category:January 1, 2019 (Q48766236)

Please note: on the date page you can see there are various date pages added as sitelinks for Wikinews.

The main rule is that all categories from Wikinews about the same date should be in the same item on Wikidata, as well as all the date pages in one Wikidata item

This was pretty consistent until earlier when one user decided to move (only) some of these date categories from the category item to the date item.

The issues:

  • On various date items date pages and date categories are mixed, example: 1 August 2018 (Q45920935) (en + ru)
  • No consistent method, example: Russian category on day item: December 10, 2020 (Q57397014) + Russian category on category item: Category:December 11, 2020 (Q99463188)
  • Many date categories on Wikinews have not been added to the Wikidata items or have been removed from items earlier this year.
  • There are also pages like "évènements du 1er juin 2020" on frwikinews, which are to me about the same as "1. červen 2020" on cswikinews. These are overview pages of what happened on a certain date.
    • A part of them have been added to empty Wikidata items, example: Q95852870 (I think is wrong)
    • While elsewhere from a different date is added to an item with other date pages Q95628254 (I think is wrong)
    • While this page on cswikinews is added to the date page, example: June 1, 2020 (Q57396763) (I think is right, but fr missing) (but added wrong together with categories to the same item)
    • While elsewhere cs + fr page are both added to the same item, example: May 25, 2020 (Q57396755) (I think is right) (but should not be combined with the categories in the same item)
  • A part of all these items still has no P31.

Also there for certain dates also Wikisource categories and those are added to the item for the date category, example: Category:August 1, 2019 (Q48767327).

It is a big mess. I have no idea how to fix this. Romaine (talk) 00:18, 1 February 2021 (UTC)

Whenever this topic occurred, I never understood why having categories linked with categories and main space linked with main space was not acceptable by some Wikimedians. It's the cleanest solution. Wikis can always use {{noexternallanglinks}}, load category's main topic (P301)/topic's main category (P910) and use Lua to generate whatever interwiki they want. If the data is consistent, doing that is much easier. --Matěj Suchánek (talk) 09:41, 3 February 2021 (UTC)

Kurdish Wikipedia

Should Kurdish Wikipedia (Q1154741) be split into two items, one for each wiki? It has https://ku.wikipedia.org/ (in Kurmanji) and https://ckb.wikipedia.org/ (in Sorani). It looks like the only Wikimedia project like this. (I was looking for projects whose language code doesn't match their subdomain.) — Sam Wilson 04:14, 3 February 2021 (UTC)

There are already items for both versions: Kurmanji Kurdish Wikipedia (Q92600463) and Sorani Kurdish Wikipedia (Q4115463). I connected them to the parent item via has part(s) (P527), although has edition or translation (P747) might be more appropriate (who really knows?). -Animalparty (talk) 08:02, 3 February 2021 (UTC)

New tool: Ranker

 
screenshot of the tool

Hi all! This is just a quick note that I wrote a new tool, called Ranker (documentation), which lets you edit the rank of multiple statements at once. You can find a usage example in this tweet or this video, or just look at this edit as the result :) cheers! --Lucas Werkmeister (talk) 17:19, 30 January 2021 (UTC)

Hello -Lucas, thanks for your work on this! I think it's high time we had some nice tools for editing ranks. This is really useful, although I often want to mass-edit statements in more than one item. It would be great if I could load more statements using a SPARQL query, such as this one:
select ?item ?id ?statement where {

  ?item wdt:P762 ?id .
  ?item p:P1435 ?statement .
  ?statement ps:P1435 wd:Q385405 ; wikibase:rank ?rank filter(?rank != wikibase:DeprecatedRank) .  

} limit 10
Try it!

... and the tool would load all statements displayed in the ?statement variable and enable me to change their rank. Do you think this would be feasible? Vojtěch Dostál (talk) 15:35, 3 February 2021 (UTC)

Conflation in authority databases

Do we have a way to get in touch with LoC or VIAF to let them know that they need to fix their authorities? This LoC authority, replicated in this VIAF entry, conflates Philip Alexander Bell (Q28777243) with another Philip Bell (who might be Philip Bell (Q98660228), but I'm not sure). AleatoryPonderings (talk) 17:31, 1 February 2021 (UTC)

I've had good luck emailing the VIAF at their "comment" address bibchange@oclc.org. - PKM (talk) 20:50, 1 February 2021 (UTC)

The LC authority in question doesn't conflate more than one person. This authority is for the person associated with the 1839 publication A plea for "a man and a brother" and for no other works. The work that was cataloged is: A plea for "a man and a brother" / by David Ruggles : made on the 18th July, 1839, before a public meeting held at the hall 245 Spring Street : also, extracts from the speeches of Messrs. Philip A. Bell & William P. Johnson ; with notes and remarks. While this identity may have been used on records for other works by different Philip A. Bells, this authority is only for the Philip A. Bell mentioned on the title page of the above work. No other works are cited in that authority record. If this LC ID has been used on items for people who are not that Philip A. Bell, it should be deprecated or removed from those items.

The VIAF ID cluster represents two different persons, only because the ISNI ID incorrectly groups two different people. I've reported the error to ISNI. Otherwise, VIAF is fine too and represents the same Philip A. Bell as the LC name authority. UWashPrincipalCataloger (talk) 01:23, 2 February 2021 (UTC)

@UWashPrincipalCataloger: The reason I thought nr98021013 conflated two people is that it lists the subject of that authority as a contributor to "The impact of sample rotation patterns and composite estimation on survey outcomes", which is clearly not by the same Philip A Bell. Is that not a component of the authority? AleatoryPonderings (talk) 17:29, 3 February 2021 (UTC)
@AleatoryPonderings: If you look at the actual authority, it has only one work cited and one database: found: A plea for "a man and a brother", 1839:t.p. (Philip A. Bell) and found: RLIN, 6/4/98(hdg.: Bell, Philip A.). The VIAF record includes in its cluster an ISNI record that is for the other person from Australia. I created a separate LC authority for him which has not made it into the LC Linked Data Service yet but will be there in a day or two. But nr98021013 never had both of these people on it. UWashPrincipalCataloger (talk) 17:37, 3 February 2021 (UTC)

Statement or separate item for translated editions of a book

I'm working on an item for a novel that's been translated and published in four other languages. I created this item for the original (Hebrew) edition with the related data: publisher, date, etc. How to add information in Wikidata on those other language editions? My attempt to add a foreign title to the original-language item via qualifiers was flagged. Attempting to use the statement "has edition or translation" didn't recognize the foreign title (for which apparently no item exists). Do I need to create a Wikidata item for each translated edition with its identifying info (e.g. publisher, date, ISBN) and then link them to the first (and each other??) via statements? (N.B. I read most of those languages so am qualified to manage the initial editing here.) -- Deborahjay (talk) 12:16, 3 February 2021 (UTC)

@Deborahjay: Yes; discrete items for each edition. Wikidata:WikiProject Books#Bibliographic properties and particularly Wikidata:WikiProject Books#Edition item properties are your friends. --Tagishsimon (talk) 13:59, 3 February 2021 (UTC)

Duplicates

Jorge Vargas (Q10308258) and Jorge Vargas (Q101096417) are duplicates. Could someone please help merging them? Thanks. Tonyjeff (talk) 02:09, 4 February 2021 (UTC)

Help needed: Wikinews date categories

Every news article on Wikinews is normally added to a date category on Wikinews based on the publication date of an article.

Until earlier this year, the situation (for about 10 years) was that all date categories are added to the date category item on Wikidata, while other Wikinews categories are added to the item about that subject. This difference exists as there are also date pages on various Wikinews wikis that are added to the date items on Wikidata.

Example date item: January 1, 2019 (Q57316168) + example category item: Category:January 1, 2019 (Q48766236)

Please note: on the date page you can see there are various date pages added as sitelinks for Wikinews.

The main rule is that all categories from Wikinews about the same date should be in the same item on Wikidata, as well as all the date pages in one Wikidata item

This was pretty consistent until earlier when one user decided to move (only) some of these date categories from the category item to the date item.

The issues:

  • On various date items date pages and date categories are mixed, example: 1 August 2018 (Q45920935) (en + ru)
  • No consistent method, example: Russian category on day item: December 10, 2020 (Q57397014) + Russian category on category item: Category:December 11, 2020 (Q99463188)
  • Many date categories on Wikinews have not been added to the Wikidata items or have been removed from items earlier this year.
  • There are also pages like "évènements du 1er juin 2020" on frwikinews, which are to me about the same as "1. červen 2020" on cswikinews. These are overview pages of what happened on a certain date.
    • A part of them have been added to empty Wikidata items, example: Q95852870 (I think is wrong)
    • While elsewhere from a different date is added to an item with other date pages Q95628254 (I think is wrong)
    • While this page on cswikinews is added to the date page, example: June 1, 2020 (Q57396763) (I think is right, but fr missing) (but added wrong together with categories to the same item)
    • While elsewhere cs + fr page are both added to the same item, example: May 25, 2020 (Q57396755) (I think is right) (but should not be combined with the categories in the same item)
  • A part of all these items still has no P31.

Also there for certain dates also Wikisource categories and those are added to the item for the date category, example: Category:August 1, 2019 (Q48767327).

It is a big mess. I have no idea how to fix this. Romaine (talk) 00:18, 1 February 2021 (UTC)

Whenever this topic occurred, I never understood why having categories linked with categories and main space linked with main space was not acceptable by some Wikimedians. It's the cleanest solution. Wikis can always use {{noexternallanglinks}}, load category's main topic (P301)/topic's main category (P910) and use Lua to generate whatever interwiki they want. If the data is consistent, doing that is much easier. --Matěj Suchánek (talk) 09:41, 3 February 2021 (UTC)

Conflation in authority databases

Do we have a way to get in touch with LoC or VIAF to let them know that they need to fix their authorities? This LoC authority, replicated in this VIAF entry, conflates Philip Alexander Bell (Q28777243) with another Philip Bell (who might be Philip Bell (Q98660228), but I'm not sure). AleatoryPonderings (talk) 17:31, 1 February 2021 (UTC)

I've had good luck emailing the VIAF at their "comment" address bibchange@oclc.org. - PKM (talk) 20:50, 1 February 2021 (UTC)

The LC authority in question doesn't conflate more than one person. This authority is for the person associated with the 1839 publication A plea for "a man and a brother" and for no other works. The work that was cataloged is: A plea for "a man and a brother" / by David Ruggles : made on the 18th July, 1839, before a public meeting held at the hall 245 Spring Street : also, extracts from the speeches of Messrs. Philip A. Bell & William P. Johnson ; with notes and remarks. While this identity may have been used on records for other works by different Philip A. Bells, this authority is only for the Philip A. Bell mentioned on the title page of the above work. No other works are cited in that authority record. If this LC ID has been used on items for people who are not that Philip A. Bell, it should be deprecated or removed from those items.

The VIAF ID cluster represents two different persons, only because the ISNI ID incorrectly groups two different people. I've reported the error to ISNI. Otherwise, VIAF is fine too and represents the same Philip A. Bell as the LC name authority. UWashPrincipalCataloger (talk) 01:23, 2 February 2021 (UTC)

@UWashPrincipalCataloger: The reason I thought nr98021013 conflated two people is that it lists the subject of that authority as a contributor to "The impact of sample rotation patterns and composite estimation on survey outcomes", which is clearly not by the same Philip A Bell. Is that not a component of the authority? AleatoryPonderings (talk) 17:29, 3 February 2021 (UTC)
@AleatoryPonderings: If you look at the actual authority, it has only one work cited and one database: found: A plea for "a man and a brother", 1839:t.p. (Philip A. Bell) and found: RLIN, 6/4/98(hdg.: Bell, Philip A.). The VIAF record includes in its cluster an ISNI record that is for the other person from Australia. I created a separate LC authority for him which has not made it into the LC Linked Data Service yet but will be there in a day or two. But nr98021013 never had both of these people on it. UWashPrincipalCataloger (talk) 17:37, 3 February 2021 (UTC)

Kurdish Wikipedia

Should Kurdish Wikipedia (Q1154741) be split into two items, one for each wiki? It has https://ku.wikipedia.org/ (in Kurmanji) and https://ckb.wikipedia.org/ (in Sorani). It looks like the only Wikimedia project like this. (I was looking for projects whose language code doesn't match their subdomain.) — Sam Wilson 04:14, 3 February 2021 (UTC)

There are already items for both versions: Kurmanji Kurdish Wikipedia (Q92600463) and Sorani Kurdish Wikipedia (Q4115463). I connected them to the parent item via has part(s) (P527), although has edition or translation (P747) might be more appropriate (who really knows?). -Animalparty (talk) 08:02, 3 February 2021 (UTC)

Statement or separate item for translated editions of a book

I'm working on an item for a novel that's been translated and published in four other languages. I created this item for the original (Hebrew) edition with the related data: publisher, date, etc. How to add information in Wikidata on those other language editions? My attempt to add a foreign title to the original-language item via qualifiers was flagged. Attempting to use the statement "has edition or translation" didn't recognize the foreign title (for which apparently no item exists). Do I need to create a Wikidata item for each translated edition with its identifying info (e.g. publisher, date, ISBN) and then link them to the first (and each other??) via statements? (N.B. I read most of those languages so am qualified to manage the initial editing here.) -- Deborahjay (talk) 12:16, 3 February 2021 (UTC)

@Deborahjay: Yes; discrete items for each edition. Wikidata:WikiProject Books#Bibliographic properties and particularly Wikidata:WikiProject Books#Edition item properties are your friends. --Tagishsimon (talk) 13:59, 3 February 2021 (UTC)

Duplicates

Jorge Vargas (Q10308258) and Jorge Vargas (Q101096417) are duplicates. Could someone please help merging them? Thanks. Tonyjeff (talk) 02:09, 4 February 2021 (UTC)

P629 and P747 values for the national Creative Commons licenses

This problem doesn't affect 4.0 version of licenses, but do affect 1.0 through 3.0. Currently these licenses are having edition or translation of (P629) values directly to the main "CC BY", "CC BY-SA"... items, e.g. Creative Commons Attribution 3.0 Singapore (Q75859751)edition or translation of (P629)Creative Commons Attribution (Q6905323) results the main items have a large scale of has edition or translation (P747) values. but someone on Wikimedia Commons think that this sort of property usages are weird, and they propose to only keep the "Generic", "Unported" editions on Q6905323 and others, and change these P629 values to Generic/Unported, e.g. Creative Commons Attribution 3.0 Singapore (Q75859751)edition or translation of (P629)Creative Commons Attribution 3.0 Unported (Q14947546), any opinions on them? --Liuxinyu970226 (talk) 04:27, 4 February 2021 (UTC)

The problem is basically that there is no such thing as “the Creative Commons Attribution (Q6905323) license”; it’s just a family (class) of licenses including Creative Commons Attribution 3.0 Unported (Q14947546), Creative Commons Attribution 3.0 Singapore (Q75859751), etc. The individual localized licenses are, indeed, not an edition/translation of the family (that would not make sense), but (I guess; in most of the cases at least) translations/editions of the English unported version.
So the correct model would be IMHO to have Creative Commons Attribution 3.0 Unported (Q14947546)instance of (P31)Creative Commons Attribution (Q6905323), Creative Commons Attribution 3.0 Singapore (Q75859751)instance of (P31)Creative Commons Attribution (Q6905323), etc. (with all instance of (P31) claims of Creative Commons Attribution (Q6905323) changed to subclass of (P279)). The edition or translation of (P629) claims are not that important, I think, but could/should be changed to point to the unported version.
A slight problem is that claims like e.g. SuperTuxKart (Q971909)copyright license (P275)Creative Commons Attribution (Q6905323) are inherently wrong, but currently we consider them valid.
--Mormegil (talk) 09:19, 4 February 2021 (UTC)

Getting WikiData template to correspond with the right slots on Commons

Does anyone know how to fix this problem with the 'occupation' value? Is it possible to "pipe" (or something else) WD so a subject shows up in the right slot in the right Commons category? --W.carter (talk) 09:42, 4 February 2021 (UTC)

This is apparently a glitch in the Wikidata Infobox template when the item has qualifiers on work period (start) (P2031). There are some other examples at c:Template_talk:Wikidata_Infobox#Incorrect_categorization. Ghouston (talk) 11:03, 4 February 2021 (UTC)
Yes, it was a bug in the infobox, it's fixed in the sandbox and I've changed the affected category to use the sandbox for now. I'll work through some of the other outstanding issues soon and then do a combined update of the main version of the infobox. In general, the best place to raise these issues is at commons:Template talk:Wikidata Infobox. Thanks. Mike Peel (talk) 11:53, 4 February 2021 (UTC)

P629 and P747 values for the national Creative Commons licenses

This problem doesn't affect 4.0 version of licenses, but do affect 1.0 through 3.0. Currently these licenses are having edition or translation of (P629) values directly to the main "CC BY", "CC BY-SA"... items, e.g. Creative Commons Attribution 3.0 Singapore (Q75859751)edition or translation of (P629)Creative Commons Attribution (Q6905323) results the main items have a large scale of has edition or translation (P747) values. but someone on Wikimedia Commons think that this sort of property usages are weird, and they propose to only keep the "Generic", "Unported" editions on Q6905323 and others, and change these P629 values to Generic/Unported, e.g. Creative Commons Attribution 3.0 Singapore (Q75859751)edition or translation of (P629)Creative Commons Attribution 3.0 Unported (Q14947546), any opinions on them? --Liuxinyu970226 (talk) 04:27, 4 February 2021 (UTC)

The problem is basically that there is no such thing as “the Creative Commons Attribution (Q6905323) license”; it’s just a family (class) of licenses including Creative Commons Attribution 3.0 Unported (Q14947546), Creative Commons Attribution 3.0 Singapore (Q75859751), etc. The individual localized licenses are, indeed, not an edition/translation of the family (that would not make sense), but (I guess; in most of the cases at least) translations/editions of the English unported version.
So the correct model would be IMHO to have Creative Commons Attribution 3.0 Unported (Q14947546)instance of (P31)Creative Commons Attribution (Q6905323), Creative Commons Attribution 3.0 Singapore (Q75859751)instance of (P31)Creative Commons Attribution (Q6905323), etc. (with all instance of (P31) claims of Creative Commons Attribution (Q6905323) changed to subclass of (P279)). The edition or translation of (P629) claims are not that important, I think, but could/should be changed to point to the unported version.
A slight problem is that claims like e.g. SuperTuxKart (Q971909)copyright license (P275)Creative Commons Attribution (Q6905323) are inherently wrong, but currently we consider them valid.
--Mormegil (talk) 09:19, 4 February 2021 (UTC)

Getting WikiData template to correspond with the right slots on Commons

Does anyone know how to fix this problem with the 'occupation' value? Is it possible to "pipe" (or something else) WD so a subject shows up in the right slot in the right Commons category? --W.carter (talk) 09:42, 4 February 2021 (UTC)

This is apparently a glitch in the Wikidata Infobox template when the item has qualifiers on work period (start) (P2031). There are some other examples at c:Template_talk:Wikidata_Infobox#Incorrect_categorization. Ghouston (talk) 11:03, 4 February 2021 (UTC)
Yes, it was a bug in the infobox, it's fixed in the sandbox and I've changed the affected category to use the sandbox for now. I'll work through some of the other outstanding issues soon and then do a combined update of the main version of the infobox. In general, the best place to raise these issues is at commons:Template talk:Wikidata Infobox. Thanks. Mike Peel (talk) 11:53, 4 February 2021 (UTC)

Problem with items for 'USB Flash Drive' and 'USB mass storage device' - how to proceed?

I put a lot of work today in USB mass storage device and USB Flash Drive, which were some hours ago (imho) both strongly improvable (irony). They were partly (from a technical point of view) mixed with each other, partly wrong, partly the english description wrong AND contrary to the German description or vice versa.

However, I arrived at a dead end for my Wikidata skills - I realized only now that, e.g., the identificators in the "mass storage" item are (nearly) all for the USB flash drive, the interwiki links as well.

I already put in a lot more work than I intended, and I have the feeling that completion would take me alone some more hours and would probably lead to some errors due to my lack of experience with the rest of the tasks tbd. Hence my suggestion - either I redo all I did completely (see for yourself how the state was before I started), or some other contributors here help me out. I am fine with either version. Please advise. Pittigrilli (talk) 17:26, 31 January 2021 (UTC)

I agree. I originally thought it would be a good idea to have a generic item for "USB mass storage device", but when one looks at the taxonomy and inner logic of Wikidata, it is just a mix-up and redundant. The "class" item USB mass storage device class (Q1155870) is a perfect higher class for all other, inluding USB flash drive, USB hard disc, USB card reader, etc. Pittigrilli (talk) 10:18, 1 February 2021 (UTC)
As I do not see anyone disagreeing, I would say we follow your proposed course. The only bigger task I see is that nearly all identificators and interwikis (at least 15 each) in the to-be defunct USB mass storage device are actually wrong where they are now, because they all correctly belong to USB Flash Drive, which now has almost none. How do we solve that elegantly? Merge both items? To be honest, your proposal above exceeded my Wikidata skills. Pittigrilli (talk) 18:39, 1 February 2021 (UTC)
I'll look into it. I think a lot of the site links can be moved from USB storage conflation (Q4432) to USB flash drive (Q1647694), for a start. Ghouston (talk) 01:28, 2 February 2021 (UTC)
Looks very good. I made some more minor edits in USB flash drive (Q1647694), I think it is now satisfactorily. I will create an item for USB Hard Disk soon. Thanks for the good cooperation, Pittigrilli (talk) 16:55, 2 February 2021 (UTC)
Depends if the type of device, and not the interface, is what is needed in a statement somewhere. Peter James (talk) 17:14, 2 February 2021 (UTC)
The Deed Is Done (Q7729535) (joke): Here is the new USB hard disk (Q105232187). The status is 'in progress'. Pittigrilli (talk) 17:59, 2 February 2021 (UTC)
Your category c:Category:USB hard disks is a duplicate of c:Category:USB hard disk drives, isn't it? Ghouston (talk) 21:22, 2 February 2021 (UTC)
No. It appears at first sight like that, but no. When I created yesterday the new category c:Category:USB hard disks, I first looked around and found exactly the one you mentioned: c:Category:USB hard disk drives. I then wondered why it only had two subcategories, and, even more strange, each of those has only pics of 'blank' hard disk drives without enclosure - hence, they are strictly not at all USB, but might be produced for use in USB hard disks. After some confusion on my side I realized that this category (strangely categorized very low in the tree as well) is only meant for blank hard disk drives (the inner thing without enclosure etc.) meant for use in USB hard disks. There you go. And it has some logic to it. Hence, I left the whole thing as it was and created the new category c:Category:USB hard disks where it belongs, directly below c:Category:USB devices. I hope I could make myself clear ;-) I found that old category a bit strange alltogether, maybe it could be considered to change/delete it. Pittigrilli (talk) 14:38, 3 February 2021 (UTC)
The names are synonyms, and a functional drive with a USB interface is still a USB hard drive, even if it lacks an enclosure. Maybe there could be a category for disassembled USB hard drives. Ghouston (talk) 22:47, 3 February 2021 (UTC)
@Ghouston:I had a closer look at c:Category:USB hard disk drives. The raw hard drives there have a directly attached USB receptacle, in comparison to the normal SATA interface. Thus, they are indeed "USB hard disk drives" and quite special, I assume. Pittigrilli (talk) 11:07, 5 February 2021 (UTC)

Nicknames in quotes in the middle of a name

Do we want entries like John Sumner Burroughs (Q98424972)? I doubt someone will type the name this exact way to find the person, I think these nicknames should be broken down into "John S. Burroughs" and "Buddy Burroughs", what do you think? --RAN (talk) 06:29, 5 February 2021 (UTC)

If the others are added as aliases, then it's still searchable. According to Help:Label, the label should be the "most common name that the item would be known by", and if you mostly see the name written elsewhere as John S. "Buddy" Burroughs, then it seems that's what the label should be. Ghouston (talk) 07:59, 5 February 2021 (UTC)

Massive influx of duplicates through Cebuano WP ?

By @GZWDer (flood): bot, for example Godziesze Wielkie (Q49351573) vs Godziesze Wielkie (Q985924). Distinct values constraints fire twice per item (GeoNames ID (P1566) and Who's on First ID (P6766)). Kpjas (talk) 08:41, 5 February 2021 (UTC)

How long before proposals marked "Ready" get created as properties?

There seem to be a fair number of proposals on Wikidata:Property proposal/Person marked as "ready". I'm just wondering how long it takes for these to be converted into properties? There's one on there from me that I'd like to be able to use as soon as it is created. UWashPrincipalCataloger (talk) 01:06, 2 February 2021 (UTC)

Universal Code of Conduct consultation - Second round questions: reporting system

It's time for the second round of questions about the ways of implementing UCoC, this time focusing on the reporting system. I tried this time to better formulate the questions, but please remember that I have to be as much general as possible in formulating questions.

As I said for the first round questions, there are other aspects that will be taken into consideration, but if you think something's missing, please do bring it up in the discussion! Be bold and have your say!

Also, if you haven't answered the first round questions, go give them some love. ;) --Sannita (WMF) (talk) 15:04, 5 February 2021 (UTC)

Lil Eazy-E

Here Q4042897

On the photo, there are Knife and Lil Eazy E. Is it proper photo for Lil Eazy E on wikidata? When there are 2 men instead of 1. Longbowman (talk) 16:59, 5 February 2021 (UTC)

@Longbowman: I cropped it with the Commons CropTool. Inductiveload (talk) 17:50, 5 February 2021 (UTC)

How long before proposals marked "Ready" get created as properties?

There seem to be a fair number of proposals on Wikidata:Property proposal/Person marked as "ready". I'm just wondering how long it takes for these to be converted into properties? There's one on there from me that I'd like to be able to use as soon as it is created. UWashPrincipalCataloger (talk) 01:06, 2 February 2021 (UTC)

QuickStatement Approval?

We require approval for bot actions but do not for bulk QuickStatement actions. Should we produce some guideline for bulk actions in general that require approval? Like a bot action that edits 100 items seems pointless to get approval for when I can make 5000 edits with no approval through QS.

I would propose rules of the form (off the top of my head):

  • Any bulk edit that makes more than 10,000 distinct changes (not edit count) needs approval
  • Any bulk import that makes more than 1,000 new items needs approval
  • Small requests for approval are assumed approved if they garner no opposition within 48 hours (currently the bot approval process is very slow, i have multiple requests out with no comments for weeks)
    • small requests are < 50k changes or 10k imports

Thoughts? BrokenSegue (talk) 22:57, 4 February 2021 (UTC)

What problem is this seeking to solve? I could do without bottom inspections and 48 hours delay in a situation where I wish to add or amend sets of items, not least when the item sets I tend to play with, which number in the thousands & tend of thousands. --Tagishsimon (talk) 23:02, 4 February 2021 (UTC)
honestly the problem is an inconsistency in the current policy. We should either change the rules on bots to match that on QS or do this. This intermediate case just encourages everyone (including me) to do things via QS which is worse than if I used a bot (but I'm not waiting 3 months for approval)... BrokenSegue (talk) 00:14, 5 February 2021 (UTC)
Inconsistency in the current policy is not a very good reason for introducing QS bureaucracy. If you have an issue with the bot approval process, please try to address that without dragging other activities into the mix. I note a salient difference between a bot and QS is that QS is known, whereas when I rock up with my new bot, you don't have a clue what it is nor how it will behave. And once I have bot approval, I can still make mistakes by the thousand by the process of GIGO without having to go through additional bot approval. So the bot approval / QS comparison is not all that useful in any event. --Tagishsimon (talk) 00:36, 5 February 2021 (UTC)
Given that it's possible to undo a QuickStatement batch in a way you can't undo all edits of a bot, using the bold principle with QuickStatements isn't as problematic as using it with bot edits. ChristianKl00:47, 5 February 2021 (UTC)
I think if consensus for a change has been obtained somewhere, such as Project chat or wherever, then that should be sufficient to permit implementation using a bot if desired. Obtaining a second bot approval seems redundant. Ghouston (talk) 07:38, 5 February 2021 (UTC)

Nicknames in quotes in the middle of a name

Do we want entries like John Sumner Burroughs (Q98424972)? I doubt someone will type the name this exact way to find the person, I think these nicknames should be broken down into "John S. Burroughs" and "Buddy Burroughs", what do you think? --RAN (talk) 06:29, 5 February 2021 (UTC)

If the others are added as aliases, then it's still searchable. According to Help:Label, the label should be the "most common name that the item would be known by", and if you mostly see the name written elsewhere as John S. "Buddy" Burroughs, then it seems that's what the label should be. Ghouston (talk) 07:59, 5 February 2021 (UTC)

Massive influx of duplicates through Cebuano WP ?

By @GZWDer (flood): bot, for example Godziesze Wielkie (Q49351573) vs Godziesze Wielkie (Q985924). Distinct values constraints fire twice per item (GeoNames ID (P1566) and Who's on First ID (P6766)). Kpjas (talk) 08:41, 5 February 2021 (UTC)

Universal Code of Conduct consultation - Second round questions: reporting system

It's time for the second round of questions about the ways of implementing UCoC, this time focusing on the reporting system. I tried this time to better formulate the questions, but please remember that I have to be as much general as possible in formulating questions.

As I said for the first round questions, there are other aspects that will be taken into consideration, but if you think something's missing, please do bring it up in the discussion! Be bold and have your say!

Also, if you haven't answered the first round questions, go give them some love. ;) --Sannita (WMF) (talk) 15:04, 5 February 2021 (UTC)

Lil Eazy-E

Here Q4042897

On the photo, there are Knife and Lil Eazy E. Is it proper photo for Lil Eazy E on wikidata? When there are 2 men instead of 1. Longbowman (talk) 16:59, 5 February 2021 (UTC)

@Longbowman: I cropped it with the Commons CropTool. Inductiveload (talk) 17:50, 5 February 2021 (UTC)

Wiki Loves Folklore 2021 is back!

Please help translate to your language

 

You are humbly invited to participate in the Wiki Loves Folklore 2021 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.

Please support us in translating the project page and a banner message to help us spread the word in your native language.

Kind regards,

Wiki loves Folklore International Team

MediaWiki message delivery (talk) 13:25, 6 February 2021 (UTC)

Change broken link

Hi, can someone change the value I specified here: https://www.wikidata.org/wiki/Talk:Q882 I can't change it because page is locked. Thanks.Tehonk (talk) 20:15, 6 February 2021 (UTC)

Just changed it now TB5ivVaO1y55FkAogw1X (talk) 20:41, 6 February 2021 (UTC)
Great, thanks.Tehonk (talk) 21:15, 6 February 2021 (UTC)

Short URL link

If a SPARQL query is run you can create a "Short URL to result". Is the link persistent or time-limited? If I make a small change to the query will it create a new short URL?--Wolbo (talk) 13:15, 6 February 2021 (UTC)

Persistent. The short URL links to the query URL as it was at the time you caused the creation of the short URL. Changes made to the query after causing the short URL to be created, will not be found if the short URL is used. Neither is a new short URL created automatically in such circumstances, unless you go through the process of causing a new short URL to be created. --Tagishsimon (talk) 13:20, 6 February 2021 (UTC)
That's good to know, thanks. Two follow-up questions. It seems the variable part of the URL is only the three characters after https://w.wiki/ eg https://w.wiki/y2U. With all those queries run (must surely be millions) how does the URL link stay unique? Also it seems the URL link defaults to the table view of the query result. Is it possible to create a direct URL link to e.g. the timeline or map view of a query? --Wolbo (talk) 13:45, 6 February 2021 (UTC)
As to the first, short URLs are created (in WDQS) only when the user selects Link / Short URL to result. As to the second, you can create a short URL for any wikimedia URL at https://meta.wikimedia.org/wiki/Special:UrlShortener - and there is more info on the service at https://meta.wikimedia.org/wiki/Wikimedia_URL_Shortener ... so you could copy the URL of a WDQS query such that you're taken to the WDQS UI or - I presume - to a timeline or other specific visualiation. I think the salient difference is the embed.html part of the URL - which takes you to the result, versus no embed.html which takes you to the WDQS UI.
Thanks again, will have a look. One of the nice aspects of wiki is that if you don't know something there is always someone else who does.--Wolbo (talk) 14:13, 6 February 2021 (UTC)

Wiki Loves Folklore 2021 is back!

Please help translate to your language

 

You are humbly invited to participate in the Wiki Loves Folklore 2021 an international photography contest organized on Wikimedia Commons to document folklore and intangible cultural heritage from different regions, including, folk creative activities and many more. It is held every year from the 1st till the 28th of February.

You can help in enriching the folklore documentation on Commons from your region by taking photos, audios, videos, and submitting them in this commons contest.

Please support us in translating the project page and a banner message to help us spread the word in your native language.

Kind regards,

Wiki loves Folklore International Team

MediaWiki message delivery (talk) 13:25, 6 February 2021 (UTC)

Change broken link

Hi, can someone change the value I specified here: https://www.wikidata.org/wiki/Talk:Q882 I can't change it because page is locked. Thanks.Tehonk (talk) 20:15, 6 February 2021 (UTC)

Just changed it now TB5ivVaO1y55FkAogw1X (talk) 20:41, 6 February 2021 (UTC)
Great, thanks.Tehonk (talk) 21:15, 6 February 2021 (UTC)

Dates with <11 precision

Hello, me and Mormegil have discussed that we are not sure what is the proper way to fill in dates with precision less than day. For example, you can write +1866-00-00T00:00:00Z/09 for year 1866, but you can also write +1866-01-01T00:00:00Z/09 or +1866-12-31T00:00:00Z/09 and nothing will change on the output for users. This seems like a trivial problem, but tools such as QuickStatements will understand these as three different values and add a new statement instead of recognizing that the value had already been there (see here for example). What is the formally correct way to express dates with <11 precision and if there isn't consensus yet, should we try to form it and then ask a bot to correct all such values accordingly?Vojtěch Dostál (talk) 05:39, 2 February 2021 (UTC)

  • Given that the Wikidata user interface doesn't support precision that's less then a day I don't think we should create a consensus around adding that kind of precision via QuickStatements. It needs UX work on the side of WMDE that should come first. ChristianKl14:13, 2 February 2021 (UTC)
    Precision <11 means “lesser precision”, e.g. “month” or “year”, not “smaller time resolution”, e.g. “hour” or “second”. :-) It’s a normal thing used everywhere and rendered by the Wikidata UI correctly.
    The problem, as Vojtěch wrote, is that the statement [e.g. born in] “year 1866“ can be written and stored in innumerable ways, from the default (“+1866-00-00T00:00:00Z/09”) through straightforward (“+1866-01-01T00:00:00Z/09”) to less straightforward (“+1866-05-17T00:00:00Z/09”). The default using -00 is quite strange (“+1866-00-00T00:00:00Z/09” – that’s not an ISO 8601 timestamp there, right?) but at least it might be quite a simple standard how to represent these less-precise values, if used universally (and ideally enforced by the software). All those ways are allowed and used, but I am not aware of any explanation what do they mean. Do they mean the same thing (they are displayed in the same way in the UI)? Do they mean something slightly different (as Vojtěch mentioned, QS does not consider them equal; the quality constraints checker looks at the full date even for lower precisions (see e.g. phab:T168379))? What exactly do they mean? Does “+1866-05-17T00:00:00Z/09” mean “any time in 1866, ignore the random ‘05-17’” or “1866-05-17 ± 1 year” or “1866-05-17 ± 0.5 years” or something else entirely? That should be made clear and the software should enforce it, IMHO.
    What needs development work is not only support for the time part of the value, but also the before/after pieces (which are currently completely ignored in the UI, IIANM), and possibly timezone.
    --Mormegil (talk) 14:00, 3 February 2021 (UTC)
    P.S. A similar problem exists for coordinates where the different services and UI uses the “indeterminate” parts beyond the specified precision in different ways, some ignoring them, some using them without regard to the stated (lower) precision.
    There's also a bug about how to define centuries. I think it's in the too-hard basket. phabricator:T196674. Ghouston (talk) 03:26, 4 February 2021 (UTC)
    According to the discussion it's not a bug and Wikibase per design defines century not in the ISO 8601 way but in the way it's defined in the Wikipedia articles. According to ISO 8601 the first day in this century was 2000-01-01 but according to the Wikipedia definition it's 2001-01-01 (many other sources define it also as 2001-01-01). ChristianKl00:13, 5 February 2021 (UTC)
    I see that Help:Dates has been modified since I originally commented on the bug. Whether it's all consistent now, I don't know. Ghouston (talk) 01:52, 5 February 2021 (UTC)

@Ghouston, Mormegil: Hmm, if I understand Help:Dates#Time_datatype correctly, the "empty" digits in the timestamp should be zeros, quite possibly contrary to ISO 8601. I am unfamiliar with international time standards but having a consensus here is nevertheless important because we can then ask a bot to standardize the digits in datetime statements.Vojtěch Dostál (talk) 06:42, 5 February 2021 (UTC)

Perhaps setting it to zero makes it clear that these "reduced precision" formats aren't valid dates in ISO 8601 format, but just resemble it a bit (the slash at the end when written like +2021-00-00T00:00:00Z/9 also does that). In the standard, you can use "2021-02" to represent a month, or "2021" for a year, and apparently even "20" for the century, but it's a 2000-2099 century in that case. Ghouston (talk) 07:52, 5 February 2021 (UTC)
See also mw:Wikibase/DataModel#Dates and times. That seems to agree that, for example, the 19th century comprised the years 1801 to 1900 inclusive. But the first decade of the 1800s was 1800 to 1809 inclusive. Jc3s5h (talk) 15:16, 5 February 2021 (UTC)
Should we then ask a bot to regularly change the digits to zeros in these cases? Vojtěch Dostál (talk) 08:30, 7 February 2021 (UTC)
This would technically require a way to find dates that don't conform. I don't know if there's a practical method. Ghouston (talk) 10:13, 7 February 2021 (UTC)

Property for current full name

While using Wikidata infobox in Wikipedia, I noticed that I can't get the person's current full name via the template. I can only input it myself with the parameter {{{name}}} or else it would use the page name instead. What I want is for example, getting Chelsea Manning (Q298423) as "Chelsea Elizabeth Manning" not only "Chelsea Manning". I tried to find a property using "full name" but I noticed it has been used for the alias of birth name (P1477) and I can't add it on the item since she is trans and it has been used for her deadname. Is there any other way I can get her current full name or maybe there is a property I'm not aware of? RXerself (talk) 17:45, 5 February 2021 (UTC)

Archive index doesn't work

For some reason Wikidata:Requests for deletions/Archive/2020 only shows the archives until September and Wikidata:Requests for deletions/Archive/2021 doesn't contains any archives. --ZabeMath (talk) 13:14, 6 February 2021 (UTC)

Request for split?

Little Russia (Q1048315) represents both the historical region, and a disambiguation page (and errors appear because of this conflict). I’m reasonably certain only one wikilink (cs) is a disambig page. There’s a recent merge, but I can’t tell whether undoing that would resolve this. Advice or help, please. —Michael Z. 16:24, 7 February 2021 (UTC)

@Mzajac: I've undone the unhelpful merge, but not looked to tidy either item up more than that. Little Russia (Q36941668) is the other side of the merge. --Tagishsimon (talk) 16:32, 7 February 2021 (UTC)
Thanks, @Tagishsimon:. Can you swap the two cs links between the items? w:cs:Malorusko (rozcestník) is the disambig page for Little Russia (Q36941668), and w:cs:Malorusko the regular article for Little Russia (Q1048315). (I get an error message, and don’t know the right way to do this.) —Michael Z. 17:11, 7 February 2021 (UTC)
w:cs:Malorusko is a redirect, is the problem. WMDE don't seem interested in sorting out (or even commenting on) the redirect issue; I'm not going to get involved in the workaround needed to made good that lack. --Tagishsimon (talk) 17:43, 7 February 2021 (UTC)
Oh well. Thanks for the split. This is now much better. —Michael Z. 21:23, 7 February 2021 (UTC)

Call for participants: Let's design a delightful mobile app for Wikidata!

We need a seamlessly working tool that makes editiong a breeze.

I would love to participate in or lead the designing and writing of a kotlin app as a study project. You can join me in realizing this project and learn more about design sprints.

Coding skills are not required. We need testers, project members that help fleshing out a delightful design, etc. The best would actually be multiple design groups that each do a series of design sprints and optimize for a delightful experience for the targeted user group (sv. målgrupp)

Designing a successful app is team effort (can be done using video conferencing). I recommend using design sprint 2.0 and tools like Miro (useful for storyboarding, crazy 8s image uploads, and silent art museum) and Figma (prototyping).

I recently created Design Sprint 2.0 (Q105078321) to describe the process in detail. If anyone is interested in joining me in creating a succesful app that is a delight to use, feel free to contact me.

There is a WMF call for grant applications that end Feb 10, eight days from now.

Together we can move mountains, alone everything is a struggle uphill 😉--So9q (talk) 03:55, 2 February 2021 (UTC)

Why Kotlin? Flutter would produce an App that can be used outside of Android whether or iOS or the PC. ChristianKl14:38, 2 February 2021 (UTC)
Good point! Do you know how to program? Wanna join?--So9q (talk) 16:46, 3 February 2021 (UTC)
We are now 3 in the group. Please spread the word, to your dog and grandma. 😃 Join us at [1]. We don't bite and you can be sure to learn something about design sprints and geek stuff.--So9q (talk) 06:58, 4 February 2021 (UTC)
The group is growing, feel free to join if you want to contribute to realizing the goal. We value both small and big contributions. We will soon begin drafting the Grant Application (deadline in March). Paid work is possible depending on the Grant Committees decision.
Currently editing of statements from m.wikidata.org is not possible. That's bad and hindering a lot of users who don't have a PC from editing and contributing. Mobile is the most widespread computing device in the world. I believe editing on the go is the way to move forward, just look at how many valuable edits are made to other WMF projects from mobile.
Since Wikidata is now about to turn 10 years and no one even tried building a mobile App (except the GTK-powered Daty, which might work on Android phones also, but it's not finished and work has stalled) I find it likely that the WMF is going to support this project generously if they like our application and believe we can pull it off. Let's get together and start working. Please join us today [2] and introduce yourself and the skills you bring to the table.--So9q (talk) 07:21, 5 February 2021 (UTC)
I'm not a coder, but I'd be willing to test such an app as an editor. UWashPrincipalCataloger (talk) 19:55, 5 February 2021 (UTC)
As the sole developer of the only available mobile Wikidata app, of course I am in. Ogoorcs (talk) 21:47, 7 February 2021 (UTC)

Dates with <11 precision

Hello, me and Mormegil have discussed that we are not sure what is the proper way to fill in dates with precision less than day. For example, you can write +1866-00-00T00:00:00Z/09 for year 1866, but you can also write +1866-01-01T00:00:00Z/09 or +1866-12-31T00:00:00Z/09 and nothing will change on the output for users. This seems like a trivial problem, but tools such as QuickStatements will understand these as three different values and add a new statement instead of recognizing that the value had already been there (see here for example). What is the formally correct way to express dates with <11 precision and if there isn't consensus yet, should we try to form it and then ask a bot to correct all such values accordingly?Vojtěch Dostál (talk) 05:39, 2 February 2021 (UTC)

  • Given that the Wikidata user interface doesn't support precision that's less then a day I don't think we should create a consensus around adding that kind of precision via QuickStatements. It needs UX work on the side of WMDE that should come first. ChristianKl14:13, 2 February 2021 (UTC)
    Precision <11 means “lesser precision”, e.g. “month” or “year”, not “smaller time resolution”, e.g. “hour” or “second”. :-) It’s a normal thing used everywhere and rendered by the Wikidata UI correctly.
    The problem, as Vojtěch wrote, is that the statement [e.g. born in] “year 1866“ can be written and stored in innumerable ways, from the default (“+1866-00-00T00:00:00Z/09”) through straightforward (“+1866-01-01T00:00:00Z/09”) to less straightforward (“+1866-05-17T00:00:00Z/09”). The default using -00 is quite strange (“+1866-00-00T00:00:00Z/09” – that’s not an ISO 8601 timestamp there, right?) but at least it might be quite a simple standard how to represent these less-precise values, if used universally (and ideally enforced by the software). All those ways are allowed and used, but I am not aware of any explanation what do they mean. Do they mean the same thing (they are displayed in the same way in the UI)? Do they mean something slightly different (as Vojtěch mentioned, QS does not consider them equal; the quality constraints checker looks at the full date even for lower precisions (see e.g. phab:T168379))? What exactly do they mean? Does “+1866-05-17T00:00:00Z/09” mean “any time in 1866, ignore the random ‘05-17’” or “1866-05-17 ± 1 year” or “1866-05-17 ± 0.5 years” or something else entirely? That should be made clear and the software should enforce it, IMHO.
    What needs development work is not only support for the time part of the value, but also the before/after pieces (which are currently completely ignored in the UI, IIANM), and possibly timezone.
    --Mormegil (talk) 14:00, 3 February 2021 (UTC)
    P.S. A similar problem exists for coordinates where the different services and UI uses the “indeterminate” parts beyond the specified precision in different ways, some ignoring them, some using them without regard to the stated (lower) precision.
    There's also a bug about how to define centuries. I think it's in the too-hard basket. phabricator:T196674. Ghouston (talk) 03:26, 4 February 2021 (UTC)
    According to the discussion it's not a bug and Wikibase per design defines century not in the ISO 8601 way but in the way it's defined in the Wikipedia articles. According to ISO 8601 the first day in this century was 2000-01-01 but according to the Wikipedia definition it's 2001-01-01 (many other sources define it also as 2001-01-01). ChristianKl00:13, 5 February 2021 (UTC)
    I see that Help:Dates has been modified since I originally commented on the bug. Whether it's all consistent now, I don't know. Ghouston (talk) 01:52, 5 February 2021 (UTC)

@Ghouston, Mormegil: Hmm, if I understand Help:Dates#Time_datatype correctly, the "empty" digits in the timestamp should be zeros, quite possibly contrary to ISO 8601. I am unfamiliar with international time standards but having a consensus here is nevertheless important because we can then ask a bot to standardize the digits in datetime statements.Vojtěch Dostál (talk) 06:42, 5 February 2021 (UTC)

Perhaps setting it to zero makes it clear that these "reduced precision" formats aren't valid dates in ISO 8601 format, but just resemble it a bit (the slash at the end when written like +2021-00-00T00:00:00Z/9 also does that). In the standard, you can use "2021-02" to represent a month, or "2021" for a year, and apparently even "20" for the century, but it's a 2000-2099 century in that case. Ghouston (talk) 07:52, 5 February 2021 (UTC)
See also mw:Wikibase/DataModel#Dates and times. That seems to agree that, for example, the 19th century comprised the years 1801 to 1900 inclusive. But the first decade of the 1800s was 1800 to 1809 inclusive. Jc3s5h (talk) 15:16, 5 February 2021 (UTC)
Should we then ask a bot to regularly change the digits to zeros in these cases? Vojtěch Dostál (talk) 08:30, 7 February 2021 (UTC)
This would technically require a way to find dates that don't conform. I don't know if there's a practical method. Ghouston (talk) 10:13, 7 February 2021 (UTC)

Redirects

When it will be possible to add redirects without removing them at Wikipedia page? Eurohunter (talk) 13:45, 4 February 2021 (UTC)

It would be useful to get an update on progress on redirects as sitelinks. Perhaps @Mohammed Sadat (WMDE): can help? I think the three main issues are, 1) when can we expect to be able to add redirects as sitelinks, exactly as we now add sitelinks to article & other such pages; 2) how exactly will redirect sitelinks be differentiated from non-redirect sitelinks in the user interface and via WDQS; 3) will such differentiation depend on the user (e.g. badging the sitelink) or on the system recognising that the sitelink is to a redirect. And, of course, 4) when? --Tagishsimon (talk) 14:18, 4 February 2021 (UTC)
@Mohammed Sadat (WMDE): Anything? --Tagishsimon (talk) 17:40, 7 February 2021 (UTC)

Property for current full name

While using Wikidata infobox in Wikipedia, I noticed that I can't get the person's current full name via the template. I can only input it myself with the parameter {{{name}}} or else it would use the page name instead. What I want is for example, getting Chelsea Manning (Q298423) as "Chelsea Elizabeth Manning" not only "Chelsea Manning". I tried to find a property using "full name" but I noticed it has been used for the alias of birth name (P1477) and I can't add it on the item since she is trans and it has been used for her deadname. Is there any other way I can get her current full name or maybe there is a property I'm not aware of? RXerself (talk) 17:45, 5 February 2021 (UTC)

Sitelinks to Incubator

I found a new item Category:Countries in Europe (Q105273258). It seemed to be empty (version link), so I merged it with Category:Countries in Europe (Q4587626). The diffs (diff1, diff2) show that the item had a sitelink to Incubator, and now that link should be connected to Q4587626. However, when I look at Q4587626, I can't find it. According to Wikidata:Incubator, Incubator is not a Wikidata client. Wikidata:Notability says nothing about links to Incubator.

According the query below, we currently have 51 items with links to Incubator.

#Sitelinks to Incubator
SELECT ?item ?itemLabel ?article WHERE {

    ?article schema:about ?item .
    ?article schema:isPartOf <https://incubator.wikimedia.org/>.

    SERVICE wikibase:label {
       bd:serviceParam wikibase:language "en"
    }
}
Try it!

I don't think it's good design to have invisible data linked to an item.

  • What should we do with sitelinks to Incubator?
  • How is it even possible to add sitelinks to a project we don't yet support?
  • How can the sitelink be edited or deleted when it doesn't show up in the user interface?

--Shinnin (talk) 08:38, 6 February 2021 (UTC)

  • Either it's a bug or unannounced new feature. I think some keep asking for that, but Wikibase hasn't really found a good way to support multiple sitelinks to the same wiki.
I would guess it's a bug and in that case, they can just be deleted. --- Jura 09:12, 6 February 2021 (UTC)
For them to be deleted, you need to ask at Wikidata:Contact the development team. api and Special:SetSiteLink don't seem to support "incubatorwiki" --- Jura 09:25, 6 February 2021 (UTC)
Couldn't an abuse filter do this? ChristianKl11:15, 6 February 2021 (UTC)
It might be worth a try. It still needs cleaning up though. --- Jura 11:31, 6 February 2021 (UTC)


SELECT ?item ?itemLabel ?itemDescription ?pagename ?article ?langwiki (lang(?pagename) as ?langpagename)
WHERE
{
    ?article schema:about ?item .
    ?article schema:isPartOf <https://wikisource.org/> ; schema:name ?pagename ; schema:inLanguage ?langwiki
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

Same with https://wikisource.org . Sample diff: [3] from [4]. --- Jura 11:31, 6 February 2021 (UTC)

We should probably hold off on doing anything with multilingual Wikisource, as it's in the process of getting Wikidata support; see Tech news from earlier this week. Vahurzpu (talk) 04:22, 7 February 2021 (UTC)
Or check if any cleanup is needed given that (if it actually happens). --- Jura 11:14, 7 February 2021 (UTC)

Archive index doesn't work

For some reason Wikidata:Requests for deletions/Archive/2020 only shows the archives until September and Wikidata:Requests for deletions/Archive/2021 doesn't contains any archives. --ZabeMath (talk) 13:14, 6 February 2021 (UTC)

Request for split?

Little Russia (Q1048315) represents both the historical region, and a disambiguation page (and errors appear because of this conflict). I’m reasonably certain only one wikilink (cs) is a disambig page. There’s a recent merge, but I can’t tell whether undoing that would resolve this. Advice or help, please. —Michael Z. 16:24, 7 February 2021 (UTC)

@Mzajac: I've undone the unhelpful merge, but not looked to tidy either item up more than that. Little Russia (Q36941668) is the other side of the merge. --Tagishsimon (talk) 16:32, 7 February 2021 (UTC)
Thanks, @Tagishsimon:. Can you swap the two cs links between the items? w:cs:Malorusko (rozcestník) is the disambig page for Little Russia (Q36941668), and w:cs:Malorusko the regular article for Little Russia (Q1048315). (I get an error message, and don’t know the right way to do this.) —Michael Z. 17:11, 7 February 2021 (UTC)
w:cs:Malorusko is a redirect, is the problem. WMDE don't seem interested in sorting out (or even commenting on) the redirect issue; I'm not going to get involved in the workaround needed to made good that lack. --Tagishsimon (talk) 17:43, 7 February 2021 (UTC)
Oh well. Thanks for the split. This is now much better. —Michael Z. 21:23, 7 February 2021 (UTC)

Wikipedia overview article (Q20136634)

Is there an advantage of having that? religion in Bhutan (Q4393008) was an instance of religion, religion in Japan (Q1056672) an instance of religion of an area (Q66374263) and a few others are instances of Wikipedia overview article (Q20136634). --- Jura 17:40, 7 February 2021 (UTC)

ID for the censored Chinese alternative to Wikipedia?

There was some chat on the Wikipedia discord today about Baidu Baike, so I went to propose adding an ID for it, and found that Wikidata:Property proposal/Baidu Baike ID already exists and was declined back in 2018.

For those not in the know, Baidu Baike is the de facto version of Wikipedia in Chinese, and has 16x as many entries as Chinese Wikipedia, but is heavily censored and has various neutrality/copyright/etc. issues. I'm rather surprised that the proposal failed, as I didn't think adding a property ID for an entity carried any sort of implied endorsement, and like it or not, Baidu Baike is probably the best source of information for non-controversial Chinese topics that might be too obscure to have much or any coverage on Wikipedia. Documenting Baidu Baike IDs could presumably have applications for censorship researchers or for identifying areas of expansion for Wikipedia related to Chinese topics.

Am I off in thinking this, and if not, how do I revive the proposal to get some fresh eyes on it? {{u|Sdkb}}talk 22:12, 7 February 2021 (UTC)

Las Vegas Hotel

Basically the same thing, with a name change? Westgate Las Vegas Resort & Casino (Q61741811) vs Westgate Las Vegas Resort & Casino (Q1340365). Ghouston (talk) 01:10, 8 February 2021 (UTC)

Wikipedia overview article (Q20136634)

Is there an advantage of having that? religion in Bhutan (Q4393008) was an instance of religion, religion in Japan (Q1056672) an instance of religion of an area (Q66374263) and a few others are instances of Wikipedia overview article (Q20136634). --- Jura 17:40, 7 February 2021 (UTC)

  • I guess it could work if Wikipedia had two articles about a topic, e.g. "religion in Japan" and "overview of religion in Japan" (similar to outline articles: we have "religion" and "outline of religion"). Even if some Wikidata labels include "overview of ", that doesn't seem true for Wikipedia. --- Jura 10:02, 8 February 2021 (UTC)

BREAKING / SIGNIFICANT CHANGE: wbeditentity response to use standard JSON serialization

This is an announcement for a change to the response of the wbeditentity API module, which is a breaking change for MediaInfo entities (Structured Data on Commons), a significant change for Lexeme entities (lexicographical data), a minor change for Property entities, and a no-op for Item entities.

The wbeditentity API module, which can be used to edit any part of a Wikibase Entity, has long included a part of the edited data in its response. However, this response data was incomplete: it included e.g. Labels, Statements, Sitelinks, but not the datatype of a Property or the Lemmas of a Lexeme. Additionally, Statements were always returned under the key "claims", even though MediaInfo entities generally use the key "statements". On or around February 10, we will deploy a code change that will make wbeditentity return the entity data using the standard serialization format of an entity type, the same that is used by wbgetentities and Special:EntityData. This means that the response will now contain all the parts of an Entity, and also that, for MediaInfo entities, the Statements will now be returned under "statements". (These Statements will also be missing the "datatype", just like the MediaInfo data from wbgetentities and Special:EntityData – see T246809.)

To avoid breaking MediaInfo API users immediately, we are temporarily adding Statements under the key "claims" as well – that is, the change on February 10 is only significant, not yet breaking, and MediaInfo API users can use either the "claims" or the "statements". On or around March 3, we will remove this compatibility code, and MediaInfo API users will have to use "statements" if they want to look at the Statements of the returned entity data.

It’s also worth mentioning here what the wbeditentity response data represents. The API returns the Entity data as edited by your API request, and the revision ID of the page that the change was saved under. This is not necessarily the Entity data of that revision ID: if Wikibase patched any edit conflicts between the base revision ID that your request specified (baserevid parameter) and the actual latest revision ID, then those changes are not included in the response. For example, if you load an Item with revision ID X and labels “a” and “b” in different languages, and make a wbeditentity request with baserevid=X to change the label “a” to “A”, but in the meantime someone else had already changed the label “b” to “B” and saved this as revision Y, then the API response for your request will have a last revision ID ("lastrevid") of Z, and this revision Z will have labels “A” and “B” if you get it from Special:EntityData, but the API response for your request will have labels “A” and “b” (the result of applying your edit to the base revision). If you need the actual latest Entity data after your edit, make a separate request to Special:EntityData or wbgetentities. (This is nothing new, and unaffected by the change being announced here, but we thought it was still worth mentioning.)

If you have any issue or question, feel free to leave a comment at T271105. --Lucas Werkmeister (WMDE) (talk) 10:44, 8 February 2021 (UTC)

ID for the censored Chinese alternative to Wikipedia?

There was some chat on the Wikipedia discord today about Baidu Baike, so I went to propose adding an ID for it, and found that Wikidata:Property proposal/Baidu Baike ID already exists and was declined back in 2018.

For those not in the know, Baidu Baike is the de facto version of Wikipedia in Chinese, and has 16x as many entries as Chinese Wikipedia, but is heavily censored and has various neutrality/copyright/etc. issues. I'm rather surprised that the proposal failed, as I didn't think adding a property ID for an entity carried any sort of implied endorsement, and like it or not, Baidu Baike is probably the best source of information for non-controversial Chinese topics that might be too obscure to have much or any coverage on Wikipedia. Documenting Baidu Baike IDs could presumably have applications for censorship researchers or for identifying areas of expansion for Wikipedia related to Chinese topics.

Am I off in thinking this, and if not, how do I revive the proposal to get some fresh eyes on it? {{u|Sdkb}}talk 22:12, 7 February 2021 (UTC)

2y is a long time. Re-proposing it seems fine. BrokenSegue (talk) 04:52, 8 February 2021 (UTC)
  Support --Lectrician1 (talk) 05:19, 8 February 2021 (UTC)
See also: Wikidata:Project_chat/Archive/2020/02#Is_Wikidata's_purpose_to_provide_links_to_every_(open)_wiki?--GZWDer (talk) 07:11, 8 February 2021 (UTC)
Reproposing is generally fine but you should address the arguments of the previous discussion and ping all people involved in the previous discussion. ChristianKl16:10, 8 February 2021 (UTC)

Charles Algernon Parsons

Charles Algernon Parsons (Q150910) (Q55254181) (Q58934990) (Q99429677) these are all the same person and need merged.

He is conflicting with Charles Parsons (Q18508052) who is a prolific painter. Q18508052 should be the creator Charles Parsons Q18508052

Charles Algernon Parsons has an entry as a creator and this can be deleted. He probably created nothing.

Charles Parsons (Q18508052) has been, and is confused with his son Charles R. Parsons (Q51558271), which is also another conflict when it come to the creator.

Also no one here is British Armenian. Feel free to ask questions... Broichmore (talk) 15:30, 8 February 2021 (UTC)

Well that seems like it was a wild goose chase. Charles Algernon Parsons (Q150910) Category:Charles Algernon Parsons (Q55254181) Charles Algernon Parsons (1854–1931) (Q58934990) Parsons, The Hon. Sir Charles Algernon (Q99429677) are the well-known inventor and a category and 2 articles on him. They need to stay as separate things b/c a human is not a category is not an article about the human. The other two are artists with no obvious link nor conflict - Charles Parsons (Q18508052) and Charles R. Parsons (Q51558271). I have not looked in detail, but I cannot see any obvious errors to fix except perhaps in your understanding of wikidata. --Tagishsimon (talk) 15:39, 8 February 2021 (UTC)

Maybe it's more readable in the above format. --- Jura 18:09, 8 February 2021 (UTC)

Wikidata weekly summary #454

QuickStatement Approval?

We require approval for bot actions but do not for bulk QuickStatement actions. Should we produce some guideline for bulk actions in general that require approval? Like a bot action that edits 100 items seems pointless to get approval for when I can make 5000 edits with no approval through QS.

I would propose rules of the form (off the top of my head):

  • Any bulk edit that makes more than 10,000 distinct changes (not edit count) needs approval
  • Any bulk import that makes more than 1,000 new items needs approval
  • Small requests for approval are assumed approved if they garner no opposition within 48 hours (currently the bot approval process is very slow, i have multiple requests out with no comments for weeks)
    • small requests are < 50k changes or 10k imports

Thoughts? BrokenSegue (talk) 22:57, 4 February 2021 (UTC)

What problem is this seeking to solve? I could do without bottom inspections and 48 hours delay in a situation where I wish to add or amend sets of items, not least when the item sets I tend to play with, which number in the thousands & tens of thousands. --Tagishsimon (talk) 23:02, 4 February 2021 (UTC)
honestly the problem is an inconsistency in the current policy. We should either change the rules on bots to match that on QS or do this. This intermediate case just encourages everyone (including me) to do things via QS which is worse than if I used a bot (but I'm not waiting 3 months for approval)... BrokenSegue (talk) 00:14, 5 February 2021 (UTC)
Inconsistency in the current policy is not a very good reason for introducing QS bureaucracy. If you have an issue with the bot approval process, please try to address that without dragging other activities into the mix. I note a salient difference between a bot and QS is that QS is known, whereas when I rock up with my new bot, you don't have a clue what it is nor how it will behave. And once I have bot approval, I can still make mistakes by the thousand by the process of GIGO without having to go through additional bot approval. So the bot approval / QS comparison is not all that useful in any event. --Tagishsimon (talk) 00:36, 5 February 2021 (UTC)
Given that it's possible to undo a QuickStatement batch in a way you can't undo all edits of a bot, using the bold principle with QuickStatements isn't as problematic as using it with bot edits. ChristianKl00:47, 5 February 2021 (UTC)
I think if consensus for a change has been obtained somewhere, such as Project chat or wherever, then that should be sufficient to permit implementation using a bot if desired. Obtaining a second bot approval seems redundant. Ghouston (talk) 07:38, 5 February 2021 (UTC)
We already have an approval for the most common bulk actions - homogeneous imports for newly created (or maybe not so newly created, but yet unfilled) properties. That's what "Planned usage" field is for: if something about import is written there, and community agreed with it, expect it to happen. The tool for import is just a technicality, it also can be an OpenRefine, TemplateHarverster, PetScan, various cmd tools, etc. What is worth talking about and needs some procedural improvements is catalogue import, e. g. see what recently happened with The Peerage. --Lockal (talk) 09:14, 8 February 2021 (UTC)
We need to define good practices of (semi)automatic editing. Many users are doing semi (or fully) automatic edits (e.g. imports) without any approval.
The following is based on MisterSynergy's comment: Strictly speaking, the things that only needs an approval is bot editing, and (if we lay aside gaming the system issue) anyone can do as many edits as they like using QuickStatements without a bot account (and this is also the de facto practice), which are batch editing. This is why we need to revise our bot policy. --GZWDer (talk) 17:29, 9 February 2021 (UTC)

property proposal

Does ip have the right to vote? I saw Wikidata:Property proposal/Patamu Certificate ID but I don’t know if this is a valid consensus. (`・ω・´) (talk) 03:45, 9 February 2021 (UTC)

i mean I like the enwiki policy that suggests it isn't really a "vote" but an attempt to reach consensus so all these   Support's with no comment hold little weight. BrokenSegue (talk) 03:47, 9 February 2021 (UTC)
Property proposal is not a vote but a discussion.--GZWDer (talk) 17:04, 9 February 2021 (UTC)

Mobile app model item

Is Deezer Android app (Q41697521) a good model item? I don't remember if there were ever a consensus regarding having different items for Android and iOS. --Trade (talk) 12:47, 9 February 2021 (UTC)

@Trade: It's fine IMO because Android apps can be on various Android app stores (but it doesn't seem we have ID properties for those app stores yet), there is a defining statement code|operating system = Android, and you wouldn't want to put, operating system = Android, IOS on the same item. --Lectrician1 (talk) 13:54, 10 February 2021 (UTC)

Instance of Commons gallery?

https://www.wikidata.org/wiki/Q2064095 - is it correct to place Instance of Commons gallery there?

This is cathedral, not a Commons Gallery. Is there some property for "has commons gallery"? Mateusz Konieczny (talk) 10:14, 10 February 2021 (UTC)

Usually in the sitelinks, but there is a property Commons gallery (P935). It's only in instance of (P31) because it was merged from a separate item Q21153199. Peter James (talk) 10:31, 10 February 2021 (UTC)
Then I removed it Mateusz Konieczny (talk) 11:00, 10 February 2021 (UTC)

Qualifiers break on Narrow (ish) screens below about 900px

If you look at a statement with a qualifier on a screen under about 900px wide, the value of the qualifier is very squeezed:

 

It's even worse if you try to edit the qualifier:

 

900px isn't that narrow a screen. The CSS causing this appears to be:

.wikibase-statementview-qualifiers .wikibase-snaklistview .wikibase-snaklistview-listview .wikibase-snakview-value-container .wikibase-snakview-body {
	margin-left: 16px;
	margin-right: 18em;
	word-wrap: break-word;
}

Where the very large margin-right is what causes this. Is there something we can do about this? Inductiveload (talk) 23:46, 9 February 2021 (UTC)

Request for feedback on CentralNotice banner for Wikidata user diversity survey

Hello,

The Wikidata development team at Wikimedia Germany is planning a brief survey of the core demographics that make up the Wikidata community in order to provide us with a baseline for future diversity efforts.

To yield representative results, we want to deploy the survey to a broad range of users via the CentralNotice.

We have put up a request for a CentralNotice banner; the request is open for feedback and comments until February 17th, 2021. You can also find more information about the survey, the use of the data and the questions asked.

Feel free to take a look and let us know if you have any questions.

Cheers, -Mohammed Sadat (WMDE) (talk) 10:49, 10 February 2021 (UTC)

  • I'm not sure if you can really get "representative results" when people volunteer to do a survey. You don't know if these volunteers are representative of the people who see the banner. Ghouston (talk) 21:39, 10 February 2021 (UTC)

Is there a way to create a qualifier constraint on a property that limits the qualifier to specific values?

For example, Steam application ID (P1733) has a required constraint (required qualifier constraint (Q21510856) for platform (P400). The only valid values for a platform on a Steam Application ID are Microsoft Windows (Q1406), macOS (Q14116), or Linux (Q388). Steam supports no other platforms. Despite this, some items have been given invalid platform qualifiers.

Is there a way to have a constraint on the platform qualifier for Steam App ID that limits it to just the three valid items? Restricting the platform property itself wouldn't make sense, since its top-level use or usage in other qualifiers is fine with other values. I only want to limit it for qualifiers on this specific property.

You could do the same thing for the platform qualifier on Nintendo eShop ID (P8084), allowing only the Nintendo platforms supported by the eShop.

Is there a way to accomplish this? Thanks. -Nicereddy (talk) 00:27, 9 February 2021 (UTC)

@Nicereddy: one-of qualifier value property constraint (Q52712340) looks like it might do this. Doesn't seem much used - is used only on flag bearer (P3022). --Tagishsimon (talk) 01:20, 9 February 2021 (UTC)
@Tagishsimon: Thanks! I think it fits, and I've added it to the Steam Application ID property constraints, but it doesn't look like the WikibaseQualityConstraints extension actually supports it. :( Nicereddy (talk) 01:03, 11 February 2021 (UTC)
@Nicereddy: Suggest you take it to Wikidata:Contact the development team to find out what's going on. --Tagishsimon (talk) 01:15, 11 February 2021 (UTC)

Sitelinks to Incubator

I found a new item Category:Countries in Europe (Q105273258). It seemed to be empty (version link), so I merged it with Category:Countries in Europe (Q4587626). The diffs (diff1, diff2) show that the item had a sitelink to Incubator, and now that link should be connected to Q4587626. However, when I look at Q4587626, I can't find it. According to Wikidata:Incubator, Incubator is not a Wikidata client. Wikidata:Notability says nothing about links to Incubator.

According the query below, we currently have 51 items with links to Incubator.

#Sitelinks to Incubator
SELECT ?item ?itemLabel ?article WHERE {

    ?article schema:about ?item .
    ?article schema:isPartOf <https://incubator.wikimedia.org/>.

    SERVICE wikibase:label {
       bd:serviceParam wikibase:language "en"
    }
}
Try it!

I don't think it's good design to have invisible data linked to an item.

  • What should we do with sitelinks to Incubator?
  • How is it even possible to add sitelinks to a project we don't yet support?
  • How can the sitelink be edited or deleted when it doesn't show up in the user interface?

--Shinnin (talk) 08:38, 6 February 2021 (UTC)

  • Either it's a bug or unannounced new feature. I think some keep asking for that, but Wikibase hasn't really found a good way to support multiple sitelinks to the same wiki.
I would guess it's a bug and in that case, they can just be deleted. --- Jura 09:12, 6 February 2021 (UTC)
For them to be deleted, you need to ask at Wikidata:Contact the development team. api and Special:SetSiteLink don't seem to support "incubatorwiki" --- Jura 09:25, 6 February 2021 (UTC)
Couldn't an abuse filter do this? ChristianKl11:15, 6 February 2021 (UTC)
It might be worth a try. It still needs cleaning up though. --- Jura 11:31, 6 February 2021 (UTC)


SELECT ?item ?itemLabel ?itemDescription ?pagename ?article ?langwiki (lang(?pagename) as ?langpagename)
WHERE
{
    ?article schema:about ?item .
    ?article schema:isPartOf <https://wikisource.org/> ; schema:name ?pagename ; schema:inLanguage ?langwiki
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

Same with https://wikisource.org . Sample diff: [6] from [7]. --- Jura 11:31, 6 February 2021 (UTC)

We should probably hold off on doing anything with multilingual Wikisource, as it's in the process of getting Wikidata support; see Tech news from earlier this week. Vahurzpu (talk) 04:22, 7 February 2021 (UTC)
Or check if any cleanup is needed given that (if it actually happens). --- Jura 11:14, 7 February 2021 (UTC)

edit war?..

I've gone about to migrate information on the operating system for software items from the P400 property (platform) to the more specific P306 (operating system). But User:BrokenSegue is not happy about it. Now he has found the revert button, without responding to any of the evidence I provided. Can someone help us out here?--Reseletti (talk) 02:22, 9 February 2021 (UTC)

yeah I replied to all the comments. It is you who was acting without consensus and creating a bunch of constraint violations. Look at the usage of platform (P400) on Doom (Q189784) and you will see how it is commonly used here. Removing all such usages is not what we want. BrokenSegue (talk) 02:25, 9 February 2021 (UTC)

I'll note that bulk unapproved actions like this are what I had in mind when I wrote Wikidata:Project_chat#QuickStatement_Approval?. Though this changeset is fortunately small. I wish we had a low friction approval process for batch actions so people can once over these. BrokenSegue (talk) 02:43, 9 February 2021 (UTC)

What do you think about my proposal at Property_talk:P306#Restrict_to_devices? Ghouston (talk) 06:14, 9 February 2021 (UTC)

@Ghouston: I think I'm grateful for the constructive proposal. I see how it may solve two problems at once. Seems like the more radical solution, but the slew of implied problems should be solvable. We should think about adjusting the name of the OS property in case we implement the proposal since that name would get (more) misleading.--Reseletti (talk) 07:10, 11 February 2021 (UTC)

I'm not sure you can call this an edit war when you did not gain consensus before making such a broad change. Even if it _were_ a change we all agreed was good in hindsight, you went about it the wrong way. Always gain consensus from fellow editors before doing things like this, please. Nicereddy (talk) 13:42, 9 February 2021 (UTC)

It looked like the beginning of one at one point.
I've done some research and it didn't look like anything really controversial, at least not the completed state. I wouldn't be very productive if I were to seek discussion nevertheless in all of these cases. So: move fast and break things – wiki style; accept a residual risk... But for that I need productive discussions and it didn't look like one.
The complaints mainly sounded like resistance to any change. I'm glad that other people were able to clarify his point for me a little, although at first there wasn't much help in finding a solution to what I was trying to solve.
All the better now with this constructive proposal from User:Ghouston.--Reseletti (talk) 07:10, 11 February 2021 (UTC)

Las Vegas Hotel

Basically the same thing, with a name change? Westgate Las Vegas Resort & Casino (Q61741811) vs Westgate Las Vegas Resort & Casino (Q1340365). Ghouston (talk) 01:10, 8 February 2021 (UTC)

  • One seems to have been about a train station [8], thus the French description "gare ferroviaire américaine". I think they can be merge/the second sitelink to Commons deleted. @Missvain: --- Jura 09:58, 8 February 2021 (UTC)

Technical maintenance planed‬ (Wednesday 17th at 07:00 AM UTC)

This section was archived on a request by: --- Jura 07:15, 17 February 2021 (UTC)

Proper "instance of" for a physical sign

As physical entrance sign is not a method or technique something seems wrong.

It seems to me that Ash Mountain Entrance Sign (Q4804421) should be instance of "physical sign" (not to be confused with [https://www.wikidata.org/wiki/Q262246 sign - concept in semiotics or linguistics]

Is my diagnosis correct? Is it OK to create such entry (I failed to find it). Is it maybe existing?


To avoid XY problem: I am trying to distinguish physical objects located at specific location (specific object such as sign, castle, road, garden, tree) from abstract or moving objects (specific human, event, "garden" as a concept, brand, species of a tree) for my small OpenStreetMap validator https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/

Currently number of entities such as Ash Mountain Entrance Sign (Q4804421) are misidentified due to broken Wikidata structure.

For example https://www.wikidata.org/wiki/Q2908764 according to Wikidata is a behaviour (people mover [9] -> public transport (shared transportation service for use by the general public) [10] -> transport (human-directed movement of things or people between locations) [11] -> move [12] -> en: behavior [13])

Mateusz Konieczny (talk) 10:06, 10 February 2021 (UTC)


I created https://www.wikidata.org/wiki/Q105449313 "physical sign - sign existing as an object, not a concept or idea" Mateusz Konieczny (talk) 06:55, 12 February 2021 (UTC)

Fujimoto, 2 entries for the same family name

There are Q1473211 and Q21513147, both about the family name Fujimoto but one is a Wikimedia human name disambiguation page but it is not, can the 2 entries be merged?--37.162.178.165 14:12, 10 February 2021 (UTC)

No, if you look at the German link for the object Fujimoto (Q1473211), you will see that there is a disambiguation page. --Gymnicus (talk) 14:40, 10 February 2021 (UTC)

The above four should be separate. One incorrectly included a P31 statement for Wikimedia disambiguation page (Q4167410) (reverted since). Not sure why there are both Wikimedia human name disambiguation page (Q22808320) and Wikimedia disambiguation page (Q4167410), but that's a different question/problem. --- Jura 14:44, 10 February 2021 (UTC)

Wikimedia disambiguation page (Q4167410) I didn't know the object Wikimedia disambiguation page (Q4167410) before either. But this object doesn't really bother me. --Gymnicus (talk) 14:58, 10 February 2021 (UTC)
In ja.wikipedia there's also Q11624103, alone, also Q21513147 is alone whitout other entries, why in some languages it's in disambiguation page and in other no? practically there's no differrence for how those are written. From the German page there's no link to the Japanese or English pages, that's the matter.--37.162.178.165 15:18, 10 February 2021 (UTC)
      • Some Wikipedia combine names differently into disambiguation pages. If they consider it one, it would be linked to a disambiguation item here. I don't think Wikidata should have a view on how they "ought" to do it. Also Wikipedias can set additional interwikis (manually or automatically) to whatever page they prefer without a need to edit Wikidata.
      • Just noticed that Q21513147] was incorrectly edited. It should just be Latin script "Fujimoto" (e.g. for Americans with that family name). --- Jura 16:33, 10 February 2021 (UTC)
  • Interestingly, there are also: Fujimoto (Q90035954) and 藤本 (Q90035431). --- Jura 16:37, 10 February 2021 (UTC)
Some can use disambiguation pages but why it should affect also wikidata? It's always a list of people with that family name. I think Q21513147 and Q11624103 should be merged into Q1473211, there are no info differences and there's not another page with same name on wikidata, it's incorrect to say "family name has to use a different item than disambiguation pages" because there isn't another Fujimoto disambiguation, it's always the same page in different wikipedias.--37.162.178.165 17:04, 10 February 2021 (UTC)
I don't really care about the merger of disambiguation pages. Fujimoto (Q21513147) should remain separate because it has a specific function at Wikidata (family name (P734) value for James Fujimoto (Q26923747)). How many sitelinks any of these have isn't really relevant. --- Jura 17:15, 10 February 2021 (UTC)
It doesn't matter much for Wikidata. We should try to make the Wikipedia interlinking work well, instead of bureaucratically insisting that some Wikipedia links should be kept separate from others because of minor differences in format. If a Wikipedia disambiguation page contains only surname or given name entries, then it could be added to the relevant Wikidata name item. This can be easily added to the Wikidata disambiguation page guidelines. Ghouston (talk)
  • I think so too, but there isn't much of a point of amalgamating different types of items based on the current version of ever changing Wikipedia content.
    Most of the handling of disambiguation pages could be automatized and wikis that are interested can include additional sitelinks based on Wikidata statements in fairly simple way. Oddly, there isn't much demand for it or users come here because Wikipedia wont make the editorial changes they were looking for.
    Also, I don't quite see how we could accommodate wikis that, on the Wikidata item for a disambiguation page, want to include information about other topics, e.g. a locality. At some point we occasionally got that type of request from ruwiki contributors, as apparently there disambiguation pages are more like short articles on a series of topics. --- Jura 08:28, 11 February 2021 (UTC)
It often happens that Japanese family names are the same in Latin script, but have different kanji. So often non-Japanese users are confused.Fujimoto (Q1473211) and Q11624103 are different disambiguation pages. This is because one is Fujimoto in Latin script and the other is Fujimoto in Kanji. Fujimoto (Q1473211) lacks information about which kanji is used.--Afaz (talk) 02:27, 11 February 2021 (UTC)

approx. dates qualifiers

I'm not sure if I understood the logic properly. Say Q105450654 - it is known that Pietro Staggi died not earlier than 1814. I would assume that "date of death" is 1814 and for that field above I add qualifiers if needed. But the interface requires to set it twice (or no save option). So I wrote 1814 for death, and added below "earliest date = 1814". Is this the way to be done? --NeoLexx (talk) 08:28, 12 February 2021 (UTC)

It's rather: DOD=19th century, earliest date = 1814. The intro at Help:Dates doesn't seem to mention it. --- Jura 08:35, 12 February 2021 (UTC)
Oh, OK - so the assumed logic is 1) to fill the main field with the least precise date not requiring qualifiers 2) more precise date goes to qualifiers subsection. It is indeed far from being obvious and should be hinted somehow in the interface. --NeoLexx (talk) 08:44, 12 February 2021 (UTC)
Jura - and how to set DOD to XIX century? If I choose Precision - century, then 19 gives me "1. century", XIX - "The time value is malformed" --NeoLexx (talk) 08:51, 12 February 2021 (UTC)
You could leave 1814 and just change precision, or type "19. century" (if I recall correctly). --- Jura 08:54, 12 February 2021 (UTC)
I made so far 1810s + earliest date 1814. Just wondering how our ru-wiki data grabber will eat it (fine or choke). Thank you! --NeoLexx (talk) 08:58, 12 February 2021 (UTC)
I vaguely recall the date-module on frwiki formatting it quite nicely. BTW, you could also set DOD to unknown. --- Jura 09:04, 12 February 2021 (UTC)

Related entries that split up interwiki links

Hello. I just came upon ice sailing (Q1320458) and ice boat (Q487307). One about a sport, one about the vehicle the sport is practiced with. Half of the Wikipedias have chosen to make an article about the one, half about the other. Only three Wikipedias have articles about both. It makes it difficult to find the articles in other languages. For instance I was on the “ice boat” article of the English wiki, and I could not find the “voile sur glace” article of the French wiki, that I discovered only because I was looking for the correct name for “ice boat” in French in the idea to start a French article about it. What are the best way to handle situations like this? Make interwiki links to redirections? (currently the case for the English wiki, with the Wikidata entry for the sport linking to the redirect page “ice sailing” that goes to “ice boat”) — but I highly doubt that’s good practice. Nclm (talk) 22:09, 8 February 2021 (UTC)

I have a sneaking suspicion a special property "cross-wiki equivalent" is the only way to properly deal with such cases when different sets of wikis use a different wikidata concept for what are essentially equivalent pages. Circeus (talk) 19:32, 12 February 2021 (UTC)

Project Grant Proposals for the Performing Arts Domain

This is to notify the community that two Wikimedia Foundation project grant proposals related to the performing arts are currently under review.

  • The Canadian Association for the Performing Arts (CAPACOA) and Conseil québécois du théâtre are proposing a second project grant to build a critical mass of performing arts items in Wikidata, and to broaden engagement in Canada and internationally.
  • Aotearoa New Zealand is proposing a project grant to populate performing arts information and content in Wikidata, Wikipedia and Wikimedia Commons.

Please review/comment/endorse these proposals. Fjjulien (talk) 22:32, 11 February 2021 (UTC)

  • What happened to the first grant in the field?
Last year there was a request for $33,500 CAD (see meta:Grants:Project/Fjjulien/Modelling_and_Populating_Performing_Arts_Data_in_Wikidata).
Did this get cancelled due to COVID? --- Jura 08:05, 12 February 2021 (UTC)
Jura1 This first project went ahead with only minor changes, since it was designed to take place almost exclusively online. It received funding from the Wikimedia Foundation, the Canada Council for the Arts and the Government of Quebec. Overall, the project went quite well (see the [meta:Grants:Project/Fjjulien/Modelling_and_Populating_Performing_Arts_Data_in_Wikidata/Midpoint Midpoint Report]). Yet, we are challenged when it comes to uploading datasets of productions, because we are missing a critical mass of production and person items. This is one particular issue we wish to address with the second project. Fjjulien (talk) 15:46, 12 February 2021 (UTC)

How to add about yourself

we want to add us on Wikipedia like others  – The preceding unsigned comment was added by Barkhia International (talk • contribs).

Have a look at Help:Introduction, as well as Wikipedia:COI. --Bender235 (talk) 18:27, 17 February 2021 (UTC)
This section was archived on a request by: —Hasley+ 23:27, 18 February 2021 (UTC)

Call for participants: Let's design a delightful mobile app for Wikidata!

We need a seamlessly working tool that makes editiong a breeze.

I would love to participate in or lead the designing and writing of a kotlin app as a study project. You can join me in realizing this project and learn more about design sprints.

Coding skills are not required. We need testers, project members that help fleshing out a delightful design, etc. The best would actually be multiple design groups that each do a series of design sprints and optimize for a delightful experience for the targeted user group (sv. målgrupp)

Designing a successful app is team effort (can be done using video conferencing). I recommend using design sprint 2.0 and tools like Miro (useful for storyboarding, crazy 8s image uploads, and silent art museum) and Figma (prototyping).

I recently created Design Sprint 2.0 (Q105078321) to describe the process in detail. If anyone is interested in joining me in creating a succesful app that is a delight to use, feel free to contact me.

There is a WMF call for grant applications that end Feb 10, eight days from now.

Together we can move mountains, alone everything is a struggle uphill 😉--So9q (talk) 03:55, 2 February 2021 (UTC)

Why Kotlin? Flutter would produce an App that can be used outside of Android whether or iOS or the PC. ChristianKl14:38, 2 February 2021 (UTC)
Good point! Do you know how to program? Wanna join?--So9q (talk) 16:46, 3 February 2021 (UTC)
We are now 3 in the group. Please spread the word, to your dog and grandma. 😃 Join us at [14]. We don't bite and you can be sure to learn something about design sprints and geek stuff.--So9q (talk) 06:58, 4 February 2021 (UTC)
The group is growing, feel free to join if you want to contribute to realizing the goal. We value both small and big contributions. We will soon begin drafting the Grant Application (deadline in March). Paid work is possible depending on the Grant Committees decision.
Currently editing of statements from m.wikidata.org is not possible. That's bad and hindering a lot of users who don't have a PC from editing and contributing. Mobile is the most widespread computing device in the world. I believe editing on the go is the way to move forward, just look at how many valuable edits are made to other WMF projects from mobile.
Since Wikidata is now about to turn 10 years and no one even tried building a mobile App (except the GTK-powered Daty, which might work on Android phones also, but it's not finished and work has stalled) I find it likely that the WMF is going to support this project generously if they like our application and believe we can pull it off. Let's get together and start working. Please join us today [15] and introduce yourself and the skills you bring to the table.--So9q (talk) 07:21, 5 February 2021 (UTC)
I'm not a coder, but I'd be willing to test such an app as an editor. UWashPrincipalCataloger (talk) 19:55, 5 February 2021 (UTC)
As the sole developer of the only available mobile Wikidata app, of course I am in. Ogoorcs (talk) 21:47, 7 February 2021 (UTC)
@UWashPrincipalCataloger: big thanks 😃 we are now 15 members in the team and there is still a possibility to join. I would like to start working on a grant application soon, so if any of you reading this want to help on that or any of our other tasks, please join the group. If you are not willing to join because of Telegram, let me know.--So9q (talk) 08:07, 13 February 2021 (UTC)

Freebase (bis)

In recent weeks, the number of items with Freebase ID (P646) increased from ca. 1.3 million to 4.2 million (thanks to @Lockal:).

Is there way to make use of it to import more data from the last Freebase data exports? --- Jura 08:07, 9 February 2021 (UTC)

There are quality and licensing questions for Freebase. CC-BY is not compatible with CC0. So if you find a sequence of facts, which are correct (in some jurisdictions even trivial facts), you can not just "take and copy" them to Wikidata as a due to database rights. However, what you can do is analyse the provenance statements from Freebase and recollect data from the original source. For example, if you have a list of IMDB ids not present in Wikidata (for example, from https://mix-n-match.toolforge.org/?#/list/2709/unmatched), you can use Freebase dump as additional source for matching. Previously there was a Wikidata:Primary sources tool which did a similar thing, but it is defunct now (see https://phabricator.wikimedia.org/tag/wikidata-primary-sources/, also @Tpt:) --Lockal (talk) 08:50, 9 February 2021 (UTC)
To ingest data into PrimarySources we used a 4.4M links mapping. However we have not uploaded it into Wikidata because we considered that its quality was not good enough (there were quite a lot of mistakes in it). It was mostly based on shared identifiers (a Wikipedia article, an OpenLibrary id...). We also considered using "functional" relations but it did not gave us good results (a lot of errors for a few new good matches). About licensing problems, Google agreed to release the data mapped from Wikidata in the CC0 license. I have build freebase.toolforge.org to be able to patrol Freebase id changes after the death of freebase.com, if someone wants to improve it by also presenting the other Freebase facts, it would be much welcomed. The source code is here. Tpt (talk) 14:19, 13 February 2021 (UTC)

Short URL link

If a SPARQL query is run you can create a "Short URL to result". Is the link persistent or time-limited? If I make a small change to the query will it create a new short URL?--Wolbo (talk) 13:15, 6 February 2021 (UTC)

Persistent. The short URL links to the query URL as it was at the time you caused the creation of the short URL. Changes made to the query after causing the short URL to be created, will not be found if the short URL is used. Neither is a new short URL created automatically in such circumstances, unless you go through the process of causing a new short URL to be created. --Tagishsimon (talk) 13:20, 6 February 2021 (UTC)
That's good to know, thanks. Two follow-up questions. It seems the variable part of the URL is only the three characters after https://w.wiki/ eg https://w.wiki/y2U. With all those queries run (must surely be millions) how does the URL link stay unique? Also it seems the URL link defaults to the table view of the query result. Is it possible to create a direct URL link to e.g. the timeline or map view of a query? --Wolbo (talk) 13:45, 6 February 2021 (UTC)
As to the first, short URLs are created (in WDQS) only when the user selects Link / Short URL to result. As to the second, you can create a short URL for any wikimedia URL at https://meta.wikimedia.org/wiki/Special:UrlShortener - and there is more info on the service at https://meta.wikimedia.org/wiki/Wikimedia_URL_Shortener ... so you could copy the URL of a WDQS query such that you're taken to the WDQS UI or - I presume - to a timeline or other specific visualiation. I think the salient difference is the embed.html part of the URL - which takes you to the result, versus no embed.html which takes you to the WDQS UI.
Thanks again, will have a look. One of the nice aspects of wiki is that if you don't know something there is always someone else who does.--Wolbo (talk) 14:13, 6 February 2021 (UTC)
@Wolbo: For the other part of your question, you can change the target by using the #defaultView... code in the query itself; eg this query (result) will default to showing images, while this one (result) will show the normal table view. Andrew Gray (talk) 22:30, 9 February 2021 (UTC)
Andrew Gray, that's also useful as well as easy. Thanks.--Wolbo (talk) 17:31, 13 February 2021 (UTC)

Wrong Freebase and Google Knowledge Graph IDs in song items

Hi, I've recently noticed Lockal adding Google Knowledge Graph IDs to items. He seems to be using a tool named Machine-Readable Entity IDs resolver.

The problem is that the tool doesn't seem to work properly for songs. Like, here's one of his edits. If you click on the resulting link, you'll get

I've also corrected a number of Freebase ID added by Legobot back in 2013. They also have the same problem:

I've already went through the band's songs and I've found out that two-thirds or even three-fourths had incorrect IDs.

Please forward this message to the right place. --Moscow Connection (talk) 07:50, 12 February 2021 (UTC)

@Moscow Connection: Hi, actually I believe all my edits are correct, but there is an issue on Google search side (not even on Google Knowledge Graph) in calculation of full-text-search string.
  1. Bim bam toi (Q78291625)
    • My suggestion: /g/11j47tw9gd - instance of MusicComposition, associated with 3 Wikipedia articles, as English Wikipedia says, "Bim bam toi" (English: Bim bam you) is a song by Carla that served as France's entry in the Junior Eurovision Song Contest 2019.
    • Your suggestion: /g/11h7qp94y2 - Junior Eurovision Song Contest 2019 entry, which uses this song.
  2. Aitai Lonely Christmas (Q2828814)
    • My suggestion: /m/0gxzy0j - instance of MusicComposition, associated with 7 Wikipedia articles, "Aitai Lonely Christmas" is the 14th major single by the Japanese idol group Cute, released on December 1, 2010 on the Zetima label.
    • Your suggestion: /g/11b7qbt1g2 - instance of MusicAlbum, name of Album by Cute
  3. Sekaiichi Happy na Onna no Ko (Q1106992)
    • My suggestion: /m/0h3wk7d - instance of MusicComposition, associated with 7 Wikipedia articles, "Sekaiichi Happy na Onna no Ko" is the 17th major single by the Japanese idol group Cute, released in Japan on September 7, 2011 on the Zetima label.
    • Your suggestion: /m/0np7b9d - instance of MusicAlbum, name of Album by Cute, named as "Aitai Lonely Christmas", associated with Apple Music album.
So what I want to say, you need a lot of luck to actually find a mistake in this import. The most common case of issues with misassociated ids occur when Wikipedia describes multiple different thing in a single article. Japanese wiki does this a lot. For example, pages describing manga series, anime series, dorama-movies and so on - in a single article with multiple infoboxes. A huge pain for Wikidata. --Lockal (talk) 09:18, 12 February 2021 (UTC)
What's strange is that the item didn't even mention Tsunku back then. - well, of course Google is not a Wikidata mirror (even though they parse Wikidata too), of course they have their own parsers for automated fact extraction from human-readable texts (in this case, maybe from Wikipedia). --Lockal (talk) 09:26, 12 February 2021 (UTC)
  • @Lockal: Thank you for the explanation! --Moscow Connection (talk) 21:16, 12 February 2021 (UTC)
  • I have some questions and a proposal.
    1. What is a "MusicComposition"? The music part of a song, its melody? Not a complete song? Why does Google put the composer's name into the search string? Maybe since Google processes "compositions" in such a strange way, it is better to choose some other database entries to connect Wikidata items to.
    2. As I understood from en:"Google Knowledge Graph", the purpose of having these IDs in Wikidata items is to put a link to the Wikipedia article into the infobox next to the Google search results. But Google doesn't provide an infobox for "compositions" (whatever a composition is in this context), only for singles. So I think it is advisable to connect Wikipedia items not to "MusicCompositions", but to "MusicAlbums". I do understand this can only be done for those songs that are firmly associated with one performer and whose Wikidata items define them as "singles". Should we maybe ask the tool's creator to fine-tune the tool's behavior for such cases?
  • --Moscow Connection (talk) 21:16, 12 February 2021 (UTC)
  1. @Moscow Connection: MusicComposition is a creative work, which may have composer, firstPerformance, lyricist, lyrics, etc, but no performer. MusicAlbum is a subclass of MusicPlaylist, again, with specific attributes, including byArtist (performer), but no composer. All entities in Google Knowledge base are mapped to schema.org classes. If entity does not match any class, it will be stored as Thing. In case of melodies, it depends on facets; if melody has a composer and musical key, it will be likely treated as MusicalComposition by duck typing. For example, Dies Irae (Q83771) considered as a MusicComposition[16], even though this is much more than just a "Musical work by Thomas of Celano".
    To solve the issue you faced with, there is definitely no need to connect songs with ids of albums. The correct solution is to create separate entities for albums (manually or automatically) and add all album-related identifiers there. If you scroll down Bim bam toi (Q78291625) or Sekaiichi Happy na Onna no Ko (Q1106992), you can see many constrain violations, same item can not have both "MusicBrainz work ID", "MusicBrainz release group ID" and "MusicBrainz recording ID" (and be a "single").
  2. Definitely no (Wikipedia editors will never agree for that and there is no need to), but it works in an opposite direction. After setting a backreference to Google from Wikidata, Google raises confidence value that Wikidata entry is related to specific cluster of pages, so Wikidata is boosted in specific search queries (and deboosted in irrelevant queries). Also Google Knowledge base is surprisingly good in finding duplicate entries in Wikidata (because their parser can extract facts from Wikipedia texts, not just infoboxes). More reasons are described here.
So the final question: what's going on with the text in search query? I can not say for sure, that it's a bug. I would rather call it "a strange implementation". This text is a result of fixing Spoofing Google Search results problem. Previously it was possible to set an arbitrary text there. After few people abused it, the behaviour changed, so that this field is filled by "some text, strongly associated with entity". Googlebot associates all indexed pages and images with Machine Readable Entity ID (a.k.a. MREID or kgmid parameter in Google Search). When kgmid parameter is used, associated pages are boosted in results. After directly connected entries, Google fills search results with simple full-text search results by text from this field. Due to the reasons I wrote in #1, for albums Google sets search string to "Performer WorkName", for compositions "Composer WorkName". --Lockal (talk) 16:54, 13 February 2021 (UTC)

I'm logged in, but...

This edit was attributed to my IP address. What gives? - Jmabel (talk) 20:12, 13 February 2021 (UTC)

How to prevent Maria column from being classified as a process?

Marian Column in Kłodzko (Q3894014) is marked as Maria column (Q2713614) what makes sense.


Maria column (Q2713614) is subclass of Marian and Holy Trinity column (Q1549521), subclass of sacred architecture (Q47848), subclass of religious art (Q2864737), subclass of art (Q735), subclass of process (Q3249551)

As Marian Column in Kłodzko (Q3894014) is not a process, it means that something went wrong. How it may be fixed? Mateusz Konieczny (talk) 08:18, 12 February 2021 (UTC)

  • And again:
  en: sculpture of Jesus Christ [17]
  en: religious sculpture (genre of sculpture with religious themes) [18]
   en: religious art (art that is religious in theme) [19]
    en: art (expressive work intended to be appreciated for its beauty or emotional power; or the process of creating such a work) [20]
     en: process (series of events which occur over an extended period of time) [21]

I tried to edit "religious art" but it was reverted reverted. I tried to write to that editor, I will also try to revert that revert with pointer here. But I think that I will also start aggressively blacklisting broken wikidata items rather than trying to fix them - I am not really sure which parts are broken and I feel like I am just poking randomly at things Mateusz Konieczny (talk) 14:23, 14 February 2021 (UTC)

Religious art is an art genre, just like rock music (Q11399) is an instance of a music genre (Q188451) so please stop breaking it. Multichill (talk) 14:39, 14 February 2021 (UTC)
@Multichill: The question is about sacred architecture (Q47848) is that a subclass and/or an instance of "art genre" and/or "religious art". --- Jura 14:48, 14 February 2021 (UTC)

New video about Wikidata available

I can highly recommend this video by Markus Krötzsch which put Wikidata into perspective and tells the story about how it came about and how surprised he is with the success of it. \o/--So9q (talk) 13:10, 14 February 2021 (UTC)

Diversity on Wikidata

Hello, i have been asked wether there has been suties and / or reflection about gender gap on wikidata (more on the aspect of representation within contributors of women and minorities). Do we have data or is there a project page and research on the subject? Kind regards, --Nattes à chat (talk) 07:58, 12 February 2021 (UTC)

It is interesting that this does not interest the wikidata community, (apart from the francophone chat where I asked the same question Topic:W39jqb0ubkyp46br ). I think we never quesitonned that aspect on wikidata, considering that technicity primed over other matters. However, reading at the moment a book called Hacking Diversity upon suggestion from a wikidata contributor, it occurred to me that the book was evoking the lack of social analysis in FLOSS communities, which tend to have a hands on culture of DIY to solve practical technical probblems. Now a european study accordiong to the book in 2006 showed a percentage of 2% of women in OSS communities, wheras at the same time in the proprietary sowtware development this percentage was 28%. It occurred to me that I had never seen the quesition adressed on wikidata, although it has been extensively adressed, mentionned and questionned on Wikipedia. Nattes à chat (talk) 21:38, 12 February 2021 (UTC)
How do you know that "[diversity] does not interest the wikidata community"? It interests me. Honestly I met very few women in my life who were interested in technical subjects and who was willing to dedicate unpaid spare time on it. Have you tried inviting your female friends to join? How did it go? There might be a steep learning curve. I have used at least 1000 hours in here to get a solid grasp on most of the stuff going on. That's not necessary to start editing, but understanding the difference between P31 P279 and "facet of" might take longer than you expect.--So9q (talk) 19:07, 14 February 2021 (UTC)
If you look a few topics up, you'll find Request for feedback on CentralNotice banner for Wikidata user diversity survey. --Shinnin (talk) 22:01, 12 February 2021 (UTC)

Ellipsis

In quotations and title, should we be standardized on three periods ASCI "..." or the Unicode "…". I noticed recently that Google Chrome is suggesting the Unicode version as I type. It makes the difference between finding a title or quotation, or not finding it. They display identically, but control-F will only find the specific one. --RAN (talk) 18:57, 12 February 2021 (UTC)

I think it depends on the language and maybe the discipline. It would be safe to follow sources even if that means inconsistency. In English they might look practically the same, but in Japanese, the most common ellipsis in print is the middle-positioned one unless you are quoting something in Latin letters, although confusingly the middle-positioned ellipsis is commonly encoded as the horizontal ellipsis "…" (U+2026) which seems ambiguous about its vertical position and its position can vary between fonts. There is the Unicode codepoint for the middle positioned ellipsis "⋯" (U+22EF), but I have not seen it often. (Is it used in math?) whym (talk) 11:58, 13 February 2021 (UTC)
How do you know it makes a difference for finding it? If it does it seems to me like a programming error of not normalizing. ChristianKl19:33, 14 February 2021 (UTC)

RfC on new QuickStatements like tool written in Python

See https://www.wikidata.org/wiki/User:So9q/Tool_ideas/ImproveWikidata and please comment below.--So9q (talk) 13:11, 14 February 2021 (UTC)

It's not really an RfC. You've written some code. And? What exactly do you want? What is your proposal? --Tagishsimon (talk) 15:51, 14 February 2021 (UTC)
Looks more like an advanced version of {{Autofix}}, but don't understand the necessity of labels in JSON. Why can't they be fetched dynamically (when needed)? Also, I have a big fear of tools, which don't document conflict-resolution behavior, i. e. what will happen, when statement already exists? Will it add a duplicate, modify qualifiers? What if existing statement was deprecated? --Lockal (talk) 16:43, 14 February 2021 (UTC)
+1 to this. I also left some comments on the page's talk page. BrokenSegue (talk) 17:06, 14 February 2021 (UTC)

Genetics merge?

SLC45A2 (Q18040047) and Membrane-associated transporter protein (Q21149743) seem to be the same thing. I'm not quite familiar enough with genetics to call it though so I'm hoping others will weigh in and clarify the matter one way or another. --Pitke (talk) 17:08, 14 February 2021 (UTC)

They're distinct. One is about a protein, the other is about the gene that encodes it. They are different object, but typically treated as one in most wikipedia projects. The confusion comes from them sharing the same abbreviation. Circeus (talk) 18:26, 14 February 2021 (UTC)

Tagging ruins/remains left after object

There may be an object that is

How one may distinguish this cases in Wikidata?

See also case of https://www.wikidata.org/wiki/Q7341 where "instance of" has "end time" qualifier, what may seem to work.

But is inception (P571) and dissolved, abolished or demolished date (P576) supposed to be applying to the entire feature? Main part of it? Any "instance of" unless there is time qualifier overriding it?

I want some way to detect objects no longer existing. And right now Buildwas Abbey (Q1003041) linked from OpenStreetMap is marked as nonexisting, despite that it has existing ruins what confuses my validator. And I see no good and clear way to specify that this object has existing ruins that are clearly present.

See https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2017/09#How_can_I_note_that_object_is_%22dissolved%2C_abolished_or_demolished%22_but_it_is_not_demolished%3F for discussion from 2017.

Mateusz Konieczny (talk) 08:29, 13 February 2021 (UTC)

I think maybe there should be two items, one as an instance of building, or whatever, and the other as an instance of ruins. Ghouston (talk) 08:42, 13 February 2021 (UTC)
See state of conservation (P5816). Thierry Caro (talk) 10:46, 13 February 2021 (UTC)
Yes, state of conservation (P5816) is the right way to do it:
Ayack (talk) 11:24, 13 February 2021 (UTC)
How might destroyed building or structure (Q19860854) play into it? Circeus (talk) 15:45, 13 February 2021 (UTC)
destroyed building or structure (Q19860854) describes the subject and might be used as an instance of (P31) value. demolished or destroyed (Q56556915) refers to the state of conservation of the subject and is used as a state of conservation (P5816) value. --Tagishsimon (talk) 16:37, 13 February 2021 (UTC)
Personally, I think that destroyed building or structure (Q19860854) should never be used as an instance of (P31) value. instance of (P31) describes the nature of the item, not its state of conservation. A ruined church, is a church in a ruined state. Ruined is an attribute of the item, not its nature. Ayack (talk) 17:26, 13 February 2021 (UTC)
I don't like instances of "former" items, but a ruin generally wouldn't seem like an instance of any kind of building, either. Ghouston (talk) 22:25, 13 February 2021 (UTC)
@Ayack: then you're probably fighting a uphill battle. Circeus (talk) 18:17, 14 February 2021 (UTC)
A couple of other discussions I remember: Wikidata:Project_chat/Archive/2019/06#Earthquake_damage, and Wikidata:Project_chat/Archive/2019/04#Classes_for_defunct_entities. Ghouston (talk) 01:18, 15 February 2021 (UTC)

Russian Игорь (pronounced as [ˈiɡərʲ], usually transliterated as Igor), Ukrainian Ігор (pronounced as [ˈiɦɔr], usually transliterated as Ihor) and Belarusian Ігар (pronounced as [ˈiɣar], usually transliterated as Ihar) descend from the same Kyivan Rus name (of Scandinavian origin, but this doesn't matter here).

The important thing is that while these words are pronounced differently and even transliterated into English differently, never-the-less Russians, Ukrainians and Belorussians usually don't threat them as distinct names: a Russian with the name Игорь will be referred to as Ігор from within Ukrainian speech/text and as Ігар from within Belarusian speech/texts; similarly a Ukrainian with the name Ігор will be referred to as Игорь/Ігар in Russian/Belarusian speech/texts; and so on (and, of course, common historic figures like Igor of Kiev are also referred by Russians, Ukrainians and Belarusians with the different name forms).

In Wikipedias, the current state is:

So, in what direction should we move:

I personally prefer B, but it will need agreement with German, Czech, Finnish, Dutch and Polish Wikipedia communities. Sasha1024 (talk) 10:10, 13 February 2021 (UTC)

  • Not sure if Wikidata is the place to this discuss the edition of encyclopaedia articles. Generally, one would do that at the corresponding Wikipedia. At Wikidata, we usually sort out to which items to add corresponding interwikis. --- Jura 10:27, 13 February 2021 (UTC)

Below a list of items related to the above with their English descriptions. First and last items are for Latin script names.

Please avoid merging them. 11:07, 13 February 2021 (UTC)--- Jura

Jura, IMHO, it would be nice if, when visiting Wikipedia article (e.g. uk:Ігор), user sees as much interwikis as possible. Currently uk:Ігор, ru:Игорь and en:Igor (given name aren't linked, which looks unexpected for me as a user. I understand that there may be some obstacles for interwiki-linking uk:Ігор to either of the other two (and that's what my question is about), but I don't understand what prevents interwiki-linking ru:Игорь to en:Igor (given name. Sasha1024 (talk) 13:26, 13 February 2021 (UTC)
Nothing prevents making that interwiki provided you use old style interwikis : https://meta.wikimedia.org/wiki/Help:Interwiki_linking#Interlanguage_links potentially calculated by a lua module, join WD:XLINK if you are interested, a sleepy project in search for attention.
But language links on Wikidata should be restricted to exact matches, and arguably when a name is incorporated in a foreign language, it become something different. Closely linked and derived, but different nonetheless. author  TomT0m / talk page 13:38, 13 February 2021 (UTC)
BTW @Sasha1024: I forgot to mention: talk pages of given names already have such links: sample at Talk:Q26214577 --- Jura 14:09, 14 February 2021 (UTC)
Wikidata needs to deal somehow with fact that for some it is the same, for some different, for other "different name, but in the same group/series". Neither "it is a single name" nor "separate names" really works. Mateusz Konieczny (talk) 14:27, 14 February 2021 (UTC)
What use do you have in mind that the current approach can't handle? --- Jura 19:54, 14 February 2021 (UTC)
Current is fine (may add some statements about linkage between entries) but merge would be problematic for some. In other words, I am against the merge Mateusz Konieczny (talk) 08:11, 15 February 2021 (UTC)

Guidelines and compensation for UX research lead by Wikimedia Germany

Hello all,

As you may know, the User Experience team in Wikimedia Germany’s software department regularly conducts user research, surveys and interviews for the projects we develop: not only Wikidata’s software and infrastructure, but also the German Wikipedia’s Technical Wishes project.

Starting in February 2021, we will be making some improvements in our UX research processes; we’ve documented the details on this page. This includes the details and conditions for the how and why of participating in UX research, our technical and language requirements, and of the nominal compensation we provide to people who participate in research that requires significant time and involvement from its participants.

By offering compensation, common practice in the UX research field, we hope to achieve more diversity among participants and to open participation to people who cannot easily dedicate time in addition to their volunteer activities. Compensation will be optional, in the form of a gift card whose value of which will vary depending on the participant’s country. It applies only to specific types of activity (long interviews and surveys organized by our UX researchers) and does not include informal discussions online or offline nor giving feedback on mockups and new features.

You can read more details about how we plan to implement this compensation here. We have tried to be as transparent as possible, while retaining some flexibility if you have any questions, or if you find something unclear, feel free to reach out to us on this talk page.

Cheers, Lea Lacroix (WMDE) (talk) 16:54, 15 February 2021 (UTC)

Wikidata weekly summary #455

Where can I ask questions about Lua in Wikidata ?

Is there a technical project in wikidata to ask questions about technical use of Lua in Wikidata ? PAC2 (talk) 21:41, 15 February 2021 (UTC)

I think not. There is Help:Lua but it looks more like a disambiguation page. If you have a question/problem with a specific module, you can write to its talk page. Otherwise just ask here. --Matěj Suchánek (talk) 10:19, 16 February 2021 (UTC)
I think mw:Extension:Wikibase Client/Lua is the only help page. For instance, at Wikimedia Commons and on German Wikivoyage Lua scripting for Wikidata data retrieval is widely used. So you can surely ask for help there. --RolandUnger (talk) 16:38, 16 February 2021 (UTC)

How to encode has-MAC-address ?

Hi, I was wondering how I can use wikidata to encode a statment like: "machine a has a Mac Address xzy". I cannot find a wikidata property for the hasMacAddress relation. Can https://www.wikidata.org/wiki/Q20484 be used as a property? Or MAC address wiki page should really be a property instead of item? Liao (talk) 00:06, 16 February 2021 (UTC)

I don't think there's any property for it, nor for other network addresses like IPv4 or IPv6 address (although there are some properties for address blocks). I guess there aren't many items in Wikidata for individual devices, so they wouldn't be used much. Ghouston (talk) 00:56, 16 February 2021 (UTC)
For what items do you believe such a property would be valuable? ChristianKl11:55, 16 February 2021 (UTC)

How to indicate citizenship as a result of parent's citizenship

For example Christian Wolanin is a dual citizen of Canada and the United States. He holds Canadian citizenship due to his place of birth, which can be indicated by Has cause=birthplace. He holds American citizenship due to being the child of American citizens. How do I indicate this ? I don't know of a relevant item to select. CanadianCodhead (talk) 18:38, 16 February 2021 (UTC)

Perhaps you could use descent (Q89659343) as has cause (P828). --Gymnicus (talk) 18:43, 16 February 2021 (UTC)
jus sanguinis (Q333015) is the technical term, like on Andy Ruiz Jr. (Q4761262). You could perhaps use based on heuristic (P887) and some suitable value as a reference, if you don't have a reference, and if the citizenship is granted automatically in this situation. Ghouston (talk) 22:58, 16 February 2021 (UTC)

Collage as main image?

I was trying to edit Q3711 (Belgrade). I'm just beginning with Wikidata, so I may not understand some things. I can't edit, because page is semi protected. Main image right now is a collage/montage. As I understand, we now have a separate property for collage images collage image (P2716). My suggestion for main image or aerial view property: 040 Belgrade, Serbia.jpg. I posted more or less the same issue on Belgrade talk. Tupungato (talk) 16:52, 16 February 2021 (UTC)

@Tupungato:   Done. {{u|Sdkb}}talk 05:25, 17 February 2021 (UTC)

Register databases with incompatible licenses

Hi. I have been looking around the internet for non-copyrighted or CC0 information to include in WD. More often than not I meet weird home-made licenses like this one from Eurostat:

"Eurostat has a policy of encouraging free re-use of its data, both for non-commercial and commercial purposes. All statistical data, metadata, content of web pages or other dissemination tools, official publications and other documents published on its website, with the exceptions listed below, can be reused without any payment or written licence provided that:

  1. the source is indicated as Eurostat;
  2. when re-use involves modifications to the data or text, this must be stated clearly to the end user of the information."[22]

I would like to somehow have some kind of overview over how many government databases that are still locking away their data behind these kind of policies. I would also very much like WMF to lobby for opening up all this information for use in Wikidata.

I see this as a result of bad or dated leadership decisions around sharing of data and in this particular case it goes against other policies that the EU commission seem to have regarding open data.

WDYT? Is a wikipage suitable to collect this data on? How do we best push for open data from the UN Statistics (home-made license), EU (home-made license) and other governmental agencies?---So9q (talk) 22:46, 16 February 2021 (UTC)

seems like making items for the databases and tagging them with a license would make sense. BrokenSegue (talk) 12:45, 17 February 2021 (UTC)
👍 US census has the same home made license problem, see [23]. I'm pretty sure this is a widespread problem based on this little sample investigation. How do we model the home made licensing with a Qid? A new qid called "custom CC-BY like license"?--So9q (talk) 14:41, 17 February 2021 (UTC)
In my opinion (may differ from WMDE), replication of tabular governmental datasets is out of scope for Wikidata. There are 2 better ways to pull such data for reuse:
--Lockal (talk) 15:04, 17 February 2021 (UTC)

British and Canadian English

Why British and Canadian English labels often are capitalised while standard English isn't? Eurohunter (talk) 05:08, 17 February 2021 (UTC)

You'd probably have to look at the history and ask whoever set them. I don't think those labels should even be set when they are identical to "en". Ghouston (talk) 06:14, 17 February 2021 (UTC)
Didn't you ask the same question a while back? --- Jura 06:17, 17 February 2021 (UTC)
I think the reason is that they were set years ago, before the capitalization convention was well established [24]. Then somebody fixed the "en" label, but didn't notice or bother with the others. This is why it's better not to set en-gb and en-ca when they are identical to en, since they don't get updated. Ghouston (talk) 06:19, 17 February 2021 (UTC)
Thanks. @Jura1: Probably yes but if I'm asking again then probably I had no answer there. Eurohunter (talk) 18:01, 17 February 2021 (UTC)

Serbian language

I just noticed Serbian has now 4 variants in Wikidata.

Cyrillic alphabet Ekavian (sr-Cyrl-ekavsk)
Latin alphabet Ekavian (sr-Latn-ekavsk)
Cyrillic alphabet Ijekavian (sr-Cyrl-ijekavsk)
Latin alphabet Ijekavian (sr-Latn-ijekavsk)

Which one is the version used on Serbian language ekavsk or ijekavsk? Eurohunter (talk) 18:05, 17 February 2021 (UTC)

Bug generating URLs for an identifier

I found a parsing bug in the identifier’s formatter URL containing backslashes, in Internet Encyclopedia of Ukraine ID (P9070). Please comment at Property talk:P9070#Backslash decoding problem. —Michael Z. 20:44, 17 February 2021 (UTC)

Uploading of 28 thousand items of Brazilian laws and decree-laws

 

Hello everyone! Continuing the activities of the WikiProject Brazilian Laws, a project started in the context of a grant from WikiCite, we plan start uploading the items of Brazilian decree-laws and laws, scrapped from the government websites that maintain them and wikidatified, this coming Friday. As there will be a large volume of entities created (around 28 thousand), I thought it is correct to make this announcement and also to invite the community to participate in this project. Good contributions, Ederporto (talk) 22:52, 17 February 2021 (UTC)

I clearly missed a trick or two when uploading >100k UK laws a few months ago & >2k per month thereafter. Good luck anyway. --Tagishsimon (talk) 22:56, 17 February 2021 (UTC)

Redirects

When it will be possible to add redirects without removing them at Wikipedia page? Eurohunter (talk) 13:45, 4 February 2021 (UTC)

It would be useful to get an update on progress on redirects as sitelinks. Perhaps @Mohammed Sadat (WMDE): can help? I think the three main issues are, 1) when can we expect to be able to add redirects as sitelinks, exactly as we now add sitelinks to article & other such pages; 2) how exactly will redirect sitelinks be differentiated from non-redirect sitelinks in the user interface and via WDQS; 3) will such differentiation depend on the user (e.g. badging the sitelink) or on the system recognising that the sitelink is to a redirect. And, of course, 4) when? --Tagishsimon (talk) 14:18, 4 February 2021 (UTC)
@Mohammed Sadat (WMDE): Anything? --Tagishsimon (talk) 17:40, 7 February 2021 (UTC)
@Tagishsimon, Eurohunter: Thanks for poking us about this. In order to move forward about the next steps, I'll let Lydia expand on the options that we discussed earlier. -Mohammed Sadat (WMDE) (talk) 16:29, 8 February 2021 (UTC)
@Mohammed Sadat (WMDE): Thanks Mohammed. Is that explaination likely to occur anytime soon? Forgive me if I don't think it is unreasonable to press the question of exactly what on earth is happening, or is not happening, in this currently suboptimal area of wikidata. --Tagishsimon (talk) 18:08, 14 February 2021 (UTC)
@Tagishsimon: Sorry. That's on me. Mohammed has been poking me but I've just had too many things on my plate :( (I'll get some more product management support soon so things should get better.)
As for the redirect work. I've talked through various options with one of the developers and I think we've found one that's acceptable to everyone and hopefully technically doable. He explained it in phab:T235420#6818155. It basically boils down to making it possible to link to redirects if the sitelink has a badge saying it's a redirect. This is now ready for coding and unless anything unforeseen happens it should be ready in the next 4 weeks or so. --Lydia Pintscher (WMDE) (talk) 14:34, 16 February 2021 (UTC)
Excellent news, this is great to hear!!!! ArthurPSmith (talk) 18:34, 18 February 2021 (UTC)

Official guidance for main image of cities/towns/villages

I'm a beginner on Wikidata, so go easy on me ;) I edited some towns and cities. I noticed that quite frequently, there is a collage/montage as main image, property image (P18). I think it is usually imported from other Wikipedia project where it's the main image of the city. We also have a special property dedicated for collages: collage image (P2716). As I understand, Wikidata is all about organized data, and absolute order. Should I therefore, whenever I find a collage image as main image of a city, move it to collage image (P2716), and add a single or a few regular images representative of the city, as main image (P18)? This was clearly done in items that are well maintained here. Examples: Warsaw Q270, Turin Q495, Sydney Q3130.

I tried to do this with Poprad (Q26393), but user Akul59 reverted my edit without explanation, and does not respond in his discussion.--Tupungato (talk) 09:05, 18 February 2021 (UTC)

links to page sections

#Redirects here discusses handling page redirects in WD.

I want to raise a similar question: are there plans or discussions to let WD links point to page sections as opposed to complete pages? Eg I made fuse box (Q105549086) and wanted to link to https://en.wikipedia.org/wiki/Fuse_(electrical)#Fuse_boxes but that's not possible.

This would take care of the problem that different Wikipedias have different ideas or guidelines about item granularity. Eg some Wikipedia has a page "pestle and mortar" whereas others have separate "pestle" and "mortar". This feature would allow the WD item "pestle" to point to "pestle and mortar#pestle" of that Wikipedia.

--Vladimir Alexiev (talk) 12:32, 18 February 2021 (UTC)

@Vladimir Alexiev: This is a long-standing issue here. Wikidata:Sitelinks to redirects discusses current status. The community has long requested developer support to fix this, but it has not been forthcoming, I think due to a philosophical concern with how Wikidata originated to facilitate interwiki linking. ArthurPSmith (talk) 14:07, 18 February 2021 (UTC)
Lydia kindly commented on the current position on sitelinks to redirects, above yesterday. Albeit at the cost of needing to put together on the language wiki a redirect to a page section, the proposed implementation would cater for the Fuse Box issue. --Tagishsimon (talk) 17:31, 18 February 2021 (UTC)
Ah, I should have followed Vladimir Alexiev's link, I completely misread the question. Yes, my feeling was that solving the redirect problem solves this through use of a redirect in the language wiki. ArthurPSmith (talk) 18:35, 18 February 2021 (UTC)

Should these two items be merged?

I'm a new editor on Wikidata and I've come across these two items that seem to be the same thing: Q76475674 & Q77207808. Should they be merged? AndrewRT (talk) 23:25, 18 February 2021 (UTC)

No. One is an item for the work, the other for an edition of the work. Welcome to the Functional Requirements for Bibliographic Records. --Tagishsimon (talk) 00:32, 19 February 2021 (UTC)
Basically, the edition item is a specific distribution of the work, which you'd use as a reference. The "work" item represents all editions. Ghouston (talk) 01:17, 19 February 2021 (UTC)

Standardised Data on Initiatives

main post at WikiProject_Source_MetaData

There's a paper I've been working on with user:JackNunn that's highly relevant to this community: Standardised Data on Initiatives – STARDIT: Beta Version. From the Wikidata point of view, it's a way of getting people to provide standardised metadata on different projects (especially the sorts of metadata that's often omitted). Additional co-authors to the paper are being invited to contribute before it's finally submitted (likely co-submission to Research Involvement and Engagement and also simultaneously published in the WikiJournal of Science). If it's the sort of thing you'd like to pits in on, here's:

Obviously, feel free to share this with anyone else who might be interested in being involved! T.Shafee(evo&evo) (talk) 11:37, 17 February 2021 (UTC)

  • Interesting proposal. Tricky to get all the properties and significant events together.
I copied the mapping to Wikidata_talk:WikiProject_Source_MetaData#Standardised_Data_on_Initiatives. It makes it easier to see which properties are used.
Maybe one or two actual uses could help too.
Just a minor thing: work location (P937) doesn't seem suitable for geographic scope. Maybe we need a new property when location (P276) can't be used. --- Jura 12:14, 17 February 2021 (UTC)
@Jura1: thanks. I've put a few worked examples over at the WikiProject_Source_MetaData talkpage. Good point about when work location (P937)/location (P276) might not cover it. What're your thoughts on whether it's better to broaden the use scope of P937 or propose a separate property? I usually favour broadening existing properties where their usage is unambiguous in the new context, but I'm not expert on property creation! T.Shafee(evo&evo) (talk) 04:20, 18 February 2021 (UTC)
For some it's a sort of a Mantra that there should be only one property for each datatype. What I don't find entirely clear about your proposal (for properties to use) is that I'm not really sure if "initiative" is an activity/project or a publication about such. An activity may well have a location (P276), if it's a paper about an activity, neither property seems close. The same question looms over other parts of the proposal and the three values at Q98539361#P31 seems to mix both. Maybe only research project (Q1298668) should be retained. --- Jura 23:12, 18 February 2021 (UTC)
I see what you're saying. The main aim is to be applicable to any project. The three worked examples in the table above were on the production of academic publications (because there's already quite a bit of metadata about those, so an easy starting point) but a range of other applications are outlined here in Table 1: Example applications of STARDIT (pg 10, line 281). For example, citizen science environmental research projects tracking endangered species numbers would have a range of contributors and outputs, but may not result in an academic publication. I also talked a little about the early planning at the wikicite conference. T.Shafee(evo&evo) (talk) 03:20, 19 February 2021 (UTC)

Supported sport team for death person

It make sense to add supported sports team (P6758) for death persons? --2001:B07:6442:8903:7176:190B:1E0A:CFA4 09:53, 19 February 2021 (UTC)

From my point of view, yes. Information does not disappear after the person dies. As long as the statement supported sports team (P6758) is well documented, it can remain in the data object. --Gymnicus (talk) 10:02, 19 February 2021 (UTC)
If a Wikidata claim doesn't have qualifiers that specify when the claim is true, it means that it was true at least at one point where the subject lived. ChristianKl11:54, 19 February 2021 (UTC)

I wanted to add https://ru.wikipedia.org/wiki/Имя_числительное#Количественное_числительное to https://www.wikidata.org/wiki/Q1329258#sitelinks-wikipedia and it said

A page "https://ru.wikipedia.org/wiki/Имя_числительное#Количественное_числительное" could not be found on "ruwiki".

The external client site "ruwiki" did not provide page information for page "https://ru.wikipedia.org/wiki/Имя_числительное#Количественное_числительное".

What did I do wrong? Moyprofile (talk) 10:01, 19 February 2021 (UTC)

@Moyprofile: you can't link a section as a site link, only the whole page, e.g., https://ru.wikipedia.org/wiki/Имя_числительное. Ghouston (talk) 11:11, 19 February 2021 (UTC)
And don't link the whole URL, just the page name, e.g., Имя числительное. Ghouston (talk) 11:14, 19 February 2021 (UTC)
Site link ruwiki:Имя числительное is already used by item Q63116. Perhaps the items should be merged. Ask at d:Wikidata:Interwiki conflicts if you believe that they should not be merged.
If it's already used by Q63116, then I shouldn't add the Russian version or it's a conflict? What is meant by "conflict" here? Moyprofile (talk) 14:28, 19 February 2021 (UTC)
Нельзя добавить секцию, можно только всю страницу. В принципе, можно создать перенаправление на секцию, тогда скоро можно будет добавить его (пока нельзя, но обещали такую функциональность примерно через месяц). Ну, или напишите отдельную статью о количественных числительных.--Ymblanter (talk) 20:13, 19 February 2021 (UTC)
I believe it can be done 1) create a more-or-less empty page on the Russian Wikipedia with the title you want 2) add it to Wikidata as the sitelink 3) convert the page to a redirection to the relevant section. Ghouston (talk) 21:33, 19 February 2021 (UTC)
Yes, indeed, creating an artificial redirect works as well. But the subject probably deserves a separate page anyway.--Ymblanter (talk) 23:38, 19 February 2021 (UTC)
Sure, given that quite a few other wikis have already done that. Ghouston (talk) 01:06, 20 February 2021 (UTC)

Invasive to, Endemic to exist - but what about native to

In terms of tracking data on species geographic distribution, there is a 'Invasive to' property (P5588), in its page it demonstrates there is an Endemic to property (P183). Which in turn lists a taxon map property P181 (which is fine but not really something that can be queried) and an Ecoregion property (P1425). But I can't find anything to allow entering the fact that a taxa is natively found in a geopolitical division.

Am I missing it in my searches, or does such a property exist. It seems pretty fundamental, but I'm just not finding it. Ideally there should be some way of being able to track and then in turn query what taxa are found in what nations etc. I seem to remember, but can't find a property that on a geographic item allows you to state a taxa is found there, but that's not practical for nations etc where in biologically diverse areas you could have tens of thousands of native taxa. Surely better to put on the taxa item itself where the list is much more number limited. Thanks CanadianCodhead (talk) 18:17, 19 February 2021 (UTC)

Fusión de 2 páginas de wikidata

En una hay un enlace a wikimedia commons y en la otra una a wikipedia.

 – The preceding unsigned comment was added by Bocampeón (talk • contribs).

  Done @Bocampeón: Lo he hecho. Gracias. Mike Peel (talk) 15:13, 20 February 2021 (UTC)

Spanish question

Heading added afterwards. --Gymnicus (talk) 18:19, 20 February 2021 (UTC)

como entrar un nuevo idioma wikipedia en lengua maya yucateco

publication interval

Hello. Athlitiki (Q105604379).

I have added that publication interval (P2896) -> 1 week. Is there a way to add that the newspaper was published every Monday? Data Gamer play 16:25, 20 February 2021 (UTC)

@Data Gamer: Hello, you can use the property day of regular release (P6437) as qualifier and then use there the object Monday (Q105). --Gymnicus (talk) 17:24, 20 February 2021 (UTC)
Thanks. Data Gamer play 17:26, 20 February 2021 (UTC)

Wiki Weirdness

TP updated between September 2019 and August 2020 (Q98755339) has just shown up on my watchlist as having been edited (diff).

But the edit makes no sense for the item. And no edit seems to have been made to what's actually presented on the item page -- or, at least, no difference is showing there. Has anybody seen any behaviour like this before ? Jheald (talk) 08:07, 20 February 2021 (UTC)

You should expand the languages section. Anonymous user edited "en-gb" language, not "en". Probably without malice, but it does not matter, I reverted it. --Lockal (talk) 08:21, 20 February 2021 (UTC)
 Y Thanks, Lockal -- Jheald (talk) 23:03, 20 February 2021 (UTC)

Consumers Vs. Producers mentality in Mobile "Vs." Desktop

There is currently no way of directly creating a new Wikidata item when in "Mobile view".

When I wanted to create a new item in "Mobile view" I had to first click "Desktop mode" (1 click), then "Create a new item" (2 clicks), and then "Mobile view" (3 clicks). So I had to exit mobile and go back to mobile for something "desktop" users immediately have in a single click. I think that the software developers behind the "Mobile view" likely see mobile users as "consumers" (people that mostly read) rather than "prosumers" (producers, or people that edit a lot + consumers) as "desktop" users are seen.

As we live in a time where more Mobile computers exist than desktop computers it might be wise to add more "producer" options to the "mobile mode".

For clarification, I propose that there should be option where we would essentially get the full "desktop experience" in "mobile mode", as the current options are simply too limited. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 20:35, 9 February 2021 (UTC)

I have to say it's always seemed very strange to me that Wikidata isn't editable on mobile, when entering small atomic data items with auto-complete is something very well suited to a mobile interface, much more so that tapping out encyclopedia articles, books or transcriptions. Inductiveload (talk) 23:49, 9 February 2021 (UTC)
Exactly, but how can we change it or at least make it optional? I don't think that there are any technical limitations (someone please correct me if I'm wrong) in the mobile interface that makes this impossible, this seems more like a symptom of a larger Wikimedian Zeitgeist that sees "the mobile mode" for content consumption rather than content creation. Should I address this at the Phabcricstor or open a Request for Comment? -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 14:03, 16 February 2021 (UTC)
@Donald Trung:I'm not sure it's a mentality issue. WMDE has focus on basic funcionality and the Vue desktop UI, my impression is that they are pretty bogged down with the current bugs and user stories in the backlog. I'm not sure they are gonna prioritize a better working mobile view anytime soon.
I recently started the Wikidata App group and we actually have our first meeting in an hour. Join us on Telegram (see the previous link) and let's find a way forward together. Creating a phab ticket is also a good idea, but you should create one for each missing feature, say one for the missing possibility to edit a current statement, one for the missing possibility to add a value to a current statement and one for the missing ability to add a new statements. :)--So9q (talk) 14:22, 21 February 2021 (UTC)
As an aside Daty (Q60949478) works on GNU/Linux mobile phones like Pinephone and can edit statements. It currently has only one active developer @ogoorcs: and he is looking for more contributors. He is also active in the Wikidata App group and I hope we can find a way forward to get a fully working mobile client that is a delight to use on the go (which the Desktop Vue interface is not IMO).--So9q (talk) 14:28, 21 February 2021 (UTC)

Jan H. Gardner

I noticed that the Wikipedia article for "Jan H. Gardner" was deleted, but we do not have to delete her from Wikidata. How would I find her QID to ask for restoration? --RAN (talk) 00:38, 19 February 2021 (UTC)

An admin may found it at Special:DeletedContributions/Premeditated Chaos (on 8 June 2018).--GZWDer (talk) 07:03, 19 February 2021 (UTC)
I think it was here Jan Hrinya Gardner (Q19866305) Piecesofuk (talk) 10:57, 19 February 2021 (UTC)
I restored it, but please add data to show Wikidata notability. ChristianKl11:53, 19 February 2021 (UTC)
Thanks! She was victim of the purge of all United States county executives, that never held a higher office from English Wikipedia. It is a shame, about 50 were deleted. An equal number of mayors were deleted too. No need to delete them from Wikidata. --RAN (talk) 03:53, 21 February 2021 (UTC)

Help needed (Q1259331#P18)

Hello. I am completely unfamiliar with this project and can't figure out where to ask for the help I need. I've been working on an article in English Wikipedia, and discovered that a picture in Wikipedia Commons needed to be deleted. (The species involved has been split, and another copy of the same picture has already been uploaded to the appropriate category.) However, this same now-mislabeled photo has been assigned to the species here in Wikidata. The file is Q1259331. The picture is of a Sooty Barbet, which has now been split from the Brown Barbet. (The subspecies identifier tells you that.) Can someone please remove the picture from this record? Thanks! MeegsC (talk) 11:54, 20 February 2021 (UTC)

I understand. The former subspecies "Calorhamphus fuliginosus hayii" was upgraded to a separate species "Caloramphus hayii". As a result, the bird that can be seen in the picture is not a representative of the species "Calorhamphus fuliginosus". I removed the picture because there is currently no other picture of a bird of the species "Calorhamphus fuliginosus", which means that the picture is still displayed on Reasonator and in the Wikidata Infobox on Commons, even if it is disapproved of. --Gymnicus (talk) 18:19, 20 February 2021 (UTC)
Thanks very much for your help Gymnicus. I'll try to find a replacement picture! MeegsC (talk) 12:49, 21 February 2021 (UTC)

Instance of high-rise building (Q18142) which was actually never built

I develop an app where buildings missing a image (P18) show up on a map, for volunteer photographers to go and shoot.

Minerva Building (Q1936628) was proposed in 2002, but the project was abandoned in 2006. Of course, I don't want such non-existing buildings to show up in my app.

Question: How should I filter out such items? In other words, what property(ies) should be added to Minerva Building (Q1936628) (and Lothbury tube station (Q6684745))?

Thanks! Syced (talk) 07:13, 21 February 2021 (UTC)

You can use item Q811683#P31 Pmt (talk) 09:10, 21 February 2021 (UTC)
There is a proposed building or structure (Q811683), corresponding to Category:Proposed buildings and structures (Q8797862), but there appears to be no item that corresponds to Category:Unbuilt buildings and structures (Q8863483). There is unfinished building (Q1570262), which seems to be conflating "unfinished" and "unbuilt". Maybe a new "unbuilt building or structure" item would make sense. —Xezbeth (talk) 09:16, 21 February 2021 (UTC)
Commons has a category for that, c:Category:Unbuilt buildings. Ghouston (talk) 20:47, 21 February 2021 (UTC)

Do polymorphic properties exist?

I am new to WikiData, and a ruby developer which may reflect my thought process. I create a proposal here Wikidata:Property proposal/workers represented by and was curious if properties can be polymorphic, meaning this property could be applied to not only company (Q783794) but also university (Q3918) or any other institution that is reasonably construed as a legal organization with employers/employees. And then the second question is, making usage of this. I can see how this would be useful for company (Q783794) entries, and e.g. auto pulling data in w:template:infobox company Shushugah (talk) 11:53, 21 February 2021 (UTC)

Yes, when you have a relationship X P Y, there's no restriction on the types of X and Y; as long as the statement still makes sense. Ghouston (talk) 20:56, 21 February 2021 (UTC)
Well, restrictions on the types can be expressed with constraints that are added to the property, but the default is that anything goes. For the proposed property, you'd probably constrain the items to be instances of organization (Q43229), or any subclass of it. Ghouston (talk) 21:11, 21 February 2021 (UTC)

RfC on the use of P155/P156 as qualifiers on statements, rather than as main statements

Hello everyone,

Back in October I started a thread on this page regarding the use of follows (P155)/followed by (P156) as qualifiers on statements, rather than as statements themselves. In the interest of better formalizing and solidifying discussion around such a shift, I have started a request for comment: P155/P156 as qualifiers only, rather than as main statements. Your statements regarding it are most welcome there.

Thank you. Mahir256 (talk) 05:20, 22 February 2021 (UTC)

Question about getting my bot approved for a task

I'm not sure where best to put this, but my request for permission has been pending for almost a month now and I was wondering what I could do to move it along in this process. In the past, it's usually only taken about a week to gain approval. Thanks, Nicereddy (talk) 05:59, 22 February 2021 (UTC)

Posthumous births

I think there is an issue with one of the constraints. I've just added Wawrzyniec Żuławski (Q2713080) as the child of Jerzy Żuławski (Q1373117). In this case the son was born on 14th Feb, 1916, while his father died on 9th Aug, 1915. This triggered warning caused by contemporary constraint (Q25796498) constraint. As we obviously all know, human pregnancy is usually ca. 9 months long, so it was entirely possible for the child to be born 6 months after the father's death. I think the constraint should be fixed to reflect such situations. Powerek38 (talk) 08:38, 19 February 2021 (UTC)

I support your suggestion. But unfortunately I don't know whether this is currently feasible here in Wikidata and if so, how. --Gymnicus (talk) 09:42, 19 February 2021 (UTC)
One way would be to remove the constraint, since it doesn't seem valid. Ghouston (talk) 11:16, 19 February 2021 (UTC)
The other way is to add another exception to the constraint on father (P22). Ghouston (talk) 11:22, 19 February 2021 (UTC)
@Richard Arthur Norton (1958- ): Yes, I like your idea. But I guess there is a problem with the feasibility here too. I believe that in order to solve this problem, you have to sit down with the developers and work out a possibility. --Gymnicus (talk) 12:35, 21 February 2021 (UTC)
Absolutely! But no one seemed interested last time. Maybe someone can tell us the best way to move forward. Perhaps a Phabricator ticket, since it is a flaw. --RAN (talk) 18:16, 21 February 2021 (UTC)

Merge request

Could somebody please merge Calamagrostis × acutiflora (Q12346033) and Calamagrostis × acutiflora (Q105625531)? I can't ever seem to get the automatic merge to work. Also, shouldn't some sort of alert be given when the item names differ only by a space? Abductive (talk) 13:18, 22 February 2021 (UTC)

Merged. --Tagishsimon (talk) 13:46, 22 February 2021 (UTC)

Scraping RetractionWatch database for retracted papers?

Retraction Watch maintains a fairly large database that connects retracted papers with their retraction notice (or corrections), each uniquely identified by PubMed ID (P698) and/or DOI (P356). Since we have a great many entries of scholarly article (Q13442814), I wondered if we could have a bot scrape this database and add properties such as is retracted by (P5824), as well as amend scholarly article (Q13442814) by retracted paper (Q45182324) where appropriate?

For instance, according to the RetractionWatch database, Collateral sensitivity of multidrug-resistant cells to the orphan drug tiopronin (Q35528557) has been retracted by Retraction of "Collateral Sensitivity of Multidrug-Resistant Cells to the Orphan Drug Tiopronin" (Q89512165). Both entries already existed on Wikidata, and I now connected them by hand, but it would be great if we could have a bot do this on a large scale. Also, current scholarly article (Q13442814) entries that are actually retraction notice (Q7316896) could be fixed in the same going. --Bender235 (talk) 16:55, 17 February 2021 (UTC)

@Bender235, ChristianKl: Sorry, late to the discussion but great questions! I actually made some notes on this over at Wikidata_talk:WikiProject_Source_MetaData#Retracted_articles, where I'd been thinking a bit about this last year but still haven't gotten around to implementing! I'm looking to at least implement a large submission of statements via a quickstatements (using WikidataR in R). I agree a bot to keep updated from various sources would be ideal, though I don't know how to implement bots currently. T.Shafee(evo&evo) (talk) 10:50, 23 February 2021 (UTC)
From what I understand after reading RetractionWatch's database user guide, they don't actually allow webscraping of their database. However, they are willing to hand over a CSV of the database "to scholars, journalists and others." I'm not sure if that would include us. --Bender235 (talk) 15:18, 23 February 2021 (UTC)

cross-wiki issue(or not?) - userpage on Wikidata transcluded from meta-wiki but no working Template:Lexeme

It was suggested to me by billinghurst to ask for help here or somewhere over at the meta-wiki to talk "about what you are trying to achieve". Well I have my userpage on meta-wiki to serve as a global userpage and I had some Lexemes using Wikidata templates(which obviously don't work on meta-wiki but they helped me with the Template:Property there but there is no Template:Lexeme there) I wanted to be displayed on my userpage. I used the Wikidata Template:Lexeme ie. ama/𒂼 (L1) on meta-wiki(but it does not work there as Template:L means something else) as I used to use it on my Wikidata userpage when I still had one. One workaround so that nobody has to do anything is I can create a Wikidata userpage again. Then I can lay this matter to rest and focus on other things. LotsofTheories (talk) 00:35, 22 February 2021 (UTC)

Does anybody mind if I get back my local userpage here on Wikidata? Meta-wiki does not have support for some templates I need that work fine on Wikidata. ChristianKl, I was aware. LotsofTheories (talk) 20:19, 23 February 2021 (UTC)
@LotsofTheories: Once you've created a new user page on Wikidata it will be displayed rather than the one from Meta. --Nw520 (talk) 20:29, 23 February 2021 (UTC)

Modelling of items for datasets ?

Question from twitter [25]:

Does #wikidata have an ontology for datasets, including content creators and curators?

I suggested the following, but I am pretty sure I missed some things (thread, unrolled):

A useful and I think very important point was made back to me, that

For academic (and credible non-academic) reuse of datasets, especially when combining datasets, for analysis and subsequent reference it is crucial to know creator, curator, version number and authoritative repository
Andheb (talk) ElanHR (talk) 10:05, 17 March 2019 (UTC) Jneubert (talk) 20:55, 23 July 2019 (UTC) Daniel Mietchen (talk) 20:47, 26 September 2019 (UTC) Eihel (talk) 11:21, 21 March 2020 (UTC) PAC2 (talk) Blue Rasberry (talk) 20:57, 15 February 2021 (UTC) PKM (talk) 03:29, 23 February 2021 (UTC) KAMEDA, Akihiro (talk) 12:07, 28 June 2021 (UTC) Vladimir Alexiev (talk) 16:58, 12 December 2021 (UTC) Dhx1 (talk) 12:14, 23 September 2022 (UTC) RShigapov (talk) 08:42, 12 June 2023 (UTC)

  Notified participants of WikiProject Datasets

Overall, this does seem rather a fundamental subject, both in its own right, and in its importance for citations.

It did feel that I had to go 'round the houses' a bit to find the information we had. I would have completely forgotten about WikiProject Datasets, and never found its item style-guide if I hadn't chanced to look at data set (Q1172284). And there's probably also more on here, that I never did find? -- Jheald (talk) 09:07, 22 February 2021 (UTC)

Any follow-up to Wikidata_talk:WikiProject_Datasets#Request_for_ontology Jheald (talk) 19:04, 23 February 2021 (UTC)

Recusants

I am torn about modeling recusant (Q105635772): person who refused to attend mandated Anglican services in the period following the English Reformation as occupation (P106) but I'm not sure what else to do with it. Suggestions?

Example: Sir Philip Constable, 1st Baronet. - PKM (talk) 00:00, 23 February 2021 (UTC)

@PKM: Maybe as a quality (Q1207505) for use with has characteristic (P1552)? William Graham (talk) 00:50, 23 February 2021 (UTC)
Or a subclass of (P279) intentional human activity (Q451967). William Graham (talk) 00:52, 23 February 2021 (UTC)
Just repeating my suggestion from elsewhere of political ideology (P1142), which although labelled political ideology also covers just ideology, so you have all your suggestions in the same place.
Returning to note however that recusancy (Q286321) is defined currently as a religious movement so I guess that suggests religion or worldview (P140) as a possibility too (by which I mean if you decide that it's better modelled in some other way then maybe recusancy needs to be altered to match). DrThneed (talk) 02:15, 23 February 2021 (UTC)
@DrThneed: I like “ideology” a lot. And I just added “religious movement” to recusancy today, and I’m not married to it, and I’d be happy to remove it. I’m even considering merging “recusant” and “recusancy” (see Jacobitism (Q212983) as well as Cavalier (Q2284765)). - PKM (talk) 03:45, 23 February 2021 (UTC)
Yes the Jacobite example makes the merge seem sensible to me.DrThneed (talk) 08:22, 23 February 2021 (UTC)
It has been pointed out to me that recusancy was an offense under the law, and that therefore a recusant could be a subclass of "offender". I like this, and I like that we can then say someone was convicted of (P1399) "recusancy", a property which recommends a citation. I have change "recusancy" to both "offense" and "ideology" for now, and linked the main regulatory texts, one of which "defines a recusant as one 'Convicted for not repairing to some Church, Chapel, or usual place of Common Prayer to hear Divine Service there..."' [27] - PKM (talk) 23:28, 23 February 2021 (UTC)

List of links on Modules pages

Pardon me the very basic question: the modules' pages in Wikidata begins with a list of links in a kind of "toolbar". The links are Code | Discussion | Links | Link count and so on. For instance this is visible in Module:Wikitext.
How is this bar generated? Looks it is not part of the module nor of the /doc subpage. Is it an extension doing it?
Thanks in advance --Lucamauri (talk) 11:29, 23 February 2021 (UTC)

https://www.wikidata.org/w/index.php?title=Module:Wikitext&action=info has Template:Module-nav. Not entirely sure which interface message leads it to be displayed. --- Jura 12:08, 23 February 2021 (UTC)
Actually, that template explains it. --- Jura 13:11, 23 February 2021 (UTC)
@Jura1: Thanks a lot for the info and also for reminding me to look at the info page! --Lucamauri (talk) 14:19, 23 February 2021 (UTC)

Best approach to have a desktop app upload changes to Wikidata

Hi all! I'm developing a WikiCite plugin for Zotero. I'm implementing the module that will upload changes to Wikidata (mostly adding "cites work" P2860 statements between already existing Wikidata entitites), and I want to make sure I'm making the best decisions to let users make these changes using their Wikidata accounts. I would appreciate it if you could provide your comments in the OAuth topic I just posted on the project's discussion page. Thank you! --Diegodlh (talk) 20:47, 23 February 2021 (UTC)

Wrong merge

In my opinion, this merge is wrong. The object for a disambiguation page named Čoban from the serbo-croation wikipedia was merged with the object for Shepherd. I don't know how to unmerge. --Senechthon (talk) 22:02, 23 February 2021 (UTC)

Help:Merge#Unmerging tries to explain it. --- Jura 22:35, 23 February 2021 (UTC)
Čoban is shepherd so it is now attached to the correct item. The labels and descriptions "Wikimedia disambiguation page" were incorrect, so no need to undo that part. Looks good now I think. MSGJ (talk) 22:42, 23 February 2021 (UTC)
The question is if the Wikidata items were about the same or not. https://www.wikidata.org/w/index.php?title=Q16109379&oldid=731294639 is about something different than Q81710. --- Jura 22:56, 23 February 2021 (UTC)

Same thing

I brought this up here but I don't think that is a very visible place to have raised the issue. There are three Wikidata items for the results of the Bolivia national football team and, as I'm very new here, I wasn't sure how to go about fixing it. I think the issue has arisen because English Wiki breaks the results lists into separate articles while Spanish, German, Italian and French Wikis keep them as one longer article. I don't know how many Wikidata items this will affect but any help fixing this particular issue would be much appreciated. Stevie fae Scotland (talk) 22:11, 23 February 2021 (UTC)

I've replied there MSGJ (talk) 22:35, 23 February 2021 (UTC)

Wikidata weekly summary #456

"URL" vs "described at URL"

hi, a few days ago @Nw520: added a property constraint on URL (P2699), so I added that to a few dozen of type specimen items that I created for the most part, now I see that Nw520 replaced URL (P2699) by described at URL (P973) for a few items that I had not yet modified . I would like to have a general opinion, it is not a very serious problem, it is just that I worked to add the URLs, and then I worked again to add the qualifiers when it has becomed mandatory, and now I wonder if I (or we) have to replace all that I have done. No problem but I just want to be sure of what I have to use for that we can work toward the same direction. Christian Ferrer (talk) 17:46, 23 February 2021 (UTC)

Maybe to explain my reasoning behind the changes I made: Regarding URL's constraints: I interpreted that the Wikidata usage instructions of URL essentially states that one should always use more specific properties, if existent, otherwise when using URL one should always add an of-qualifier.
Regarding the mentioned property changes I made to some data objects personally I think that described at URL (P973) is a suitable property and therefore thought that since it's modelled as described at URL (P973)subproperty of (P1647)URL (P2699) and therefore in a sense "more specific" than URL it should be preferred. However, this is only my train of thought I had when making the changes, I don't have a strong opinion on this matter so I am completely open to counter-suggestions. --Nw520 (talk) 18:51, 23 February 2021 (UTC)
@Nw520: The property was created with the hint Preferably use a specialized property like P856, URL P854, or P1065. Otherwise, qualify with P642., but a mandatory usage of of (P642) was not discussed in the property proposal. Honestly: I do not understand the reason for that qualifier. Are there any examples? --Succu (talk) 20:39, 23 February 2021 (UTC)
@Succu: The description in the proposal you've linked states “URL of something, other than P856, P854, or P1065. Must qualify with P642” and Filceolaire mentioned that instead of using of (P642) they'd prefer separate properties. Additionally, the proposal contains a hand-full of examples which in my opinion are quite informative: URL (P2699)http://vocab.getty.edu/doc/of (P642)technical documentation (Q1413406). While many of the examples nowadays would be modelled with more specific properties like API endpoint URL (P6269), download URL (P4945), user manual URL (P2078) I'd claim that using of (P642) is still highly useful as it narrows down to what type of page/service a URL is pointing to since URL (P2699) still more-or-less acts as an fallback for all types of URLs for which there are no adequate more specific properties (yet). --Nw520 (talk) 21:16, 23 February 2021 (UTC)
  • The subject of the mandatory qualifier aside, about which I have no strong opinions, note that I was thinking doing well and if I used URL (P2699) instead of described at URL (P973) it was because I had the feeling that it was not approrpiate for the type specimens, see Property talk:P973, I quote "This is to be used to provide links to reliable external resources that are not the item's official website, when no relevant "authority control" property exists (note: this should be moved to the property statements)". However in my cases the URLs given are toward the official websites or towards official databases, so those links are not just links to pages that describe the items. Christian Ferrer (talk) 09:39, 24 February 2021 (UTC)

Horsepower

What field do I use to add in the horsepower for an entry on an engine? I tried looking for an example using various car models, but there are no entries I can find. --RAN (talk) 23:09, 23 February 2021 (UTC)

See Wikidata:WikiProject Railways/Properties for rolling stock. nominal power capacity (P2109) seems to be most suitable. --Jklamo (talk) 23:37, 23 February 2021 (UTC)
Thanks, I will make it work! --RAN (talk) 06:52, 24 February 2021 (UTC)

Cleanup/Import of scientific articles and our notability criteria

Recently there has been a discussion started by me in the telegram wikidata channel on whether scientific articles are in notable or not and thereby have a place in Wikidata.

The notability criteria currently does include scientific articles (#2 as conceptual entities) but it's unclear whether scientific articles can freely be imported in bulk or not. Some users have expressed concern importing more articles because of these reasons. These growing pains have been questioned by Fnielsen on the talk page, but interested enough it did not result in a discussion at all.

Additionally past imports have unfortunately yielded items of very low quality that are not well connected to the rest of the graph which has been upsetting to some users calling for blocks of those who import articles.

There are numerous quality related problems to the scientific articles:

  1. millions of items have authors as text strings and we don't have the will or manpower to match all those - not even with tools from Manske like AuthorDisambiguator.
  2. many articles are missing references to other articles effectively lowering their value because you can't find the references easily.
  3. many articles are missing main topic, making them hard to find.
  4. sometimes wrong DOI numbers from PubMed (if I understood GZWDer correctly)

The problems are so severe that just talking about them seems to be a strain on the community in the telegram wikidata channel which is pretty interesting as we I recently build a tool that finds DOIs in Wikipedia by following the eventstream and tells the user whether we have it in WD or not. As of yet the tool cannot import anything, but it's mere existence seem to be alarming to some fearing a mass import by me or others. I have recently opened a bot request, but no one has cared to comment yet despite a some fuss in the wikidata channel on the topic.

I'm curious how we can move forward with this issue of our scientific articles as it seems to be affecting the community a lot in negative ways as mentioned in the link above. What is needed to realize WikiCite?

If we keep them in-house, how can we isolate them from spamming the search box? Can we technically house them with the current infrastructure? If not what is needed to accomplish that? We already have query timeouts for human (Q5) and scholarly article (Q13442814) but anyone can hire a server, run their own WDQS in docker and import the dump and run queries for days if they want. I don't see that the WQDS is affected a lot except during imports, but that can be managed by lowering the import rate (of my bot for example).

Arthur commented on the WikiCite talk page 3 years ago citing an earlier RfC and arguments for having scientific articles as Q-items but no one has answered yet.

The only problem I personally see with the scientific articles is that they turn up in the CirrusSearch which is annoying when not working on them which I generally don't. But we could probably easily fix that and simply exclude them from ElasticSearch or make a separate ElasticSearch server that include them that users can turn on in the settings or whatever. How hard can it be? They can still be queried via sparql so Scholia will still work I guess. I see this as a frontend deficiency that should not dictate the contents or decisions of our incredibly valuable knowledge graph.

I sincerely hope the community can come together and find a fruitful way forward with or without the 86 million scientific articles in Crossref that are available to us (which by the way is included in the sum of all knowledge that is the goal of WMF). @ArthurPSmith, GZWDer, fnielsen:--So9q (talk) 20:05, 11 February 2021 (UTC)

  • Now that the first sister site of Wikidata starts taking off, maybe the options at Wikidata:WikiCite/Roadmap#Four_scenarios_for_the_future_of_WikiCite could be re-evaluated.
    There are indeed a few re-occurring problems with scientific articles and bibliographic data that might be easier to manage in a different setting.
    As far as Cirrus search is concerned, I think articles are already ranked after other items in results. You might want to ping the other importers of these articles as well. --- Jura 21:25, 11 February 2021 (UTC)
@Succu: I do actually provide Wikidata items as sources in Wikidata statements daily. So far my experience is that for half of the sources I use I need to create a new item. This takes just a minute or two, but if the item already exists then I can use the saved time to think about, say, a good description for the item I'm working on. So, while I don't have a solution for the question asked here I do thank all the people working on the hard problem of having items for sources - in whatever form that will be in the end. Toni 001 (talk) 11:06, 14 February 2021 (UTC)
@Toni 001:I wholeheartedly agree. It's annoying when items are missing, it takes valuable time from me doing work a machine can do faster and better. My recent bot is gonna be able to import all of ISBN also (first those appering in Wikipedia, then the rest) if it get's approved, but we gotta talk quality and max new items per minute to not overload the bridge between MySQL and Blazegraph/WDQS as happened when GZWDer and others went crazy with bots and QS a while back. We are balancing on a knifes edge, because we are still waaaay behind all of science and all of the worlds books and that is gonna take time to catch up when our infrastructure has this bottleneck bridge between the two data stores.--So9q (talk) 21:46, 14 February 2021 (UTC)
  • @Jura1: What "first sister site of Wikidata" are you referring to? I don't see "sister site" mentioned on this page at all previous to this comment? But on the above questions from So9q - Wikidata is currently incomplete on many topics. We are doing much better on the scholarly record than we are on plain old books, for example, for which we hold only a tiny fraction of the potential total. Any project along these lines cannot be a one-time thing, but must be planned as an ongoing import process to keep the data in sync and hopefully keep making it more and more useful (cleaner in one respect or another, more interlinked, etc.) If there are X million items of some sort created in the real world every year and we are importing Y million of them per year then we're in good shaped if Y > X, and we're falling behind if Y < X. If for capacity reasons Y will always be less than X then we need to add some filtering criterion so the most useful items, by some relevant measure, are the ones being imported. Longer term I do see federation as a potential solution to the cases where Y < X, but we're not there yet with the wikibase software at least. ArthurPSmith (talk) 22:19, 11 February 2021 (UTC)

Some points:

  1. (As you likely already know) There are some proposals to move articles to another site, but it does not get consensus.
  2. Previously Magnus have a bot that periodically import articles from Wikipedia DOIs. It is not running for a number of unfixed issues (Topic:V2fzk650ojg2n6l1, [29]). (Issues and problems of Magnus's bot far exceeding this and some of them exist for years.)
  3. Daniel Mietchen also have a bot that imported more than 18 million article from PubMed. However, they does not create new author items (though they will use existing items with known ORCID). I have go thorough all 33 million PubMed ID (as of 2020) and created one million new items from ORCID - P.S. See m:WikiCite/2020_Virtual_conference/Author_items_in_Wikidata (they are sparse but being improved) - though this result in issues such as invalid ORCID, and misattributed authors (very rare but hard to detect).
  4. The bots of Magnus, Daniel and me can only import articles from Crossref. They are a significant articles in other sources (e.g. CNKI, where Stevenliuyi is working on but only 1% is complete), some of which contain DOI (not resolvable by Crossref).
  5. "references to other articles" - this is what User:Citationgraph_bot and User:Citationgraph_bot_2 did, currently not active. SCIdude also imported some. I have a plan to do so in far future but I think we should enrich our corpus first. (This is the planned 2.0 version of article bot, and 1.0 will eventually retire, but I have not written any codes yet.)
  6. ElasticSearch is very scalable service, but its feature needs significant improvement (phab:T200859, phab:T248363, phab:T239950 and eventually phab:T199887).

--GZWDer (talk) 23:19, 11 February 2021 (UTC)

  • "authors as text strings" - at least it is searchable (by search box), and it is much better than the Microsoft Academic approach (create entries for each authors and one author may have 15 entries) and the Semantic Scholar approach (use some automatic algorithm to resolve them and some authors are conflated to one entries).--GZWDer (talk) 23:22, 11 February 2021 (UTC)
I would just like to point out that I recently brought Citationgraph Bot back online after two years of being offline and Citationgraph Bot 2 will also be coming back in the next few days. Harej (talk) 23:26, 11 February 2021 (UTC)
This will be much helpful as currently PubMed IDs are 100% complete (triple checked) for IDs<32240000 and 99% completed for IDs<33420000. However we does not have even one half of Crossref articles.--GZWDer (talk) 23:36, 11 February 2021 (UTC)
  • as to references, there is in my opinion no open source of bulk references other than Crossref. The problem IMO is all the paywalled articles that cannot be parsed in bulk, despite sophisticated tools existing for extraction. So this will not be solved in the near future.
  • scientific articles turning up in the CirrusSearch, I completely agree. Also they are not consistently sorted to the bottom, contrary to what was said above, and I have given examples in an earlier thread on this...tldr: if a non-article matches the input exactly then it gets sorted up, but if the input is shorter, i.e. a prefix, then articles will show at the top, annoyingly. This is a bug that was completely ignored despite my reporting.
  • missing main topics, this is a hard problem that you cannot expect to solve in Wikidata alone. This data is likely to be collected from many sources, Pubmed, curated databases, libraries etc. --SCIdude (talk) 15:55, 12 February 2021 (UTC)
  • "If we keep them in-house, how can we isolate them from spamming the search box" our current solution is that we rank items about academic papers a lot lower then most other items, so that they are listed after other items. To me it seems like our current solution works well. If you think that there are searchers where you think academic articles spam the search box in a undesirable way please provide examples. ChristianKl16:05, 12 February 2021 (UTC)
  • When reassessing Wikidata:WikiCite/Roadmap#Four_scenarios_for_the_future_of_WikiCite, maybe we could consider a fifth option: build a way to integrate and annotate other catalogues. We don't really need to recopy all library catalogues on WMF servers. --- Jura 18:09, 12 February 2021 (UTC)
  • I do find it unfortunate that the WikiCite roadmap page has not been updated since August 2019. Is there no action in this area? Or is the discussion happening somewhere else off-Wiki? - PKM (talk) 01:34, 13 February 2021 (UTC)
  • Re:author names as text strings - these can be cleaned up using authorDisambiguator, which I use in my area of expertise. If the strings aren't there, they can't easily be cleaned up. - PKM (talk) 01:37, 13 February 2021 (UTC)
  • I propose we instead delete them until Crossref has been updated with ORCID. If that does not happen we can always import them later and match directly (via a semi-automatic tool like LexUse) instead of now storing a truckload of bad data. I can easily build a bot that checks every single scientific article with a DOI in crossref and pubmed regularly to see if they have a new ORCID.--So9q (talk) 07:27, 14 February 2021 (UTC)
    • @So9q: See Wikidata:Property_proposal/Archive/39#P2093: having them will make article items possible to be used in reference of Wikipedia articles.--GZWDer (talk) 12:56, 14 February 2021 (UTC)
      • @So9q: Re: I propose we instead delete them [author name strings] I don't see the value in deleting work done by others (including me), in particular work which can (and is) being built upon. You assume that every author will get an ORCID, which is unlikely given that many authors of works with CrossRef DOIs are no longer alive. Even if an author is alive they may not intend to get an ORCID, and even if they do, they may not add any publications to their ORCID profile. So let's be as flexible as possible, accept that at the time of being added to Wikidata we may not have identifiers for authors, and that adding authors as strings gives us an opportunity to reconcile these in the future. --Rdmpage (talk) 15:07, 14 February 2021 (UTC)
        • @Rdmpage: Thanks for chiming in. I think you have good arguments for bringing in the names as strings so I'll change my bot to do that also. I would anyway like to have a bot that regularly looks up articles with string names and see if any of them now got an ORCID. I would also very much like the publishers to more or less mandate the use of ORCID in journals going forward and start assigning ORCID to dead authors from the past. I propose sending Crossref a nice letter with this wish and ask them to talk to their members, WDYT?--So9q (talk) 18:46, 14 February 2021 (UTC)
        • @So9q: My understanding is that major publishers that are part of the CrossRef ecosystem are increasingly asking for an ORCID for corresponding authors, so this is happening anyway. I don't know whether this will extended to a requirement for EVERY author of a submitted paper to have an ORCID. And given the size and diversity of the publishing landscape, I suspect that there will be many exceptions to this requirement. Regarding ORCIDs for dead authors, this violates ORCID's policy of "individual control" see https://support.orcid.org/hc/en-us/articles/360024829193-How-are-ORCID-records-for-deceased-people-handled- . Their model is that the individual creates and manages their ORCID. --Rdmpage (talk) 08:31, 15 February 2021 (UTC)
  • As long as there is no alternative, I find references to statements notable (and as far as I know, they are). I understand all the complications, but to me "mass import" is not an argument: either you want to have a machine readable capture of knowledge, or you do not. There are millions of chemical compounds, genes, species, stars, studied. But I still have issues with confounding technical problems with fundamental questions and goals, like the one where we want to explain where knowledge is coming from. Maybe this is too controversial, but I rather see all humans removed from Wikidata before we start removing our references. my 2 cents --Egon Willighagen (talk) 15:14, 14 February 2021 (UTC)

Could I say, for the record, how much of a nothingburger of a thread this is. Little heat. Little light. Someone running around suggesting on no premise whatsoever that scholarly articles are not notable, cause cirrussearch problems, should have author name strings deleted. All nonsense on stilts. A person is entitled to their opinion, of course, but no credible case has been made in this thread for anything other than to move on to other subjects entirely and let this dead end be archived. --Tagishsimon (talk) 15:46, 14 February 2021 (UTC)

Thanks for chiming in Tagishsimon. Here is what I have learned from the discussions above:
  1. No one on-wiki seems to hold the views I saw expressed by a few participants in the telegram chat:
    1. that the infrastructure can not bear all 84 mio articles (I heard no good arguments why we should not collect all articles as they are clearly in scope of "sum of all knowledge" and pretty basic if you want to develop insights and reference the work of others)
    2. that we are bogged down with quality issues and mere talk about a bot to help improving the quality and coverage of scientific articles results in talk of blocking. (I do see that few articles have "cites work" - we should fix that ASAP - which Haraj has bots that do.)
    3. that we should not import the sum of all scientific knowledge (because "no") in a way that makes sense to the community on-wiki.
  2. The lack of participants from the Telegram chat here despite the fact that I shared the link to this discussion just after I published it could mean this:
    1. the people who chat in Telegram do not wish to participate on-wiki in this discussion (and have it recorded)
    2. the people who chat in Telegram do not have good arguments for why moving the 84 mio articles (we have 32 mio today, but within a year or 2 I suspect we will have imported all from crossref) is paramount that they wish to contribute here.
    3. and/or worse: we have a split community with one group of ~600 people sitting in Telegram and x number of other participants discussing here on-wiki.
  3. @Harej: is on their way to restart the 2 bots adding cited works, which is very good news.
As an aside: I have never advocated seriously for a deletion of valuable content like scientific articles, but moving them away from WD is a possibility worth pondering given that structured data on commons is both searchable from CirrusSearch when adding statements which as mentioned above seems better than importing every single object from commons as an item here.
On the other hand I don't know if it's easy to query say all photos of Mona Lisa using the structured data on commons as I have not tried that yet. If anyone have an example query that would be interesting. A WikiCite that has the same features as Commons have today could be valuable IMO, but it would split this community in 2 and require adaptation of tools like QS and others to work on items in the new place. Unfortunately we don't have a lot of people maintaining our tools so I would prefer to keep it all in-house for that reason and lack of other good arguments to move and keep a third structured project alive within WMF with tools and all. Thanks for participating in the discussion so far :) I'll keep working on my bot and more people will respond to my bot request.--So9q (talk) 18:46, 14 February 2021 (UTC)
re the lack of participants from Telegram @So9q:: @ArthurPSmith: is a member of that chat, but a number of others, including @PKM, Multichill, Yupik:, got tired of your messages regarding this there and may not have wished to follow you to the discussion here (in other words, for them, only the first of your bullet points applies, although not for any nefarious reasons of which you may conceive). Mahir256 (talk) 19:14, 14 February 2021 (UTC)
I posted a couple of comments above. - PKM (talk) 19:32, 14 February 2021 (UTC)
@mahir256, PKM: Good, I'm happy to hear we do not have a split. I'm taking a break from the telegram chat to let things cool down there as my presence and enthusiasm was not a gift to some of the others. This "got tired" I still don't understand by the way and I presume it means "felt annoyed with stimuli from me". I have not yet seen anyone quote which of my messages was upsetting and I guess I'll never know.
Anyways Mahir, I'm feeling curious, do you agree to import all 86 scientific articles in Wikidata to reach the goal of WMF? To the others reading some in Telegram drew a parallel between all humans in WD and all scientific articles in WD but 2 things make them very different 1) there are a factor 70 difference in amount (86mio vs 7bn) and 2) humans in themselves are not notable by default and cannot be used as reference in themselves but scientific articles are almost without exceptions part of our sum of collective knowledge. Our collective brain you could say as it contains way more knowledge than any human can digest in a lifetime.--So9q (talk) 21:29, 14 February 2021 (UTC)

Sorry, but what is the point of Wikidata

Wikidata is considered a support project for Wikipedia. How it is increasingly used is to link references in Wikipedia to the data in Wikidata. The point made is that as the data improves the quality of the reference improves. It follows that the wiki notion that things do not have to be perfect is alive and well. At the same time we find that Scholia knows in what Wikipedia article a paper is used and also there is a Scholia template used on many Wikipedia articles. Many of the papers are linked to papers through the "cites work" property. The quality of these links have a dramatic impact in a Scholia and as information on these cited works increase it affects all the scholias linked in whatever way.

The notion that things remain the same is false. Elsevier has provided all its citations to Crossref. It follows that when we indeed add those links it will introduce many new items, author strings. That is good. The notion that ORCiD is important.. sure. But not exclusively so. When we truly think that ORCiD is important, we have a tool whereby scientists can verify what we have, improve based on what they have at ORCiD, maybe cooperate with ORCiD so that authors may update Wikidata based on the info at ORCiD. In the end we provide a platform where links to papers flow from Wikipedia articles. It could be a way whereby we flag Wikipedia articles where the science became stale.

The notion that Telegram is where we discuss developments for Wikidata is as valid as discussing it on Facebook. Interesting but not really. Thanks, GerardM (talk) 15:58, 14 February 2021 (UTC)

Wikidata is considered a support project for Wikipedia. My background is Wikipedia and I think that Wikidata is independent project and it has its own goals in terms of content what it chooses. However, Wikipedia is important because it actually tries to use data from Wikidata and it really is an acid test for the data quality, user interface, our abilities to query wikidata. If Wikipedia has a problem with those it is likely that other parties will have same problems too. --Zache (talk) 19:29, 14 February 2021 (UTC)
@zache: +1 😃 In Danish this is called lakmus test.--So9q (talk) 09:40, 15 February 2021 (UTC)
Regarding the state of WikiCite, there was a whole conference a few months ago - videos available here on YouTube. ArthurPSmith (talk) 16:32, 15 February 2021 (UTC)

I am very much interested in Knowledge Graphs of Science and I think Scholia is great, but there are 2 problems with importing articles (or museum collections) en-masse:

Even core pages about Wikidata itself don't agree or present a consistent statement about what the purpose of Wikidata is. Right on the homepage it states 'Wikidata acts as central storage for the structured data of its Wikimedia sister project'.
However on one of the core help pages on the site ( https://www.wikidata.org/wiki/Help:Statements#Add_only_verifiable_information ) it states Wikidata is not a database that stores facts, but rather stores references to facts.Specifically it describes the objective as 'Wikidata is not a database that stores facts about the world, but a secondary knowledge base that collects and links to references to such knowledge'. Just getting a consistent statement across various elements in the site documentation would be nice. CanadianCodhead (talk) 14:38, 24 February 2021 (UTC)

Contre-jour images

How do we treat contre-jour images in the Structured Data in the Commons? example:

 

Is there photografy method property? I tried to use the general 'instance of', but I get an warning message.Smiley.toerist (talk) 23:00, 23 February 2021 (UTC)

Maximum length of monolingual text

I remember that we have a maximum length for monolingual text but not what exact value it is. Our documentation at https://www.wikidata.org/wiki/Help:Data_type#String doesn't seem to list it. Does anybody know? ChristianKl02:57, 24 February 2021 (UTC)

I believe the current max length is 1500 characters, last set in T154660. --Lucas Werkmeister (WMDE) (talk) 10:55, 24 February 2021 (UTC)

Is person from the Middle East (Q79082251) within scope or of any use?

I was looking through some query results of subclass of = human and that's when I found this item about a person from the middle east. I was further thinking if 'person from Europe' or 'person from the USA' would be appropriate or if they would be out of scope? I also wonder how this could be used, would it be used on items with instance of (P31) = human (Q5) or for instance of (P31) = Wikinews article (Q17633526)? LotsofTheories (talk) 12:52, 24 February 2021 (UTC)

Wikidata items for all Debian Packages?

Could I add a Wikidata item that represents each Debian Package? I know this subtitle editor which I didn't find a Wikidata item for but I don't want to clutter the database if its out of scope. Even feedback where you are unsure if it is out of scope or not is enough for me, I think it is helpful and this might help me to be bold. LotsofTheories (talk) 15:44, 16 February 2021 (UTC)

  • How much Debian packages are there? Are you thinking about an item for the Debian package that's separate from other items about the same software? ChristianKl16:24, 16 February 2021 (UTC)
    • We have items for releases of databases, but only for the reason they are needed as reference; releases of software are mentioned as statement in the software item. I consider distribution packages as normal software releases (specialized to the distribution), so before collecting these it would be more important to have all the general releases (provided we even have the software item). --SCIdude (talk) 15:10, 17 February 2021 (UTC)
  • Definitely not for "transitional dummy packages", or internal dependencies like https://packages.debian.org/buster/wesnoth-1.14-data. There are 28839 source packages[30], but there are things like "kde-l10n" too. Maybe worth importing to mix'n'match and create case-by-case, if you are interested in. --Lockal (talk) 16:07, 17 February 2021 (UTC)
@Lockal: Yes please. I'm getting to know Mix'n'match (Q28054658) by following a tutorial on YouTube so if you add something related to this then it would be interesting to see how I can do something about Debian packages. LotsofTheories (talk) 16:50, 24 February 2021 (UTC)

What about this page/item?

Hello, I am new here. I have been contributing to Wikipedia. I just wanted to edit here as well. I went to a random item and fount this item. Why is this blank (with no label and other fields)? Is it a test page/item? I don't know how to improve it, or if it is to be improved or not. Can you please tell me what to do? Lightbluerain (talk) 18:01, 22 February 2021 (UTC)

@Lightbluerain:It appears blank (at least the label) most likely because there is only 1 language the label is filled in for, which is Polish, and I assume you are not running in Polish. If you click the link under the labels to see all languages, you will see it in the list. The page is an import of a dedicated Wikipedia category page from the Polish language version of Wikipedia.

CanadianCodhead (talk) 18:07, 22 February 2021 (UTC)

Alright. So, can we add similar categories from other Wikipedias, like from english wikipedia? If it exist in that language? And, what should be the label here? Lightbluerain (talk) 18:14, 22 February 2021 (UTC)
Of course you can add them, just best to check that it does not already exist. If you are not aware, at the bottom left of the links list of any Wikipedia page is a link to the associated Wikidata item. I'm not sure there is a need to add any language label other than the Polish, but I guess it would be 'Wikipedia articles - Łódź' or something similar as the category groups pages about that city. I'm pretty sure various bots do much of the importing of Wikipedia content pages automatically though.

CanadianCodhead (talk) 18:26, 22 February 2021 (UTC)

Alright, thanks. Lightbluerain (talk) 18:32, 22 February 2021 (UTC)
@CanadianCodhead:, I am unable to edit the label of this page. How to edit it? Thanks. `Lightbluerain (talk)
I see a successful edit under your user name for the history of that page, should it be taken to mean you figured it out? CanadianCodhead (talk) 14:57, 23 February 2021 (UTC)
Yes, I figured out how to edit the labels. Although, I am little doubtful about the edit I made was it right? or not? Lightbluerain (talk) 17:36, 24 February 2021 (UTC)

Accidental creation

I created https://m.wikidata.org/wiki/Q105637111 but request it to be merged with https://m.wikidata.org/wiki/Q12900729 . The Latin Wikipedia article confusingly didn't link to the Wikidata item when I visited it. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 09:27, 23 February 2021 (UTC)

@Donald Trung: I can only say that in "normal" mode it links the Wikidata object. I don't know why it doesn't work in mobile phone mode. --Gymnicus (talk) 09:40, 23 February 2021 (UTC)

  Done --★ → Airon 90 16:38, 24 February 2021 (UTC)

Hey Folx there is no Facebook event Property...

How to add link of Facebook event? I wanted to add this to my last edits https://www.facebook.com/events/418603696065088/

Zblace (talk) 23:00, 23 February 2021 (UTC)

@Zblace:
  1. Event is unavailable, at least in Italy, so I cannot define if this event is useful or spam
  1. There isn't any FB event property. You can propose it in WD:PP, although I doubt about its usefulness for the project.
--★ → Airon 90 16:30, 24 February 2021 (UTC)

Can someone merge these pages?

I tried doing this myself but it keeps giving me errors about different descriptions.

--Psiŏczek (talk) 14:31, 24 February 2021 (UTC)

"the publication it illustrates", and "colorist"

What property should I use to refer to the book that a particular picture was used to illustrate?

Also, there's a version of this picture on Commons which I coloured. Is it appropriate to set colorist (P6338) to myself?

Thank you! Marnanel (talk) 19:54, 24 February 2021 (UTC)

part of (P361) would fit, maybe on the edition items if this is an illustration not on every editions but just of a specific one. author  TomT0m / talk page 19:59, 24 February 2021 (UTC)

Interested in templates in Wikidata?

If you're interested in the use and development of templates in Wikidata, join the brand new WikiProject Templates. The goal is to provide documentation and discussion about templates in Wikidata. PAC2 (talk) 21:29, 24 February 2021 (UTC)

Modelling interrupted events

Hi, I'm about to create items about a famous annual event (palio of Legnano (Q3361439)) in which there is a winner. However, in some cases, e.g. because of WWII or COVID-19, this event didn't take place and in some cases this event took place but were prematurely stopped. How can I model this last case? --★ → Airon 90 16:26, 24 February 2021 (UTC)

⟨ competition ⟩ winner (P1346)   ⟨ no value Help ⟩
cause Search ⟨ premature ending ⟩
for the lack of winner, I guess. author  TomT0m / talk page 16:45, 24 February 2021 (UTC)
@TomT0m: My fault, I was not so clear to explain my question. My question was about the qualifier: is there an item about premature ending? I am asking before creating a new one. --★ → Airon 90 17:12, 24 February 2021 (UTC)

Suggestion: change notes

I have a suggestion, each change to something has a way to add a note (ie. edit summary) as to what the change represents. (ie. new population statistic from new census; fixing a misspelling; additional data; etc) -- 65.93.183.33 12:19, 22 February 2021 (UTC)

This is, for the most part, done automatically and done well. What are you hoping to improve by requiring lazy insubordinate humans to do something already well done by software? --Tagishsimon (talk) 13:48, 22 February 2021 (UTC)
It is not reliably done for edits from QS though which is quite frustrating to me since it should be so easy to write a short explanation of a change for a batch (instead it usually says "quickstatements; #temporary_batch_etcectc"). BrokenSegue (talk) 14:05, 22 February 2021 (UTC)
I'd like that, too. The automatic edit summary explains what was done, not the why. Sometimes I'm making an edit that I suppose will look weird to someone else, so I'd like to explain that with the edit. We of course have a talk page; but then, we can leave a justification when undoing an edit, so why not when doing an edit? Best wishes. Toni 001 (talk) 10:09, 23 February 2021 (UTC)
@65.93.183.33, Tagishsimon, BrokenSegue, Toni 001:, I created a new userscript - EditSum - which allows adding summary to all kind of edits: label edits, adding/modifying statements/qualifiers/references, etc. Hopefully it will save some time for editors. --Lockal (talk) 18:43, 23 February 2021 (UTC)
Thanks for the tool. Toni 001 (talk) 09:29, 25 February 2021 (UTC)

Duplicate items

While using OpenRefine I've found two items that appear to be about the same person, Q56278318 and Q97214839. Both items are linked to articles on the Indonesian Wikipedia. Is there a way to fix this? Overcast07 (talk) 16:48, 25 February 2021 (UTC)

@Overcast07: I agree those items are the likely the same person, but they both link to full articles, i.e. not redirects. If this were on the English Wikipedia, I would do the text content merge and redirect one to the other so that the items can be merged. However, I don't speak Indonesian and am no familiar with Indonesian Wikipedia policies so I would recommend you try to find an editor for that site that can help you. William Graham (talk) 17:46, 25 February 2021 (UTC)
There's a userscript to conveniently mark duplicates, which I've now done for this case. It should probably be added as a gadget at some point. --SilentSpike (talk) 23:18, 25 February 2021 (UTC)

"In other projects" sitelinks by LUA

Is there a LUA module that can add interprojects links to https://wikisource.org/wiki/Main_Page/Aragon%C3%A9s based on sitelinks on Q5296? I think it would be interesting to have links to https://an.wiktionary.org/wiki/Portalada and https://an.wikipedia.org/wiki/Portalada . This would be in addition to links that come directly from the item associated with the page (Commons, Wikispecies).

Modules like Module:Interwiki only add to "In Wikipedia" or "In other languages". Maybe something similar had been done for Commons links or other before. --- Jura 22:35, 25 February 2021 (UTC)

Is there anything to protect data from forgery?

Is there anything to protect data from a forgery? Is anything like this planned?

I am working on a project where it makes sense to send you data about such things as customer's crypto and bank account numbers. If the data is forged, money may be sent to the wrong recipient. --VictorPorton (talk) 02:42, 26 February 2021 (UTC)

what? we don't store bank account numbers or the like. if you are relying on wikidata to decide where to route money you have a big problem. BrokenSegue (talk) 04:19, 26 February 2021 (UTC)

Wikipedia redirect

There are two badges about redirect, sitelink to redirect and intentional sitelink to redirect. But when sometime the page is a redirect, it will say Site link ...(goal of this redirect) is already used by item ... (Q...). Perhaps the items should be merged. However, in some cases, the content of Wikidata may be classified more finely, and some content may need to be redirected to a main item for introduction in Wikipedia. But still need a link to connect to the other languages. w:en:Punctuation mark is this case. When can and should those badge be used? When Badge is used, is it possible not to prompt this? (Reply with a metion please.)--LaMagiaaa (talk) 12:11, 26 February 2021 (UTC)

Geodata for Bookburnings by the nationalsocialists in Germany 1933

Hi,

i'm working for an Organisation which is running an remembrance and information project about the bookburnings by the nationalsocialists in germany in 1933. We collected over 140 Places where bookburnings took place. We have geodata, date, short description for it as well as the source of the information. We would like to offer at least the geodata and date information to the wikidata community. With this link it would be possible to have list of Places where and when bookburnings took place and connect that to other data. We our self have interesting questions in mind what to do with this data. For example.

1. Make a list of the Place sorted by size of the city.

2. Connect it to Information of authors of which the books were burned.

The data is accessible via an georss and geojson API. I would like to hear your Opinions about that. Thanks a lot.

JanSchenck (talk) 16:25, 26 February 2021 (UTC)

I think it would make sense for each instance of a "bookburning" to be a Wikidata item - so that would be 140 new items. You can then attach data to these items such as location, lists of books or authors, etc. - I would hope existing properties can handle this, but not sure exactly which ones to recommend. ArthurPSmith (talk) 18:27, 26 February 2021 (UTC)

Media legends don't appear on wikipedia pages with infoboxes

Many wikipedia pages use infoboxes which, in turn, refer to the wikidata records. Very often, e.g. for settlements, a picture is also used that is referred to in wikidata. I seem to remember that - at least some months ago - the media legend was also copied from wikidata if it existed in the language of the wikipedia page. This does not seem to be the case any more. Is it the fault of the infobox templates (of which several are affected, and in different languages), or has something been done to prevent the forwarding of media legend to the wikipedia pages? --Schlosser67 (talk) 09:24, 25 February 2021 (UTC)

  • No. Many pictures don't have legends in Wikidata as one can be found on Commons and should eventually be available directly from there.
If there is a legend in Wikidata and it's not displayed in a given language version of Wikipedia, this is something to check there: either in the article or its infobox settings.
With a sample, we can try to help you figure it out.
Given that Commons is working on image legends, in general, it's preferable to contribute them directly there going forward. --- Jura 10:28, 25 February 2021 (UTC)
It is somehow inconsistent. I have just added a photo for "Samtgemeinde Sickte" on wikidata with German and French media legends, and it shows up all right on the French wikipedia, complete with legend. On the other hand, the legend for the view of Elze is not displayed on fr:Elze (Basse-Saxe). Is this perhaps because of the different infoboxes? The article for Elze uses "Commune d'Allemagne" while fr:Samtgemeinde Sickte uses "Localité". I don't know much about the programming of infoboxes. --Schlosser67 (talk) 07:32, 26 February 2021 (UTC)
Indeed fr:Modèle:Infobox Commune d'Allemagne used on fr:Elze (Basse-Saxe) doesn't use the legend from Wikidata at all. It seems that initial Wikidata support was added to the infobox only last year. Maybe @Pelanch3:, who edited it, can help you. --- Jura 11:52, 27 February 2021 (UTC)

Merge request

I think Q2740581 should be merged into Q1068611. See, for example, ru:Salpidae (from Q1068611) redirects to ru:Сальпиды (from Q2740581). --Gryllida 01:13, 27 February 2021 (UTC)

The difference is in taxonomic rank. It happens rarely that two different taxa have the same name, in those cases you always have different rank. Also in general, if you see two items that appear the same and both have lots of statements and wikilinks, then there is probably a reason they weren't already merged. --SCIdude (talk) 10:12, 27 February 2021 (UTC)

Help needed: Floor cloth (Q46146955) vs. Floorcloth (Q1409430)

I would very much appreciate any guidance that can be provided. I have been working on the Floorcloth article in Wikipedia. When I started, it was defined as per Q1409430 and had one sentence reflecting that use of the term (for cleaning floors), but the bulk of the entry reflected Q46146955 (a floor covering). I have added to the article in the sense of Q46146955, floor covering. The sources I have been using primarily spell it as used for a floor covering as one word. Therefore, I am concerned about a couple of things: the Wikidata item linked to the developing Floorcloth article, and the definition of the term as a single word. How might this confusion be resolved? Thank you. --TrudiJ (talk) 12:05, 27 February 2021 (UTC)

  • @TrudiJ: The sitelink should be moved from Q1409430 to Q46146955 reflecting the new scope of the Wikipedia article.
--- Jura 12:22, 27 February 2021 (UTC)
@Jura1:Thank you very much for your amazingly quick help. I was able to do this with the information you provided. --TrudiJ (talk) 12:57, 27 February 2021 (UTC)

Description capitalisation

Hello,

I was just curious as to why the rules of capitalisation for descriptions are the way they are. Why do they start in lower case – unless there's a proper noun etc.?

Cheers, Ritenerek (talk) 00:27, 26 February 2021 (UTC)

Probably because they aren't complete sentences. -Animalparty (talk) 00:30, 26 February 2021 (UTC)
And so they can easily be quoted within sentences. Similarly why labels for items for generic things are lower-case. Jheald (talk) 11:00, 28 February 2021 (UTC)

I cannot edit anymore

All entries seem to be read-only for me as of a couple of minutes ago. Is there a reason why? I just merged a second entry into Q77581 and mistakenly added his wife a second time. When I wanted to undo that I was unable to edit anymore.--176.199.18.119 16:08, 27 February 2021 (UTC)

I removed the duplicaed wife from Fritz Wepper (Q77581), the item is not semiprotect. Joao4669 (talk) 14:21, 28 February 2021 (UTC)

How to add a reference multiple times, without creating seperate item for it

Hello, I am trying to update information for Dutch politicians. For this I use sources that support multiple claims I'm trying to make (such as this curriculum vitae of Mark Rutte). I do not believe this webpage qualifies for being a seperate item. However, I find it quite cumbersome to add all the reference info (archive url, date, retrieved date, url, author etc.) to every claim I make based on this url. Often I take the shortcut of only placing the url, which is problematic ofcourse. Is there a way to re-use a reference (e.g. copying?) for multiple claims, or should I perhaps create a seperate claim? Thanks in advance! Dajasj (talk) 13:17, 28 February 2021 (UTC)

Sounds like you need the "DuplicateReferences" gadget from Special:Preferences#mw-prefsection-gadgets. —MisterSynergy (talk) 14:03, 28 February 2021 (UTC)
That's exactly what I needed! Thank you :) Dajasj (talk) 14:11, 28 February 2021 (UTC)
I find that often the page has to be reloaded for this gadget to work. --SCIdude (talk) 15:52, 28 February 2021 (UTC)