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

 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.  In an effort to standardize communications that support RFID, representatives from the vendor community and these two organizations came together to develop a set of protocols that support all the things libraries would like to be doing with RFID.  

The Library Communication Framework defines a set of protocols that includes, and goes beyond, basic circulation activities (which are handled now by the SIP2 protocol). Unlike SIP2, the LCF is designed to support RFID technology which allows for parallel processing of RFID tags.  

Whereas existing protocols (SIP2, NCIP2, and even the forthcoming SIP3) can only process one item at a time because they are based on barcode technology, the LCF protocols are designed around RFID technology which means several tags can be read at once and processed accordingly. This makes a very big difference when it comes to supporting inventory and it also optimizes circulation (beyond what anyone has seen so far because everyone uses SIP2).  

The Library Communication Framework (LCF) is designed to be a framework for all communication between the ILS and other RFID devices.  As I said, it incorporates SIP2, but moves beyond SIP2.  It will be updated soon to incorporate the SIP3 protocol (which is still based on barcode technology) and it is designed to be a living set of protocols (e.g. new protocols can be defined as we develop new ways to use RFID tags). BIC has committed to supporting and evolving LCF (and I'm sure they'd be happy to share the work with a US entity).

Rather than creating hundreds of proprietary applications supported by one RFID vendor for one ILS product, the LCF is an opportunity for us to standardize RFID communications worldwide.

Some RFID vendors have already committed to supporting LCF (including Bibliotheca and D-Tech). I'm not clear on 3M.  Also, one UK ILS vendor has provided a LCF-supported interface.  Other ILS and RFID vendors will follow suit only if we apply sufficient pressure that they do so.

Supporting the LCF is good for libraries more than anyone else.  It makes it easier for us to choose best of breed RFID products without getting locked into someone's proprietary solution.  And it reduces the cost of development overall.

That said, using the LCF benefits the RFID vendors and ILS vendors too since it creates a common understanding of what data needs to be exchanged and describes the protocol necessary to accomplish certain functions (e.g. use cases).  Instead of creating unique interfaces for every function and every ILS, the communications can be standardized for everyone.  

So, what am I asking for exactly?  What I would like to see is an LCF API or specific support for LCF-defined protocols using standard Web Services in both Koha and Evergreen. 

The first draft of the Library Communication Framework (at that time called the BLCF) is available here: https://bic.org.uk

Note that the above is the first draft.  A new draft will be released soon and it will incorporate the additional SIP3 messages.  The objective is to have one standard set of protocols worldwide that support everything we (as libraries) do with RFID and to base it on our shared RFID data model (ISO 28560-2).  Cooperating with the UK and Australia, both of which use ISO 28560-2 for their data model (as does the U.S.), we leverage our collective efforts to have proper access to data stored inside the ILS. 

You may be wondering why we should bother with all this for our Open Source ILS products....the reason we should use LCF as a framework for RFID-related developments in Koha and Evergreen is that it makes it that much easier for Evergreen libraries to choose from a wider range of RFID vendors.  Rather than paying for RFID support to be developed one vendor at a time, we develop one interface that is compliant with the LCF and then demand that all RFID vendors support that same set of protocols.  It doesn't all have to done at once but each time we look into adding RFID-enabled functionality, we should do it per the LCF and gradually built up an complete API or set of Web Services.

This gives each library lots more flexibility in choosing RFID products.  It saves everyone development money because once support is developed for one RFID vendor, it should be usable by any other vendor and won't require another development initiative.  And, it puts pressure on the ILS vendors to create APIs or support the same Web Services support or they run the risk of lagging behind what the Open Source ILS products are doing.  

In other words, its a big win for libraries any way you look at it.  And that is why it will be the libraries that make it happen.  

I urge all libraries to demand that new developments be based on the protocols defined in the Library Communication Framework.