[OPEN-ILS-GENERAL] Library Communications Framework

[Lori Bowen Ayre]

I have just returned from the UK where I met with BIC and CILIP (Chartered
Institute of Library and Information Professionals) representatives as well
as RFID vendors.


BIC has commissioned of a new set of library interoperability standards,
which define a framework for the communication of data between self-service
devices and other library terminal applications to and from library
management systems. This framework replicates and extends the range of
activities commonly conducted using 3M's open SIP.2 protocol and
additionally provides web services functionality for the exchange of
information.

It is anticipated that further functionality will be added over time, as
new requirements are identified by libraries and by their management system
and terminal application developers and suppliers. Support for additional
functionality in the areas such as stock management is under consideration.
Greetings All,

I have just returned from the UK, where I met with representatives from the
Book Industry Communications (BIC) and the Chartered Institute of Library
and Information Professionals (CILIP).  These are two UK entities roughly
equivalent to the BISG (Book Industry Study Group) and ALA.  In an effort
to standardize communications that support RFID, several people came
together to develop a set of protocols that support all the things
libraries would like to be doing with RFID.  This incorporates and goes
beyond basic circulation activities (e.g. adequately covered by SIP2) and,
very importantly, it 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. This makes a 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 a framework for all
communication between the ILS and other RFID devices.  It incorporates
SIP2, but moves beyond SIP2.  The LCF is an opportunity for us to
standardize these communications worldwide.  Some RFID vendors have already
committed to supporting LCF (including Bibliotheca and D-Tech).  Also, one
UK ILS vendor has provided a LCF-supported interface (with Bibliotheca).
 Others will follow if we apply sufficient pressure that they do so.

Using the LCF benefits the RFID vendors as well as the ILS vendors since it
creates a common understanding of what data needs to be exchanged and
describes the exchange 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.

Ideally, what we should be providing in Evergreen is an LCF API or support
for LCF-defined protocols using standard Web Services. Those technical
details are for developers to determine but I hope you will do what you can
to build on and support this initiative.

The first draft of the Library Communication Framework (at that time called
the BLCF) is available here:
http://www.bic.org.uk/e4libraries/16/INTEROPERABILITY-STANDARDS/

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.

Why bother with all this for an Open Source ILS?  The reason we should use
LCF as a framework for RFID-related developments is that it makes it that
much easier for Evergreen libraries to choose from a wider range of RFID
vendors.  Rather than paying for developments for 3M, then Envisionware,
and now PV Supa, we develop interfaces that are compliant with the LCF and
then demand that our RFID vendors in turn support that same set of
protocols.

Supporting the Library Communication Framework will save us money and give
us more flexibility.

In addition, by leading the charge by supporting LCF here in the states, we
will add to the pressure already being applied by the UK libraries who are
working to get their RFID and ILS/LMS vendors to do the same. Some of our
ILS and RFID vendors overlap so we all benefit from moving in the same
direction.  And make no mistake, this is good for libraries more than
anyone else.  It makes it easier for choose best of breed RFID products
without getting locked into someone's proprietary solution.  And it reduces
the cost of development overall.

However, to get any traction on this, we need to start demanding that new
developments are based on the protocols defined in the LCF and if we
identify new uses for RFID, we should submit our use cases to the LCF
(which BIC has promised to actively manage).

I'd love to see the Evergreen community lead the charge on this, on behalf
of all library users whether they are on an Open Source ILS or not.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
Lori Bowen Ayre //
Library Technology Consultant / The Galecia Group
(707) 763-6869 // Lori.Ayre at galecia.com
Availability:  http://doodle.com/loriayre

<Lori.Ayre at galecia.com>Specializing in open source software solutions,
RFID, filtering,
workflow optimization, and materials handling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20121119/304b3c97/attachment-0001.htm>