Federated search products and FullText/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-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.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&am
p;&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&am
p;&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.e
du/dwalker
>
> --
>
> 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/
>

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

We actually have developed a work-around for this approach
in SFX but take a
different approach to Rochester as we don't have a
metasearch tool.  Like
others, we wanted to ensure that users didn't have to
choose between
sources, but get taken directly to the full text.  

In a sense, we show a mini-menu... allowing the user to go
to the full-text
but get back to the Menu and a few other options.  We use
the SFX logic and
sort rules to govern which targets are 'preferred'. 

You can see the result here:

http://sfx.exlibrisgroup
.com:9003/haverf?sid=google&auinit=G&aulast=Mazza&am
p;at
itle=Absorption+of+anthocyanins+from+blueberries+and+serum+a
ntioxidant+statu
s+in+human+subjects&id=pmid:12475297

The Frame (one of the few places where it actually is a
functionally useful
thing) provides the context and a way to get back to the SFX
Menu.

- adam

_____________________________________
Tri-Colleges Systems Coordinator
Bryn Mawr | Haverford | Swarthmore
610.526.5294


-----Original Message-----
From: web4lib-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.org] On Behalf Of Binkley,
Peter
Sent: Monday, April 24, 2006 11: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-bounceswebjunction.org
[mailto:web4lib-bounceswebjunction.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&am
p;&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&am
p;&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.e
du/dwalker
>
> --
>
> 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/
>

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

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