Page MenuHomePhabricator

Inverse statements duplicate work, data, and may be out of sync
Open, Needs TriagePublic

Description

Problem
There are a huge number of properties that have inverse properties.
Examples:

There might be a way to query for properties that have inverse properties, but I imagine it's in the hundreds (if not, thousands?). It seems that for almost any property that refer to another entity, there is an inverse of that same property.

This is a huge amount of duplicate data and duplicate work.

However, as one user pointed out, this is currently necessary in order to use the data in infoboxes:

It would be very difficult to retrieve all this information from somewhere else, as we cannot use queries while building infoboxes.

Another user added:

The inverse thing is unfortunate. When querying data, you'd actually need to run the query in both directions and merge the results, since the inverses are often missing.

While there is a need for project-wide policy, the infobox use-case cannot be resolved by policy as it is a technical problem rather than a policy problem.

Solution
Make it possible to refer to inverse values of the current entity in an infobox.

For example, if the child property was removed, then on Alec Baldwin they would need a way to get all of the items that list their father as Alec Baldwin.

Maybe a new template should exist? something like:

{{#inverse:P22}}

or maybe just another parameter?

{{#statements:P22:inverse}}

Regardless of the specific syntax, making this possible will greatly reduce the number of properties on wikidata, the amount of data, and the amount of work.

Alternative Solution
A concept of "virtual properties" could be implemented. These properties would be tied to their inverse. For instance owner of might be a virtual property, so you would see the values and be able to edit them (just as you can today), but any edits would actually be stored as owned by on whatever entity value specify. This would allow the wikis to continue to use the owner of property the same way they do now.

I imagine this would be more challenging on a technical level, but it would make the usability of inverses a lot better. The user wouldn't be required to figure out what the inverse is and wouldn't have to go to each item to set it. It would also allow for inverses with a huge number of values to be presented (and paginated) to the user.

If there is one that is ambiguous (like child) perhaps the "virtual properties" would allow an inverse to multiple real properties (i.e. mother/father) and the user would be forced to specify which one they want (just like a user is forced to specify a unit on amount properties or a language on monolingual properties). Then the inverse can be retrieved for both of the real properties, which would make it way easier to query or include in sidebars, etc.

Event Timeline

dbarratt created this task.Nov 15 2018, 4:47 AM
Restricted Application added a project: Wikidata. · View Herald TranscriptNov 15 2018, 4:47 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
dbarratt updated the task description. (Show Details)Nov 15 2018, 4:48 AM
dbarratt added a subscriber: Addshore.
dbarratt updated the task description. (Show Details)Nov 15 2018, 5:40 AM
Jc86035 added a subscriber: Jc86035.

This would be so useful, regardless of how it's implemented.

I'd suggest having a query timeout for querying inverses, since trying to load every inverse of "instance of human" would probably break something.

I would definitely submit this for the Community Wishlist Survey in November, since the only reason "Automatically add inverse properties" didn't get into the top 10 in the November 2018 survey was that @ArthurPSmith and @Mahir256 (correctly) noted – after a week of voting, when the proposal was still in the top 10 – that adding all the inverses would be fairly problematic and unworkable. This would hypothetically garner the same level of support (or do better), since it would solve the same problem.

This RfC is related, although it's not very active right now.

Swpb added a subscriber: Swpb.Feb 5 2019, 5:22 PM
Restricted Application added a subscriber: Liuxinyu970226. · View Herald TranscriptApr 14 2019, 11:34 AM