Beth’s Blog

I need to ask for a moment of silence in remembrance of the URSA brothers, Alleycat and iBorrow.  (Pause…)  And now it’s time to move on. 

Our FLIN Project officially began on October 1, but nothing really exciting happened then.  We have been working on some parts of the new project for months, while others can’t begin until people who don’t actually report to us do some things that we’d like to see happen.  So, work just flowed around that October 1 date without even noticing it.

Here’s a brief update:  The FLIN Project has a staff component and a public component.  Each one is a complex bundle of goals, objectives, and activities.  The main goal of the staff component is to make staff work easier and less time consuming by letting automation do the tasks whenever possible.  Some of that will involve making automation do things it doesn’t yet do.  And a lot of it will involve training (i.e. TBLC Continuing Education) to show library staff how to get the biggest bang for the buck out of tools that are already out there.  More on  that in future posts.

The public component’s main goal is to make it easy for patrons to initiate their own ILL requests from anywhere.  Just like Alleycat and iBorrow, but with the whole state as the ‘group’.  We’ve been building the early parts of that for several weeks, and a couple of libraries are already using our prototype tools.  Our successes so far tell us that we’re on the right track.  And the problems we’ve run into so far tell us this will be no stroll in the park.

I love analogies–OK, I’m addicted to them–and to me this is like the early days of the space program, when we knew we wanted land a man on the moon, but we weren’t sure exactly how to do that.

IBorrow is going away at the end  of this month.  You know that.  And you know that its replacement will have some kind of OCLC flavor to it.  But it gets kind of fuzzy after that.  Will our patrons be using FirstSearch?  WorldCat?  FloridaCat?  Or that new Navigator thingy?  And what about the staff side?  How much of what iBorrow did automatically will still get done that way?
 
The deeper you dig in to this, the more complicated it gets, so let’s start at a nice, shallow simple level.  To allow your patrons to continue to place their own request, you will need to give them access to FloridaCat through your web site and authenticate them, as they move from your system to OCLC.  Read that again.  Lock it in.  As it gets more complicated, it all comes back to that.
 
Let’s complicate “access to FloridaCat” first.  OCLC is a huge organization.  They offer many services.  One of them is an Interlibrary Loan management tool called FirstSearch.  FirstSearch can be used with a number of ‘databases’  The best known of these is WorldCat.  FloridaCat is also a database.  It is a subset of WorldCat, composed of–Surprise!–titles owned by libraries in Florida.  The Admin section of FirstSearch lets you specify which databases various kinds of users will see.  You want your staff to see the sophisticated FirstSearch screen.  You want to pass your patrons on to the simpler and more appropriate FloridaCat search screen.  Both of these–and other OCLC services–are web sites that you reach through a browser.  Since you control your own web site, you would put in the link that goes to FloridaCat.
 
Your ILL staff authenticate in FirstSearch by logging in.  OCLC doesn’t recognize them as individuals through this login.  But it knows what library they are coming from.  You don’t want your patrons to log in as staff.  But you do want OCLC to know what their home library is.  No mystery as to why.  When they request a title, you want the copy that is captured to come to you, not to Boise, Idaho, or somewhere.
 
So, how do we tell the OCLC FirstSearch system what the patron’s home library is?  Two ways.  We’ll do the easy one first:  IP address.
 
Each of your library buildings has unique IP address, and OCLC knows what it is.  If a patron is in one of your library buildings, when he makes a request, the IP address he comes from tells OCLC which library system he’s coming from.

In ‘the old days’ that would have been plenty.  Now it’s not.  Lots and lots of patrons do their library shopping from home.  They don’t have access to your staff’s login, and OCLC does not recognize their home PC’s IP address.  What’s the solution?  There are two.  Let’s call them Plan A and Plan B.
 
Plan A is to use whatever tool you currently use to let your patrons connect to your online subscription resources from home.  If it can take patrons to a ’success URL” for those resources, it can probably do the same for OCLC’s FloridaCat.  When your patrons use Gale tools or Ebsco tools from home, the vendors know they’re your patrons, and you get the usage stats.  So, you may already have the tool you need to let OCLC recognize your patrons.  But if you don’t, we go to Plan B.
 
Plan B is RPA.  We have it at TBLC, and we know it is pretty versatile, because we’ve used it with many libraries in the past.  So, RPA would become the middleman between your system and FloridaCat.  Here’s the short version.  The FloridaCat link on your web site takes the patron to RPA at TBLC.  RPA gets his barcode, looks him up in your patron database, and–if he really is your patron–sends him to FloridaCat with a note pinned to his shirt that tells OCLC what library he started at.
 
