Accessing items with particular statements via Lua
Problem: A number of Wikidata's properties are essentially inverses—"part of administrative territory" and "contains administrative territory", "has part" and "part of", and so on. This redundancy, however, has led in many instances, and has the potential in many others, to cause an excess amount of bloat—thousands of "owner of" values caused items for Japanese prefectures and India's rail operator to be briefly unmanageable, thousands of "part of" values caused items for chemical elements to be briefly unmanageable, thousands of values for "child astronomical body" are currently making it difficult to manage the item for the Sun, and lots of values for "head of government" on an item X are frequently redundant and go out of sync with the list of items with "position held" (head of government of X). A number of proposals to delete some inverse properties havebeenstalled precisely because they are required for other wikis to display information that is otherwise stored on the target items themselves.
Proposed solution: provide in the Lua interface a function similar to the "haswbstatement" keyword in Wikidata's text search: supposing this function were named "haswbstatement", a call in Lua to haswbstatement('P39', 'Q839078') would return a list of items for individuals that are or were Prime Ministers of Canada.
Who would benefit: all other Wikimedia wikis which use Lua to access Wikidata's data
More comments: ** The Wikidata Query Service's Linked Data Fragments endpoint already allows a property (as a predicate) and an item or other value (as an object) to be specified so that items with the resulting statement (as subjects) can be returned and possibly paged through. (Here 'subject', 'predicate', and 'object' refer to any such entity within Wikidata's RDF triple store.) In addition to the functionality desired above, if it is possible, being able to ask for predicates matching a subject-object pair might also be useful.
There is a gadget which displays "inverse properties", but this does not inherently solve the inverses problem that client wikis have since it does not run on the server side.
IMO, this is the biggest systemic issue with Wikidata data models and cuts across every model and almost every relational property. Having an ad hoc mishmash of properties, some with inverses and some not, is a nightmare for using the data, maintaining it, reasoning about it (how sure am I all the inverses match?) as well as making it painful to create items because you get constraint violations for missing inverses. Which also shows something, somewhere already knows the answer! Inductiveload (talk) 23:09, 12 January 2022 (UTC)[reply]
As a music editor on WD I see a lot of bad modelling stemming from the needs of different Wikipedias. This reads like something that would greatly benefit both projects. Moebeus (talk) 11:31, 21 January 2022 (UTC)[reply]
Having manually defined inverse properties is redundant (in a bad way) and unsustainable. Conceptually, every property defines its own inverse automatically. If performance is the problem, then the solution should be at a low level--for example, the system could define a hidden entry for a property inverse and maintain a cache automatically, and none of this should be visible to the user. Silver hr (talk) 20:00, 2 February 2022 (UTC)[reply]
Making inverse relationships/statements visible in the Wikidata GUI is already possible with the built-in Gadget "[ ] relateditems: Adds a button to the bottom of item pages to display inverse statements." Geert Van Pamel (WMBE) (talk) 12:10, 3 February 2022 (UTC)[reply]
Good idea; I've encountered similar issues of redundancy, not due to inverse claims, but due to poor aggregation of identical values, such as stating the time zone for each of 100,000 villages and other locations in China, when all of China runs on the same time zone anyway, as well as a rumored desire among WP editors to hand-pick property claims based on what looks good in WP infoboxes (such as preferring P361 part of over P279 subclass of as a matter of style, in spite of the different ontological implications). This problem is essentially what got me into Lua programming and trying to model the rules for implied property values (including inheritance and transitivity) in Swedish Wikipedia a year and a half ago, but I didn't have the time to continue working on it then; I may resume it later. Your suggested approach looks very much in line with mine. --SM5POR (talk) 07:16, 4 February 2022 (UTC)[reply]
Support - this would be really useful for infobox development work, but this is quite tricky as it basically means running a query on Wikidata to get a list of the results (which would actually be really useful in Lua as well!). Thanks. Mike Peel (talk) 18:47, 28 January 2022 (UTC)[reply]
Support I'd love to see this implemented and look very much forward to voting in favour of deletion for all those useless inverse properties which solely exist to allow efficient Lua-querying. Nw520 (talk) 23:28, 29 January 2022 (UTC)[reply]
Support This approach would address several issues at once, not only individual items becoming unmanageable, but also the general layout of the class tree. SM5POR (talk) 07:24, 4 February 2022 (UTC)[reply]
Support Moebeus (talk) 18:23, 28 January 2022 (UTC)