#1040: BibSort: second order sort
------------------------+----------------------
Reporter: lmarian | Owner: lmarian
Type: enhancement | Status: new
Priority: major | Component: BibSort
Version: | Resolution:
Keywords: |
------------------------+----------------------
Comment (by simko):
Not sure the end users would want to fiddle with complex UI with many
sorting options at the search-time. A small selection of sort buttons
should be enough for the end users.
Vesa's use case concerned more an indexing-time extension to BibSort.
I.e. sorting method definition should allow for things like sorting by
`"(909C4y OR 260__c) AND 245__a"`. This would be called ranking method
"foo" and the end users would simply see "sort by foo" option.
It concerns a possibility free combination of values. Currently we don't
implement the "AND" bit but we behave more in an "OR" manner there. See
`/search?sf=041__a,245__a&of=hm&ot=041,245` on a demo site. Basically we
could extend sort field definition to say:
{{{
[sort_field_2]
name = foo
definition = PYTHON: bibsort_custom_sorting_method_combining_foo_and_bar
washer = NOOP
}}}
where people would be able to supply a bibsort method they want into some
pluginutils directory (like BibFormat elements) to have any custom sorting
method they want.
So I would not call this to be a call for introducing nth-order sorting
facility at searching time, but rather a call for re-factoring
`bibsort_engine.get_field_data()` to use e.g. pluginutils so that people
could easily write and use a custom sorting method at the indexing time.
Other such example: sort by the number of citations and within the same
citation count perform sub-sort by the number of downloads for the past 30
days and within the same number of download perform sub-sub-sort by the
publication date, say.
--
Ticket URL: <https://invenio-software.org/ticket/1040#comment:3>
Invenio <http://invenio-software.org>
