Undo limit on search results for lookups

[kallimathios]

Describe the feature you'd like
We would like to

• expand the number of returned results in lookup queries beyond the first 10
• provide pagination for results exceeding display/return limit of 10

Give an example
When searching a name with many entries like "twain, mark" we are only returned 10 results, none of which contain the desired authority. Further pagination is needed.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I left Sinopia and navigated to the service which the lookup is caching in order to find the authority and provide the full LC label for my lookup search in Sinopia. Sinopia's lookup will not return the desired result using the URI or the LC identifier. Alternatively, after visiting id.loc.gov, I could enter my own URI/label and no longer use the lookup service.

[justinlittman]

@kallimathios Can you please provide precise instructions on how this can be replicated?

[kallimathios]

Hi @justinlittman - no problem. Please see below for this specific example, and if I can provide more details please let me know.

-In Sinopia Stage, navigate to the template pcc:bf2:Monograph:Work, and create a new description
-Navigate to "Primary Contribution" in the left-hand side menu, or scroll down to "Primary Contribution"
-Under Creator of Work, click on "Add Creator of Work"
-Select optional class of person (optional)
-Click on "Add Agent"
-Enter "twain, mark" into the lookup search field and click search

Thank you!

[justinlittman]

Thanks. Exactly what I needed.

[justinlittman]

I believe the pagination issue is due to a known and long-standing bug in QA: LD4P/qa_server#477 (cc @sfolsom).

We can easily change the number of results on a page. What would you like that number to be? (If I recall, it was deliberately set to a low number for display purposes.)

[kallimathios]

Thank you - I will take a look at the bug and hope to have more info about an ideal number soon!

[sfolsom]

Thanks for cc'ing me. With the move to data provider API-based QA lookups, I wonder if we need to reconsider how pagination should be handled. We're relying on what data providers include in their responses, and I haven't noticed any counts and rank coming from their native APIs to translate into the QA response.

For APIs that are returning RDF (no order), results are being sorted alphabetically in the JSON that QA is providing. For APIs that return JSON, we're using the relevancy order that they provide in the QA-styled JSON. Is there the possibility that Sinopia could take the results of the search and chunk it up into pages?

[justinlittman]

@sfolsom If I'm not mistaken, the bug is with cached QA lookups. Does QA pagination work correctly for direct QA lookups?

I'd suggest that pagination is firmly a QA responsibility and should not be handled by a consuming application like Sinopia.

[sfolsom]

I'm seeing evidence that at least some direct lookups have startRecord and response_header. total_records is definitely not reporting in some. I'll get back to you asap once I've confirmed the situation.

@justinlittman can you confirm what needs to be provided to support pagination in Sinopia? Is it maxRecords, startRecord, and the response_header with total_records?

[justinlittman]

I believe that is correct @sfolsom.