Serials Solutions modifications? -- LexisNexis linking

[Kenneth R. Irwin]

Hi all,

After my earlier post, a few folks wrote asking how to link directly to 
LexisNexis journals. They don't make it easy, and it's not possible to link 
a browseable version of the periodical, but it is possible to link to a 
search page pre-set to only search the periodical in question. We arrived 
at the urls for doing this by downloading the 26 separate A-Z title list 
pages, eg:

http://cisweb.lexis-nexis.com/sourceselect/listSources.asp?srcpdn=academic&product=universe&unix=http://web.lexis-nexis.com/universe&extendRQ=Y&startingChar=C

and then parsing the HTML for the relevant bits, namely the titles and urls 
for "Search this Title"; the titles were then correlated with the other 
data about the title (issn, coverage dates, completeness of coverage), 
which is available from:
http://cisweb.lexis-nexis.com/marketsource/productTitlesText.asp?submit=Text+Report
(they make this page tricky to find, but our trusty LexisNexis rep pointed 
me to it.)

This process is a big ol' pain in the butt, but it does work. Call you 
LexisNexis rep and tell them to make it easier! They are just about the 
only fulltext provider to make it this difficult to obtain information that 
will drive the use of their products... (*grrr* *sigh*)

I hope this helps; junky code available upon request.

Ken

>At 07:56 PM 11/10/2002, you wrote:
>>Hi all,
>>
>>I don't know to what extent Serials Solutions is likely to modify their
>>product to link to individual titles, but this is certainly something that
>>you can do on the local level. At our library, we do our whole serials list
>>locally, with no third party intervention; that gives us full control over
>>the linking capability.
>>
>>It can be a little tricky to go it on your own, but if you someone who's
>>Perl and SQL skills are adequate, it should be quite manageable. You want
>>Perl to take the vendor's title lists out of their native form and squeeze
>>the data into the right shape for your local database; you'll want the SQL
>>& interfacing script language (I use PHP; you could use Perl there too) to
>>handle the user side. We're quite happy with the end result, which we've
>>been using in one form or another since 1998.
>>
>>You can see the current implementation at:
>>http://www6.wittenberg.edu/lib/research/ejournals/
>>(although the URL just says "ejournals", it actually has our print and
>>microfilm holdings as well)
>>
>>(The UNC Greensboro library has a similar and probably more extensive
>>project at:
>>http://journalfinder.uncg.edu/uncg/ )
>>
>>Be not afraid -- do it yourself! (I expect that it would be possible to
>>take the SS list and run some Perlish modifications, but at that point, you
>>might as well save yourself a few thousand bucks on SS and just do the
>>whole thing yourself.)
>>
>>Caveats:
>>1. The startup time on this is not negligible; a personweek or two, with an
>>incremental hour or two for each new vendor you want to include (since you
>>need to write individual data-loaders).
>>2. Libraries that don't have the in-house scripting skills will be happier
>>just using the plain SS product. Unless, of course, you've always wanted an
>>excuse to learn Perl... ;)
>>
>>If anyone wants to tackle something like this, I'll be happy to help out,
>>though I'll probably be more useful to folks who are inclined toward
>>Unix/Linux development.
>>
>>Joy and independence,
>>Ken
>>
>>
>>
>>Ken Irwin                                               kirwin at wittenberg.edu
>>Reference/Electronic Resources Librarian        (937) 327-7594
>>Thomas Library, Wittenberg University
>

Ken Irwin                                               kirwin at wittenberg.edu
Reference/Electronic Resources Librarian        (937) 327-7594
Thomas Library, Wittenberg University