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:17:10 EDT