You are here

Home

sip3

Harmonization of Library Protocols

Submitted by Lori Ayre on Thu, 04/25/2013 - 5:00pm

I just got back from attending my first NCIP Standing Committee meeting at OCLC headquarters in Dublin, Ohio.  It turned out to be a far better experience than I could have imagined. The people working on this committee are dedicated to making NCIP the "go-to" protocol for communications with the ILS/LMS. My objective going there was to possibly challenge that idea insofar as my intention was to introduce them to the Library Communcation Framework (LCF) - a protocol being developed in the U.K. by people who aspire to make LCF the library "go-to" protocol.

SIP3 and RFID Dropped into NISO Black Hole

Submitted by Lori Ayre on Tue, 12/04/2012 - 4:00pm

On June 6, 2012 Library Journal announced that 3M would be donating the copyright for SIP to NISO which would mean that NISO "will now have responsibility for future development and ongoing maintenance of SIP." 

The article also correctly points out that 

SIP is the de facto standard for communication between library self-service devices and the wide variety of integrated library systems (ILS) that libraries use. It provides the crucial common language that makes possible such widespread functions as self checkouts, automated materials handling systems, PC management systems, or fine and fee payment transactions.

In other words, SIP is really important when we try to integrate ANYTHING with our ILSs.  So, given its importance you'd think that there might be something in the works for 2013 at NISO but alas SIP is not the subject of discussion at any of the scheduled 2013 NISO Events.

Call for Open Source ILS Communities to Support the Library Communication Framework (LCF)

Submitted by Lori Ayre on Sun, 11/18/2012 - 4:00pm

 I have just returned from the UK, where I spoke at the RFID in Libraries Conference.  While there, I met with representatives from the Book Industry Communications (BIC) and the Chartered Institute of Library and Information Professionals (CILIP) as well as RFID vendors. BIC and CILIP are two UK entities roughly equivalent (very roughly) to the BISG (Book Industry Study Group) and ALA.

SIP 3.0 Ready for Implementation

Submitted by Lori Ayre on Wed, 01/04/2012 - 4:00pm

SIP3 has just been released and it provides many new messages which means communication between ILS/LMS and your self-check, sorters, security system, PC management system....will be easier to implement and you'll have more options.  That is IF your ILS vendor supports it!  

So, make sure you start adding a requirement for SIP3 support to your procurement documents.

Here's what's new:

  • allow creation / registration of patrons from self-service devices
  • allow patrons to update their PINs / Passwords from a self-service device in the library
  • allow patrons to update their home addresses and phone numbers
  • support for handling electronic resources
  • support for staff overrides on self-service circulation
  • support for sortation systems
  • support for PC Management systems
  • added some other new messages simplify implementation and clarify usage
  • added Undo Checkout and Undo Check-in messages to simplify implementation. It has been confusing for many developers to send a Check-in w/cancel flag to cancel a Checkout and send a Checkout w/cancel flag to cancel a Check-in. This was confounded by the fact that many ILS vendors did not support cancelling a transaction and would then proceed as a standard check-in (if cancelling a checkout) causing the patron to be removed from the hold list.
  • added Off-line Checkout and Off-line Check-in messages to support off-line processing
  • added Unsupported Message Response to indicate that the message request is not supported by the library system
  • added Grouped data.  Data can now be grouped to provide all information required for a specific event. For example, a fee consists of the following fields: fee identifier, currency code, fee amount, and fee type. These fields can now be grouped together to simplify the passing of multiple fees on a single request or response message. Each set of group data starts with a group identifier and ends with a group end field.