Problem: It takes a long time to add inverse statements, father/mother -> child; owner of-> owned by; Spouse/Partner (including qualifiers start time, place of marriage, etc)
Who would benefit: Everyone editing
Proposed solution: Possibility to automatically add inverse statements, including qualifiers.
I actually wonder why inverse properties exist in the first place. It seems like they exist so that the inverse can be referenced on other wikis. Perhaps it would be better to make it easy to reference "the inverse" in a sidebar on Wikipedia instead of having to actually duplicate the data in the database. For instance, if there was a way to say that I want the items, where the "father" is this page, it would give me a list of the page's children. That seems like it would be way better than trying to ensure that the inverse statements are correct everywhere. U+1F360 (talk) 23:22, 14 November 2018 (UTC)[reply]
@Germartin1: How would this handle qualifiers and references, and statements with the same value but different qualifiers (for e.g. adjacent stations, offices held)? I like this proposal (and added my support vote) but I think these are things that would need to be addressed in the implementation. Jc86035 (1) (talk) 08:11, 20 November 2018 (UTC)[reply]
Support As I added above, I think the reasons why we have inverse properties should be investigated first (as their might be a better technical solution that removes the need for them). But if removing them is impossible, then we should make it faster/easier to add them. U+1F360 (talk) 21:53, 16 November 2018 (UTC)[reply]
Support Inverse properties are trivial case of properties which can be derived from other properties. See https://phabricator.wikimedia.org/T167521 for more complicated cases. We should have some mechanism to define such properties. Maybe as "read-only" properties automatically generated if some condition is met. One danger of inverse properties is thay have to be removed in 2 places. One thing we do not want is a property added by bot, so if a person deleted one of them bots re-adds them based on the other one. Jarekt (talk) 05:47, 17 November 2018 (UTC)[reply]
Support also "has part" - "part of" and similar. Perhaps the properties could be "weak ones" - autogenerated, unless someone overrides them? Andree.sk (talk) 19:58, 17 November 2018 (UTC)[reply]
Support model and implement 1:1, 1:n, n:m relationships navigable in both directions as single entities and all operations (like add & remove) as atomic, not as two inverse properties (which exposes an implementation detail). The names of the relationship's ends still should make sense, like ownes and owned by.. Herzi Pinki (talk) 22:52, 17 November 2018 (UTC)[reply]
Support At least checking and easily creating the other end for symmetrical properties (spouse, etc.) would be great. Note we'd also need to be careful with qualifiers. References should be carried over too. Laboramus (talk) 07:14, 21 November 2018 (UTC)[reply]
Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)[reply]
Oppose (with the understanding that oppose votes are not counted here) per Arthur in full. I think this is useful for properties where the likelihood of introducing unnecessary bloat to items is very low, but I am against using this functionality with properties that have a strong likelihood for bloat (such as "part of", "has part", and most recently "owner of" and "owned by"). Mahir256 (talk) 21:07, 23 November 2018 (UTC)[reply]
Support Only as optional, not as mandatory. It can be either per property (e.g. father/mother -> child is automatic, part of is not) or as an option (Preferences, pop-up etc.) — NickK (talk) 15:32, 30 November 2018 (UTC)[reply]
Support --Tohaomg (talk) 18:22, 16 November 2018 (UTC)
Strong oppose I'm sorry but this is NOT a good idea for several reasons: (1) We have several properties that are stated as "inverses" but are not really - for example "part of" vs "has part"; for concrete entities they are pretty close to exact inverses, but in more abstract cases not so much, and there are things like "has parts of the class" that are better ways to handle the relation. (2) Do we want every entity in the universe listed under the "universe" item, since everything is "part of" the universe? This is a very general issue: many relations that are invertible are "one to many" type, where there would be only one statement on thousands of items on one side, with thousands of statements on the one item on the other side. Sometimes for many-to-many relations they are close to "one-to-many" in some contexts and "many-to-one" in others - that is, sometimes one side of the relation and sometimes the other side would be unreasonable to reify as statements on items. (3) We would need to be very careful with vandalism of properties: if a vandal stated that some other property was an "inverse of" a widely used property like for example P31 (instance of), and the system automatically created millions of such statements, we would have a terrible mess to clean up. (4) There is already a javascript gadget to do this at least as far as the UI goes - 'User:Pasleim/derivedstatements.js' - maybe that needs some improvement or cleanup, but an approach like that is the only way I could see this being useful, i.e. actually generating the inverse statements in real time based on current data, rather than inserting inverse statements into items in a more permanent manner. ArthurPSmith (talk) 16:39, 23 November 2018 (UTC)
Oppose (with the understanding that oppose votes are not counted here) per Arthur in full. I think this is useful for properties where the likelihood of introducing unnecessary bloat to items is very low, but I am against using this functionality with properties that have a strong likelihood for bloat (such as "part of", "has part", and most recently "owner of" and "owned by"). Mahir256 (talk) 21:07, 23 November 2018 (UTC)
Neutral Manu1400 (talk) 04:12, 25 November 2018 (UTC)
