Exporting holdings from SFX to Summon
Tags:
Last Updated: Jul 14, 2011 00:44
- Description
This is a script to export a library's SFX holdings in a form suitable for loading into Serials Solutions' 360 Core. This enables us to maintain our threshold information in SFX and have Summon reflect the SFX holdings without further work in Summon.
Note that we have still enabled most of the important targets (databases) in 360 Core, so that we can benefit from that knowledgebase too. The main reason for exporting from SFX is to avoid maintaining local thresholds in both systems for targets with varying start dates like Science Direct.
- Author: Matthew Phillips
- Additional author(s):
- Institution: University of Dundee
- Year: 2010
- License: GNU Public General License
- Skill required for using this code:
basic
State
Stable
Programming language
Perl
Software requirements
None
Rationale and use at Dundee
University of Dundee is using Summon in conjunction with SFX: with SFX as the link resolver pointed to from the Summon results. You can see this in action from the Dundee library home page (the search box searches Summon).
The Summon system needs to know which journals are available to your library so that it can accurately exclude from the search results journal articles which are not accessible to your users. This is controlled by the Serials Solutions knowledge base, called "360 Core". Serials Solutions will be expecting you to turn on your packages in there (they refer to them as "databases"). Summon links the user to the full text of the article via an OpenURL resolver. You could use 360 Link from Serials Solutions, or you can use SFX.
If you are using Summon resolving via 360 Link, then you will have to maintain the knowledgebase properly in 360 Link. There's no way of avoid this, as 360 Link will need to know where to link your users to for each journal.
If your library is intending to use SFX as the link resolver for Summon, then it is possible to avoid maintaining the 360 Core knowledgebase by using this script, and synchronising with your SFX knowledgebase. In this scenario all Summon needs to know is whether you have access to a journal article, not how to link to it. The linking is handed over to SFX.
You can thus set up a library-defined database of holdings in 360 Core, which will signify to Summon that your library has full-text available for the appropriate journals. Essentially you create in the 360 Core system a Library local holdings "database" and load the file produced by the script into the interface. It's as simple as that. The Serials Solutions folk should be able to help you with this once you have produced the file.
SFX has rather more sophisticated threshold specification than 360 Core, which is purely date based. Fortunately the Google Scholar export is also date-based so the script uses this output and converts it for loading into 360 Core. The output from the script is exactly what you require for loading into the 360 Core knowledge base. The 360 Core import routines handle a variety of date formats, and the script just outputs plain years with no months or dates. It also handles embargo periods with the correct syntax for Serials Solutions' system.
When to use 360 Core standard databases
At Dundee, we turned on the major packages in 360 Core, as well as loading the file generated by this script. The process for synchronising between Summon and SFX is imperfect, for various reasons, and this is why we also turned on packages in 360 Core, to minimise the problems. But also it took a while to develop the script so we started our implementation of Summon using 360 Core the way Serials Solutions would have expected.
The packages we avoided turning on in 360 Core were the awkward packages like Science Direct where everyone has different thresholds/coverage. We would have had to customise these extensively in 360 Core so it was easier to do the work in one place, namely SFX.
Another difference was in the area of free e-journals. There was no point turning on free e-journals in 360 Core when SFX might not know anything about them, so using SFX as the basis worked well here.
The problems with synchronisation were largely because when you load a custom set of coverage details into a library local holdings "database" in 360 Core the system insists on matching both ISSN and Title. Several things can go wrong here. We found that Serials Solutions' title matching was particularly fussy. Even punctuation seemed to matter with some examples, and the Serials Solutions knowledgebase seemed to have less in the way of variant titles (added entries) than the SFX knowledgebase. Titles in Chinese characters in SFX failed to match with transliterated titles in 360 Core.
If the titles failed to match then the record did not "normalise" (this was Serials Solutions' term for the process) and the Summon content for that title would not be activated. The title would appear in the library local holdings database, but would not be tied in with the indexed articles.
Another set of problem databases are things like Lexis Nexis, where the publishers fail to supply details of ISSN to SFX anyway. There is no hope of matching these. So for packages like that you really have to turn them on in 360 Core.
From the experience at Dundee the recommendation is that you activate your straightforward packages in 360 Core, to ensure they're going to be covered, and use this script to handle the packages which require more maintenance. But you'll want to do some testing of a good selection of journals to make sure it's going to work for you.
Frequency of maintenance
Reloading the SFX coverage into Summon ought to be done after any major SFX knowledgebase update or after turning on or off packages in SFX.
Download
Release notes
15th July 2010: First release.
13th July 2011: Second release.
The first release of the script assumed that there would only be one title for each publication. The SFX knowledgebase has subsequently been enhanced with many more variant titles: for these the first version of the script exported garbage in place of the titles, for example "ARRAY(0x7b62a64)".
The second release exports each variant form of a title on a separate line of the file. This means that potentially you will be importing several different versions of the title of a journal as separate journals into 360 Core. This
is probably a good thing because the full-text availability only works if the title and ISSN from SFX both match ("normalise") with the records already in 360 Core. My tests in 2010 indicated that Serials Solutions' title matching was pretty fussy, even down to punctuation, it appeared. So a larger number of variants should improve the situation.
Installation instructions
See the attached Word document for full details.
Known issues
Titles with no ISSN will not be exported as 360 Core will not load and normalise them. Some other titles fail to match.
When loading a very large file into 360 Core the system can time out. To avoid this you may need to split the file into several separate files to load. The script could be further enhanced to split into suitable chunks automatically.
Comments
Text...