LOCALIZED REFERENCE LINKING PROJECT Dale Flecker NFAIS/NISO Linking Workshop February 24, 2002 Philadelphia
Mar 27, 2015
LOCALIZED REFERENCE LINKING PROJECT
Dale Flecker
NFAIS/NISO Linking Workshop
February 24, 2002
Philadelphia
Citation LINK
MAGICLINK
Cited Article
Citation
THE PROMISE OF CITATION LINKING
CLICK
Any old system
Any old system
CitationDOI
Step1
Step2 DOI Resolver
DOI
URL
Cited article
Search response
RepositoryURL
Article
Step3
HOW DOI PERFORMS “MAGIC”
CLICK
BUT -- WHAT IF MORE THAN 1 COPY EXISTS?
• Elsevier journals, for example, are on-line at:– Elsevier ScienceDirect– OhioLink– University of Toronto
WHICH URL?
HandleServer
DOI
URL?
Sciencedirect.com?
Ohiolink.edu?
Utoronto.ca?
A PROBLEM
DOI today cannot naturally resolve to more than 1 copy
ACM
DOI (to Elsevier)
Ohio State User
ELSEVIER
Cited article
OhioLink
A BAD THING….
(or: “$25, please”)
CLICK
ARTICLECitation
WHY MULTIPLE COPIES
• Local loading
• Aggregators
• Mirror sites
• Paper copies
• E-print “archives”??
• Preservation archives??
THE APPROPRIATE COPY
When more than one copy exists, specific populations frequently have the
right to access specific copies
CROSSREF/DLF LINKING PROTOTYPE
• Group of research libraries (coordinated by DLF) approached CrossRef on the “appropriate copy” issue
• Series of discussions between publishers, DOI, CrossRef, libraries, service providers, NISO
• Prototype to test “localization” of linking using OpenURL Framework
PARTICIPANTS
• International DOI Foundation/CNRI
• CrossRef
• Los Alamos National Laboratory
• University of Illinois
• Ohio State/OhioLink
• Ex Libris
OpenURL FRAMEWORK
NOT:
LINK TARGET
RATHER:
LINK SERVICE
TARGET A
TARGET B
TARGET C
LINKING SERVICE
• An agent for the user
• Knows what the link is for– OpenURL transports information to the service
about the link
• Knows the user’s context– therefore can “localize” the link
• Reasons about the appropriate target(s) for a link
OpenURL
Transports metadata to a service:
http://serv.univ.edu/id=doi:123/4567
Identity of local service
Metadata aboutlink
DESIGN ISSUES IN “LOCALIZING” LINKS
• How to identify which users need localization
• How to insert the service agent in DOI resolution to do localization
• How does the agent know what a DOI identifies
• How does the agent know how to appropriately resolve the DOI
Any old system
CitationDOI
Step1
Step2 DOI Resolver
DOI
URL
Cited article
Search response
RepositoryURL
Article
Step3
REMEMBER HOW DOI PERFORMS “MAGIC”
CLICK
Any old system
CitationDOI
Step1
Step2 DOI Resolver
DOI
Search response
PROTOTYPE ARCHITECTURE
CLICK
DOI SERVER:Does user havelocalization?
LOCALIZATIONSERVICE
Y
N
DOI (Handle) Resolver
PROTOTYPE ARCHITECTURE
DOI web proxy:Does user havelocalization?
LOCALIZATIONSERVICE
Y
NDOI
CrossRef
OpenURL with DOI
Metadata in XML
Address of alternate copy
to User
DOI with localization switch = “no”or
DESIGN ISSUE #1
• How to identify which users need localization– solution = cookie
• user’s institution must implement method of getting appropriate cookie on user workstation
• transparent to the user
– highly controversial• how to set? keep set? avoid setting inappropriately?
– but…what alternative?
DESIGN ISSUE #2
• How to insert localization service in DOI resolution– put a filter in front of DOI resolution service
which looks for cookie• if no cookie, just resolve DOI as usual
• if cookie, redirect transaction to local agent, using an OpenURL containing the DOI
DESIGN ISSUE #3
• How does a service agent know what a DOI refers to?– University of Illinois service did not need to
• just keep a list of DOIs for articles in the local system
– other implementations retrieved descriptive metadata from CrossRef
DESIGN ISSUE #4
• How does the service agent know how to appropriately resolve the DOI– up to the local agent
• look up DOI in local database which gives local address
• look up journal in local database, giving linking syntax
• send search to opac
– Can resolve to locally stored digital copy, local paper copy, aggregator service, document delivery service, original publisher….
IMPLEMENTATION
• CNRI implemented a “cookie pusher”, and filter for resolution requests
• LANL and Ohio State used SFX as the localizing agent
• Illinois wrote a localizing agent
• All three libraries implemented a script to trigger “cookie pushing”
• CrossRef implemented “reverse look-up” (DOI to metadata)
EXPERIENCE
IT WORKS!!!!
A COUPLE OF REMAINING ISSUES
• Cookies the big issue– how to consistently get them on user machines,
maintain them• Locating metadata not addressed in prototype
– will become an issue as other DOI registration agencies come on-line
• need to know which agency to ask for the metadata
STATUS -- DOI LOCALIZATION
CrossRef and International DOI Foundation committed to
support localization model
STATUS -- OpenURL
NISO workgroup on fast-track to standardize format
Many companies already committed to support OpenURL: EBSCO, OCLC, Gale, IOP SilverPlatter, Ovid, Bowker,
Wilson, ProQuest….
STATUS -- LOCALIZING AGENTS
Two commercial products available:Ex Libris’ SFX and Endeavor’s LinkFinderPlus
-- these provide liking options beyond appropriate copy-- many working installations of SFX already
OhioLink and University of Illinois have implemented custom agents
MORE DETAIL?
On the prototype:
D-Lib Magazine, September, 2001www.dlib.org
On OpenURL:
library.caltech.edu/OpenURL