Community Wishlist Survey 2022/Wikidata/Accessing items with particular statements via Lua

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 have been stalled 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.
    • Some initial concerns about inverses were raised as ArthurPSmith's and my own oppose votes on this 2019 Wishlist proposal, and this proposal would cut the scope of properties to which this current Wishlist proposal applies.
  • Phabricator tickets: phab:T199887, phab:T209559 (directly) phab:T185313 (indirectly)
  • Proposer: Mahir256 (talk) 22:54, 10 January 2022 (UTC)

Discussion

  • A perennial problem, which is why people keep proposing inverses to existing properties. Solving this would be very helpful. ArthurPSmith (talk) 19:48, 11 January 2022 (UTC)
  • 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)
  • Would be very useful at least in ru-wiki Ghuron (talk) 17:47, 19 January 2022 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)

Voting

  •   Support Moebeus (talk) 18:23, 28 January 2022 (UTC)
  •   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)
  •   Support * Pppery * it has begun 18:57, 28 January 2022 (UTC)
  •   Support Inductiveload (talk) 20:01, 28 January 2022 (UTC)
  •   Support Izno (talk) 00:09, 29 January 2022 (UTC)
  •   Support Fralambert (talk) 00:26, 29 January 2022 (UTC)
  •   Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:31, 29 January 2022 (UTC)
  •   Support Tpt (talk) 13:35, 29 January 2022 (UTC)
  •   Support Aca (talk) 15:39, 29 January 2022 (UTC)
  •   Support Ainali talkcontributions 15:46, 29 January 2022 (UTC)
  •   Support really very important. Cheers, VIGNERON * discut. 20:10, 29 January 2022 (UTC)
  •   Support Lectrician1 (talk) 20:11, 29 January 2022 (UTC)
  •   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)
  •   Support josecurioso ❯❯❯ Tell me! 00:43, 30 January 2022 (UTC)
  •   Support --Hsarrazin (talk) 06:48, 31 January 2022 (UTC)
  •   Support JAn Dudík (talk) 09:20, 31 January 2022 (UTC)
  •   Support Yes! ArthurPSmith (talk) 15:54, 31 January 2022 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 15:52, 2 February 2022 (UTC)
  •   Support Silver hr (talk) 20:00, 2 February 2022 (UTC)
  •   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)
  •   Support Betseg (talk) 08:33, 4 February 2022 (UTC)
  •   Support Syced (talk) 10:45, 4 February 2022 (UTC)
  •   Support Thingofme (talk) 14:23, 4 February 2022 (UTC)
  •   Support "cheap" - Efficiency will become vital. Vollbracht (talk) 15:26, 4 February 2022 (UTC)
  •   Support - Darwin Ahoy! 21:37, 4 February 2022 (UTC)
  •   Support Hanif Al Husaini (talk) 12:11, 5 February 2022 (UTC)
  •   Support Kpjas (talk) 13:33, 5 February 2022 (UTC)
  •   Support —— Eric LiuTalk 10:10, 6 February 2022 (UTC)
  •   Support Ayumu Ozaki (talk) 04:08, 7 February 2022 (UTC)
  •   Support Arvelius (talk) 20:47, 7 February 2022 (UTC)
  •   SupportDaxServer (t · c) 12:49, 10 February 2022 (UTC)
  •   Support Dipsacus fullonum (talk) 00:30, 11 February 2022 (UTC)
  •   Support Valerio Bozzolan (talk) 17:20, 11 February 2022 (UTC)
  •   Support. Geagea (talk) 21:42, 16 May 2022 (UTC)