| dbarratt updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
**Alternative Solution**
A concept of "virtual properties" could be implemented. These properties would be tied to their inverse. For instance [[ https://www.wikidata.org/wiki/Property:P1830 | 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 [[ https://www.wikidata.org/wiki/Property:P127 | owned by ]] on whatever entity value specify. This would allow the wikis to continue to use the [[ https://www.wikidata.org/wiki/Property:P1830 | 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 [[ https://www.wikidata.org/wiki/Property:P40 | child ]]) perhaps the "virtual properties" would allow an inverse to multiple real properties (i.e. [[ https://www.wikidata.org/wiki/Property:P25 | mother ]]/[[ https://www.wikidata.org/wiki/Property:P22 | 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.
...
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 [[ https://www.wikidata.org/wiki/Property:P1830 | 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 [[ https://www.wikidata.org/wiki/Property:P127 | owned by ]] on whatever entity value specify. This would allow the wikis to continue to use the [[ https://www.wikidata.org/wiki/Property:P1830 | 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 [[ https://www.wikidata.org/wiki/Property:P40 | child ]]) perhaps the "virtual properties" would allow an inverse to multiple real properties (i.e. [[ https://www.wikidata.org/wiki/Property:P25 | mother ]]/[[ https://www.wikidata.org/wiki/Property:P22 | 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.
TASK DETAIL
EMAIL PREFERENCES
To: dbarratt
Cc: Addshore, Aklapper, dbarratt, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, D3r1ck01, Wikidata-bugs, aude, Mbch331
Cc: Addshore, Aklapper, dbarratt, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, D3r1ck01, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
