Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Wikidata

< Community Wishlist Survey 2019
Community Wishlist Survey 2019
Wikidata
19 proposals, 231 contributors, 552 support votes
The survey has closed. Thanks for your participation :)



Ability to filter Watchlist in Wikidata via language

  • Problem: I have many items on my watchlist in Wikidata and I'm only able to evaluate the quality of edits of labels/descriptions/interwikilinks in German and English. Yet whenever there are changes in another language on the items I watch they show up and clutter my watchlist.
  • Who would benefit: All Wikidata editors who use the watchlist.
  • Proposed solution: Allow users to filter out changes in the watchlist that aren't in the languages in their babel box.
  • More comments:
  • Phabricator tickets: T43686, T141866, T90435
  • Proposer: ChristianKl (talk) 12:25, 3 November 2018 (UTC)Reply[reply]

Discussion

  • wikidata:User:Yair rand/DiffLists.js can do this to some extent if you include that script in your wikidata common.js (code: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Yair_rand/DiffLists.js&action=raw&ctype=text/javascript', 'text/javascript' ); // [[User:Yair rand/DiffLists.js]]). —MisterSynergy (talk) 13:30, 3 November 2018 (UTC)Reply[reply]
  • I support this request. The main issue is with added descriptions/aliases of other languages which I don't speak (Side benefit for this request: filtering out recent changes entries => less purges/reparsing?). eranroz (talk) 18:16, 10 November 2018 (UTC)Reply[reply]

Voting

Display reference in edit summary when a reference is added

  • Problem: Repost since this is still a problem: The edit summary for this diff does display that a reference was added, but not which reference it is. References can be unreliable, spam links etc. so having them be easy to monitor is desirable.
  • Who would benefit: People who patrol Wikidata items for problematic edits, since the content of the diff is immediately displayed.
  • Proposed solution: Add the content of the reference to the edit summary; in this case it would be "Added reference (imported from:English Wikipedia) to claim: mountain range (P4552): Andes (Q5456)"
  • More comments: I hope that this isn't too late. This feature would be useful as well if it displayed in crosswiki watchlists. There may be length issues when the reference is long.
  • Phabricator tickets:

Discussion

Voting

Sort claims of a property by date

  • Problem: Currently Wikidata do not sort claims of a property and it could cause terrible mess. Many templates on a lot of Wikipedias load their parameters from Wikidata, so there are thousands of articles where parameters (e.g. awards) aren't in ordinal scale (but they should be). Fixing is very hard or almost impossible, because the only way to do it is deleting and re-adding every claims.
Two examples:
Sergei Movsesian (Q460020) has more than a thousand ELO rating claims, sorting them without any automatic solution would be impossible.
Hermann Kövess von Kövessháza (Q78544): a person has won an award (A, B, C, D, E) year by year and the Wikidata item looks like this:
  • B (2001)
  • C (2002)
  • D (2003)
  • E (2004)
Now, if I want to add A (2000), I have to delete all of them, put 'A' to the first place and then add the others.
  • Who would benefit: Editors of Wikidata, plus readers of Wikipedias which are using templates loading information from Wikidata.
  • More comments:

Discussion

Voting

Solution to the ‟Bonnie and Clyde” problem

  • Problem: Wikidata can only link one article per language. There are, however, cases where a single article in one language corresponds to two articles in some other language. A prototypical instance is Bonnie and Clyde, with most languages having an article about the duo Bonnie and Clyde, some having an article about Bonnie Parker, and some having an article about Clyde Barrow (see also d:WikiProject Cross Items Interwikis). The articles about the individual bank robbers cannot (at least not both) link to the many articles about the duo, which exist in many languages, so it is hard to find the corresponding articles in those other languages when coming from such a single-person article. (Other relevant situations I can think of are misfitting taxonomies; while e.g. in biology the international research community has agreed upon a common hierarchy, this is not the case in many other fields, where it might turn out to be unclear or questionable which term in another language an article should be linked to when there is no perfect match.)
  • Who would benefit: Potentially all readers, exact number of relevant cases unknown so far
  • Proposed solution: While allowing Wikidata items to link more than one page per language is probably not a viable option, having language links as displayed in Wikipedia side-bars link to more than one article in another language should be principally possible. A language link to a language version in which more than one article is linked to the current one could, for instance, show a pop-up menu instead of directly navigating to the foreign-language article in question. More important than the GUI design for this feature would be the question where to take the target articles from. In the case of Bonnie and Clyde, a language link connecting Bonnie Parker articles (or Clyde Barrow articles, respectively) with Bonnie-and-Clyde articles could be obtained from the ‟part of” relation (d:P361). A sufficiently general solution would perhaps allow for a set of relevant Wikidata relations, to be determined by the Wikidata community, that are used to populate ‟multiple” interwiki connections of the proposed form. Even if the ability to have ‟multiple” interwiki connections is undesired, the Wikidata relations could still be used to connect articles to languages for which a direct equivalent has not yet been registered in Wikidata (either because a corresponding artcile has not yet been linked or because such a corresponding article does not yet exist).
  • More comments:
  • Phabricator tickets: T54564
  • Proposer: Lothar Scherners (talk) 17:04, 8 November 2018 (UTC)Reply[reply]

Discussion

I don't think the other way should be done via a property based way. Lets say we have en:"Bonnie"->de:"redirect:Bonnie-and-Clyde" and en:"Clyde"->de:"redirect:Bonnie-and-Clyde" but no existing link from the de:"redirect:Bonnie-and-Clyde" to English. We could have a plugin that provides a page that lists en:"Clyde" and en:"Clyde" that gets automatically generated (e.g. no Wiki page) when a user clicks on `English` in the interwikilink list. ChristianKl ❪✉❫ 18:38, 14 November 2018 (UTC)Reply[reply]
  • Another example could be lists such as List of something A to E on xy.wiki and List of something A–C on yx.wiki. (Same list, but different alphabetic seperation into sub-lists.) I've noticed couple of articles/items like this, these lists often doesn't have any interwiki. But it might be comment for other discussion. Regards, — Draceane talkcontrib. 21:51, 18 November 2018 (UTC)Reply[reply]

FYI: The Wikidata folks say that they could commit to analyze and solve the problem, but not necessarily with the solution offered here. Ryan Kaldari (WMF) (talk) 23:08, 14 November 2018 (UTC)Reply[reply]

See also Community Wishlist Survey 2019/Wikisource/Create integrated interwiki mechanism for Wikisource for a specific aspect of this problem. Cheers, VIGNERON * discut. 12:37, 18 November 2018 (UTC)Reply[reply]

Voting

  •   Oppose I think that we should find a way to deprecate P2959 instead. --Liuxinyu970226 (talk) 04:18, 17 November 2018 (UTC)Reply[reply]
    • The problem of P2959 related to, however independent from, the problem we are talking about here. With a full overhaul to the wikidata structure, both problems will be solved immediately, however it seems like no one is actually willing to spend serious efforts on improving wikidata, I guess we have no other choice than to accept that only minor improvement will be made and hope that it will become more useful after accumulating all the minor improvements after a decade or so. From this perspective, the proposal doesn't goes against resolving the problems related to P2959. Hence   Support C933103 (talk) 07:04, 17 November 2018 (UTC)Reply[reply]
  •   Support Jc86035 (talk) 10:47, 17 November 2018 (UTC)Reply[reply]
  •   Support Libcub (talk) 11:38, 17 November 2018 (UTC)Reply[reply]
  •   Support Walter Klosse (talk) 13:28, 17 November 2018 (UTC)Reply[reply]
  •   Support JAn Dudík (talk) 20:33, 17 November 2018 (UTC)Reply[reply]
  •   Support Zabia (talk) 10:15, 18 November 2018 (UTC)Reply[reply]
  • Partial   Support. I support this proposal in the sense that the issue needs to be looked into and be resolved within reasonable time, yet not necessarily in the exact same manner as suggested by the proposal. --Beat Estermann (talk) 16:33, 18 November 2018 (UTC)Reply[reply]
  •   Support Per Beat Estermann — Draceane talkcontrib. 17:21, 18 November 2018 (UTC)Reply[reply]
  •   Support Dvorapa (talk) 19:23, 18 November 2018 (UTC)Reply[reply]
  •   Support Per Beat Estermann Pharos (talk) 05:43, 19 November 2018 (UTC)Reply[reply]
  •   Support Mend My Way 23:51, 19 November 2018 (UTC)Reply[reply]
  •   Support Toto256 (talk) 06:39, 20 November 2018 (UTC)Reply[reply]
  •   Support Novak Watchmen (talk) 15:11, 21 November 2018 (UTC)Reply[reply]
  •   Support with "FYI: The Wikidata folks say that they could commit to analyze and solve the problem, but not necessarily with the solution offered here. Ryan Kaldari (WMF) (talk) 23:08, 14 November 2018 (UTC)" in mind. Topper13009 (talk) 20:34, 21 November 2018 (UTC)Reply[reply]
  •   Support GPSLeo (talk) 20:19, 22 November 2018 (UTC)Reply[reply]
  •   Support BugWarp (talk) 14:58, 23 November 2018 (UTC)Reply[reply]
  •   Support NaBUru38 (talk) 18:30, 23 November 2018 (UTC)Reply[reply]
  •   Support Nvrandow (talk) 20:18, 23 November 2018 (UTC)Reply[reply]
  •   Support Dreamy Jazz (talk) 13:27, 26 November 2018 (UTC)Reply[reply]
  •   Support Olea (talk) 21:28, 29 November 2018 (UTC)Reply[reply]

Navigate Wikidata items through category items

  • Problem: At the present moment Petscan allows the user to input one or more categories of one single project (e.g. en.wikipedia, it.wikipedia ...) and a depth (e.g. 0, 1, 2 ...) and find all the items containing one sitelink which bellongs to this category or its subcategories. However, the user has to input one by one all the categories regarding the same topic in different projects (e.g. en.wikipedia - Ancient Greece, it.wikipedia - Antica Grecia ...; the most important categories exist in tens of projects!) and cannot easily compare the results for each project.
  • Who would benefit: Wikidata users who try to find and merge duplicates (the user can explore in one single list all the items belonging to the same categories in all the projects); Wikipedia users who want to translate articles regarding a specific topic (the user can see in one single list all the items regarding this topic in all the project)
  • Proposed solution: The main idea is the possibility to explore at the same time all the articles belonging to a category which is common to two or more projects: in my opinion, the best option would be integrating this function into Petscan, but it may also be a new independent tool. The tool should be like this: the user inputs a category item (e.g. d:Q7215882) and a depth (e.g. 0, 1, 2 ...); given these inputs, the tool should give a list of all the items containing at least one sitelink which belongs to a category that is a sitelink of the category item. Possible filters: by type of project (all projects; only Wikipedias; only Wikisources ...); by the date of the articles' creation.
  • More comments:
  • Phabricator tickets:
  • Proposer: Epìdosis 08:50, 4 November 2018 (UTC)Reply[reply]

Discussion

Voting

Gather metadata of ISO/ASTM/EN... standards

  • Problem: We do not have items for many ISO/ASTM/EN... standards. This is usefull for projects because these standards list the official names and definition of some other items such as material properties.
  • Who would benefit: Wikidata projects and the community as a whole.
  • Proposed solution: Write a script that crawl ISO/ASTM/CEN sites for standards metadata.
  • More comments:
  • Phabricator tickets:
  • Proposer: Thibdx (talk) 17:27, 11 November 2018 (UTC)Reply[reply]

Discussion

  •   Comment @Thibdx: I already have a simple scrapy script that dumps ISO data into a CSV file. The time consuming part is not having a model for ISO standards, and not having an easy and efficient way to write data back into Wikidata (one edit per item with multiple statements, not Pywikibot's one edit per minor change). You can copy and have a look at the spider (especially the xpath rules) at [1]. Dhx1 (talk) 12:46, 19 November 2018 (UTC)Reply[reply]

Voting

Link labels/aliases of Q-items to lexemes

  • Problem: There is no easy way to navigate from Q-items to their connected L-items
  • Who would benefit: All wikidata editors, specially those working with lexicographical data.
  • Proposed solution: it would be nice to have a script or gadget that converts the labels/aliases of a Q-item into links to L-items that are connected with "item for this sense (P5137)". So basically what it should do is to see if the text of any of the forms of the linked L-items matches 1-to-1 with any of the label/aliases of the Q-item for that language, and if it does, it should convert the text of the label/alias into a link to the L-item.
  • More comments: Normally there should be only one exact match per label, but there is at least a known exception: both "gwenn (L30900)" (noun) and "gwenn (L30901)" (adjective) link to "white (Q23444)". For cases like this it would be nice if the additional L-items are linked with a superindex if possible, if not then it is ok to just link one of them for a first version.
  • Phabricator tickets:
  • Proposer: Micru (talk) 10:19, 7 November 2018 (UTC)Reply[reply]

Discussion

There is a team with six developers, a engineering manager, a product manager and a liaison devoted to lexicographical data. This proposal is addressed to Tech Team, so on which aspect of your proposal do you think Tech team can help? Noé (talk) 16:36, 17 November 2018 (UTC)Reply[reply]

Voting

Expand automatic edit summaries

  • Problem: When one's watchlist is set to display edits made on linked statements on Wikidata, they are always displayed in numerical code even if labels exist on the Wikidata entries. For example, this diff on enWikipedia's watchlist displays as "Created claim: Property:P4552: Q5456; Added reference to claim: Property:P4552: Q5456" whereas on Wikidata it's two diffs with two edit summaries, "Added reference to claim: mountain range (P4552): Andes (Q5456)" and "Created claim: mountain range (P4552): Andes (Q5456)".
  • Who would benefit: People who use their watchlist on a non-Wikidata project to monitor changes to the Wikidata item linked to an article they have watchlisted. On enWikipedia some templates draw information from Wikidata so making it easy to monitor the edit content may be beneficial.
  • Proposed solution: The watchlist should display the language label if it does exist in lieu of the numerical code; in this case the summary should be "Created claim: Property:mountain range: Andes; Added reference to claim: Property:mountain range: Andes" perhaps with the "property" omitted if it makes the summary overlong.
  • More comments: This is a repost of Community Wishlist Survey 2017/Wikidata/Expand automatic edit summaries as I still think it could greatly increase the usefulness of Wikidata.
  • Phabricator tickets: phab:T108688; phab:T171027 may be worth paying attention to since it's a technical issue that could impact on this project.

Discussion

Voting

Improvements to the reliability of Wikidata

  • Problem: Wikidata is often considered unreliable as a data source due to vandalism and a lack of adequate sourcing. In spite of these issues, Wikidata is still used in infoboxes across Wikipedias, even though it can be difficult for Wikipedia editors to edit Wikidata; and on many wikis references are omitted entirely from Wikidata infoboxes, making it more complicated to check the veracity of data.
  • Who would benefit: Wikidata; Wikipedia articles (infoboxes, descriptions, external database links, etc.) and other users of Wikidata data
  • Proposed solution: In order to verify existing data, it would be helpful to make sure that references used in Wikidata are shown when statements are used in Wikipedia infoboxes and the like,[note 1] and it could also be helpful to allow editors of both Wikipedia and Wikidata to add maintenance tags with a script (e.g. "[this statement] might not be true" or "needs a source"), replicating the utility of Wikipedia's venerable [citation needed]-style tags. Particularly for data which can't be verified easily using secondary sources or constraint violations, like geographic coordinates, it would also be beneficial to have tools to easily find errors (e.g. wrong coordinates) or oddities (e.g. weird precision) in the data.

Notes

  1. ↑ This would probably involve editing the Wikidata-related Lua modules for each wiki, or by creating a new module to incorporate all their features and localizing it across all wikis (there are currently multiple disparate modules in use, even on individual wikis).
  • More comments: Originally page protection enhancements were part of this proposal. These are now part of a separate proposal.
  • Phabricator tickets:
    • phab:T209242 – For Lua modules across Wikipedias, allow display of sources from Wikidata and filtering of unreferenced statements across all Wikidata infoboxes (11 November 2018)
    • phab:T209237 – Gadget for Wikidata and Wikipedia users to add maintenance tags to Wikidata items (11 November 2018)
    • phab:T209241 – Creation of software to auto-detect errors or oddities in internal or unreferenceable Wikidata statements, e.g. images, geographic coordinates (11 November 2018)
    • Related: phab:T148928 – Wikidata integration for proveit gadget (23 October 2016)
  • Proposer: Jc86035 (talk) 20:24, 29 October 2018 (UTC)Reply[reply]

Discussion

Many of the comments discuss page protection because it was originally part of the proposal before being split into Partial and multi-item protection for Wikidata items. Jc86035 (talk) 16:28, 16 November 2018 (UTC)Reply[reply]
Discussion from before the start of voting. Jc86035 (talk) 11:39, 17 November 2018 (UTC)Reply[reply]

One issue that I hit recently is outdate Wikipedia imports. For instance, a (wrong) set of coordinates was imported from de.wp. In the mean time, the data was corrected on Wikipedia, but not Wikidata. A lot of additional work can be done on coordinates, such as supporting areas, which in turn allows checks such as "is this coordinate within the area indicated by the P31 of the item?"--Strainu (talk) 21:55, 29 October 2018 (UTC)Reply[reply]

@Strainu: I agree; I've added a sentence about this to the proposal. Jc86035 (talk) 05:53, 30 October 2018 (UTC)Reply[reply]
  • One possibility would be to add a button "doubtful" to the right of the "edit" button. Then others could query the doubtful statements (possibly using Wikidata Query) and fix the problems by deleting or editing the bad quality or wrong statements. Geert Van Pamel (WMBE) (talk) 10:47, 4 November 2018 (UTC)Reply[reply]
    @Geertivp: I think that sounds like a good idea; such a feature could be used to add preset tags like in Wikipedia articles (e.g. citation needed, needs update, doubtful/dubious), possibly by making the script add qualifiers to statements. I have proposed a property for this information, since one does not yet exist. Jc86035 (talk) 11:16, 4 November 2018 (UTC)Reply[reply]
    See also phabricator:T139583 --Lydia Pintscher (WMDE) (talk) 13:51, 9 November 2018 (UTC)Reply[reply]
  • There is a way in Lua to ensure that only sourced properties are displayed in templates. That could be a first move for critical pages. Another idea could be to convert URL listed as sources into special items that could be reviewed to status on the source quality. This could be partially automated using the source base URL. Pubmed is reliable. CNN is quite reliable. The Onion is fake. -- Thibdx (talk) 00:08, 5 November 2018 (UTC)Reply[reply]

Define Quality of external source and double check

I think Open Free Knowledge most important component is having references to external trusted sources. I therefore would like to see

  • in the Wikipedia infobox
    • that the reader easy can see
      • that a fact is based on an external source
      • the quality of source used - we need to find a way to describe quality of a source and our experience using it
      • that we have confirmed that this fact is the same as an external fact compare Listeria list that runs daily comparing Wikidata with Nobelprize.org link see example diff
    • that we also visualize in the Wikipedia infobox a mismatch with an external source found in Wikidata

- 09:56, 30 October 2018 (UTC)

@Salgo60: Added a sentence and a note to the proposal. The English Wikipedia's WikidataIB Lua module is able to filter statements based on whether or not they have a source which is not to a WMF project, but I don't think it's able to display sources from Wikidata. Jc86035 (talk) 13:21, 30 October 2018 (UTC)Reply[reply]
I think the quality of a source might be difficult to categorize, although perhaps one could filter out sources which are blacklisted by the English Wikipedia for being unusable. Jc86035 (talk) 13:37, 30 October 2018 (UTC)Reply[reply]
Thanks If you listen to the vision of en:Tim Berners-Lee then in an en:linked data world then I as a reader should be able to select what sources I trust... I feel Trust is very important and we need to think about how Wikipedia explains to the reader the quality of used sources. One vision could also be that I as an reader of Wikipedia should be able to see what facts in the article I read is based on sources I trust - Salgo60 (talk) 13:44, 30 October 2018 (UTC)Reply[reply]
  • Basically your solution to vandalism is to prevent Wikipedia editors without existing Wikidata edits from removing vandalism that might show up on Wikipedia for critical fields. That sounds to me like a bad plan. ChristianKl (talk) 18:03, 2 November 2018 (UTC)Reply[reply]
    @ChristianKl: Not necessarily (although that specificially would probably not be a good idea). Obviously what exactly to protect would be decided by Wikidata admins. You might
    • prevent a class of users from editing a group of pages;
    • prevent a class of users from editing specific parts of a group of pages;
    • prevent a class of users from adding statements without references on a group of pages;
    • prevent a class of users from adding statements without references on specific parts of a group of pages;
    • prevent a class of users from editing existing data for a group of pages;
    • prevent a class of users from editing some existing data for a group of pages.
    The latter two would probably be quite difficult to implement properly without preventing some registered users from reverting vandalism and without preventing some users from editing the data that they just added, although perhaps they could be limited to the scope of statements with existing references which have URLs or which cite another item.
    I think some of these would also be particularly useful for items about scientific articles, since usually after import they shouldn't need to be edited manually (and edits are likely to come from Special:Random). Jc86035 (talk) 05:19, 3 November 2018 (UTC)Reply[reply]
I would forbid that it could be put "imported from Wikimedia project (P143)", because we are not a primary source and can not serve as a reference in certain affirmations. --Vanbasten 23 (talk) 11:11, 4 November 2018 (UTC)Reply[reply]

Jc86035 Hello. Thanks for submitting a proposal for the wishlist survey. This proposal is very broad and proposes a number of different solutions. I'd encourage you to make the problem statement more focused on specific issues (like Ability to easily import references) that are individually actionable. Otherwise it will be very hard for us to focus our work on what's important. Thank you. -- NKohli (WMF) (talk) 23:40, 5 November 2018 (UTC)Reply[reply]

@NKohli (WMF): Would it be sufficient for me to order the Phabricator tickets (once I create them) from most important to least? I think they're all important, although some of them would certainly have a bigger impact than others. Jc86035 (talk) 14:08, 6 November 2018 (UTC)Reply[reply]
@Jc86035: Just writing down what you think are the steps to solve this in order of importance would be fine. Phabricator tickets would be nice but aren't necessary. I can't say we will be able to do everything but having the proposed solution in order of importance according to you would be helpful. I see Geert Van Pamel and Lydia suggested a solution above. You could also incorporate that in the proposal if you think it's a good idea. Thank you. -- NKohli (WMF) (talk) 22:49, 9 November 2018 (UTC)Reply[reply]
@Jc86035: Thanks for trimming this down. I think the remaining phab tickets are more on the scale of what Community Tech could work on. Ryan Kaldari (WMF) (talk) 21:04, 15 November 2018 (UTC)Reply[reply]
@Jc86035: I think taking out the crossed-out sentences will make this a lot more readable. Thank you. -- NKohli (WMF) (talk) 21:42, 15 November 2018 (UTC)Reply[reply]

Voting

More fine-grained diffs for Wikidata

  • Problem: Wikidata diffs (item changes views) are currently only show which statement/reference/description/etc. changed, they don’t highlight what exactly changed within it. For example, in this diff, only one word was changed (the first one in the parentheses), but the whole description is highlighted with the same style which shows the actually changed parts on wikitext pages. (I had to use Navigation Popups to find the actual changes.) Here only the first snak changed, but the whole reference is highlighted (more or less). (The hash is also different; I don’t know if it’s because of the bot edit.) Here only the day changed, but nothing is highlighted(!).
  • Who would benefit: Wikidata users patrolling edits.
  • Proposed solution: Create more fine-grained diffs.
  • More comments: For string values (including labels/descriptions/aliases as well as string/external identifier/URL/formula/etc. datatypes), it seems pretty easy as the wikitext diff engine can be reused. Time and quantity values are a bit trickier, but even more needed, as it’s much harder to use an external diff software. It doesn’t make any sense for entity values such as item, property, lexeme etc.
  • Phabricator tickets: Any? It’s quite hard to search for this on Phabricator.
  • Proposer: Tacsipacsi (talk) 21:28, 10 November 2018 (UTC)Reply[reply]

Discussion

Voting

Statements with deprecated and preferred rank should be much easier to identify in the Wikidata item pages

  • Problem: There is hard to distinguisch which statements have preferred and wich deprecated rank. Usually the best ranks are used in queries and in other wiki projects, but these are not easilly to distinguish. On the other side deprecated satements are usually not of big importance, but visualizing them in the same manner like statements with normal and preferred rank complicates the readibility.
  • Who would benefit: The acceptance of wikidata statements in other wiki projects, the wikidata projects itself (editors and users can more easylly distinguish between ranks).
  • Proposed solution: One possible solution would be that in SQID
  • More comments:
  • Phabricator tickets: T87327, T139081, T198907
  • Proposer: Datawiki30 (talk) 20:57, 7 November 2018 (UTC)Reply[reply]

Discussion

  • Whilst not taking away from your request, which I think makes good sense, deprecated statements can be made a bit more obvious by adding a reason for deprecated rank (P2241) qualifier.
The design of the visual distinction would need some care, on the one hand to make the unusual rank more obvious; but on the other hand still being quite subtle, to avoid too much damaging the visual unity and visual flow of the page. For example, Reasonator distinguishes quite strongly between statements of different rank, but I find its very pronounced bold for preferred items (see eg: Glasgow - Population [2]) to be overdone and distracting. Jheald (talk) 15:36, 9 November 2018 (UTC)Reply[reply]
  • A pink pastel and a green pastel for deprecated and preferred ranks might be a nice way to meet the intent of this wishlist item. --Izno (talk) 17:53, 9 November 2018 (UTC)Reply[reply]
  • I’ve added phab:T198907. In that task you can find CSS snippets to put into your Wikidata common.css which highlight both ranks. —MisterSynergy (talk) 01:33, 17 November 2018 (UTC)Reply[reply]

Voting

Indicate when Wikidata sitelink is to a redirect

  • Problem: The Wikidata community has now decided that sitelinks to (some) redirects should be allowed. (see RFC;subsequent discussion; 25,000 current uses of Template:Wikidata redirect on en-wiki).
    Where a Wikidata item links to a page that is a redirect on a particular wiki, it would be good if this was indicated on the Wikidata page; and by that wiki's entry in the sidebar interwiki links section of its corresponding Wikipedia pages. (An 'R' on a red circle might be appropriate next to the link, in at least some languages)
  • Who would benefit: Readers, who would know whether to expect the iw link to take them to an article with a matching subject; or whether the link would instead redirect to a related or umbrella topic.
  • Proposed solution: A relatively easy way to achieve this might be to use the "badge" mechanism, as currently used to identify interwikis to good and featured articles.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jheald (talk) 16:22, 9 November 2018 (UTC)Reply[reply]

Discussion

  • If I understand well the problem we have a script for this: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Matěj_Suchánek/checkSitelinks.js&action=raw&ctype=text/javascript' ); It show redirect and disambiguation. --ValterVB (talk) 19:01, 17 November 2018 (UTC)Reply[reply]
  • I suggest to indicate links to redirects in the iwl sidebar simply by using italics. This does not consume more space and would be in line with how redirects are rendered if they show up in categories. --(Matthiaspaul) 178.10.50.191 20:56, 17 November 2018 (UTC)Reply[reply]
The script add a simple, little icon (  or  ) is more clear that the use of italics. --ValterVB (talk) 21:13, 17 November 2018 (UTC)Reply[reply]

Voting

Automatically add inverse properties

  • Problem: It takes a long time to add inverse statements, father/mother -> child; owner of-> owned by; Spouse/Partner (including qualifiers start time, place of marriage, etc)
  • Who would benefit: Everyone editing
  • Proposed solution: Possibility to automatically add inverse statements, including qualifiers.
  • More comments:
  • Phabricator tickets:
  • Proposer: Germartin1 (talk) 16:43, 9 November 2018 (UTC)Reply[reply]

Discussion

  • At the moment we have d:User:Frettie/consistency check add.js, which allows to add inverse properties manually very quickly; of course doing it automatically would be great. --Epìdosis 14:47, 11 November 2018 (UTC)Reply[reply]
  • I actually wonder why inverse properties exist in the first place. It seems like they exist so that the inverse can be referenced on other wikis. Perhaps it would be better to make it easy to reference "the inverse" in a sidebar on Wikipedia instead of having to actually duplicate the data in the database. For instance, if there was a way to say that I want the items, where the "father" is this page, it would give me a list of the page's children. That seems like it would be way better than trying to ensure that the inverse statements are correct everywhere. U+1F360 (talk) 23:22, 14 November 2018 (UTC)Reply[reply]
  • @Germartin1: How would this handle qualifiers and references, and statements with the same value but different qualifiers (for e.g. adjacent stations, offices held)? I like this proposal (and added my support vote) but I think these are things that would need to be addressed in the implementation. Jc86035 (1) (talk) 08:11, 20 November 2018 (UTC)Reply[reply]
  • I found task T209559 which seems to cover what I mentioned above. --U+1F360 (talk) 04:22, 23 November 2018 (UTC)Reply[reply]
  • @Germartin1: I use Property:P1545 as qualifier in Property:P26. And i don't want to copy the Property:P1545 value! Manu1400 (talk) 04:15, 25 November 2018 (UTC)Reply[reply]

Voting

  •   Support --Tohaomg (talk) 18:22, 16 November 2018 (UTC)Reply[reply]
  •   Support As I added above, I think the reasons why we have inverse properties should be investigated first (as their might be a better technical solution that removes the need for them). But if removing them is impossible, then we should make it faster/easier to add them. U+1F360 (talk) 21:53, 16 November 2018 (UTC)Reply[reply]
  •   Support Consulnico (talk) 00:07, 17 November 2018 (UTC)Reply[reply]
  •   Support Meisam (talk) 00:07, 17 November 2018 (UTC)Reply[reply]
  •   Support Moebeus (talk) 01:06, 17 November 2018 (UTC)Reply[reply]
  •   Support Inverse properties are trivial case of properties which can be derived from other properties. See https://phabricator.wikimedia.org/T167521 for more complicated cases. We should have some mechanism to define such properties. Maybe as "read-only" properties automatically generated if some condition is met. One danger of inverse properties is thay have to be removed in 2 places. One thing we do not want is a property added by bot, so if a person deleted one of them bots re-adds them based on the other one. Jarekt (talk) 05:47, 17 November 2018 (UTC)Reply[reply]
  •   Support Hadrianus (talk) 10:39, 17 November 2018 (UTC)Reply[reply]
  •   Support Frettie (talk) 10:57, 17 November 2018 (UTC)Reply[reply]
  •   Support Libcub (talk) 11:35, 17 November 2018 (UTC)Reply[reply]
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)Reply[reply]
  •   Support Walter Klosse (talk) 11:56, 17 November 2018 (UTC)Reply[reply]
  •   Support Shisma (talk) 12:29, 17 November 2018 (UTC)Reply[reply]
  •   Support Naseweis520 (talk) 15:19, 17 November 2018 (UTC)Reply[reply]
  •   Support Blue Rasberry (talk) 15:34, 17 November 2018 (UTC)Reply[reply]
  •   Support Make this optional, and only for logged in users. Micru (talk) 16:19, 17 November 2018 (UTC)Reply[reply]
  •   Support Kette~cawiki (talk) 17:40, 17 November 2018 (UTC)Reply[reply]
  •   Support Crazy1880 (talk) 17:55, 17 November 2018 (UTC)Reply[reply]
  •   Support Theklan (talk) 18:20, 17 November 2018 (UTC)Reply[reply]
  •   Support Pichpich (talk) 19:01, 17 November 2018 (UTC)Reply[reply]
  •   Support Shev123 (talk) 19:51, 17 November 2018 (UTC)Reply[reply]
  •   Support also "has part" - "part of" and similar. Perhaps the properties could be "weak ones" - autogenerated, unless someone overrides them? Andree.sk (talk) 19:58, 17 November 2018 (UTC)Reply[reply]
  •   Support Property P190 (twinned administrative body) would be anaother good example Gelli1742 (talk) 20:23, 17 November 2018 (UTC)Reply[reply]
  •   Support JAn Dudík (talk) 20:34, 17 November 2018 (UTC)Reply[reply]
  •   Support Nk (talk) 20:39, 17 November 2018 (UTC)Reply[reply]
  •   Support Metrónomo-Goldwyn-Mayer 21:11, 17 November 2018 (UTC)Reply[reply]
  •   Support Epìdosis 22:52, 17 November 2018 (UTC)Reply[reply]
  •   Support model and implement 1:1, 1:n, n:m relationships navigable in both directions as single entities and all operations (like add & remove) as atomic, not as two inverse properties (which exposes an implementation detail). The names of the relationship's ends still should make sense, like ownes and owned by.. Herzi Pinki (talk) 22:52, 17 November 2018 (UTC)Reply[reply]
  •   Support Nickw25 (talk) 23:18, 17 November 2018 (UTC)Reply[reply]
  •   Support Liuxinyu970226 (talk) 01:27, 18 November 2018 (UTC)Reply[reply]
  •   Support NMaia (talk) 11:01, 18 November 2018 (UTC)Reply[reply]
  •   Support As is is already checked if the reverse is missing, it would "just" need a confirm botton. --Eingangskontrolle (talk) 11:28, 18 November 2018 (UTC)Reply[reply]
  •   Support VIGNERON * discut. 12:38, 18 November 2018 (UTC)Reply[reply]
  •   Support Juandev (talk) 13:07, 18 November 2018 (UTC)Reply[reply]
  •   Support Jeb (talk) 15:51, 18 November 2018 (UTC)Reply[reply]
  •   Support —Beleg Tâl (talk) 16:17, 18 November 2018 (UTC)Reply[reply]
  •   Support Beat Estermann (talk) 16:42, 18 November 2018 (UTC)Reply[reply]
  •   Support — Draceane talkcontrib. 17:26, 18 November 2018 (UTC)Reply[reply]
  •   Support Schwede66 (talk) 17:49, 18 November 2018 (UTC)Reply[reply]
  •   Support Gerd Fahrenhorst (talk) 20:26, 18 November 2018 (UTC)Reply[reply]
  •   Support Hyperik (talk) 20:32, 18 November 2018 (UTC)Reply[reply]
  •   Support Wesalius (talk) 22:04, 18 November 2018 (UTC)Reply[reply]
  •   Support Viswaprabha (talk) 23:33, 18 November 2018 (UTC)Reply[reply]
  •   Support Zeromonk (talk) 09:31, 19 November 2018 (UTC)Reply[reply]
  •   Support katpatuka (talk) 10:45, 19 November 2018 (UTC)Reply[reply]
  •   Support Geraki TL 14:04, 19 November 2018 (UTC)Reply[reply]
  •   Support really this would be super helpful, not having inverse properties makes writing queries sometimes very confusing John Cummings (talk) 15:13, 19 November 2018 (UTC)Reply[reply]
  •   Support Hibm98 (talk) 16:43, 19 November 2018 (UTC)Reply[reply]
  •   Support Jmmuguerza (talk) 23:35, 19 November 2018 (UTC)Reply[reply]
  •   Support Jc86035 (1) (talk) 07:42, 20 November 2018 (UTC)Reply[reply]
  •   Support 朝彦 | Asahiko (talk) 07:54, 20 November 2018 (UTC)Reply[reply]
  •   Support Gareth (talk) 13:13, 20 November 2018 (UTC)Reply[reply]
  •   Support Vadimzer (talk) 17:26, 20 November 2018 (UTC)Reply[reply]
  •   Support Rachel Helps (BYU) (talk) 19:00, 20 November 2018 (UTC)Reply[reply]
  •   Support Joalpe (talk) 22:19, 20 November 2018 (UTC)Reply[reply]
  •   Support CAPTAIN RAJU(T) 22:58, 20 November 2018 (UTC)Reply[reply]
  •   Support Omotecho (talk) 03:35, 21 November 2018 (UTC)Reply[reply]
  •   Support Vulphere 05:13, 21 November 2018 (UTC)Reply[reply]
  •   Support At least checking and easily creating the other end for symmetrical properties (spouse, etc.) would be great. Note we'd also need to be careful with qualifiers. References should be carried over too. Laboramus (talk) 07:14, 21 November 2018 (UTC)Reply[reply]
  •   Support Acer11 (talk) 08:01, 21 November 2018 (UTC)Reply[reply]
  •   Support Ayack (talk) 09:15, 21 November 2018 (UTC)Reply[reply]
  •   Support β16 - (talk) 10:12, 21 November 2018 (UTC)Reply[reply]
  •   Support Geogast (talk) 13:36, 21 November 2018 (UTC)Reply[reply]
  •   Support Novak Watchmen (talk) 15:10, 21 November 2018 (UTC)Reply[reply]
  •   Support Hienafant (talk) 19:47, 22 November 2018 (UTC)Reply[reply]
  •   Support TomT0m (talk) 19:53, 22 November 2018 (UTC) Although something more ambitious like inferred statement would be really cool. I guess it’s a step towards that goal :) @Markus Krötzsch: TomT0m (talk) 19:53, 22 November 2018 (UTC)Reply[reply]
  •   Support I agree Poslovitch (talk) 20:34, 22 November 2018 (UTC)Reply[reply]
  •   Support Thibdx (talk) 20:47, 22 November 2018 (UTC)Reply[reply]
  •   Support Wostr (talk) 20:50, 22 November 2018 (UTC)Reply[reply]
  •   Support. Useful. Nomen ad hoc (talk) 21:51, 22 November 2018 (UTC).Reply[reply]
  •   Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)Reply[reply]
  •   Support Sahaquiel9102 (talk) 17:34, 23 November 2018 (UTC)Reply[reply]
  •   Support Nvrandow (talk) 20:04, 23 November 2018 (UTC)Reply[reply]
  •   Oppose (with the understanding that oppose votes are not counted here) per Arthur in full. I think this is useful for properties where the likelihood of introducing unnecessary bloat to items is very low, but I am against using this functionality with properties that have a strong likelihood for bloat (such as "part of", "has part", and most recently "owner of" and "owned by"). Mahir256 (talk) 21:07, 23 November 2018 (UTC)Reply[reply]
  •   Strong oppose per Mahir256 and Arthur.Winged Blades of Godric (talk) 06:21, 24 November 2018 (UTC)Reply[reply]
  •   Neutral Manu1400 (talk) 04:12, 25 November 2018 (UTC)Reply[reply]
  •   Support Ranjithsiji (talk) 22:27, 25 November 2018 (UTC)Reply[reply]
  •   Support — AfroThundr (u · t · c) 02:59, 26 November 2018 (UTC)Reply[reply]
  •   Support Sebastian.Dietrich (talk) 18:47, 26 November 2018 (UTC)Reply[reply]
  •   Support YFdyh000 (talk) 20:00, 27 November 2018 (UTC)Reply[reply]
  •   Support Mhmrodrigues (talk) 20:17, 28 November 2018 (UTC)Reply[reply]
  •   Support Only as optional, not as mandatory. It can be either per property (e.g. father/mother -> child is automatic, part of is not) or as an option (Preferences, pop-up etc.) — NickK (talk) 15:32, 30 November 2018 (UTC)