Umlaut has a new feature in master (not yet in a tagged release), specific to the SFX plug-in, for ‘rolling up’ duplicate SFX targets.
Because of the way the SFX knowledge base is structured, you sometimes get multiple fulltext links listed, which are all representing different packages from the same vendor platform, and will all take you to the exact same place. There’s really no reason for multiple targets to be listed. And it ends up confusing for the user.
I think my institution may end up getting bitten especially hard by this, because we subscribe to so many packages. For instance, if you look up the serial Science in our SFX-backed tool, you see these links:
- JSTOR Early Journal Content
- JSTOR Life Sciences Collection
- EBSCOhost Academic Search Complete
- EBSCOhost Health Source Nursing Academic Edition
- EBSCOhost MAS Ultra – School Edition
- EBSCOhost MasterFILE Premier
- Highwire Press Journals
- ProQuest Central New Platform
- ProQuest Engineering Journals New Platform
- ProQuest MEDLINE with FullText
- Gale Cengage GreenR
- Gale Biography In Context
Two JStor links that both go to the same place; four EBSCO links that all go the same place; etc.
With SFX alone, there is a way many people use to ‘roll up’ these multiples using SFX display logic. Basically, you give SFX some rules that say if there are multiple targets whose internal names begin, eg, “EBSCOHOST_”, suppress all but the first one. You can even, somewhat hackily, get a bit more specific and say if there are multiple “EBSCOHOST_*” targets, and one of them is Academic Search Complete, keep THAT one whether it’s first or not.
And we used to do that here. But we ran into trouble. For article-level displays, where a click on the link should take you directly to the article you are interested in, it works fine. But for title-level displays, you are interested in seeing what coverage we have of the journal in different platforms/packages.
And the problem was, if we rolled up all EBSCOHost packages to just Academic Search Complete, the user would only see displayed the coverage dates of that package. At first we thought the ASC package, in this case, was a strict superset of coverage of any other EBSCO packages so that would be fine. — But we found at least one case where a different package had extra coverage not included in ASC. But it was being suppressed, so user was being misinformed to think our licensed coverage was less than it really was.
Now, most institutions might not mind this edge case, and just deal with it. Most institutions might not have voluminous enough fulltext licensed packages to make this edge case happen much.
But this was reported to me as a problem at one point here, so I turned off that display logic in SFX, for title-level displays anyway (left it on for article-level displays).
But then we’re back to these monstrously long lists of targets, which also confuse the user and make it awfully hard to figure out what our coverage actually is.
So, I’ve written a custom feature in the Umlaut plug-in for SFX, which analyzes the targets returned by the SFX api, and “rolls up” links from the same platform (as specified in config), but for title-level links it takes coverage dates into account. For title-level displays, it will only suppress a ‘duplicate’ link if it’s dates of coverage are a subset of another link that is not suppressed. Fortunately, the SFX api does supply coverage dates in a machine-actionable format to make this kind of logic possible.
This is done with supplying a “roll_up_prefixes” configuration key to the SFX adapter, with an array of SFX target prefixes you’d like to roll-up, such as “EBSCOHOST_” or “PROQUEST_”.
The configuration in Umlaut is pretty easy, a bit more straightforward than dealing with SFX ‘display logic’ for this purpose maybe. In the configuration for your SFX service in
Service_name: type: Sfx # ... roll_up_prefixes: - 'EBSCOHOST_' - 'JSTOR_' - 'PROQUEST_' - 'SPRINGER_LINK_' - 'ELSEVIER_SD_' - 'HIGHWIRE_'
(I could go further and still collapse to one link even when there are distinct coverages periods — but still display both (or multiple) coverage periods attached to the single link. That would be ideal — but it was hard enough to get this far, and honestly that occasion probably doesn’t happen enough to justify the extra work to optimize the UI yet further. If it does, I can always go further later.)