On 6/21/06, Karen Coyle <kcoyle_at_kcoyle.net> wrote:
> 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?
>
I believe Koha is experimenting with something along those lines,
though our (Evergreen) tests show that it's a /very/ hairy problem.
We found that it's nearly impossible to get all of
a) everything you could ever want to filter on into the non-catalog
(OPAC) store
b) no noticeable degradation in online transaction processing time
at the circ stations
c) a well normalized (read: flexible) filtering attribute layout in
the OPAC store
We have decided to go another route to decoupling the interface from
the catalog-proper: a rich, broad, simple, low-overhead, standardized
interface to the catalog. Everything that the Evergreen OPAC does can
be done through either a native OpenSRF/JSON-over-Jabber interface, an
OpenSRF/JSON-over-http web service interface, an OpenSRF/XML-over-http
interface, and with the addition of supercat, a REST-ish all-xml
interface as well as new, emerging protocols such as unAPI and (coming
soon) APP.
I guess my direct point is this: the problem of the NGO(PAC) isn't
necessarily best solved by layering an OSS hack on top of a
featureless black-box catalog, but perhaps the catalog itself (which
is the core of the circulation system, what most here seem to be
referring to as the "ILS" side of OPAC-ILS) should be fixed to provide
a real, full-featured interface -- without bankrupting the library.
IMHO, the phrase "decoupling the OPAC and ILS" should be replaced with
"decoupling the USER INTERFACE and the ILS" ... that's what we've
designed for, and, to a very large extent, what we've succeeded in.
And my round-about point is this: if (nearly) every customer demands
this interface/data decoupling -- not just a dozen movable template
parameters in some hard-wired templates, but a real API -- maybe it
will one day happen. Then we can really start talking about the next
generation interfaces.
<plug type="shameless>
Or we can all pitch in and help with Evergreen...
</plug>
'Course, that could just be me... :)
> 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
> ------------------------------------
>
--
Mike Rylander
mrylander_at_gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org
Received on Wed Jun 21 2006 - 15:02:36 EDT