Allow access to some inverse statements through Lua and parser functions
Problem: Wikidata currently has more than 100 inverse properties, which are in some ways redundant: in theory, if two statements are exact inverses of each other, one should be unnecessary. It is possible to use WDQS (and user scripts, etc.) to find inverses of statements (those matching a given value and property), but this can't be done normally on Wikimedia wikis, which means that a lot of data is effectively impossible to use on wikis. Furthermore, property proposals are occasionally declined because the properties would be unnecessary for querying, even though they would be useful for infoboxes and other templates. Allowing inverses to be accessed would significantly reduce the complexity of using data from certain properties, and would reduce the maintenance burden for properties which currently have inverses.
Who would benefit: Template designers, Wikidata editors, Wikimedia readers (particularly on smaller wikis)
Proposed solution: Creation of a parser function, Lua function and/or similar in Wikibase to allow inverse statements to be accessed (with a hard limit on how many entities can be returned from one query), automatic display of inverses on Wikidata item pages and other entity pages (also with a hard limit), and some way of integrating the data that is currently stored using inverse label item (P7087). Alternatively, another approach to allowing the data to be surfaced could be taken if that would be more technically feasible.
More comments: See also Community Wishlist Survey 2019/Wikidata/Automatically add inverse properties, which targeted the same problem but suffered from the proposed solution's lack of clarity. It was within the top 10 until an objection was raised on technical grounds. Some databases, such as MusicBrainz, already display their "inverses" automatically, so it may be possible to use the approaches of such databases as inspiration or as a basis.
Instead of enforcing data integrity by maintaining bidirectional relations and navigation along them by the software, this is left to the editors. As a help provided by the software, endless lists of constraint violations and popup messages are created. Enough said? I more and more get the impression that Wikidata is not at all focused on manual editing. Strong support for any solution on bidirectional relations. --Herzi Pinki (talk) 19:32, 20 November 2020 (UTC)[reply]
This would be very helpful. It will both help making infoboxes with content with Wikidata, remove a reason to have redundant data on Wikidata, and help to get more consistent data. For some properties the same statements would be also be displayed and be editable on the items pages for both the subject and object. --Dipsacus fullonum (talk) 14:00, 21 November 2020 (UTC)[reply]
This would be good, but I am worried that these would probably be 'expensive' queries. Some sort of caching is probably needed. On the other hand, the inverse properties can be bot-maintained on Wikidata, and we could get a lot stricter with insisting that the inverse property always exists (e.g., with bots enforcing the inverse properties, or removing values that are missing the inverse, on a daily basis). Thanks. Mike Peel (talk) 20:23, 28 November 2020 (UTC)[reply]
@Mike Peel: I think the latter would be the most tenable alternative, although it would obviously be more difficult to maintain, and I think it would be outside the scope of the wishlist survey. I don't think it would make sense to pursue it unless a more permanent solution that involves changes to Wikibase is definitively ruled out. Jc86035 (talk) 10:31, 29 November 2020 (UTC)[reply]
Sorry, no, bot-maintained inverses are a BAD idea. A vandal adds a bad statement. Bot adds inverse. Vandal's statement is reverted. Bot re-adds the original as it's the inverse of the previously bot-added inverse. And other variations on the same problem. I know you're doing some of these already, but it should not be expanded unless all these complexities are clearly addressed. ArthurPSmith (talk) 15:02, 30 November 2020 (UTC)[reply]
@ArthurPSmith: In those cases the editor needs to remove both of the inverse properties, not just one of them. It's a little bit more work but it's not that much. However, I'm all for a better solution here! Thanks. Mike Peel (talk) 16:50, 30 November 2020 (UTC)[reply]
@Mike Peel: Realistically, would the queries being expensive actually be a significant problem for the parser functions? MediaWiki already has several expensive parser functions, which the proposed parser functions seem roughly comparable to, and it seems unlikely to me that a single infobox would ever need to have 100 "expensive" queries for inverse statements. Given w:WP:PERF and MediaWiki's already-aggressive page caching, I would hope that this wouldn't be a problem inherent to the proposal. Jc86035 (talk) 17:18, 30 November 2020 (UTC)[reply]
I'm more worried about the CPU time it would take rather than whether it is classified as 'expensive' in mediawiki terms. The infoboxes on Commons already occasionally run into the 10s limit, and I know de.wikivoyage has similar issues. Thanks. Mike Peel (talk) 17:30, 30 November 2020 (UTC)[reply]
Support Inverse properties are a huge PITA and in most cases outdated since understandably nobody wants to take care of information which pretty much already exists. Nw520 (talk) 22:59, 8 December 2020 (UTC)[reply]
Support Yair rand (talk) 22:24, 8 December 2020 (UTC)