This is Plan B and not Plan A, because there are some complications in authenticating patrons from multiple library systems to the same database.  If you use your own authentication system, it is easier to make sure OCLC knows what the patron’s home library is.
 
Now, go back to my original statement of what it will take to let your patrons continue to make their own ILL requests.  I hope the ‘long version’ fleshed out the details of the short version without messing up its clarity.
 
Now, where is Navigator in all this?  As I write this on September 1, we don’t know for sure.  OCLC and The State Library have not yet cut their deal on its cost to the state and its availability to us.  If we get access to it later this year or early next year, it should reduce staff work at many libraries, and it may offer a better interface to search FloridaCat than we can get with the other potential OCLC interfaces.  But it won’t help anyone in September, and probably not October. 
 
Until Navigator steps up to automate staff tasks. the staff side of the new world will look a whole lot like traditional OCLC ILL.  But with one big difference.  A big, big part of our grant is helping all libraries–including yours–wring every possible drop of labor savings out of OCLC and the FirstSearch software.  Again, though, those classes start in October.

Please take this as a starting point for planning your transition out of iBorrow and into the FLIN project.  I’ll be putting out more stuff in more detail, but I didn’t want to put you to sleep so early in the project.  Please contact me with any specific or general questions you have at this time.

–Al Carlson

The URSA products–Alleycat and iBorrow–were great ideas, when they came along.  So was the League of Nations.  And the Apple Newton.  Unfortunately, none of them was able to live up to their expectations.  The necessary environment wasn’t there to support them.

We can’t do much about the Newton or the League, but we do have a plan to enable Florida libraries to continue doing cost effective, patron initiated resource sharing, after we close the door on iBorrow at the end of this fiscal year.  The plan involves assembling a number of “tools” that already exist and combining them in a new way.  Think “MacGyver”.  We’ve submitted a grant proposal to the State, and we expect to hear their decision by the end of July.  Assuming they give us the green light, we’ll launch the FLIN project in October.

You’d probably like to know more about it before it starts.  And you can.  Beth and I have a road show that we’ll be happy to present to you and your staff.  It takes about an hour, and that includes time for your questions.  There’s no charge, but having some bagels in the room would be a nice gesture on your part.

If you’re interested–and you should be–contact Beth or me to make an appointment.  I’m carlsoa@tblc.org and Beth is farmerb@tblc.org.   Want to call us?  Dial 813-622-8252.  Enter 237 for me and 228 for Beth.

–Al Carlson

Now, here’s the long version, mostly for ILL staff:  The URSA/iBorrow server lives in Utah and communicates with our local library servers through NCIP: the NISO Circulation Interchange Protocol.  Every major step in an iBorrow request has an NCIP message. Sometimes two of them. URSA has the easy job. It tells the local library server to “do this”, and the local server has to get it done. The local server does not get to give URSA any instructions. The most it can ever say is “Yes, sir!” or “Sorry. I can’t do that!”

When the item that your patron requested in the Portal shows up at your library in the orange Delivery bag, you do Receive Loan in the URSA client.  That generates the NCIP Accept Item message—the one that creates a brief bib, an item, and a hold for the patron.  That works in Polaris, too.

Now, before we get too excited, I should say that it has worked in Polaris so far. And Polaris staff will have to set up a particular template in your account, once you come up on Polaris.  We may be able to arrange to have that template in place on the day you come up. I guess the bottom line is that this can work and has worked. And we may have to fumble around a little at first to make it work in your particular library.

When “Request Item” works, the local server places a Title level hold for one of the URSA dummy patrons.  If the local server says, “Yes, sir! I did that!”, URSA puts the request in the Fill Loan workspace, and you work with it there.  If it fails, the request goes into your Incoming Loan workspace. You can fill it the same way you would, if the request came from OCLC. You find it on the shelf and lug it back to ILL.

Sidebar: The NCIP Request Item message is also the one URSA uses when it turns a Portal request into a local hold. That is another reason that it is at the top of our list.

“Lookup Item” uses the barcode you scan to find the title this barcode belongs to in your bibliographic database. Then it brings back the ISBN from that title and uses that ISBN to find the matching request in the URSA database. If it finds it, it uses “Checkout Item” to tell your server to check out the item to the dummy patron, while you sent the real item to the requesting library. These two NCIP messages do not yet work in Polaris, so you will need to do the kind of checkout you normally do with an OCLC request. Then you just change the request’s status to Filled in the URSA client.

