Defining Use Cases for Federating Library Services

[Steven Carmody <>]

On 11/6/09 10:46 AM, Dale,Andy wrote:
> Some thoughts about the OpenURL case:
>
> As I understand OpenURL - I can go to an indexing service and assuming
> that they recognize my institutional affiliation (via IP Auth?) they
> will put MY institutions link resolver into their search results along
> with the 'standard' bibliographic meta-data about the resources I find:
> So, if I click on a result I will be sent to my link resolver who will
> work out where an instance of the resource that I actually have access
> to can be found.
That's my understanding of how it works today. But, I'dlikeone of the 
librarians to confirm this....

Early on, the architect for the ex-libris sfx link resolver was 
suggesting that the user could login at the home site, and then be 
redirected to the abstract search site. The IDP would release to the 
abstract site a standard attribute value containing the name/address of 
the campus link resolver. This approach would replace the use of IP 
addresses to identify the campus, and work in the "userif off campus" 
situation. However, I don't think this approach has been deployed anywhere.
> If that is the case then it seems to me that the primary flow is
> different when a resource is accessed via OpenURL the difference being
> driven by the fact that IF the user is off-campus (our main case) but
> the indexing service affiliated them; they probably accessed the
> indexing service via EZProxy... Therefore when the link resolver
> redirects to the resource; an active EZProxy session can be assumed.
>
>
>    
here's my understanding of the flow -- user is at abstracts site, clicks 
OpenURl button, is redirected to campus link resolver, is redirected to 
campus EZP (with target = deep link), EZP determines whether or not 
target is shib enabled, EZP follows std logic....