Page MenuHomePhabricator

allow to change the order of statements
Closed, ResolvedPublic

Description

It should be possible to change the order of statements inside an item.


Version: master
Severity: normal
Whiteboard: backlog

Details

Reference
bz44678

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:35 AM
bzimport set Reference to bz44678.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 44880 has been marked as a duplicate of this bug. ***

This might be two separate issues: ordering of statements of one property type, and ordering the various properties.

About the latter: Is this actually necessary? Will every item need a custom listing order? Perhaps it would be better to add a "priority" property to property types, and list statements by that?

This could also be split in manual ordering, ordering on numeric id, and alphabetic sorting.

Another suggestion for ordering: sort them by usage - most uses properties first (http://www.wikidata.org/wiki/Wikidata:Database_reports/Popular_properties).

I see this kinda working for person class of objects.

That said, I would like to see a dropdown with various sorting options available.

As of sorting property values - do wee need a way to indicate that person X was mostly known as a poet and did just a bit of jounalist or politician work? What would be the way to define that?

HenkvD added a comment.Mar 2 2013, 1:10 PM

I would like the statements to be in a table format and the full table sortable on each column by the user. I suggested this at http://www.wikidata.org/wiki/Wikidata:Project_chat#Order_of_.22statements.22_and_duplicates

  • Bug 52393 has been marked as a duplicate of this bug. ***

svenmanguard wrote:

@Papuass - The reason that *manually* ordering the statements is appealing is that it allows the people that are entering and curating the data to stick the properties in an order that allows them to curate easier. For example, I could have a script put the properties for every video game article into a specific order (ideally agreed to by the video game task force), so that a person curating the data could just look down the list of properties an item has and check them against a list of properties that item *should* have, without having to go digging back and forth through the page. Ultimately, if manually ordering statements isn't possible, at least having them appear in a fixed order (likely numerical) would allow for the same ease of finding, albeit without the ability to put properties into a logical order. Having it based on popularity is problematic because popularity can change, and this is only useful if the order is stable enough that it can be used in the manner I described.

soulkeeper.wikipedia wrote:

Fixed order, alphabetically, by property id, or hard coded, should be easiest to implement. It has only one drawback that I can see: Newly added statements will change position at save, or at page reload. This is a minor issue imo. I suggest starting out by implementing a fixed order. The possibility to "override" this, either item by item, or depending on the type of item, can be added later.

Zoloinwiki wrote:

I think the user should be able to change the order, and that it should change the key associated with the statement in the Lua table. Alphabetical order is not enough. See the architects in this infobox: https://fr.wikipedia.org/w/index.php?title=Arsenal_Stadium&oldid=97323308 The architect of the renovation appears before the architect of the original building, and that is hard to reliably fix through a client-side heuristic. Wikidata should directly provide a sensible order.

Order has to be defined by user in a specific user page. It is impossible to get an unique order for each class of items because there are several ways to treat data between the different wikipedias.

The best way in my opinion is to create a tool/code which matches some class of items defined by the property "instance of" with a specific order given by the user.

soulkeeper.wikipedia wrote:

I've made a javascript tool for my own use. Maybe it can be used for inspiration:
//www.wikidata.org/wiki/User:Soulkeeper/statementSort.js

This functionality is available now: when moving the last or first statement of a statement group even further down or up, the whole group will change its position. This behavior should be re-thought when redesigning the UI because it is not very intuitive.

I have opened bug 57932 for that now. Closing this one.

Od1n added a subscriber: Od1n.Dec 12 2017, 2:53 AM

Looks like this feature is currently missing. (if I recall correctly, maybe it has been removed at some time)

It would be very useful for software versions. Often there are missing versions (gaps), or oldest versions are not listed. Adding these versions disorders the listings, and they are already tedious enough to manage...

Restricted Application added a project: Wikidata. · View Herald TranscriptDec 12 2017, 2:53 AM

Looks like this feature is currently missing. (if I recall correctly, maybe it has been removed at some time)

It's missing on purpose. Data does not always has a natural order and the order can't be viewed by tools like SPARQL.
Instead the community can nowadays set in which order the information should be displayed on the site.

It would be very useful for software versions. Often there are missing versions (gaps), or oldest versions are not listed. Adding these versions disorders the listings, and they are already tedious enough to manage...

Just add the following to your common.js:

// Sort Software-Versions
importScript( 'User:Seb35/sortValues.js' );
Od1n added a comment.Dec 12 2017, 2:26 PM

Thanks, I had a look at the javascript code, and I'm not really a fan of this solution.

  • It adds even more javascript processing, which I try to avoid.
  • Also I'm pretty sure there are cases the sorting would be wrong. Developers are sometimes messy in their versioning schemes, you know :)

In this particular case, ordering the data does make sense. But I guess the key is that it doesn't fit the general wikidata structure?

I suppose there won't be changes about this, so the only solution is that additional javascript layer.