[Web4lib] Federated search products and Full Text/PeerReviewlimiting

[Roy Tennant]

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

On Apr 23, 2006, at 9:10 PM, Eric Hellman wrote:

> From an architectural standpoint, I think that the image-based  
> linking mechanism implemented in Scopus in cooperation with several  
> link-server vendors and being experimented with at Cal State Marcos  
> is an excellent way for link servers to expose holdings information  
> at point-of-click. The neat thing is that if a OpenURL 1.0  
> ServiceType is used to trigger image serving, then the same  
> mechanism can be used in a wide variety of library applications.
>
> For an example of how this works, try the two OpenURL links below
> http://derby.1cate.com/? 
> rft.issn=0954-6820&svc_id=img&url_ver=Z39.88-2004&&rft_val_fmt=info:of 
> i/fmt:kev:mtx:journal
>
> http://derby.1cate.com/? 
> rft.issn=0022-510X&svc_id=img&url_ver=Z39.88-2004&&rft_val_fmt=info:of 
> i/fmt:kev:mtx:journal
>
> It is not difficult to engineer and deploy a link server  
> application that can handle image serving load without bogging  
> down, as David Walker is finding. Libraries should demand this  
> engineering from their vendors!
>
> Eric
>
>> Roy said:
>>
>>>>  What we are attempting to do is to use the ability
>>>>  of SFX to accept multiple OpenURLs in one resolving
>>>>  request to do a lookup before sending search results
>>>>  to the user interface.
>>
>> Karen, we're experimenting with a somewhat different approach here at
>> San Marcos, inspired in large part by the work Rolf Kwakkelaar has  
>> done
>> at Elsevier with "image-based linking."
>>
>> Rather than send requests to SFX in advance of displaying search
>> results, we're displaying the results first (so they load  
>> quickly), and
>> then using the browser's inherent asynchronous loading of images  
>> to load
>> in a full-text or non-full text image based on a query of our SFX
>> Knowledgebase -- unless, that is, the database itself has native
>> full-text, in which case this processes is skipped.
>>
>> Also, rather then query SFX directly for availability, we're  
>> downloading
>> a slimmed down set of information out of the SFX Knowledgebase,  
>> storing
>> that info in a local Oracle database, and querying that (and caching
>> results in memory).  That loads much, much faster than trying to  
>> resolve
>> a full OpenURL against the SFX API, and also keeps our SFX server  
>> from
>> getting swamped with requests.
>>
>> --Dave
>>
>> =========================
>> David Walker
>> Web Development Librarian
>> Library, Cal State San Marcos
>> 760-750-4379
>> http://public.csusm.edu/dwalker
>
> -- 
>
> Eric Hellman, Director                            OCLC Openly  
> Informatics Division
> eric at openly.com                                    2 Broad St.,  
> Suite 208
> tel 1-973-509-7800 fax 1-734-468-6216              Bloomfield, NJ  
> 07003
> http://www.openly.com/1cate/      1 Click Access To Everything
> _______________________________________________
> Web4lib mailing list
> Web4lib at webjunction.org
> http://lists.webjunction.org/web4lib/
>