Open URL Concepts and Implementation Presentation for

Open. URL – Concepts and Implementation Presentation for Texas Library Association Net Fair, March 2004 Kerry Bouchard Assistant University Librarian for Automated Systems Mary Couts Burnett Library, TCU k. bouchard@tcu. edu presentation available online at: http: //lib. tcu. edu/staff/bouchard/Open. URL/TLA 2004. htm

Problem: linking related information from different sources Citation in A & I database that does not have full text for cited article Print full text from library collection ? ? ? . . . let your imagination run wild Full text in database / ejournal aggregator collection from another vendor Author info from citation index, biographical sources

Low tech solution: bibliographic instruction Pros: • Encourages information literacy – shouldn’t college students learn some research skills? • Accurate if user is persistent – automated linking systems may fail to find resources that a manual search would uncover Cons: • Google doesn’t make me print a citation and go to a different web site for fulltext – why the library? • Checking for *all* possible sources of an article might require user to go to several different databases with different interfaces.

Non-standards based tech solution: links galore A & I database vendors provide proprietary linking mechanism from their citations to other sources. Typical approaches: • Library staff upload list of all online/print holdings, and must keep list up to date. Format of the list may vary from vendor to vendor. Worst case: may not be possible to upload list at all – instead must manually “click off” every title from a list provided on vendor site • Vendor has set up automated links to a selected list of partners, e. g. , citations in “Mega Abstracts” link to your backfile holdings in JSTOR holdings, but not your current holdings in Project MUSE.

. . . Non-standards based tech solution: links galore For a library with several databases / sources of online full text, this approach leads to a combinatorial explosion. . . Mega Abstracts Mega Fulltext EBSCO JSTOR Gale Project MUSE CSA Emerald Press Silver Platter Royal Society Ovid EBSCO etc. . . Online Catalog

. . . Non-standards based tech solution – links galore Other problems with this approach. . . • Authentication: typically links supplied by a vendor will only work if your users are “on-campus, ” since they bypass your local system. • Local holdings: If vendor automatically generates links, linking to full text from a given source is all or nothing – even though you may only have access to a portion of the titles. • Other local functions: e. g. , scripting you’ve done to collect usage statistics is bypassed.

April 1999: Herbert Van de Sompel and Patrick Hochstenbach publish first part of “Reference Linking in a Hybrid Library Environment” in D-LIB Magazine http: //www. dlib. org/dlib/april 99/van_de_sompel/04 van_de_so mpel-pt 1. html Proposes the “SFX” model – dynamic linking based on passing metadata about a resource to a resolver program.

Open. URL Dynamic Linking Model Open. URL metadata Mega Abstracts EBSCO Gale CSA Silver Platter Ovid etc. . . Links to target may or may not be Open. URL Mega Fulltext Open. URL Resolver • Database of resources – just the titles your library has access to • Authentication mechanism – your users • Parsers to construct links into systems serving as Open. URL targets JSTOR Project MUSE Emerald Press Royal Society EBSCO Online Catalog

Nomenclature: Original “Open. URL” model was called “SFX” was later licensed by Ex Libris, and is now the name of their implementation of Open. URL. “Open. URL” is a draft NISO standard. “SFX” is to “Open. URL” As “Kleenex” is to “facial tissue”

Open. URL Standard Resources NISO “Committee AX”: http: //www. niso. org/committees/committee_ax. html “The draft standard has been completed and has been released for ballot and review January 26, 2004 -March 10, 2004. ” NISO “Committee AX” (committee web site at Cal Tech): http: //library. caltech. edu/openurl/

…Open. URL Standard Resources Open. URL listserv (general discussion) openurl@caltech. edu Open. URL software development list LIB-OPENURL-DEV-L@listserv. uiuc. edu

Open. URL Components Source (e. g. , article citation) Takes metadata about the cited resource and puts it in format defined by Open. URL standard Resolver Queries local database of resources using metadata in Open. URL link. If matches found, constructs links to “services” available for that resource (e. g. , full text). Target (online journal, vendor 1) Target (online journal, vendor 2) Target (online catalog) Target (citation index)

