Wikidata:Contact the development team/Archive/2020/02

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Development plan 2020

Hello,

First, a big thanks for sharing your roadmap and having taken into account my feedback from last year.

Another feedback: the up-to-date version of the roadmap is only available as an image. This is against accessibility recommendations (it can't be read by screen reader for people with impaired vision, you can't search nor copy text on the image, etc.). It would be great if that could be improved in the future.

I have questions about specific items in the development plan:

  • Finding problems in the ontology. Is this related to ShEx?
  • Finding gaps and biases, Support the creation of underrepresented knowledge. The descriptions of these items are very vague. What do you intend to do in practice?
  • Evaluation of data quality of a subset of Items. What subsets do you intend to target?

For each of them, do Phabricator tasks already exist?

— Envlh (talk) 10:32, 2 February 2020 (UTC)

  • Where's citoid in the development plan? Making it easier to add references via citoid was in the plan for 2019. The fact that it wasn't completed seems okay because you don't achieve everything in the alocated time frame in software development. Why wasn't it moved to 2020? I think making it easier to create quality items by making it easier to add sources is much more likely to lead to higher quality items then adding some ORES based way to measure quality.
I think it's good to make the merge functionality available for all Wikibase instances but when you do that you should keep in mind that currently merging on Wikidata takes more then just the gadget. It also takes the KrBot that cleans up the links afterwards. It would be good to have a merge gadget that actually can do the job of chancing the links as well and that's also undoable without a bot. ChristianKl ❪✉❫ 14:54, 5 February 2020 (UTC)
Hello @Envlh, ChristianKl, Ayack:, and thanks for your questions. I'll answer them all together :)
  • The most up-to-date version of the roadmap is actually on Roadmunk, the screenshot will only be updated from time to time. We will update the content and the dates on Roadmunk, as it is our main working tool for the roadmap and it would be a lot of energy and potentially loss of information to replicate it elsewhere.
  • Finding problems in the ontology: we will start with a research phase, for now we don't know exactly what the result will be. It is potentially but not necessarily related to ShEx. We're open to suggestions!
  • Finding gaps and biases, Support the creation of underrepresented knowledge: same as above, we will kickstart the research phase, suggestions are welcome. A very broad ticket for biases exists here, tickets for the other projects are not created yet.
  • Evaluation of data quality of a subset of Items: we plan to develop a tool that analyze the ORES score of a subset of items based on a SPARQL query, so basically any subset could be analyzed.
  • Citoid: a contractor of WMF is taking care of the development, we're supporting them if needed. That's why it doesn't appear on WMDE's roadmap.
  • Improve the merge gadget: do you know if there's a ticket for the change that you request?
  • Wikidata Bridge: it is included in the roadmap, in the section "Wikidata for the Wikimedia projects".
Cheers Lea Lacroix (WMDE) (talk) 10:11, 6 February 2020 (UTC)
I'm not aware of a ticket having created for the merge gadget. Help:Merge does describe that currently KrBot does the job of updating statements from other items after a merge. The solution of using KrBot works for the sake of Wikidata. It's a bit just annoying that you have to ping a bot operator to undo some merges correctly and there are likely merges that are currently undone where nobody bothers to undo the redirected statements. On the other hand if other Wikibase installation want the ability to merge items that are used elsewhere they need an equivalent of KrBot or the merge gadget has to include that functionality.
The fact that merging isn't trival to undo is the reason why hide the merging functionality in the first place in a gadget instead of providing it without the user having to enable the gadget. I think ideally we would have a merge functionality that can be easily undone that wouldn't need an external gadget and that would be acore Wikibase functionality. ChristianKl ❪✉❫ 13:08, 6 February 2020 (UTC)

Wikidata search and scrolling

(1) As stated in https://www.wikidata.org/wiki/Talk:Q28529690* - please make an option which allows or disallows one to include text of properties as searchable text. For example if I search for

