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
> eric openly.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/
|