Service Oriented Library Systems

Submitted by effinglibrarian on Mon, 07/16/2007 - 20:25

Each of the systems that libraries use are self-contained silos. Each has its own embedded database/data structure, built-in search tool, and presentation / interface layers. Each requires library customers to use its unique presentation and search tools to access its unique content. Each has a completely different look, feel, and functionality.

From the user experience perspective, this system design strategy is why it is so difficult for librarians, let alone library customers, to find Time (magazine).

Ok, I'm not that smart. I've been known to get out of my car and then drop my keys on the ground because I tried to slip them into my pocket, but that day I forgot to put on pants.

I don't know about searching software or aggregated algorithms or how all this affects Tom Cruise's fluctuating height.

"They could create a database using common tools, expose it as a web service, and simply 'plug it in.'"

I don't understand a freaking thing this guy says. But nothing pisses me off more than to hear someone say, "simply plug it in."

I want to whoop his ass.

So I don't understand what he's saying, but here are some things I think I understand:

I've heard of thin-clients. You have a server and you have a client; the client requests something from the server and receives it. In some ways, it would remind you of the old dumb terminals you used in 1990.

Now, the server stores data, software, account permissions, etc. And it hosts our front end interface. To visualize, think of Google.

If you type "4+5=" into Google, you get page a page that says, "4+5=9." Google understood that you wanted the sum of two numbers and delivered it; imagine an interface that understood your library request and delivered it.

Right now, most libraries use some form of a search box and drop-down menu combo. You enter a search and click on subject or author or whatever, to tell the interface which fields of the bib record to search.

But if you had a search tool that understood the type of search, then you could eliminate the hassle of clicking and re-clicking on buttons to find something.

This is what my brain is telling me right now is a cool idea:
I type Charles Nelson Reilly into my search box and hit Enter. And my search algorithm understands that those three terms match up with a person's name. Now, if my IP address matches one used by library staff, the server might think I'm searching for a patron with that name. If I'm at a public terminal or on the net (and not logged in as staff), I won't see patron information. If I enter a patron ID, then the search immediately understands that I'm searching for patron info and that's what I get, unless I'm not authorized to see it. (Now the problem with that example is that you might not want to store
patron information on that server; I guess it doesn't have to be, but the main server might store the permissions to access the patron records server.)

If I enter Gone with the Wind as my search, the server could respond with links to books, videos or magazine and database articles. If I click on the database article, the server sends the secure login page for that database.

Now, I'm sure that this isn't the reason for Eric's article. He's a tech dude, and I'm just a happy-go-lucky kid with my head in the clouds.

I know that databases are flexible and can be designed to accommodate any recipe for data recovery, but I don't know if pre-existing patron databases can be deconstructed and rebuilt into open-source or non-library proprietary software. I don't know how the records are formatted.

But go back to the Google example and imagine an interface that filters your search intelligently and either delivers the results automatically (type dvd pufnstuf and take that funky trip back to when white cowboy boots were cool) or sends a
login script to allow you to access newspaper, magazine and database content. Once you're logged in, type ebert and harry potter and get movie reviews.

I'm not talking about a federated seach, either. If it's possible to take what Eric says and apply it to what I want, then that's what I'm talking about. Unless he uses the phrase, "simply plug it in," then he's getting a Fedex box full of ass-whoop.