Federated search products and FullText/PeerReviewlimiting

>> The only way around this I can see is if  
>> your OpenURL resolver would automatically 
>> route the user to full-text if it's available 
>> without putting up a resolver menu.

Which is what I'd like to do here.

I'm thinking of something along the lines of GUF at
Rochester, which not
only sends the user directly to the full-text, but also does
some
pre-checking of the target to see if it is alive, and some
additional
drilling-down to the article level.

I'm just nervous (unnecessarily so?) about trying to do too
much
processing up-front, particularly in a production
environment.  So I'm
looking for every opportunity to push the heavier processing
until
point-of-need.

--Dave

=========================
David Walker
Web Development Librarian
Library, Cal State San Marcos
760-750-4379
http://public.csusm.e
du/dwalker
=========================




-----Original Message-----
From: web4lib-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.org] On Behalf Of Roy Tennant
Sent: Monday, April 24, 2006 7:24 AM
To: Web4Lib
Subject: Re: [Web4lib] Federated search products and
FullText/PeerReviewlimiting

As intrigued as I am about this technique, the one downside
I see is  
that when you resolve OpenURLs this way, you cannot provide
a link  
directly to the full-text. That is, the user will still need
to click  
through the OpenURL resolver window, since the link on the
page will  
have already been constructed and delivered to the user
BEFORE the  
OpenURL is resolved. So that for me is an interesting
trade-off:  
either you resolve before you put the results up for the
user, and  
potentially get rid of an additional click and a resolver
menu for  
the user to puzzle over, but suffer any speed consequences
there may  
be, or you put the results up faster but then force the user
to go  
through the resolver menu. The only way around this I can
see is if  
your OpenURL resolver would automatically route the user to
full-text  
if it's available without putting up a resolver menu. We
are not  
presently doing this, and I'm not sure who is. So,
apparently we must  
pick our poison, which is becoming a common refrain for
those of us  
involved with constructing metasearch services.
Roy



_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

David Walker wrote:
>>> The only way around this I can see is if  
>>> your OpenURL resolver would automatically 
>>> route the user to full-text if it's available 
>>> without putting up a resolver menu.
> 
> Which is what I'd like to do here.
> 
> I'm thinking of something along the lines of GUF at
Rochester, which not
> only sends the user directly to the full-text, but also
does some
> pre-checking of the target to see if it is alive, and
some additional
> drilling-down to the article level.
> 

I'd be interested to know how direct-to-document resolvers
handle the 
appropriate cop(ies) problem -- what text does the Rochester
resolver 
present to the user when the library has multiple versions
of the same 
article from different vendors? Does it favor certain
vendors? Just a 
question...

Mark


Mark Jordan
Head of Library Systems
W.A.C. Bennett Library, Simon Fraser University
Burnaby, British Columbia, V5A 1S6, Canada
Phone (604) 291 5753 / Fax (604) 291 3023
mjordansfu.ca / http://www.sfu.ca/~mjorda
n/
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/

In our system, there are 3 modes configurable by the library
autoredirect=off  --- always show the link-server page
autoredirect=single  --- this means redirect if there is one
and only 
one 'best' link
autoredirect=best    --- redirect to the first 'best' link
found even 
if there are multiple high quality links; links can be
ordered by 
preferred providers

I believe that Endeavor's LinkFinderPlus was the first
commercial 
OpenURL resolver that touted this sort of capability.

Eric


At 8:30 AM -0700 4/24/06, Mark Jordan wrote:
>David Walker wrote:
>>>>The only way around this I can see is if 
your OpenURL resolver 
>>>>would automatically route the user to
full-text if it's available 
>>>>without putting up a resolver menu.
>>
>>Which is what I'd like to do here.
>>
>>I'm thinking of something along the lines of GUF at
Rochester, which not
>>only sends the user directly to the full-text, but
also does some
>>pre-checking of the target to see if it is alive,
and some additional
>>drilling-down to the article level.
>>
>
>I'd be interested to know how direct-to-document
resolvers handle 
>the appropriate cop(ies) problem -- what text does the
Rochester 
>resolver present to the user when the library has
multiple versions 
>of the same article from different vendors? Does it
favor certain 
>vendors? Just a question...
>
>Mark
>
>
>Mark Jordan
>Head of Library Systems
>W.A.C. Bennett Library, Simon Fraser University
>Burnaby, British Columbia, V5A 1S6, Canada
>Phone (604) 291 5753 / Fax (604) 291 3023
>mjordansfu.ca / http://www.sfu.ca/~mjorda
n/

-- 

Eric Hellman, Director                            OCLC
Openly 
Informatics Division
ericopenly.com                                    2 Broad
St., Suite 208
tel 1-973-509-7800 fax 1-734-468-6216             
Bloomfield, NJ 07003
http://www.openly.com/1c
ate/      1 Click Access To Everything
_______________________________________________
Web4lib mailing list
Web4libwebjunction.org
http://lists.we
bjunction.org/web4lib/