Transcript 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
[email protected]
presentation available online at:
http://lib.tcu.edu/staff/bouchard/OpenURL/TLA2004.htm
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
??? ... let your
imagination run wild
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/april99/van_de_sompel/04van_de_so
mpel-pt1.html
Proposes the “SFX” model – dynamic linking based on passing
metadata about a resource to a resolver program.
OpenURL Dynamic Linking Model
OpenURL metadata
Mega Abstracts
EBSCO
Gale
CSA
Silver Platter
Ovid
etc...
Links to target may or
may not be OpenURL
OpenURL
Resolver
Mega Fulltext
JSTOR
• Database of
resources – just the
titles your library has
access to
Project MUSE
• Authentication
mechanism – your
users
Royal Society
• Parsers to construct
links into systems
serving as OpenURL
targets
Emerald Press
EBSCO
Online Catalog
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”
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/
…OpenURL Standard Resources
OpenURL listserv (general discussion)
[email protected]
OpenURL software development list
[email protected]
OpenURL Components
Resolver
Source (e.g.,
article
citation)
Takes metadata
about the cited
resource and
puts it in
format defined
by OpenURL
standard
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).
Target
(online journal,
vendor 1)
Target
(online journal,
vendor 2)
Target
(online catalog)
Target
(citation index)
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 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: 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.
...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
Reg. Auth.
(online journal,
Source
• Sends DOI to
Resolver
Resolver
• Sends DOI to
Registration
Authority
• Sends full set
of metadata
about article
vendor 1)
Target
(online journal,
vendor 2)
Resolver
• Constructs
links using
better metadata
Target
(online catalog)
Target
(citation index)
OpenURL Source
Mega Abstracts
Mega Fulltext
EBSCO
JSTOR
Gale
CSA
Silver Platter
Ovid
etc...
OpenURL Resolver
Project MUSE
• Database of resources –
just the titles your library
has access to
Emerald Press
• Authentication
mechanism – your users
Royal Society
• Parsers to construct
links into systems serving
as OpenURL targets
EBSCO
Online Catalog
...OpenURL Source
URL for the link above:
http://lib.tcu.edu/PURL/OpenURL.asp?genre=journal&ISSN=00092541&DT=20030615&TI=Carbon%20isotope%20exchange%20rate%20of%20DIC%20i
n%20karst%20groundwater%2E&JN=Chemical%20Geology&VI=197&IP=14&AU=Gonfiantini%2C%20Roberto&spage=319&sid=EBSCO:aph
(example from Academic Search Premier)
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”)
…OpenURL Source - Setup
Local info supplied to vendor in setting up OpenURL linking
…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}
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.
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
OpenURL Target
Mega Abstracts
Mega Fulltext
EBSCO
JSTOR
Gale
CSA
Silver Platter
Ovid
etc...
OpenURL Resolver
Project MUSE
• Database of resources –
just the titles your library
has access to
Emerald Press
• Authentication
mechanism – your users
Royal Society
• Parsers to construct
links into systems serving
as OpenURL targets
EBSCO
Online Catalog
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
...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
...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%2
D%23&origin=tcu
OpenURL Resolver
Mega Fulltext
Mega Abstracts
EBSCO
Gale
CSA
Silver Platter
Ovid
etc...
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
Project MUSE
Emerald Press
Royal Society
EBSCO
Online Catalog
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.
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?
...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
... 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.
...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?
...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.
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.
...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).
OpenURL Resolver: Example Screens
Source Link
...OpenURL Resolver: Example Screens
We currently offer a catalog link up front, in case user actually
prefers to use a print copy.
...OpenURL 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
...OpenURL Resolver: Example Screens
Links from
Academic
Search Premier
What’s this? – all links
are failing!
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.
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
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?
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.