Don’t tell anyone, but that message does not work in Sunline. It never has. So, you have to check returned item in yourself.   This NCIP message may or may not work in Polaris. We haven’t gotten there yet. But, it can’t be worse than Sunline, so you won’t be going backwards. 

Are you still awake? Are you still with me?

The two borrowing messages work in Polaris now.

The three lending messages are being beaten into submission as you read this.

Your patrons will probably need to re-register in the Portal once. And their open requests won’t follow them to their new identity.

Aside from that, they can request just as they do now.  So, turn ‘em loose, and let them do it.

You’ll have to do more manual work while lending than you do now, but not for long.

Got questions? Got concerns? Got tickets to the next Rays game?

Call me.

–Al Carlson

Koha: Because the migration will occur between semesters, there will be a clean break for the Academics. We will set fixed and final due dates, as we do every year.

New Port Richey: We don’t know yet how we will handle this, as we do not yet know which vendor New Port Richey will migrate to.

Subscription Database Access

Subscription databases identify valid users in two main ways. They look at the IP address of the computer that is trying to connect, or they can check a validation server. As each library moves to its new system, its IP address will change. We—TBLC staff and library staff—will need to compile a list of the subscription database vendors and provide each of them with the new IP addresses and the date they will become active. Presumably, then, they will accept searches from computers with the new and different IP address. RPA is an intermediary. When a patron at home wants to search a subscription database, he comes to the RPA server first and is asked for his barcode. RPA looks that barcode up in the main library database and, if it is good, passes it on to the subscription data base with an “OK” stamp. RPA will need to be told the new IP addresses, so that at the appropriate time it can go to the correct server to validate remote borrowers. In most cases your new vendor will provide you with or help you find a substitute for TBLC-managed RPA.

Like RPA, SIP is a process that uses an intermediate server (housed here at TBLC) to validate a patron for a specific purpose. It may be for self checkout or to reserve a public access PC or for some other purpose. The patron’s barcode is keyed in or scanned at the library and is sent to the SIP server. The SIP server does a barcode lookup in the patron database and sends a response back to the device at the library. Like RPA, SIP has to know where the patron database is, so we will have to give it the IP address of the new server at the time of the transition. Again, SIP services will probably be a part of your new vendor’s package.

Four Sunline libraries currently use Debtcollect and Unique Management. Three of them are migrating to Polaris. Unique tells us that they can work with Polaris as easily as they can with Horizon, and that nothing special needs to be done for the transition. The fourth user is New Port Richey, and we do not yet know how their migration will affect their use of Unique Management.

There are a large number of iBorrow issues that come out of the migration.

1. Duplicate barcodes. The problem of duplicate item barcodes has come up with PALS in the past, but it should not come up in relation to iBorrow. This problem would occur if a library that migrated into the PALS database brought with it an item that had been borrowed (e.g through OCLC) from an existing PALS library. The copy attached to the brief record for the borrowed item would have the same barcode as the original item in the PALS database. Since iBorrow has not so far been able to communicate with Polaris, the PALS Polaris libraries are not part of the iBorrow network. So, no PALS items will have come into our Sunline system through iBorrow. Items borrowed through traditional ILL mechanisms and entered into the Sunline database with their original barcodes could cause this problem. But not iBorrow.

2. Use by patrons prior to the closed period. Patron searches in iBorrow and ILL staff work in the URSA client are both done on a server in Utah that is unaffected by the migration. When a Sunline library fills a request for another library system through iBorrow, that item is checked out to a dummy patron in the Sunline database, while it is on loan to the ‘foreign’ borrower. To Sunline, this is a normal checkout, and it will carry over intact into Polaris. Fixed and final due dates for the libraries going to Koha will prevent any issues there. Generally speaking, there is no technological reason to restrict patrons’ use of iBorrow prior to the closed period.

3. Use by patrons during the closed period. Sunline patrons who use iBorrow are, by definition, getting materials from other libraries, and these libraries are not affected by the Sunline migration. I see no reason to restrict the Polaris libraries ability to initiate requests in iBorrow during the closed period. The Koha libraries will probably cease to use iBorrow after they migrate, because Koha does not have an NCIP responder iBorrow can talk to. We can’t yet address how this will be handled with New Port Richey.

