Couple of other notes.  I gave a keynote as well and discussed moving the ILS to the network space and what that might look like within the Pacific Northwest (since we have some established partnerships that might make this easier).  The more I’ve worked with our ILS, the more I’m convienced that there really isn’t a compelling need any longer for local ILS system, but am more interested in seeing libraries consolidate systems while we wait for someone to develop a networked alternative.  In that vein, I’m curious to know what III is doing to position itself to survive within this space.  Their development model is still very client focused — so I would be curious to see how they view their own future within this space.

–TR

[knock, knock]

Homer: Who’s there
Voice: Hired Goons

[Homer opens the door to find two hired goons waiting to take him to Mr. Burns]

Is this the scenario that was being imagined?  Probably not.  I imagine what probably prompted the question was some recent events and announcements to come out of the Pacific Northwest, specifically as they had to do with Summit, a consortia made up of Oregon and Washington Libraries.  For the past 13 years (if I remember correctly, Summit started my freshman year at the University of Oregon in 1995), the Summit (or Orbis consortia, as it was known for the first 9 or so years) consortia utilized III’s InnReach software.  As of next fall, this will change, as the consortia and OCLC have entered into an agreement to build a consortia version of WorldCat Local.  This decision has put some strain in the relationship between III and the consortia (and III and it’s members) over the past year — but it really is time to move on.  In the end, we simply didn’t share the same needs and were moving in two different paths.  On one hand, the consortia had a real desire to purchase a solution that provided much greater access to API for purposes of interoperability and local development.  With OCLC’s product, this appears to be something that will be available to the consortia and it’s members — especially as OCLC’s grid services become a reality.  III on the other hand, well, I think that they will eventually come around to making an API available — they are just doing it much slower than we would like.  But more than anything though, I think it comes down to a difference of philosophy.  III, for better or worst, still sees the library catalog as the central resource of a library’s infrastructure, while Summit and it’s members are starting to see it as one small piece of a much larger whole.  Because of that, the two groups place different emphasizes on things like API access, NCIP support, OAI support, etc. — essentially, services that would ease the flow of data into and out of the library system.  For Summit, not having the ability to use or develop these services became a deal breaker (and for III, our request for them was a deal breaker as well). 

Secondly, and this is one of those things that I’m slightly concerned about as a customer and member of the IUG community is that there was an expectation by some that the above consortia changes would lead a company to blackball a group of members.  Is that really how the IUG community looks at their relationship with III, one that is built on a foundation of eggshells?  Or does it say something about librarians, who tend to treat their vendors with kid-gloves.  I think it shows a little of both — because people in the IUG community are nervous (I hear it all the time) that III will bring the hammer down on institution if they criticize their products, which certainly feeds into the library community’s built-in timidness in regards to how we work with our vendors.  But now I’m getting off topic. 

So, for the record, the reason I’m not at the IUG is because I’m in Minneapolis attending DLF.  So, no, III didn’t send Rocko to my office in Corvallis (at least, not yet) — sorry to disappoint. 

–TR

Over the past three months, I’ve been leading a group looking at next generation ILS services for our regional consortia, Summit.  Summit is a consortia made up of 33 academic libraries throughout Oregon and Washington — with all system’s being Innovative.  This is due to the fact that III’s consortia software really only works with III libraries.  In looking at the various options available — we’ve tried to keep an open mind.  I’ve been running copies of Koha and Evergreen over the past month to look at current functionality within a very untraditional consortial setting, folks have spoken to vendors like Endeca, Aquabrowser, III and OCLC as well as others.  In all, the process has showed me a couple of things.

1. Given that this decision will be just on the consortia database, our options are somewhat limited.  III doesn’t make the process of having an outside vendor interact with the Innreach system easy — though we’ve been told it could be done.  This means that we migrate off III as a group (can’t see that happening), partnering with III (what I think many would consider to be the safer, least disruptive choice), working closely with OCLC –  though the second and third options don’t hold much appeal to me personally. 
2. Which leads me to number 2 — while the consortia has more than enough talent to develop an inhouse solution — the organization infrastructure simply doesn’t exist to allow such a solution to be considered. 

The second realization is what struck me most.  I spend a great deal of my time helping folks within the Pacific NW implement tools around their ILS — but there really isn’t a centralized or formalized R&D process within the consortia — and for a group this large, that seems to be a shame.  There is a lot of talent tied up within the 33 member organizations, the question is how to get at it.

Well, I’ve got an idea.  While my group really cannot make a recommendation related to the current software available (we can talk about what’s available and what I believe to be the future trends) — I can advise that we formalize an R&D group within the consortia.  Fortunately, Summit is hiring a digital library coordinator — and I think that this position would be perfect to lead this group.  I envision a committee that could be used to:

1. coordinate Summit development efforts and investigate options like SOPAC, metasearching within a consortial environment, OpenURL within a consortial environment, etc.
2. provide Summit with shared development resources — allowing member libraries to help drive development of services, while distributing the R&D between member libraries
3. advocating for OSS and an active R&D agenda to the member libraries directors and the Summit executive board.

In all honesty, I think #3 is the most important.  The proprietary vendor community is very adapt at dealing with the library community at a high level, and this allows them to shape the overall environment within the organization.  My hope is that by creating a formal working group within the consortia and identifying that this is indeed important — and help to lead to an attitude shift within the Pacific Northwest. 

