1 / 43

OpenURL – Concepts and Implementation

OpenURL – 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.

dyami
Télécharger la présentation

OpenURL – Concepts and Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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.

  4. 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.

  5. ...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

  6. ...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.

  7. 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/april99/van_de_sompel/04van_de_sompel-pt1.html Proposes the “SFX” model – dynamic linking based on passing metadata about a resource to a resolver program.

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

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

  10. OpenURL 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/

  11. …OpenURL Standard Resources OpenURL listserv (general discussion)openurl@caltech.edu OpenURL software development listLIB-OPENURL-DEV-L@listserv.uiuc.edu

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

  13. Digression: OpenURL, DOI & CrossRef Thanks to Amy Brand (Directory of Business Development for CrossRef), Miriam Blake (Los Alamos library), and Jenny Walker (Ex Libris), who presented a session on OpenURL, DOI, and CrossRef 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 article-level 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.

  14. ...Digression: OpenURL, DOI & CrossRef • CrossRef - 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 OpenURL.

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

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

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

  18. OpenURL Source - Setup • Setup can be as simple as sending the vendor the URL of your OpenURL resolver, e.g.: http://lib.tcu.edu/PURL/OpenURL.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”)

  19. …OpenURL Source - Setup Local info supplied to vendor in setting up OpenURL linking

  20. …OpenURL 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={date1}&AU={author}&ISBN={ISBN}

  21. OpenURL 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 OpenURL links, the interface could use some work.) • If you are shopping for an OpenURL 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.

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

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

  24. OpenURL 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 ScienceDirect Web Editions • Dates of coverage for aggregator content may vary from library to library because of subscription differences

  25. ...OpenURL 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

  26. ...OpenURL Target Characteristics to Consider • Does Target support links using OpenURL 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: OpenURL metadata:genre=journal&ISSN=0002-9475&DT=19950901&TI=Ancient%20anagrams%2E&JN=American%20Journal%20of%20Philology&VI=116&IP=3&AU=Cameron%2C%20Alan&spage=477 becomes: sici=0002%2D9475%2819950901%29116%3A3%3C477%3A%3E2%2E0%2ECO%3B2%2D%23&origin=tcu

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

  28. OpenURL Resolver Components Resolver • Database (aka “knowledgebase”) of your library’s resources (“targets”) • User interface for maintaining database • Software to accept OpenURLs 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.

  29. OpenURL 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 off-campus 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?

  30. ...OpenURL 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 OpenURL 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

  31. ... OpenURL 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 OpenURL resolver database without having to re-key everything. • Do you want data for other purposes than the OpenURL 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 OpenURL resolver database.

  32. ...OpenURL Resolver: Database & DB Interface Questions to Ask OpenURL/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. • OpenURL 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?

  33. ...OpenURL Resolver: Database & DB Interface ...Questions to Ask OpenURL/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 OpenURL resolutions, especially if the resolver constructs a search of your online catalog for print holdings when you don’t have a particular journal online.

  34. OpenURL 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.

  35. ...OpenURL 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 OpenURL resolver itself).

  36. OpenURL Resolver: Example Screens Source Link

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

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

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

  40. OpenURL 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 OpenURL functionality to it may not be much work.(see http://lib.tcu.edu/staff/bouchard/OpenURL/OpenURL.ppt for more info) • On the other hand, starting from scratch creating a database-driven list just to achieve OpenURL 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 want have over the software.

  41. OpenURL 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

  42. OpenURL 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?

  43. OpenURL - 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, OpenURL 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.

More Related