Digression: Open. URL, DOI & Cross. Ref Thanks to Amy Brand (Directory of Business Development for Cross. Ref), Miriam Blake (Los Alamos library), and Jenny Walker (Ex Libris), who presented a session on Open. URL, DOI, and Cross. Ref at the October 2003 LITA Forum – info on next two slides is a highly condensed summary of that session. DOI = “Document Object Identifier” DOI’s are somewhat analogous to ISSN’s in that they provide metadata about online objects (e. g. , a journal article) that is not subject to variations in metadata (e. g. , “A. B. Smith” versus “Arnold Smith”). In the case of journal articles, it is an articlelevel identifier. DOI’s are somewhat analogous to PURLs in that the metadata is sent (via hypertext link) to a “registration authority” that resolves it into an actual URL for the object.

. . . Digression: Open. URL, DOI & Cross. Ref - an independent, non-profit membership association - is currently one of seven official DOI registration agencies worldwide. DOI’s don’t provide information about: • Sources of the document other than the publisher. (At TCU probably less than 5% of our online journals are hosted directly by the publisher) • Licensing and rights management - does your library have access to this article? . . . so DOI is not a substitute for Open. URL.

. . . Digression: Open. URL, DOI & Cross. Ref Diagram below illustrates how DOI might complement Open. URL by serving as an alternate (hopefully more complete and accurate) source of metadata for linking. Target Reg. Auth. (online journal, Source • Sends DOI to Resolver • Sends full set of metadata about article Resolver • Sends DOI to Registration Authority • Constructs links using better metadata vendor 1) Target (online journal, vendor 2) Target (online catalog) Target (citation index)

Open. URL Source Mega Abstracts Mega Fulltext EBSCO JSTOR Gale CSA Silver Platter Ovid etc. . . Open. URL Resolver Project MUSE • Database of resources – just the titles your library has access to Emerald Press • Authentication mechanism – your users EBSCO • Parsers to construct links into systems serving as Open. URL targets Royal Society Online Catalog

. . . Open. URL Source URL for the link above: http: //lib. tcu. edu/PURL/Open. URL. asp? genre=journal&ISSN=00092541&DT=20030615&TI=Carbon%20 isotope%20 exchange%20 rate%20 of%20 DIC%20 in%20 karst%20 groundwater%2 E&JN=Chemical%20 Geo logy&VI=197&IP=14&AU=Gonfiantini%2 C%20 Roberto&spage=319&sid=EBSCO: aph (example from Academic Search Premier)

Open. URL Source - Setup • Setup can be as simple as sending the vendor the URL of your Open. URL resolver, e. g. : http: //lib. tcu. edu/PURL/Open. URL. asp • May also include URL for a graphic to display next to the links, and/or the text you want to use (e. g. “Check for Full Text Sources”)

…Open. URL Source - Setup Local info supplied to vendor in setting up Open. URL linking

…Open. URL Source - Setup • Setup may also ask you to specify which fields and labels to include in the parameter string (EBSCO is an example), e. g. : DT={date 1}&AU={author}&ISBN={ISBN}

Open. URL Source - Issues • Does source send all the necessary fields? • “Necessary” may vary by target – e. g. , Project Muse requires journal name and author name for constructing article-level links, others use ISSN and date/volume/issue information. • Does source send “e-issn, ” “print issn” or both? • Does source use labels and data formats specified by the standard? (e. g. , are dates in form “ 20041204” or “ 12/25/2004”? ) • Do the links display in a way that makes sense to the user? (If users need a bibliographic instruction session just to learn how to recognize the Open. URL links, the interface could use some work. ) • If you are shopping for an Open. URL solution, keep in mind that vendor will probably not set up your source links for you, nor can they guarantee that the resolver will work if the source metadata is incomplete or malformed.

Open. URL Source – Decision Points If you have the luxury of looking at evaluating comparable, competing database products, make Open. URL support part of your evaluation. • Whether they provide Open. URL links at all • Quality of the links based on earlier criteria mentioned