4. Use by patrons after re-opening. Like SIP and RPA, iBorrow stores an IP address for a library and communicates with it at that address. We will have to change the IP addresses for the Polaris libraries in iBorrow. This will take about 2 minutes per library. The bigger post-migration issue is that–as of mid-May–Polaris can handle only one of the eight NCIP messages that iBorrow uses. Fortunately, it is the most critical of those messages: the one that enables patrons to validate and request. We are making progress with Polaris and may have many or all of the working by the time of final migration.  At present, Koha and iBorrow to communicate at all, so we’re not optimistic about the academics being able to continue to participate.

There are two migration-related issues with Overdrive: titles available and patron validation.

We need to make sure that any titles to which Polaris patrons have legal access are copied into the new database, if they are not there already.

Overdrive also uses RPA to validate borrowers. Our RPA server will not move nor change its address, so the change of home server should not matter to Overdrive, so long as they can find our RPA server and our RPA server can find the new Polaris server.  Again, new RPA or RPA-like services provided by your new vendors may eliminate any need for RPA in relation to Overdrive.

http://ipac.tblc.org will see everyone’s material, because this is the ‘all libraries’ interface.This is the first ‘draft’ of this message. I expect that there will be additions and corrections.   If you have any, contact me at TBLC by phone or email.

But don’t delay! Ms. Has-it-all-but-wants-more keeps calling us back to ask why she hasn’t gotten hers yet.  And she can’t even spell iBorrow.

 –Al Carlson

The latest build of iBorrow was installed on our server in Provo Friday evening, and we tested it over the weekend.  Our assessment so far is that it passes the test nicely.  Here’s some detail.

Java 1.6 compliance:  Yes.  No problems at all.

Faster “Edit Request” response:  Well, maybe.  A little faster, I think.  It’s not yet what you would call ’speedy’, but if you can set up a three way race with MS Vista and a glacier as the other two competitors, you can bet on URSA.

Proxy Request Improvements:  The patron’s barcode is now readable as you type it in.  Yayyy!

Incoming Loan to Fill Loan:  This one is lovely.  It is still true that URSA can’t place a hold on your local system, if it can’t give your server a single unique bib record to request.  That is why ISBN’s are so important.  But there are several other things that can drop a request into your Incoming Loan box, even if it has an ISBN.  Most of these are transient.  So, if you could try again, the hold would take.  The new build lets you do that.  If you go to your Incoming Loan space and find requests there with ISBN’s, you can right click on each request, choose Process Request, and watch it go to Fill Loan.  That’s not the important part, though.  The important part takes place in your server, where a Hold gets placed, and a copy will show up on someone’s pick list tomorrow morning.

More Detail in History:  I’ll send this out to you as Email and attach a spreadsheet Holly gave us.  When you edit an item now and look at its History, you (and SirsiDynix Support) will see a lot more information.

Availability Rules and LOLR Issues:  These weren’t really testable over one weekend.  Time will tell us how much closer to ‘perfect’ iBorrow/URSA is at following the Availability Rules and properly routing requests that run into LOLR issues.

As we learn more, we’ll share it with you.  And I trust you to tell me when you find something that doesn’t work.

–Al Carlson

It is Saturday evening, and so far the new build looks good.  Very, very good.  It has been well behaved in all the tests I’ve done so far, and the new features just add to the good feeling.  Like having the vinyl in your car replaced by hand sewn leather.

The neatest trick is being able to go into the Incoming Loan work space in the client, find a request there with an ISBN, right click and ‘process’ it, and have it show up in Fill Loan.  With a hold placed in the local system.

I used this a lot on Friday evening, because both Hillsborough County and Sunline have been ‘resistant’ to iBorrow requests for the past week.  Both issues were resolved Friday afternoon, just before the new build was loaded, so there were LOTS of requests hanging around, eager for a chance to create a real Hold.

It also runs nicely with Java 1.6.

We’ll keep testing and keep you informed.

–Al Carlson

If you are a Southeastern University borrower, any hold you place in Sunline from now on can be filled only by an SEU item.

If you are a New Port Richey borrower, any hold you place in Sunline from now on can be filled only by a New Port Richey item.

(Pause for dramatic effect)

If you are a borrower at Dunedin, Largo, Oldsmar, Safety Harbor, or Tarpon Springs, any Sunline hold you place from now on can be filled only by an item owned by any of the libraries migrating to Polaris. In other words, holds can still be filled among those five libraries just as they always could among the larger group. Those holds will behave as though New Port Richey and the Academics (Wouldn’t that be a great name for a rock band?) had vanished in the night, leaving only the Pinellas Publics behind. I can do this, because (Polaris tells me) those holds queues will be preserved and reassembled in the new system.

