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