On 6/21/06, Ross Singer <ross.singer_at_library.gatech.edu> wrote:
> On 6/21/06, Karen Coyle <kcoyle_at_kcoyle.net> wrote:
>
> >
> > 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
>
>
> I disagree -- just filter for the results on the page. That's only 20-25
> queries for bib id. For ILSes with RDBMS access, that's nothing.
>
> Ok, so your total results will be a little incorrect, but I don't think
> that's a huge deal.
>
Filter by 008/33 (literary form) = h. That'll be more than a little
off. ;) Extreme example? Maybe, depending on your audience. My
point is you can't do flexible /and/ correct with a completely
decoupled system.
>
> >
> > string (or more than one) on the OPAC system to keep the circ status
> > current, but I haven't seen that done. Anyone?
>
>
> With our fancy pants project, we are hitting the database repeatedly for
> information about every result on the page (a list of the 856s, current
> status of all copies, etc.) -- Oracle doesn't buckle nearly as much as
> Voyager does.
>
> -Ross.
>
>
>
> > 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:05:14 EDT