Then nothing is found since the property "has quality" (https://www.wikidata.org/wiki/Property:P1552) is not searchable text. https://www.wikidata.org/wiki/Q708 has both the text "has quality" and "opacity", so there should be an option to get it to show up. If you search for "has quality" or "opacity" individually then things show up since titles ("Labels") and "Descriptions" have searchable text. *Read this page (http://www.wikidata.org/wiki/Talk:Q28529690) if you think about telling me to use Wikidata query service, which does not work for everything.

(2) I use popular nonstandard propriety shit: "Kindle Fire HDX (3rd Generation)" (Amazon tablet) + "Silk Browser" (web browser), and when I view wikidata webpages with desktop view it does an annoying thing with significant frequency (e.g., it happened with https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team and, less annoyingly and frequently, with https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team&action=edit&section=14). The thing it does is it scrolls around to places which I neither want it to scroll to nor instructed my web browser to scroll to. --User123o987name (talk) 04:16, 4 February 2020 (UTC)

(1) What you ask is somewhat related to T240334
Tracked in Phabricator
Task T240334
(add all/more textual properties to the search index). But your example mentions a property that does not have a text value but an item value and thus is searchable using the haswbstatement keyword: haswbstatement:P1552=Q691914. Note that we do not index the rendered output of an entity but its internal structure. DCausse (WMF) (talk) 13:47, 6 February 2020 (UTC)
(2) I'm sorry that you experience this problem. Unfortunately we cannot reproduce the issue because we don't have a Kindle Fire HDX to test it. Therefore I'm afraid there's not much we can do at the moment. Lea Lacroix (WMDE) (talk) 14:44, 6 February 2020 (UTC)

Incorrect property label

The property label for Artnet artist ID is being displayed as 'Sara Soler' on Q83619164. A quick search shows that other pages with this property have previously been affected (although it seems to be resolved on many/all now). Is this a bug? Drw25 (talk) 18:47, 4 February 2020 (UTC)

Hello @Drw25:,
This is some leftover from a previous issue that got fixed. I purged the page with adding ?action=purge at the end of the URL and the label is now correct. If you see this issue occuring again and purge doesn't work, please let me know. Lea Lacroix (WMDE) (talk) 10:38, 5 February 2020 (UTC)

Query Builder

Hello,

what is the current status of the query builder. As far as I know in 2019 there were plans to improve it. There is a prototype of a query builder as a tool you can find it under the following link. [1] This prototype is a good start. I dont know how high the number of combinations of possible queries is. I think on solution were to collect the possibilities in a more structured way as the examples at the moment. When I want to make a query I know the item with property I look for. And also the datatype of it in the most cases and properties with qualifiers I want to see in the result. Also maybe want to see the label in a specific language and the descriptions. I think it is important that the creating of a query is more easy as it now is. At the moment there are many cases for what there is no solution without deeper SPARQL knowledge. If you want that the goal of the Wikimedia Foundation becomes true then you should find ways to change it. -- Hogü-456 (talk) 19:59, 5 February 2020 (UTC)

  • It does seem to be part of the plan "Queries and lists are an integral part of accessing the data in Wikidata and making sense of it. Right now creating lists requires knowledge of SPARQL. We want to make it easier for people to create lists without having to know SPARQL. " ChristianKl ❪✉❫ 20:36, 5 February 2020 (UTC)

translate language name

Entitytermsforlanguagelistview

How do i translate language name (ex. zh-cn "Chinese (china)") in wikidata? Is it imported from CLDR? --Ans (talk) 09:04, 30 January 2020 (UTC)

Hello,
To what part of the Wikidata interface do you refer to? Is it the description of the language for a monolingual text value? The labels at the beginning of an item page? Or something else? Lea Lacroix (WMDE) (talk) 09:35, 30 January 2020 (UTC)
The label at beginning of item page. --Ans (talk) 11:47, 30 January 2020 (UTC)
Thanks. It comes from the ULS that is based on CLDR. I'm not sure if and how you can add new translations. Lea Lacroix (WMDE) (talk) 15:41, 30 January 2020 (UTC)
Bonjour Léa, pourriez-vous prendre connaissance de cette demande ici ? Car ça semble être le même questionnement, mais ça concerne la liste des langues à côté des Libellés qui n'apparaissent pas correctement, ÀMHA. À+. —Eihel (talk) 05:02, 17 February 2020 (UTC)
Thanks for the details. Indeed, I can reproduce: in French or in Chinese, the name of the language "Chinese (Hong Kong)" is not translated, so it appears in English. I'm afraid this comes directly from CLDR. @Amire80: Do you have any clue what is happening? Is that something specific to Chinese? Lea Lacroix (WMDE) (talk) 09:41, 17 February 2020 (UTC)
User:Nikerabbit and User:Nemo bis probably know the process better than I do. --Amir E. Aharoni {{🌎🌍🌏}} talk 09:59, 17 February 2020 (UTC)

The process is described at translatewiki:CLDR. I was already contacted by VulpesVulpes825 on this, we always need more translators. Nemo 10:19, 17 February 2020 (UTC)

Increasing the frequency of constraint violation report updates

The constraint violation reports are an essential part of Wikidata's ecosystem, however they are updated by bots operated by @Ivan_A._Krestinin, Pasleim, and the updates take place sporadically depending on the computing capacity of the bot operators. Ideally they would be updated on timescales of a day or shorter, rather than the current week or two or longer. There seem to be several possible options to speed this process up, and I think it would be good if the development team could investigate them:

  1. Provide more frequent dumps, or additional computing power, to the current operators, if these are the bottlenecks
  2. Employ the current operators, if they are best placed to provide these reports more regularly
  3. Take the updating of the constraint violation reports in-house, either by building it into the Wikibase software, or adopting the current bot code and running it directly on the servers

Thanks. Mike Peel (talk) 21:32, 1 February 2020 (UTC)

For reference, relevant ticket phab:T189747. --Edgars2007 (talk) 17:28, 2 February 2020 (UTC)
Hello @Mike Peel:,
Regarding your suggestions #1 and #2, the ticket mentioned above gives you an overview of the current status. I'm not sure anything moved forward since then, and I'm afraid there's not much we can do about it - an idea has been suggested to move the bot to Toolforge, but its author needs to comply to the Wikimedia Cloud Services requirements first.
Regarding #3, that's already what we are providing for several years with the Constraints Extension, that is powering the individual constraint notifications on each item page. This is based on live data and update as soon as a relevant statement is edited. We plan to make those results more easily searchable, see phabricator:T192565.
Could you tell me more about your usecase, how you are currently using the reports and what tasks you would like to perform that are not yet doable using the constraints extension? Cheers, Lea Lacroix (WMDE) (talk) 13:48, 3 February 2020 (UTC)
@Lea Lacroix (WMDE): Thanks for the reply, I also posted this at [2] which led to some useful discussions. So the ultimate aim is to scrap the on-wiki pages, and only use the extension? Looking at the phabricator ticket, I think it covers the main use case I'm worried about, which is retrieving all constraint violations for a given property. Personally I then use these as pointers to things that can be fixed - for example, merging items - and I also use them as good examples of why it's better to store values in Wikidata rather than in local values (e.g., IDs in Commons templates). I also have a bot script that removes Commons category (P373) values to non-existent categories, which uses wikibase:hasViolationForConstraint, but this always misses items that are then picked up at Wikidata:Database_reports/Constraint_violations/P373#"Commons_link"_violations, apparently due to the way that hasViolationForConstraint is updated only when the page is edited. Thanks. Mike Peel (talk) 20:36, 9 February 2020 (UTC)

@Lea Lacroix (WMDE), Mike Peel: Thank you for this discussion. Something definitely needs to change because Ivan A. Krestinin is seemingly very busy and hard to catch, and probably does not have time for improving the constraints reporting service. There are even bugs in the way his bot handles ranks which causes erroneous appearances in his constraint tables. Is it possible to generate automatically updated tables using the Constraints Extension? Vojtěch Dostál (talk) 07:32, 12 February 2020 (UTC)

Tracked in Phabricator
Task T214362
Hello @Vojtěch Dostál: and thanks for your question. There is a project to store the WikibaseQualityConstraint check data in a persistent storage, in order to query it from the WDQS. The discussion is happening on this ticket (it's a technical RFC). Feel free to leave a comment there to give your opinion or express your support. Lea Lacroix (WMDE) (talk) 10:43, 12 February 2020 (UTC)

Shorter URLs for entity data

For example, please make https://www.wikidata.org/wiki/Q42.json equivalent to https://www.wikidata.org/wiki/Special:EntityData/Q42.json  – The preceding unsigned comment was added by Peter Jonas (shoogle) (talk • contribs).

This is https://www.wikidata.org/entity/Q42.json --Pasleim (talk) 11:13, 9 February 2020 (UTC)


link statement to statement anchor

Tracked in Phabricator
Task T203397

Now that there are anchors for individual statements on items, could we have, e.g.

link to

?

Currently it just redirects to Q2013.

The first URL is generated notably by query server [3]. --- Jura 12:35, 11 February 2020 (UTC)

Looks like the patch was already written [4]. Could we implement the P/Q-part and see for the others later? --- Jura 21:58, 12 February 2020 (UTC)
Hi @Jura1:, the change has now been deployed. Can you test if everything works as you expected? Lea Lacroix (WMDE) (talk) 08:43, 19 February 2020 (UTC)
Hi @Lea Lacroix (WMDE):, it does: thanks for your follow-up. I added it to the query available as compare with "properties for this type"-statements at talk pages for given names. --- Jura 09:35, 19 February 2020 (UTC)

tainted reference change reason

Regarding the new tool with the pop-up warning when a value supported by a reference is changed, I wonder if it might be possible/useful to include a drop-down list of checkboxes to gather information on why the user has changed the value -- eg 'old value matched to incorrect Wikidata item', or 'changed value in reference', or 'old value misinterpreted reference', etc, or 'other, please specify' with a text field.

I think this could be useful, to understand what valid reasons may exist for a referenced value to be changed, and gather statistics on them. If the claimed reason was also be auto-added to the edit summary, this could also make bad-faith vandalism easier to identify and follow. Jheald (talk) 09:54, 26 February 2020 (UTC)

Thanks for your feedback, I added it to our collection of suggestions regarding tainted references. Lea Lacroix (WMDE) (talk) 17:39, 26 February 2020 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2020/02&oldid=1142574346"