Jonathan Rochkind wrote:
> 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?
Z39.50. A query based on a record number (presumably the de-coupled
parts must have at least one identifier in common) that retrieves the
information from the circ system. However, this doesn't help you with
filtering, because the data on status isn't in your database and
therefore can't be part of a search. You would have to retrieve the
status data for all entries that meet the search criteria and filter
them on the fly. Expensive. Very expensive. So displaying very up to
date info is relatively easy, but having it be both up to date and
searchable, when the databases are decoupled, is more difficult. I can
imagine a method where the circ system would constantly refresh a bit
string (or more than one) on the OPAC system to keep the circ status
current, but I haven't seen that done. Anyone?
kc
>
> 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/ __________________________________________________
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Wed Jun 21 2006 - 13:54:33 EDT