Beth's Blog

URSA’s Done; FLIN’s Begun

Al Carlson — Tue, 06 Oct 2009 19:23:07 +0000

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.

URSA to FLIN: a brief update

Al Carlson — Tue, 01 Sep 2009 16:15:28 +0000

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

Moving from iBorrow to FLIN

Al Carlson — Wed, 27 May 2009 12:53:51 +0000

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

IBorrow and Polaris

Al Carlson — Tue, 22 Jul 2008 17:22:38 +0000

There is more information—and more detail—in this post than most of you will want to read, so I will give it to you in two versions: short and directive, and long and explanatory.

Here’s the short version: When you shut down on Sunline at the end of this week and come up on PALS, please continue to use iBorrow. It won’t be as slick–at first–on Polaris as it is on Sunline. But it will work, and it is getting better each week. Borrowing should work fine, and lending will not be any worse than it is with OCLC.

If you are a Library Director, you can stop reading here. You’re welcome to read on, but you don’t have to.

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!”

There are actually eleven NCIP messages, but we use only five of them. Two of them already work with Polaris. We are working with their tech guys on the other three. Here is the breakdown.

Requesting

When a patron (PALS or other) logs into the portal, URSA validates him with the NCIP Lookup User message. When he makes a request, it uses the same NCIP message and validates him again. (Why? I don’t know. Seems pointless to me.) The ‘Lookup User’ message works with Polaris, so your patrons can use the iBorrow Portal to make requests after you migrate.

Speed Bump: When your patrons registered for the first time, they were associated with Sunline. After the end of July, they will be associated with Polaris/PALS. They will probably have to re-register in the portal. If ALL of Sunline was moving to Polaris, we might be able to just roll them over. But patrons at four libraries are NOT going to Polaris. We’ll work on this, but don’t get your hopes up.

Receiving

Moving on, still looking at your patrons as borrowers…

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.

Returning

When your patron checks out, reads, and returns the book you got from some other iBorrow participant, you do Return Loan in the client. That generates no NCIP message at all. It does nothing but move the request from the Return Loan space at your library to the Complete Loan space at the lending library. So, being in Polaris will have no effect, and this will work just fine. So, the borrowing side of iBorrow in Polaris is mostly a piece of cake.

Now, let’s talk lending.

Z39.50 Server

When any library’s patron does a search, URSA sends the search to all the participants’ Z39.50 servers. They respond, and URSA/iBorrow assembles those results in the Portal. You’ll be happy to know that the PALS Z39.50 server works great.

Placing PALS Holds

After the patrons clicks on Request Item and gets a Request ID number, URSA/iBorrow decides who to go to first. If it chooses your library, it will send your server the NCIP Request Item message. That one does NOT work yet in Polaris. It is our highest priority, as we work with the Polaris techies, but it isn’t there yet. On the other hand, it doesn’t always work in Sunline either, so it’s an inconvenience, not a disaster. Here’s the detail.

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.

Filling PALS Holds

Once you have a copy of the requested title back at your ILL desk, you would normally scan its barcode in Fill Loan or Incoming Loan. URSA would send your local server the NCIP Lookup Item message, closely followed by the NCIP Checkout Item message.

“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.

Completing PALS Requests

Now, actually we are through with NCIP, but let’s follow through on this loan, just to give you the full story. You send it to the borrowing library in the orange bag. Their patron reads and returns it. They send it back to you. You open the URSA client, go to Complete Loan, and scan the barcode. URSA archives the request and sends the NCIP Checkin Item message to your local server.

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?

Here’s a summary.

Of the eleven NCIP messages, we’ve been using only five—two when we borrow and three when we lend.

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

Migration Issues

Al Carlson — Wed, 28 May 2008 13:39:35 +0000

As the current Sunline libraries migrate to their new automation vendors, data that is specific to each library (items, borrowers) as well as system-wide data (Bib records) must be copied out of the Sunline server, reshaped to fit the new environment, and loaded onto a new library server. In addition for some Sunline libraries, new connections must be established between the new server(s) and our local SIP and RPA servers, so that your patrons can continue to access electronic materials from their home PC’s, and so that the third party services you have purchased (e.g. Self Check, PC Reservation) can continue to function in the new environment. And, the closed period between your last day on the current system and your first day on the new system must be managed. For example, we don’t want any checked out items to be due during that period, and we don’t want patrons to place holds on the current system, after the final data extraction.

Here—in no particular order—are the specific issues we’re addressing, whom they affect, and what we are doing to stay on top of them.

Closed Period Due Dates

Polaris: Checkouts done on the current Sunline system will carry over to Polaris, so we do not need to create “fixed and final” due dates. We will make July 28 through August 4 ‘closed days’ in Sunline, and the system will simply advance the originally calculated due date to the next open day.

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.

SIP

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.

DebtCollect and Unique Management

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.

iBorrow

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.

Overdrive

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.

Suncat display

This is a pre-migration issue. To prevent problems after the migration, we are restricting our users’ ability to place holds on titles their home library or library group does not own. Because everyone’s items have been available for holds until now, everyone’s holdings display on many Suncat screens. This leads patrons to attempt a request, only to be told they are not allowed to do that. Matt and Al will work on redesigning the Suncat screens for specific libraries, so that only those titles that are ‘locally owned’ will be visible. This may help, but there are limitations. Anyone who searches from home and uses

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.

–Al Carlson

Just what I’ve always wanted!

Al Carlson — Fri, 23 May 2008 20:35:19 +0000

You’ve all heard the question, “What do you get for the person who has everything?”

To find out, we just called her up and asked her. (We’re good at getting unlisted numbers) To our surprise, she said, “I’d just love to have an iBorrow T-shirt! I look so good in black. And, despite my have-it-all reputation, I don’t have one of those.”

Well, we may grant her wish. But, frankly, we’d rather give you first dibs on one of these rare and soon-to-be-priceless items. You’ve worked with iBorrow. You’ve sweated over it and cursed it and whispered sweet nothings in its ear to make it behave. You deserve something special.

And for the price of an email, you can have it. (While supplies last, of course)

Send your email message to Vickie Frost (frostv@tblc.org) and tell her what size you’d like (Medium, Large, or Extra Large) and which library you work at. She’ll send you your own personal shirt in Delivery.

It’s that simple. Really. Even Billy Mays can’t give you a deal this good.

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

New iBorrow Build: Test Drive Results

Al Carlson — Mon, 12 May 2008 14:27:27 +0000

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

Testing the New iBorrow Build

Al Carlson — Sat, 10 May 2008 22:29:42 +0000

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

Migration Preparation–Limiting Patron Holds

Al Carlson — Fri, 02 May 2008 14:23:16 +0000

As we get closer to the day the Sunline libraries migrate to your new systems (Polaris, Koha, and ‘To Be Announced’), we want to reduce the number of borrowers who have ‘foreign’ items checked out to them.

If Tom from Tarpon Springs has an item owned by Florida Southern in his hands when the final data extraction takes place, both Polaris and Liblime will be confused afterwards, because Tom won’t exist in the Liblime Koha database, and the overdue item he has behind the couch won’t exist in Polaris.

So, I put a number of rules in place today to limit whose items could fill whose holds. Hold on tight. This gets a bit complicated.

If you are a Clearwater Christian College borrower, any hold you place in Sunline from now on can be filled only by an item owned by CCC.

If you are a Florida Southern College borrower, any hold you place in Sunline can be filled only by an FSC item. (This rule has been in place for a few weeks now, but I’ll list it here anyway)

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

New Players Added; Some Current Players Sidelined

Al Carlson — Thu, 01 May 2008 14:41:22 +0000

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