Open. URL Target Mega Abstracts Mega Fulltext EBSCO JSTOR Gale CSA Silver Platter Ovid etc. . . Open. URL Resolver Project MUSE • Database of resources – just the titles your library has access to Emerald Press • Authentication mechanism – your users EBSCO • Parsers to construct links into systems serving as Open. URL targets Royal Society Online Catalog

Open. URL Target Characteristics to Consider • Fulltext “database” (e. g. , Academic Search Premier) vs “Ejournal aggregator” (e. g. , Project Muse) • With databases that include fulltext content, you typically have access to *all* titles for which they have full text • Because the list of journals in a fulltext database is typically large, and changes frequently, locally keeping track of the list may not be practical • With aggregators, content is typically based on subscriptions to individual titles – just as you probably don’t subscribe to all the Elsevier journals in print, you probably don’t have access to all titles in Science. Direct Web Editions • Dates of coverage for aggregator content may vary from

. . . Open. URL Target Characteristics to Consider • How “deep” can a link go? • Database search screen • Journal volumes/issue pages (all dates) • Specific issue of journal • Article-level linking

. . . Open. URL Target Characteristics to Consider • Does Target support links using Open. URL syntax, or does the resolver need to parse the data into another format? JSTOR article-level linking example – JSTOR uses SICI codes for article-level links: Open. URL metadata: genre=journal&ISSN=00029475&DT=19950901&TI=Ancient%20 anagrams%2 E& JN=American%20 Journal%20 of%20 Philology&VI=116&IP=3&AU=Came ron%2 C %20 Alan&spage=477 becomes: sici=0002%2 D 9475%2819950901%29116%3 A 3%3 C 477%3 A%3 E 2%2 E 0 %2 ECO%3 B 2%2 D%23&origin=tcu

Open. URL Resolver Mega Fulltext Mega Abstracts EBSCO Gale CSA Silver Platter Ovid etc. . . Open. URL Resolver • Database of resources – just the titles your library has access to JSTOR Project MUSE Emerald Press • Authentication mechanism – your users Royal Society • Parsers to construct links into systems serving as Open. URL targets Online Catalog EBSCO

Open. URL Resolver Components Resolver • Database (aka “knowledgebase”) of your library’s resources (“targets”) • User interface for maintaining database • Software to accept Open. URLs as input, query database, construct appropriate links, and display available resources to user Note: Many vendors are selling both the database and software components – may or may not offer the option to unbundle the two.

Open. URL Resolver: Database & DB Interface Database of resources (“targets”) your library has access to • Should include titles in full text databases, not just subscription aggregators (currently TCU has app. 8, 900 ejournals through aggregators, versus app. 27, 500 journals in full text databases. ) • Should include accurate dates of coverage for each source of each title • Should include information for authenticating for offcampus use – e. g. , prefixing the URLs with the address of an EZproxy server or local script • Should include information about level of linking supported – e. g. , are article-level links possible?

. . . Open. URL Resolver: Database & DB Interface • Database record format – MARC, or tabular (RDBMS)? • TCU subscribes to a MARC feed that is loaded into our online catalog, and a tabular file that is loaded into a relational database – same information in both. • The MARC records allow users to find our print and online journals with a single search of our catalog • However, MARC data does not lend itself to use in an Open. URL resolver: • Much more difficult to write software that uses MARC • Dates of coverage may be embedded in free text notes – difficult or impossible to parse • Difficult to create links between MARC records and non-MARC data

. . . Open. URL Resolver: Database & DB Interface Questions to Ask Yourself • Are you starting from scratch, or have you already built a database of some/all your e-journal holdings? If you’ve already done work in-house, find out if/how you can supply that data to the vendor to populate the Open. URL resolver database without having to re-key everything. • Do you want data for other purposes than the Open. URL resolver – e. g. , MARC records for your online catalog? • What processes do you have in place to keep track of your subscription holdings – for example, noticing when titles you get in print become available online for no/reasonable additional cost? Think through how you will integrate these processes with updating the Open. URL resolver database.

