Multiple Sorting in PubMan Exports

One thing I owe to the community since the PubMan Days is the explanation how publication lists that are exported by the Search&Export service can be sorted by more than one index field.

The use case for this is the integration of sorted publication lists into an institute’s homepage.

As an example, a desired sorting can be

1) by author’s name (ascending)

2) by publication date (descending)

The problem is that the Search&Export example form only provides  two form fields for sorting, „Sorting Key“ and „Sorting Order“

So obviously you can put in a sorting key (one of these) and the according sort order, ascending or descending. This results in a query like this:

  • CQL search query: escidoc.objecttype=“item“ and escidoc.any-organization-pids=“escidoc:578627″ and escidoc.content-model.objid=“escidoc:persistent4″ (as an example we use a query for a department’s publications)
  • Sorting Key: sort.escidoc.publication.creator.person.compound. person-complete-name
  • Sorting Order: ascending

makes

http://pubman.mpdl.mpg.de/search/SearchAndExport?cqlQuery=escidoc.objecttype%3D“item“+ and+escidoc.any-organization-pids%3D“escidoc:578627″+and+escidoc.content-model.objid%3D“escidoc:persistent4″&exportFormat=APA&outputFormat=escidoc_snippet&sortKeys=sort.escidoc.publication.creator.person.complete-name&sortOrder=ascending&startRecord=1&maximumRecords=50

But there is more to it!

The sorting key field can also be used for multiple keys. As obviously the second field (sorting order) only allows one value (either „ascending“ or „descending“) it is useless for multiple keys. So this field should remain „ascending“ and all information has to go into the sorting keys field. This is done in the SRU 1.1 standard format. It defines that a sorting parameter consists of up to 5 values, separated by comma: field name, schema, sort order, case sensitivity, missing value policy.

  • Field name: one of those mentioned above
  • Schema: PubMan doesn’t use any index schemas so the second argument is empty
  • Sort order: 1 for ascending, 0 for descending
  • Case sensitivity: 1 for case-sensitive searches, 0 when cases don’t matter
  • Missing value policy: should be omitted (actually I have to check if we implement that)

In that syntax, the example from above would look like this:

  • Sorting Key: sort.escidoc.publication.creator.person.compound. person-complete-name,,1
  • Sorting Order: ascending

makes

Another sorting key can be appended separated by a space. Let’s secondarily descend the results by the year of publication:

  • Sorting Key: sort.escidoc.publication.creator.person.compound. person-complete-name,,1 sort.escidoc.publication.compound. most-recent-date,,0
  • Sorting Order: ascending

makes

http://pubman.mpdl.mpg.de/search/SearchAndExport?cqlQuery=escidoc.objecttype%3D“item“+and+escidoc.any-organization-pids%3D“escidoc:578627″+and+escidoc.content-model.objid%3D“escidoc:persistent4″&exportFormat=APA&outputFormat=escidoc_snippet&sortKeys=sort.escidoc.publication.creator.person.compound.person-complete-name,,1+sort.escidoc.publication.compound.most-recent-date,,0&sortOrder=ascending&startRecord=1&maximumRecords=50

There you are! This can of course be extended infinitely.

Best,

Michael Franke