Got all that?   Want to read it again?  Good.  Let’s go on.

“Caveat” is Latin for “Gotcha!”  And there are some caveats to tell you about.

(1) This is one complex set of rules. I may have formulated them perfectly on the first try. And I may be the long lost heir to the throne of Pottsylvania. But I will not be surprised if errors crop up. Or someone else winds up on the throne. If you or your borrowers encounter weird stuff while placing holds, tell me.

(2) If things go as we hope they will with Polaris, the New Port Richey borrowers and the Clearwater Christian College borrowers will be part of the migration and will wind up in the PALS database as reciprocal borrowers. They will also be on their own new systems, of course. So, in theory, I could have tweaked the rules to allow those groups to be part of the Polaris Public group for requesting purposes, although their parent libraries would still be off limits to the borrowers in the Polaris Publics group. At present, I have decided not to attempt that level of rule complexity. If the rule set I put in place today works perfectly, and if we get hard data on what will happen to those borrowers during and after the migration, I can revisit this. But not right now.

(3) Keep in mind that Holds are placed at the Title level and filled at the Copy level. You don’t place a hold on the Dunedin copy of Dracula in Suncat. You place a hold on Dracula, and you get the first available copy. Which may or may not be Dunedin’s. So, depending on how many copies of a title there are in Sunline and who owns those copies, my new rules may stop a hold from being placed at all or they may not. If you are a CCC patron and try to place a hold on Dracula, you may see lots of copies and be unable to place a hold, because CCC owns none of them. If CCC owns one copy, you can place a hold. If that copy is out, and all the other libraries have copies on the shelf, you may be surprised by how long it takes your hold to be filled. Because none of those on-the-shelf copies at Oldsmar and Safety Harbor and so on can fill your request. Only the CCC copy can.

Got a headache, yet?  I do.   So, I’ll stop here and we’ll see what happens with Holds over the weekend and coming week.  I’d like to say, “If you run into problems, call Matt”, but that wouldn’t be fair.  Call me.

–Al Carlson

You may want to take notes.  There is a lot happening right now.

Let’s start with the good stuff.  Citrus County is now an active iBorrow participant, and Collier County will join us on Monday morning, May 5.  Did I hear an “Ooooo!” or perhaps an “Ahhhh!”?  Well, I should hope so.

Both systems are easing in rather than jumping in, so here are the complications.  Citrus will begin by lending only.  That’s right.  Citrus County has been added to your list of lenders, and you should find yourself getting loans from them any day now.

For a while, they will request only out of Tech Svcs HQ.  These will mostly be staff tests, but for real items.  No more sandbox testing for them!  When they get used to that and work out any bugs, they will open it up to Reference Desk staff as a tool Reference can use when the patron’s needs suggest it as the best option.  When that is going smoothly, they’ll open it up to their borrowers for direct access.

Collier County will be doing pretty much the same thing.  They will begin lending right away on May 5.  But they will ease into borrowing a little at a time.  So, for a while, you may have to put up with both Citrus County and Collier County lending you more than they borrow from you.  Try to be brave about that.

 Now, let’s do the not-so-good-at-the-moment stuff.

East Lake, Palm Harbor, and Pinellas Park have all completed their migration to Polaris.  That’s good for the citizens of Pinellas County, but it moves them to a library system that URSA/iBorrow cannot—at the moment—talk to.  So, as I write this, they cannot fill any new requests for you.  (They can still fill requests they got before the migration, and they will return your stuff.  They promised.)

 But we are working with Rob Gray at Polaris on getting it and URSA to talk to one another.  Earlier this week we were able to get past a major hurdle on their test server.  We were able to go to the iBorrow Portal as a Polaris patron (which the Palm Harbor, East Lake, and Pinellas Park patrons now are), create an iBorrow user, and request a title.  If we can get that same thing set up on the ‘real’ Polaris server, East Lake, Pinellas Park, and Palm Harbor borrowers can start requesting again.  I think there is also a way they can fill iBorrow requests, but we haven’t had a chance to really test that yet.  Remember all the glitches and strange errors that you went through when you were first coming up on iBorrow?  Well, it’s now Polaris’ turn for all that.

Check in here from time to time for updates.  I’ll also put them out as Email.

–Al Carlson