[Web4lib] Federated search products andFullText/PeerReviewlimiting
David Walker
dwalker at csusm.edu
Mon Apr 24 14:43:32 EDT 2006
>> it does raise an accessibility problem:
>> users who don't see the images won't have
>> any way to benefit from the pre-resolution.
>> But perhaps a bit of AJAX could take care of
>> that.
Which brings us back to Jonathan's earlier comment about AJAX and his
(and my) hesitancy to say that AJAX is more accessible.
I've yet to read anything definitive on this. It appears that some
screen readers can read content dynamically inserted into a browser's
DOM, but if JavaScript is turned off or the user has an older browser,
obviously AJAX will not provide us with an out.
--Dave
=========================
David Walker
Web Development Librarian
Library, Cal State San Marcos
760-750-4379
http://public.csusm.edu/dwalker
=========================
-----Original Message-----
From: web4lib-bounces at webjunction.org
[mailto:web4lib-bounces at webjunction.org] On Behalf Of Binkley, Peter
Sent: Monday, April 24, 2006 8:37 AM
To: Web4Lib
Subject: RE: [Web4lib] Federated search products
andFullText/PeerReviewlimiting
Routing direct to full-text is an option in SFX (it chooses the first
full-text option based on the priorities you've configured), and we're
thinking of trying it. The downside is that if the link fails, there's
no safety net: the user never sees the other options that a menu might
offer.
I like Eric's image-based system, though it does raise an accessibility
problem: users who don't see the images won't have any way to benefit
from the pre-resolution. But perhaps a bit of AJAX could take care of
that.
Peter
-----Original Message-----
From: web4lib-bounces at webjunction.org
[mailto:web4lib-bounces at webjunction.org] On Behalf Of Roy Tennant
Sent: Monday, April 24, 2006 8: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
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/
>
_______________________________________________
Web4lib mailing list
Web4lib at webjunction.org
http://lists.webjunction.org/web4lib/
_______________________________________________
Web4lib mailing list
Web4lib at webjunction.org
http://lists.webjunction.org/web4lib/
More information about the Web4lib
mailing list