search

ebsco / edsapi-ruby

A Ruby interface to the EBSCO Discovery Services API
MIT License
7 stars 10 forks source link

Allow the ability to paginate and sort a query that is a list of identifiers #87

Closed jkeck closed 3 years ago

jkeck commented 5 years ago

We currently use the #solr_retrieve_list method to build our selections lists. This effectively iterates over the given array of identifiers, retrieves the full document for each id, and builds a response with those documents to be returned.

https://github.com/ebsco/edsapi-ruby/blob/352098d59ce2b7185ef55551a08a2ecac7c7cd0d/lib/ebsco/eds/session.rb#L459-L474

While this does work, it presents at least two complications in building a selections interface that has parity with what our catalog users expect.

  1. We don't have the ability to sort the selections list based on the same criteria that we sort our search results on. For Stanford's Article Search implementation, the sorts that we support are relevance (which doesn't make sense for a list of IDs, but for consistency would return the documents in the order that the identifiers were passed in) and two date sorts (date (most recent) / date (oldest)).
  2. Pagination ends up getting a little murky if we need to handle it on the app side, where for our catalog results it's handled on the solr side. This isn't an insurmountable complication, but having our catalog selections and article selections pagination differently adds some additional overhead for our development and maintenance efforts on this feature.

The way that catalog results are requested/returned in Solr is that we send over the list of identifiers to the same search endpoint that our normal searches are made against. The query that we send in is simply an ORed query of the ids (e.g. q=id:(1234 OR 4321 OR 6789 OR 9876)). The entire selections list of IDs are sent in w/ the query and we let solr sort and paginate using the same mechanisms for standard search result. This makes our selection effectively a simplified search result view with the added ability to do things with that list that we normally only allow you to do with a single record (e.g. email, cite, export).

The documents that we need to be returned in the selections list need to be "full records", or at least, from our perspective, records that have the ability to get the citation and export data from. We build a search result view (wrt to metadata displayed to the use), but the Cite and Export functionality are imperative to this feature being useful to our users.

efrierson commented 3 years ago

Closing some old issues, but a couple of comments and an invitation to re-open this:

We are working on a new set of EBSCO APIs, including potentially new search endpoints as well as APIs to support the specific use case of saved lists of results, etc. The functionality of those will be better suited to the "I'm looking at my selected list" use case - sorting by date added, title, etc., as opposed to the search oriented sorts you mention above. Pagination could be handled through this API as well, and it would be compatible with the newer citation endpoints we introduced earlier.

While that would certainly provide a better list API toolkit, I'm a little worried that our approach might not work here because of something I'm just realizing: these folders are associated with a specific user, and we need to have an identity to connect them to. Currently, those are accounts created on our platform (the MyEBSCO accounts), and I think you'd prefer to have them associated with a Stanford ID that SearchWorks sends, post-authentication.

Anyway, I know this is an old story, but if you're interested in discussing what we've got brewing and think through some use scenarios with us, we'd be appreciative. This goes for anyone who reads this!

And a final note - we will plan on providing an option to use our new APIs through the same methods this ruby gem exposes today so you can switch without breaking changes.