Page MenuHomePhabricator
Create Task
Maniphest T74297

[RFC] Have API return and accept lists instead of maps to maintain order
Closed, InvalidPublic
Actions

Description

The structures returned by the API are optimized for "raw" API usage (e.g. via Bots). Statements grouped by property as well as qualifiers and reference snaks are returned as maps. While there are awkward "qualifiers-order" and "snaks-order" attributes for qualifiers and reference snaks, there is no way to determine the order of statements via the API. Consequently, no reliable mechanism to manually order statements can be implemented.
Instead of having to apply complex logic evaluating special attributes like "qualifiers-order" and "snaks-order", there should be a way to retrieve natively ordered structures from the API.
The proposal is to provide a flag that, when submitted to API modules, will make lists instead of maps getting returned.

See also: T59666: [Task] Ensure normalized ordering of claims and snaks in the API

Details

Reference
bz72297

Related Objects
Search...

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusAssignedTask
· · ·
InvalidadrianheineT60180 changes to ordering don't persist under certain condition
OpenNoneT87327 [Story] Group statements within statement group by ranks
InvalidNoneT59666 [Task] Ensure normalized ordering of claims and snaks in the API
DeclinedLydia_PintscherT65564 Don't visually group property values by property in qualifiers
ResolvedthiemowmdeT99243 [Story] consistent order of statements in an item
InvalidNoneT74297 [RFC] Have API return and accept lists instead of maps to maintain order
· · ·

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 3:52 AM
bzimport added a project: MediaWiki-extensions-WikibaseRepository.
bzimport set Reference to bz72297.
bzimport added a subscriber: Unknown Object (MLST).
adrianheine added a comment.Oct 21 2014, 1:56 PM

Currently we get our data from wbEntity, too, so that would have to have this grouping, too.

Snaterlicious added a comment.Oct 24 2014, 10:37 AM

Of course, the front-end needs to be able to submit order changes to the API as well. At the moment, this can be done by submitting a plain "index" parameter which, probably, is not the most robust solution.

Lydia_Pintscher added a project: Wikidata.Dec 1 2014, 2:38 PM
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 13 2015, 4:45 PM
thiemowmde renamed this task from Maintain order: Have API return and accept lists instead of maps to [RFC] Have API return and accept lists instead of maps to maintain order.Aug 13 2015, 4:46 PM
thiemowmde updated the task description. (Show Details)
thiemowmde set Security to None.
thiemowmde edited subscribers, added: thiemowmde; removed: Wikidata-bugs.
thiemowmde added a comment.Aug 13 2015, 4:51 PM

Personally I really, really like the "qualifiers-order" and "snaks-order" fields. The major advantage of these is that diffs are always minimal. In the JSOPN blobs a qualifier sub-blob does not move around when a qualifier is moved. Instead only the qualifier's ID moves around in the qualifiers-order field.

The disadvantage is that external consumers of the data have to know about these "order" fields and apply them before displaying anything. But this is a) not always needed and b) not hard.

I suggest, instead of the proposal in this ticket, to implement a "statements-order" field similar to the existing ones.
I also suggest a similar "references-order" field if this makes sense.

Lydia_Pintscher closed this task as Invalid.Nov 21 2016, 2:51 PM
Lydia_Pintscher added a subscriber: Lydia_Pintscher.

Closing for now. Please reopen when it becomes relevant again.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL