Beth’s Blog

Did you know…

OCLC places the iBorrow request number in the Patron ID field of the OCLC ILL request?

and

iBorrow places the OCLC ILL request number in the Reference # field of the iBorrow request?  (it’s labeled Review File #, but it’s the request #,too!)

The Polk County Library Cooperative has decided to step back from participation in iBorrow for a while, but they want you to know that they are not dropping out of local InterLibrary Loan activities. They will still gladly respond to requests they receive through OCLC.

Because PCLC patrons have active iBorrow requests at the moment, and because other participants currently have PCLC materials in the hands of their patrons, PCLC will sort of fade out of iBorrow activities and not just vanish abruptly. Matt and I will go through Agency Setup in the URSA client and in the Portals to remove PCLC from the borrowing sequences of the other participants, from the Z39.50 search operations, and from any other relevant parts of the software. And we will look at the requests currently waiting to be filled by PCLC and try to find new lenders for them.

PCLC’s departure will temporarily shrink the pool of local lenders, but Collier County is currently on track to come up as an active participant in May, and that will enlarge the pool again.

Our latest build of iBorrow has an enhancement that many of you will like.  But it requires a choice on your part.  Here’s my offer:  I’ll explain the new feature, and you’ll tell me whether you want Option One, Option Two, or Option Three.  OK?  Think of yourself as the “borrowing” library as I do this.  Here we go.
When a patron requests a title through the iBorrow portal, the iBorrow server automatically checks with all the current players to see if anyone has an available (Checked In) copy.  If none of them do, iBorrow checks the Setup rules at the borrowing library (the patron’s home library) and either sends the request to OCLC or just leaves it in that library’s Mediated Borrowing work space for the ILL Librarian to figure out.  If you told us you wanted OCLC as your Lender Of Last Resort when we did your Setup, the request goes to OCLC.  If you said you did not want OCLC as your LOLR, it does not. 
So, you chose the initial options, but you had only two choices.  Now you have three.
Here are your new choices.
Option One
You choose OCLC as your Lender Of Last Resort, and any requests that can’t be filled ‘locally’ will go there.  (Those of you who have this option now know that it’s more complicated than that, but let’s stick to the three main choices for now.)
Option Two
You choose yourself as Lender Of Last Resort, and any requests that can’t be filled locally fall into your Mediated Borrowing work space, and you decide how best to handle them.
Option Three
You leave Lender Of Last Resort blank, and any requests that can’t be filled locally vanish.  Well, something like that.  They get archived with a status of Unfilled.  And iBorrow sends the requestor an Email message that politely says, “We’re sorry.  We were unable to fill your request for A Tale of Two Cities.”
Got all that?  Feel free to read through it again, if any part is fuzzy.
Now it’s your turn.  Please tell me ASAP whether you want Option One, Option Two, or Option Three.
Thanks.

When you launch the SirsiDynix URSA client on Thursday, April 12, your PC should download the latest iBorrow build.  I just got a list of the fixes and new features.  Some of them seem to have accidentally been written in Martian, so I’ll need to get those translated.  But, here is what I know now.

• LOLR.  If we forced a Lender Of Last Resort on you (as a borrower) so that other participants could decline your requests when they lacked the needed item, we can now take that away.  But, there is a new “Last Resort” feature below, so read on.
• Availability Rules.  Not perfect, but better.  The SirsiDynix programmers found several circumstances that cause iBorrow to think you have an ‘available’ copy when you really don’t.  And they fixed those.  But they say, “We think there are more lurking out there!”  (Cue the theme from “Jaws”)  So, I’ll be asking you to continue to tell me when iBorrow asks you to lend that Reference DVD you have.
• Horizon Holds.  If you are on a Horizon system, and you do Receive Loan, iBorrow should now always–always, always, always–place a Hold on that item.
• Mediated Borrowing.  When you use Search Items in Mediated Borrowing to find a lender and actually get lucky, the request WILL go to a status of Pending at Lender.  (That doesn’t guarantee the lender will send it to you, of course.  They may not trust you with their Reference DVD.)
• Patron Portal.  The requestor’s name and email address WILL appear in the portal when his request is confirmed. (Unless, of course, his email address is not on file in the local server.)
• Not Filled.  This is the new one.  Some requests just never get filled, and this new set of features is designed to deal with that sad fact of life.  I have not seen it yet, but here is how SirsiDynx describes it.  “Libraries can configure the Borrowing Sequences to send requests that cannot be filled by any library on any tier (1) to be sent to a Lender Of Last Resort, (2) to go to staff at the borrowing library to identify new lenders, or (3) to be marked “unfilled”.  If marked “unfilled” a new event allows email to be automatically generated to notify patrons that they request cannot be filled.  The library’s designated contact can also be sent notification when a request is marked “unfilled”.  Patrons will not see unfilled requests in My Account, since the request is no longer active.”  [I think that the choice among 1, 2, or 3 will depend on whether your lender of last resort is OCLC, blank, or yourself.  But I need some confirmation on that.]

That’s not ALL that’s in the new build, but it covers the highlights.  I’ll add more when I have the translations from Martian and/or when I get to see it myself.

We recently did an informal Email survey to find out which materials types the participating iBorrow libraries would not loan via iBorrow. Here is what we’ve gathered so far.  We’ll update it as additional information comes in.

Non-lendable Item Types by Library
A few lines below you will find a list of the participating iBorrow libraries and descriptions of the item types they will not loan.  We hope you find it useful, but please be aware of these limitations.
1.  The URSA availability rules are based on Collection Code (to use Horizon terminology) not on item type.  For those of you with a long attention span, I’ve posted an explanation of why it works that way below the list.
2.  Many libraries have “unwritten rules” about what they will lend to whom.  They may choose not to allow ILL lending for some things that they will loan within their own local system.  And they may choose not to lend some things within their local system that they will lend to their very own borrowers.

Briefly put, many libraries’ actual lending rules are more complex than their published rules.  One value of the list below is that it shows you the wide variation in lending rules, even among the relatively small number of current participants.
Participants and Item/Media types they will not lend.
Hernando County
 Reference Items
Hillsborough County
 DVD’s, VHS, music CD’s, reference materials
Lee County
 Music CD’s, Books on CD, DVDs, Software, Book Discussion Kits, Digital Audio Players, Assistive devices, periodicals, books in these collections: E-books, leased, new book section, professional collection, reference, story shelf
Palm Harbor
DVDs, CD books, New Items, Reference, Genealogy, Periodicals, Newspapers, Adaptive Toys

East Lake
  Digital Audio Players (Playaways)
Pinellas Park
  Reference materials and playaways
Polk County Library Cooperative
  Lake Wales
   DVD’s, VHS, “New” books, genealogy, Reference
  Lakeland
   Music CD’s, VHS, DVD’s, computer games, software
Sunline
  Clearwater Christian College
   AV items (Cassette, CD, VHS, DVD), curriculum items, reference works 

  Dunedin
   Best sellers, magazines, any AV material

Florida Southern College
     CDs, DVDs, VHS, software, children’s books from the Instructional Materials collection,
       Reference items
  Largo
    No: Interactive multimedia, Fiction VHS, Fiction DVD, Genealogy, High Demand, Board Books, Toys, Hooked on Phonics, Local History, Vertical file, magazines.  [Book Clubs to Go: OK in Pinellas County only]
    Yes:  Playaways, Books on mp3 discs

Oldsmar
    Best sellers, VHS, DVD
  Safety Harbor
   Fiction DVD’s, ‘new’ books, professional or reference items.
Why iBorrow uses Collection code and not Item Type
IBorrow’s availability rules are based on Collection Code rather than Item Type, because it searches the participating servers using the Z39.50 protocol.  That search generally brings back the Collection Code, because that is what tells users ‘where’ it is shelved, and that is what online catalogs were originally for.  IBorrow matches the Collection Code of the title the patron requests against the list of lendable or not lendable codes you sent us.  If you have items you will loan and items you will not loan in the same collection code, iBorrow will not be able to tell them apart.  URSA/iBorrow uses the Z39.50 protocol, because “all” libraries speak that, and only servers from the same vendor speak that vendor’s PAC language.

Given the right tools and a decent tail wind, iBorrow will place a Hold on the requestor’s desired title, put it in your Fill Loan work space, and you can just gather it in with the rest of the items on your morning ‘pick list’.  (aka trace list, request pull list, POSH list, etc.)

But iBorrow needs an ISBN to do that.  If the title the requestor clicked on in the portal has no ISBN in the MARC record, iBorrow can’t place a hold on your local server, and the request winds up in Mediated Loan.  I’ll try to explain why below, but let’s stick with practical steps at the moment.

If a request shows up in your Mediated Lending work space, and if you can get your hands on it, you can scan its baracode, and iBorrow will handle it just as it would if you scanned the barcode in Fill Loan.  How you get your hands on it will vary widely from library to library.  However you do that is OK with me.  And you’ll want to be sure the copy has a status of Checked In when you scan it.

Now–for those of you with long attention spans–let’s look at why this happens.  (I have not checked this explanation with SirsiDynix, so I may issue corrections and updates later.)  IBorrow’s original search is a Z39.50 search, often a Title Keyword search.  It finds what it finds, and the requestor picks one.  IBorrow grabs what it can from that choice’s MARC record and does a background search of the participants, using the Borrowing Sequence of the requestor’s home library.  If it has an ISBN, it has a number that will exactly match one title in any local catalog.  The ISBN 0310207096 will always bring up “When Dreams Cross”.  It can then place a hold on that bibliographic record. 

If all it has is a title or author, it knows it does not have enough information to safely place a hold.  So, it hands it off to you in Mediated Lending, because it knows you are smarter than it is, and you can figure out how to get the ‘right’ book.

Now, if the the ‘bib key’–the unique bibliographic identifier–were in the MARC record in a Horizon or Unicorn system, it could use that, at least in the one system where it got the MARC record.  But, even though Horizon and Unicorn bib records have bib keys, they are not in the MARC record.  So, iBorrow can’t see them.
Thanks for staying with me through all of that.  Treat yourself to an extra doughnut at break time.

Mmrgh pgrmp rgglug.  That is the sound of me trying to talk with my foot in my mouth.  Which is where it (my foot) strayed in my previous post. 

When the bug in the last build prevented you (as a lender) from declining a request, if the borrower had no Lender Of Last Resort on file, Ken and I grabbed the first available library that was ‘in the grid’ and not yet a participant.  That happened to be the one labeled Sanibel.  We did not consult them.  We just plugged that data line in and watched the problem go away.

Unfortunately, some of you missed our original explanation of why ‘Sanibel’ was now part of your lending string, and blamed them for unfilled requests.  So, I put out an Email explaining why they were there, then added it as a post to this blog.  That’s how my foot got in my mouth.

So, please be aware that the real Sanibel was an innocent bystander throughout this entire process.  And with some help from Peter Fripp at SirsiDynix, the term ‘Sanibel’ that you’ve been seeing has been replaced–until the next build–with the term ‘LOLR’.  When we get the new build, this whole problem should go away.

When you look at your iBorrow requests in Request Manager, you may see Sanibel crop up as a lender.  And they always decline.  How rude!  Well, there’s a reason.  The Sanibel you see in iBorrow has nothing to do with the real Sanibel.  You know about virtual/dummy borrowers in iBorrow.  Think of Sanibel as a ‘virtual library’.  Here’s the whole story.

SirsiDynix fixed several bugs in the last build, but they also broke something. They broke the ability of a ‘lending’ library to decline a request when the ‘borrowing’ library had no Lender Of Last Resort (LOLR) on file.  (Read that again to make sure you connect all the dots.)

Many participants had no LOLR on file. Whenever one of them requested anything that the last lender in the ROTA could or would not fill, declining produced an error message, and the request just stayed there in Mediate Loan or Fill Loan.

Ken Adams and I devised a workaround. We needed a dummy library. We needed a library that already existed in the iBorrow database, but that would not ‘do’ anything. Sanibel was one of those libraries. They are so far over the horizon for iBorrow that they don’t even know we exist yet.  (OK.  Slight exaggeration there.)

So, for libraries with no LOLR, we plugged Sanibel into Agency Setup as the LOLR with an aging period of Zero days.

Now, when iBorrow looks through all of the real participants and finds no available copies, it takes the request to Sanibel, waits five minutes, and then returns it to the original borrower. In your case, that would be you.

And if it finds a possible lender and that lender is the last or only lender in the ROTA and that lender declines it, iBorrow takes the request to Sanibel, waits five minutes, and returns it to the original borrower.  That’s still you.

If it were not for the bug in the build, the requests would still come back to you. But if they went to a real library first and were declined, they would come back to you directly, not via Sanibel.

So, when the bug in the build is fixed (and the flagon with the dragon has the brew which is true), Sanibel will go away, and your declined requests will come back to you directly, rather than taking the scenic route.

Get it?  (Got it!)  Good!