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

• characters ↔ present in work
• child ↔ mother/father
• owner of ↔ owned by
• participant ↔ participant of

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.