This is a task to evaluate a mechanism to create a well-defined order for everything in our data model.
What is order?
There are different kinds of orders:
- An order that is stored within the data in the database (eg. an extra list next to the map in the json representation)
- These kind of orders can be edited through the api and in the ui.
- An order that is defined globally in a list or an "after" relation (eg. a global order of properties or statements on properties)
- This order should also be editable, but not within the ui but in a separate place for the whole wiki
- This kind of order is not attached to some particular data and thus not stored in the database. We can add it to the api output but don't need to.
- An order that is also defined globally but cannot be edited because it is already pre-defined
- An example for this order is the list of sitelinks, which is sorted alphabetically by site id.
Where do orders apply?
We have lots of places where orders apply in our data model. Basically everywhere we have a list of things, we need to order them by some sorting criteria. Another interesting aspect we have to deal with is grouping before ordering. Often similiar data is grouped by some criteria and then sorted by another. Basically, we have two orders then.
Header
In the head of our currently defined entities, we have a Fingerprint. It consists of labels, descriptions and aliases, all defined per language. In the ui, only a selection is shown based on the user's language settings. The shown terms are sorted by user preference (kind of a global order). It cannot be edited in the ui but is well defined and seems to make sense.
It gets more complicated with the new "show more languages" feature. Suddenly, a bunch of languages get shown without a really nice order. Here, we could sort alphabetically by language code or the language's name in the users language etc. However, we should give the list some kind of order. needs action
Statements
Statements are perhaps the most complicated part of our data model and thus also the ui. Here, a bunch of things needs to be ordered.
Current situation
Statements are grouped by property id, so the first thing we need to sort are the statement groups by property id. There is currently no defined order for these. The order cannot be changed in the ui although the api provides a kind of broken mechanism for this. needs action
The other part of statements that needs to be ordered are the lists of statements that have the same property id. They are grouped together but still need some kind of order to be displayed which isn't currently defined as well. needs action
Future concepts
In future we want to group statements that have the same property id by rank. The "by rank and property id" groups can be ordered by rank within the same property id but statements in such a group still need ordering. Another possible extension to improve the ui is grouping property ids by topic. This would introduce yet another kind of ordering since we need to sort the topics as well. needs action
Qualifiers
Qualifiers as part of a statement also need to be sorted but the problem seems to be the same as ordering statement groups by property id.
References
References again need two orders, one for the list of references and one for the list of snaks within a single reference. While the second order is again the same as ordering statement groups by property id, the order of the references themselves is its own problem. needs action
Sitelinks
Currently, only items have sitelinks. They are grouped by project and then sorted by langauge code. While the order of the projects is kind of arbitrary, it is well defined in the configuration and cannot be modified inside of Wikidata. There seems to be no issues with this solution currently.
How do we fix the issues?
- T125523: [Bug] Fix order of additional languages
- task for the ordering by property id
- task for ordering statements with the same property id
- task for ranks + task for topic groups
- task for ordering of references