Symphony’s problem with operators

I’d be quite alarmed if this hasn’t already been reported since SirsiDynix’s Symphony OPAC has been out in the wild for quite some time, but here’s an annoying “bug” that I just discovered today.

Search for near in any out-of-the-box Symphony OPAC and you’ll get yourself an error.  Now try with, adj, same, and even the Boolean operators or, not, & and (I’ll ignore “xor“, since I can’t think of any examples when I’d ever type that).

[digression: If you try to search for but (for, by, etc.), however, it will tell your that your search contains all stopwords.  And,  I’ll try to forgo the argument about whether or not a library catalog should remove so-called stopwords in this day and age, but suffice it to say that a user can’t find any albums by “The The” without moving beyond the default search form; and, in my opinion, a user should never have to do such a thing for such a simple search. ]

So, yes, the Symphony OPAC seems to have a problem with operators, but it’s certainly not likely that someone will search for adj.  If someone does, however, whether by accident or not, they shouldn’t be greeted with an error.  Instead, their query should be run as is, but on the results page there should also be a new <div>, placed unobtrusively, that informs the user that “adj” is also a proximity operator, and this is how to use it, should they want/need.

What’s worse, though, is that you cannot use near, with, same, or, not, and at the beginning OR end of any of your queries (exception:  you can use not at the beginning of your query without getting an error since that operator doesn’t require a first half of an argument, but it will still treat not as an operator).  And this, in my mind, is the real bug here.  You cannot, then, search for:

  • Near a thousand tables
  • Near eastern archaeology
  • The singularity is near
  • With wings like eagles
  • Same differences
  • Same river twice (but you’re fine if you include the stopword “the” at the beginning, since “same” will no longer be the first word in the query)
  • I love you just the same
  • Or else my lady keeps the key
  • Ready or not
  • Not philosophy (won’t search for the query “not philosophy” but will instead search for any record that doesn’t contain the keyword “philosophy”…  so, you won’t get an error, but you’ll get a LOT of results).
  • And then there were none
  • And the band played on
  • And you get the idea…

Of course, you can move beyond the default search values and use any of those proximity operators in conjunction with the “browse” (or “begins with”) radio button, but that should NOT be a requirement for using a select few query terms.  Or, worse, you could work around this bug, for now, by altering your search to something like this:

“and” then there were none

or even

the and then there were none

but that’s a pretty silly solution, as well.  In any event, I have no idea if this bug has been reported or not, but I am quite certain that it would be a very easy fix for SirsiDynix to implement, so I hope that they do so soon — that is, if they don’t already have a patch for this in the works.

Anyhow, if you want to try this out, of if you’re really ambitious and think that you can find any other bugs worth reporting, here’s a list of libraries using Symphony that I’ve compiled:

Unfortunately, it’s hard to dertermine a static link to Symphony OPACs, so most of those links will take you to a timed-out session.  Once there, though, you can get back to the main search page usually just by clicking on “OK”, and then starting a new search.

[ update: I just checked a Sirsi Unicorn library catlog, and it also seems to have this same issue on default, keyword searches.  So apparently this is a carryover from that legacy system (we were previously on Dynix’s Horizon, which did not have the same issue by default; at least not that I’m aware of).  So, in hindsight, I guess this is a Unicorn bug, which makes me certain that it’s already been reported, but I really wonder why it exists.  Indexing a default query in this manner seems very strange to me.  Certainly they could just require their operators to be followed by a special character, such as “#”, or even just  not treat any boolean or proximity operators as operators when they appear at the beginning or end of a query.]


One response to “Symphony’s problem with operators

  1. Ah, thanks! This cleared up some contradictions I’ve heard.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s