Will it work?  Who knows.  I’ve floated the idea by a few folks — some on other committees, some familiar with the current makeup of the executive committee, and the overall mood isn’t optimistic.  The biggest challenge to overcome is this idea that one’s library doesn’t have any special skills to offer (or any bodies to offer).  If R&D is valued at an organization — resources and people can be found. 

Anyway, my hope is that the recommendations that come out of this study will help to move this conversation forward.  As I said — there is a lot of talent in the Pacific Northwest — its time we started tapping into as a group and seeing what can be accomplished within a consortia when everyone contributes.

–TR

The rest of the day, I spent either speaking (2 topics) or preparing to speak.  I did two topics.  One was on III’s global update functionality, which is an innovative specific application for database maintenance.  The second topic continues this recent spat of evangelism that I’ve been participating in regarding the need to require our vendors to provide open apis.  The title of my talk was entitled, Being innovative without innovative and I thought went well.  I actually recorded the talk, but I’m never sure what I can post and not post (III’s usergroups, both national and regional follow some courtesy rules when dealing with III topics) so I’ll have to see if I can post my talk.

–TR

King County Library System

A discussion of why and how the King County Library brought up AquaBrowser.  AquaBrowser is an interesting application, but I’m not sure what to think about it to be honest.  However, what I did find interesting was how they sync. data between AquaBrowser and III.  I have a lot of methods that I use to extract data — but none of them would scale if exporting our catalog on a nightly basis.  So what I really enjoyed was hearing about III’s MarcOut tool.  Apparently, this tool provides a simplified method for extracting your MARC data.  This is a tool I’m unfamiliar with — so I’m going to be spending some time chatting with the help desk to figure out what this tool is and how we can make use of it.

–TR

(Linda Pitts)

This session focuses on the implementation of MARC holdings within III and the UW’s process converting their free text holdings into MFHDs.  The presentation gave a very quick overview of the MFHD format as well as some information relating to the problems that they have encountered both in moving the free text data as well as dealing with some III quirks with how the holdings information has been rendered.

I actually felt alittle bad attending this session.  About 8 months ago, UW had asked if I would be willing to help them do an automatic conversion of these records.  At the time, I had the time to work on it and spent time talking with them about various things needed to do to do the conversion automagically.  I’ve done this in the past for libraries — but it takes a lot of time to get it done and unfortunately, their desire to start the conversion landed on my busy time (June – August), so I couldn’t dedicate the time to work as closely with them on this as I would have liked. 

–TR

The NWIUG conference is actually an interesting usergroup.  Its different from the national conference in that there are a lot fewer III staff presentations — so you tend to get a lot of information from actual users of the system so you can see some interesting things folks are doing. 

While at the same time, this is an III usergroup, which is reflected in the keynote.  This year, Dinah Sanders gave a talk on the future of the WebPac, Innovatives public interface.  The discussion this year centered around Encore, III’s next generation web opac.  Encore will include a number web 2.0izy features like user tagging and comments.  Will this be free — I doubt it, will it be interesting — for public libraries yes.  Academics — interesting but I’d be curious to see how useful.  Unfortunately, I think that there is a dangerous side to Encore as well.  It will integrate all III packages, like their federated search, openURL, etc.  Basically, it encourages vendor-lock, as the integration only works with III products — so it basically just makes a bigger silo’d data store.  And unfortunately, I’m sure there will be a number of people ready to drink the III kool aid.  The one bright spot of Encore is that III says that it will rely on webservices.  From what I’ve heard, there isn’t an interest at this point in making these webservices available for public consumption, but I’m sure that could change. 

We’ll see.  From my perspective, III is on the clock.  I don’t see the OPAC as having a future in libraries.  It won’t go away right away, but I firmly believe that libraries need to stop spending money on it and start looking at other solutions.  III could make lives much easier for innovative libraries by providing an open API — but so far, they haven’t and if they don’t, I predict that they will start to find themselves losing relevance within libraries.  I given them 5 years.  If they can’t recognize this shift from black box development to open architectures — well, I’d be concerned about their future — particularly in the academic market where libraries have development resources.  Tick, tick.

–TR

–tr

Why broken? Well, within the federated search model, there are just to many unknown variables that the system literately has no control. Start with query normalization. Targets will interpret user queries differently across the board meaning that a query at on target will search very different from a query at another. This leads to some difficulty as any tool created then must either code specifically for each target or provide a generalized search that normalizes to the most common target format. Likewise, as seen with our ILS, sometimes targets fail. And when they fail, there is really nothing that the system can do but report the error to the user.

So how do we fix the model? This is why LibraryFind is as much a harvester/indexer as it is a federated search tool. Our underlying belief while developing this program is that we want to harvest and index as much data as possible — so the tool is setup that way so that as vendors become more comfortable allowing their data to be harvested — we can take advantage of it. Of course, this can bring its own set of issues to the forefront — but I would gladly deal with database/indexing related issues over the current federated searching issues.

So what are we planning on doing with our ILS? Well, at this point, we will continue to remotely query our data — but we are in the process of looking at ways to simply harvest all our data and index it locally. The problem of course, is that this needs to be a process that is is in fairly real time — and I’m not sure if we will find and exporting method that can support those requirements, but we shall see.

–tr

–Terry