Last modified: 2014-05-23 14:26:26 UTC
There's been a lot of discussion on Wikidata about bidirectional/reciprocal properties (in the adminstrative unit/subdivides into, parent/child, succeeds/precedes, overlies/underlies etc.) Some kind of support for displaying the reversed version in infoboxes would likely be appreciated, but there are other possible areas too. The first step would just be reversing for display, but it would be even better if you could reverse while editing (i.e. the real property is 'succeeds', but when you add 'precedes', it's automatically converted internally). I don't know if the latter is worth the complexity.
This one needs a RFC first, because there are a few issues with that (e.g. think about the "place of birth" <-> "born in" property, and how long that would be in some cases). Queries can probably do the same job. I suggest to close this bug, or else write the RFC to discuss the above issues.
(In reply to comment #1) > This one needs a RFC first, because there are a few issues with that (e.g. > think about the "place of birth" <-> "born in" property, and how long that > would be in some cases). > > Queries can probably do the same job. I suggest to close this bug, or else > write the RFC to discuss the above issues. Denny Are you really saying we can decide the direction of wikidata development with RFCs? Because we are still waiting for sitelinks to redirects and a subproperty relation which were called for in RFCs months ago. We can have an RFC. Side A will say that having reciprocal properties means having the same information in two places and this means twice as much work keeping the information correct - and they will be right. Side B will point out that if we only have the information in one place then it is difficult to find that relation if you start from the other place. If all we know is that C is 'subclass of' D then how do we find what subclasses D has without a reciprocal D 'has subclass' C property - and they would be right too. We can discuss that RFC for months and we wouldn't get any farther because side B is raising a technical problem and proposing a policy hack to fix it using the current technology while this bug is proposing a change from the current technology to fix this problem. It's easy to find the claims which have the current item as their subject. If it was as easy to find the claims which have the current item as their object then the problem would go away and we could get rid of all the reciprocal property duplication. Do you really want an RFC first? Are ready to participate in the RFC and advise us if this change is practical?
*** Bug 58853 has been marked as a duplicate of this bug. ***
Symmetrical and complementary properties should really work reciprocally. Wikidata are essentially wrongly based when a property is a part of history of one item page only. Reciproocal property (such property which is edited in one item but should display as the identic or the inverse property in other item) should be equally and automatically displayed in both involved items and their history pages and equally editable from both involved items. Most of properties are reciprocal from their nature and reciprocality should be their basic and primary function. If there is no will to repair the essential structure of Wikikdata properties, we need to create tools which would substitute/simulate the correct structure, i. e. which would render every property to the reciprocal property
