Add backend: ProQuest Federated Search Gateway #3991
Conversation
|
Other than the TODOs, I think this is far enough to be worth a review. Also worth noting that there is no authentication config, it's simply IP-based access. |
…l $filter means display all of them
Co-authored-by: Demian Katz <[email protected]>
Co-authored-by: Demian Katz <[email protected]>
Co-authored-by: Demian Katz <[email protected]>
…m/maccabeelevine/vufind into proquest-federated-search-gateway
There was a problem hiding this comment.
This all looks good to me now, @maccabeelevine. Thanks again! I'll just wait for one more look by @sturkel89 and then will get it merged.
demiankatz
added
new feature
new language strings
There was a problem hiding this comment.
@maccabeelevine, I think victory is very near, but there's just one last thing below!
| cql.serverChoice = "All Fields" | ||
| title = Title | ||
| author = Author | ||
| subject = Subject |
There was a problem hiding this comment.
@sturkel89 noticed one last problem: if you go to a record and click on a subject in the core metadata, the resulting search results have the "All Fields" option selected in the drop-down, even though a Subject search is being performed. This appears to be due to the default link-subject.phtml template using "Subject" and this configuration using "subject." If the API is case-sensitive, you'll probably want to create a custom link-subject.phtml template (just as you have already created link-author.phtml). If it is not case-sensitive, maybe it's worth considering changing the names here so things match up using default templates.
There was a problem hiding this comment.
Good catch @sturkel89 -- this is fixed. That part of the API actually appears to be case-insensitive, but the documentation has everything lower case so I'd rather just match it in case some other part of it turns out to care.
There was a problem hiding this comment.
I poked around and did several searches and browses. Everything looked good, except that one small issue I reported to Demian.
Once the fix on the subject search display is in, I think we're ready to merge!
Thanks for all your hard work on this, @maccabeelevine! This is a really great contribution to the project, and I'm excited to see how it will be put to use.
|
I am very interested as well to see how other institutions will decide to use this (or not). Originally we hoped to blend these results with EDS, and we still do, but the facts are so dissimilar that it will be a real challenge. Alternatively we may decide to to do one or more recommendation modules alongside EDS results, focused on the specific ProQuest databases that are most annoyingly missing from EDS. There is a good presentation in here somewhere if different institutions decide to do this differently. |
|
Wait, crap, I forgot to document the recommendation module in searches.ini... |
This is done. |
There was a problem hiding this comment.
Thanks, @maccabeelevine, all looking good to me!
I'll hold off on merging this until early next week; it's too late in the day for me to do the documentation parts coherently right now.
How do you want to handle the checkbox about #4004? Do we need a JIRA ticket to track that, since this will likely get merged first?
Drafted: https://openlibraryfoundation.atlassian.net/browse/VUFIND-1749 |
The ProQuest Federated Search Gateway is an SRU API for searching across research databases licensed via ProQuest. It's old (docs last updated 2016) but still works and per ProQuest customer service:
On the plus side, it has a fairly rich CQL syntax for search. On the minus, there are no facets offered other than the constituent databases.
Implementation is patterned after the soon-to-be-deleted WorldCat backend as they both use SRU.
TODO