. . . Open. URL Resolver: Database & DB Interface Questions to Ask Open. URL/Database Vendors • If the vendor is selling a bundled solution – a database and resolver software together – try to get as much detail as you can on the database – where it comes from, how it’s updated, how you maintain information about your subscriptions. • Open. URL resolvers are (so far at least) fairly simple applications to write. It’s easy for a vendor to demo their software. . . • Making sure the data being queried is accurate (e. g. reflects your holdings) is the hard part. • Can the vendor take a list of all your fulltext databases and subscription journals and confirm which ones they can supply data for?

. . . Open. URL Resolver: Database & DB Interface. . . Questions to Ask Open. URL/Database Vendors • How do you input your subscription holdings – initially, and then to keep it up to date? Mechanics of this could have a major impact on how quickly you get up and running, and how much labor is required to keep the information accurate. • How do you input “fulltext database” holdings? (Hopefully not by clicking on each individual title. ) • Do they supply both “e-issn” and “print issn” for titles? All or some? Ability to query the database by either issn and find a match will increase the rate of successful Open. URL resolutions, especially if the resolver constructs a search of your online catalog for print holdings when you don’t have a particular journal online.

Open. URL Resolver: Software Should be able to take the data sent by the source, query the database, and present the user with a list of relevant links to targets. If source was a journal article citation, the software: • Should take dates into account (why show a user eight links, if only three sources are for the volume/issue they need)? • Should provide article-level links when possible (whether it’s possible is something you may want to verify independently) • Should be able to check your catalog for print holdings when online holdings are unavailable – ideally without the user having to click on a second link to search the catalog.

. . . Open. URL Resolver: Software • Should be able to take advantage of all the data in the database – for example, if database has both print issn’s and e-issn’s, search both. • If no print or online holdings found, link to ILL request system. • Provide you with statistics – particularly link failure statistics, so you can track down problems with Sources and Targets (which may be unrelated to the Open. URL resolver itself).

Open. URL Resolver: Example Screens Source Link

. . . Open. URL Resolver: Example Screens We currently offer a catalog link up front, in case user actually prefers to use a print copy.

. . . Open. URL Resolver: Example Screens Article-Level Link Journal-Level Link Other sources in case date check flaked out Journal-level link Links to database search screen

. . . Open. URL Resolver: Example Screens Links from Academic Search Premier What’s this? – all links are failing!

Open. URL Resolver: Software Questions to Ask Yourself • Develop in-house, buy bundled hardware/software solution, buy software only and rely on other vendor for data feed? • Do you already have a database-driven online e-journal list, and is the programmer still available? If so, adding basic journal-level Open. URL functionality to it may not be much work. (see http: //lib. tcu. edu/staff/bouchard/Open. URL. ppt for more info) • On the other hand, starting from scratch creating a database-driven list just to achieve Open. URL functionality may not be very practical. • Host the server locally, or remotely at vendor site? May depend on the size of your staff, how much control (customizability) you

Open. URL Resolver: Software. . . Questions to Ask Yourself • Usability – will your users understand the interface? • Are you interested in other services besides linking from citations to full text? – e. g. , citation index searching, links to book reviews

Open. URL Resolver: Software Questions for vendor • If hosted locally, does it require a dedicated server? What size? Are other licenses required (e. g. , Oracle or SQL Server)? • How customizable is it – for example, can you create new services (e. g. , linking to a book review database) that aren’t already “canned”? • What kinds of statistics and reports are available? • Can it link to your online catalog? Does user have to “blind click” to see if there are sources in your catalog, or can the software search the catalog and tell them without the extra click? • Can it send a link on to your ILL system if no other sources available?

Open. URL - Conclusion • No solution will be completely turnkey – just as online catalog software is only useful if you have a cataloging department to maintain the data, Open. URL resolver software is useless without accurate data behind it. • But some are more turnkey than others – especially if you don’t want/have time to customize the interface. • It’s not that hard to do if you approach it with realistic expectations, and even if you rarely hear from them, your users will appreciate it.