ProQuestFSG: Support Blender mode

[maccabeelevine]

The original ProQuestFSG did some custom facet logic that worked, but it turns out not as a Blender target. This works and brings things (hopefully) more into line with normal facet handling.

To test blending ProQuest with EDS (which is probably the most likely combination?), and the single shared facet (source / database), you need:

• ProQuestFSG.ini's enabled set to true
• and something like this in Blender.ini

[Backends]
EDS = "EBSCO"
ProQuestFSG = "ProQuest"

[Blending]
initialResults[] = "EDS"
initialResults[] = "ProQuest"

[Results]
blender_backend = Platform
source = Database

[Advanced_Settings]
delimited_facets[] = "source||"

TODO

• Figure out the zero-based start record discrepancy from Blender.
• Avoid the backend error messages when selecting a facet that only works on one backend.

[maccabeelevine]

Yeah... haven't solved this yet. ProQuest's offset starts at 1.

[EreMaijala]

I think it would be better for offset to always be 0-based in VuFind, because it's displacement from the first record, i.e. for offset it doesn't really matter if first record is 0 or 1 in the API, because it's always relative to the first record. Adjust as necessary in the Proquest API calls instead.

[maccabeelevine]

I used a | as the delimiter in the original ProQuestFSG code as well, and it works fine, but it does make the declaration of the delimiter in Blender.ini a little awkward:

[Advanced_Settings]
delimited_facets[] = "source||"

So could change it to something else if preferred.

[maccabeelevine]

As I added above as a TODO, the Source facet will only ever apply to one backend at a time, and both EDS and ProQuest throw errors when you try faceting on the other one's database. There should be a way to short-circuit that process before the wrong one is searched, but the facets don't seem to store the source of each blended value (since usually they are supposed to work in multiple backends and it's not an issue).

On the ProQuest side it's particularly bad because the error returned is an SRU authentication error (1,3), as it thinks I'm requesting a database that we're not subscribed to. That's the same error code as wrong-IP-address error, so I can't just silently ignore it. In theory I could parse the actual error message text but that's going to be brittle so a last resort.

The other last resort is of course not to use the source facet at all, but that makes the entire Blender display much less useful.

[maccabeelevine]

Early input welcome @demiankatz @EreMaijala

[demiankatz]

As I added above as a TODO, the Source facet will only ever apply to one backend at a time, and both EDS and ProQuest throw errors when you try faceting on the other one's database. There should be a way to short-circuit that process before the wrong one is searched, but the facets don't seem to store the source of each blended value (since usually they are supposed to work in multiple backends and it's not an issue).

I think you have to fill in the Values section in BlenderMappings.yaml to indicate which values are allowed by each backend -- then Blender will be smart enough to send the correct values to the correct backends. Obviously the problem here is that you need to know every possible value from every possible backend in order to set up the configuration properly. Perhaps @EreMaijala has some other ideas for the future....

[maccabeelevine]

As I added above as a TODO, the Source facet will only ever apply to one backend at a time, and both EDS and ProQuest throw errors when you try faceting on the other one's database. There should be a way to short-circuit that process before the wrong one is searched, but the facets don't seem to store the source of each blended value (since usually they are supposed to work in multiple backends and it's not an issue).

I think you have to fill in the Values section in BlenderMappings.yaml to indicate which values are allowed by each backend -- then Blender will be smart enough to send the correct values to the correct backends. Obviously the problem here is that you need to know every possible value from every possible backend in order to set up the configuration properly. Perhaps @EreMaijala has some other ideas for the future....

Right, that would work if I had all the data --- and to be fair I can probably get it on the EDS side since empty searches are allowed. Not so for ProQuest. And of course the list will change over time. So this is maybe a third bad option and like you say I am curious whether @EreMaijala has other ideas.

[EreMaijala]

I think it would be better for offset to always be 0-based in VuFind, because it's displacement from the first record, i.e. for offset it doesn't really matter if first record is 0 or 1 in the API, because it's always relative to the first record. Adjust as necessary in the Proquest API calls instead.

[EreMaijala]

The source facet is a tricky one. I'm not sure if there's a good way to handle it as a blended facet (apart from mapping all the possible values). Perhaps it would be better to make ProquestFSG's source a separate facet? It's not very elegant, I know, but that, or parsing the error message are the options that come to my mind. I suppose there's the additional issue that the FSG would return an error also if you selected a source that it supports as well as one that it doesn't, right? That would be hugely confusing.