Screen-scraping of the "old" OPAC works just fine, and the latency is
really low if you're just talking about a detail view. Might be a lot
more noticeable if you're scraping the 20 screens needed for a list view
though (or the hundreds needed to get statuses for filtering). In those
cases you could cache it, but then you're back to back to less than 100%
currency.
Ed.
http://marginalist.blogsome.com/
-----Original Message-----
From: Next generation catalogs for libraries
[mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Jonathan Rochkind
Sent: Wednesday, June 21, 2006 12:06 PM
To: NGC4LIB_at_listserv.nd.edu
Subject: [NGC4LIB] ILS and OPAC coupling
I agree that the ILS and the OPAC should be decoupled, but the issue is
that the OPAC has _got_ to show you completely current availability
information from the circulation component---checked out, checked in, in
transit, how many holds, etc.
Somehow AquaBrowser does this, although it only does it in the item
detail view---does anyone know some technical details of how it
accomplishes this? Or how/if any other 'decoupled' OPAC experiments
accomplish this?
Really, patrons want it in the list results, not just in the detail
view. Actually, REALLY, patrons want to be able to filter and sort by
availability, which few OPACs currently let you do, and which would be
even more of a challenge in a 'de-integrated' OPAC. I'm not sure how it
would be best accomplished technically--and then there's forcing your
ILS to actually do it.
--Jonathan
At 8:31 PM +1000 6/21/06, Alexander Johannesen wrote:
>On 6/21/06, Bernhard Eversberg <ev_at_biblio.tu-bs.de> wrote:
>>That sounds like you advocate a complete decoupling of OPAC and ILS,
>
>Yes, absolutely; I don't understand the fascination for mammoth
>systems, and I think a lot of people in the library world is waking up
>to find that their monolith systems should be a series of decoupled
>services. You may know where this leads to :) but I'm a huge SOA guy.
>
>>with regular automatic updates of the former from the latter?
>
>Depends on what is the best process, but it seems an export from the
>ILS on a nightly basis is ok if you've got a big ILS that handles it
>all.
>
>>It would mean that the OPAC could be the same even when the ILSs are
>>radically different.
>
>Yes, it's a comfortable consistancy problem solved. In fact, you can
>totally swap out your ILS without affecting the OPAC in any way at all,
>neither in features nor look and feel.
>
>>Besides the OPAC then being not 100% up-to-date, what disadvantages
>>might make you reluctant to call it "next generation"?
>
>I hate fads? :) Seriously, that the OPAC is 12 hours behind your ILS
>means probably very little. The main disadvantage I guess is that there
>is no vendor support for the OPAC. The good thing about this is of
>course that there is no vendor tie-in either. And given the
>user-interface to most OPACS today, I'd say it's a good thing to get
>away from them.
>
>Another big advantage is that you can concentrate on the user-interface
>of what you've got instead of asking vendors for features. It isn't
>that hard to extend something you've got all the sources and data for;
>Lucene is open-source, got a huge following and community, bundles of
>plugins and extra applications (like Nutch) ...
>it supports stemming, clustering, just heaps, and heaps of stuff, and
>growing every day. All you have to worry about is creating the
>user-interface you think suits your users, which we all do through UCD
>of course. :)
>
>Anyways, we're dumping the prototype to a test machine, and it's being
>opened tomorrow, and that's very exciting because we want to share our
>stuff with the lib community. The system is also exposed as a
>webservice in a Topic Maps lookalike schema which I also reuse for
>other applications; adding complex search to other applications is a
>matter of parsing some XML. It's a *very* powerful notion, because we
>don't have to wait for a single vendor to a) understand our problem,
>nor b) try to come up with a solution for it.
>
>
>Alex
>--
>"Ultimately, all things are known because you want to believe you
know."
> - Frank
>Herbert __ http://shelter.nu/
__________________________________________________
Received on Wed Jun 21 2006 - 12:29:28 EDT