Helios or not

18 June 2008 | Sean | Coding, Philosophy | No Comments

Brett and I met on Thursday to talk about the project. The notable issue that came up is the degree to which LISinfo could borrow from a similar project I’m working on, Helios, a discovery layer we’re using at Drexel to make it easier to browse the DVDs in our catalog. It has also been used at some other places listed at the Google code page.

At the moment, the main difference between the projects is that Helios doesn’t have any record-editing function. Drexel maintains its records in III’s Millennium ILS and I import them into Helios. That model won’t work for LISinfo. We need to be able to edit records.

We have three options:

  1. Continue to develop Helios and LISinfo as separate, but similar, projects, swapping code where appropriate.
  2. Use Helios as the discovery layer, and develop an LISinfo catalog application that complements it.
  3. Rely entirely on Helios. Develop a full catalog application in Helios that serves LISinfo’s needs, but maintains enough flexibility for current Helios uses to continue.

The thing is, Helios already has the beginnings of a catalog app, but it’s
really just a per-record view of the index. That’s because Helios was
originally developed as an OPAC, so there are multiple
paradigms to consider.

The first paradigm is that of the OPAC, in which applications are split between the staff/admin and public. This is also the way most web projects are built. In this paradigm, an application or group of applications handles the search page, the results page, and the view of each record, while another application or group of applications handles the “behind the scenes” interfaces for editing records and altering the site. If LISinfo follows this paradigm, it should be fairly easy to make sure we provide a consistent look and feel across the site.

The second paradigm splits the applications between the discovery layer and the various resources the discovery layer indexes, such as the catalog. This is the search engine model, as well as the one employed by federated search applications. The main benefit is the loose coupling between the search/results application and the various applications that display
and maintain the indexed resources. It’s obviously less centralized, and considering that we plan to keep all of the records for LISinfo in one place, this paradigm might not be a good fit. However, it is the direction in which I’ve been pushing Helios.

If I limit the Helios project to the role of a discovery layer, it becomes one app. I agree with the Unix philosophy—each tool should do one thing well—but I’d rather make Helios more comprehensive and simplify the goal of each app within Helios. I think with some careful planning I can satisfy both paradigms and create something flexible enough to use for LISinfo as well as various library collections.

I think the best fit, then, would be to maintain the discovery app, but include
an optional record-level display within it. That’s three views (index, search,
record), all pulling information from the Solr index. It will serve the role
of the OPAC as well as the discovery layer. A separate app, named “cataloging,”
will handle the staff interface for the creation and maintenance of records.
The cataloging app will include views for both batch and individual editing of
records, and will either update the index directly or alert the discovery app
to do so. Each one should contain hooks for interoperability, but be able to
operate independently if needed, as if the cataloging app is just another
resource for the discovery layer to display.

Leave a Reply