Ivar
It certainly does and is pretty much what I half knew/suspected. But doesn't
that approach make it almost impossible for libraries to change their RFID
supplier in the future? That's precisely why I started this "crusade" a year
ago. Libraries simply aren't aware of what's going on inside their RFID
systems. They have made a lot of assumptions about how all this stuff works
- encouraged by the market - that simply aren't accurate.
What you describe is the process we thought we were about to begin - how
best to use the data elements that the profile allows. I was hoping to
retrofit some of the changes to which you refer - and which we know exist -
into the profile but we still then need an API or extended protocol to
enable this process. What you seem to be saying is that RFID companies have
already made those decisions on our behalf and now they need an API to get
the genie back into the bottle.
Glad to have your support though.
Best
Mick
Mick Fortune
m. +44 (0)7786 625544 t. +44 (0)1865 727411
> -----Original Message-----
> From: Discussion List for RFID in Libraries [mailto:LIB-RFID-
> [log in to unmask]] On Behalf Of Ivar Thyssen
> Sent: 23 June 2009 16:25
> To: [log in to unmask]
> Subject: Re: RFID/LMS database interaction - summary and reflections
>
> Mick,
> Now it starts to cost money (joke).
>
> Basically, an RFID tag is just an advanced barcode label. However, P.V.
> Supa
> as well as nearly all other suppliers on the European continent has
> developed staff desk solutions utilising the additional information
> stored
> in the RFID tag. I write like this as I do not know the status of the
> solutions provided by British manufacturers. These solutions offer a
> lot
> more functionality to the staff desk in terms of material control,
> security
> control etc.
>
> Just to send the item ID-number to the LMS/ILS is some time very
> troublesome. Way back in first generation it was done via a keyboard
> wedge
> or similar. Very primitive but working solutions. Unfortunately, this
> kind
> of solutions is not always optimal and the industry must move forward.
>
> Today, information are exchanged in numerous ways from full integration
> between LMS/ILS and RFID-solutions down to the "good" old keyboard
> wedge.
> Between these to outer points there are many steps. The most convenient
> method for all parties (and probably also the cheapest) for exchange of
> information is as I wrote earlier an API made by the LMS/ILS.
>
> Please notice that this discussion is only concerning data flow at the
> staff
> desk units and programming units, as all self-service units operates
> via SIP
> or NCIP.
>
> I hope this clarified the issue.
> Best regards
> ivar
>
>
>
>
> -----Original Message-----
> From: Discussion List for RFID in Libraries
> [mailto:[log in to unmask]] On Behalf Of Mick Fortune
> Sent: 23. juni 2009 16:57
> To: [log in to unmask]
> Subject: Re: RFID/LMS database interaction - summary and reflections
>
> Ivar
>
> I don't understand your point I'm afraid. If you use a barcode scanner
> the
> only data that passes between the item and the PC is the barcode. Why
> would
> you want to do something different with tags? Or are you suggesting we
> use
> more than just the barcode number?
>
> For self-service we use SIP to exchange data because we need the
> self-service units to display data from the LMS (and each supplier uses
> their own display software) but with other operations this isn't
> necessary
> since the LMS/ILS only needs to use the barcode ID to interrogate the
> database.
>
> That at least has always been my understanding in conversations with
> systems
> librarians - which I was myself for quite a while.
>
> Anyone else want to jump in here? I think this is an important point
> and we
> need to be clear about how we want it to work or else it seems we will
> have
> multiple systems to manage.
>
> Mick
>
> Mick Fortune
> m. +44 (0)7786 625544 t. +44 (0)1865 727411
>
>
> > -----Original Message-----
> > From: Discussion List for RFID in Libraries [mailto:LIB-RFID-
> > [log in to unmask]] On Behalf Of Ivar Thyssen
> > Sent: 23 June 2009 15:46
> > To: [log in to unmask]
> > Subject: Re: RFID/LMS database interaction - summary and reflections
> >
> > Mick,
> > No matter which of your 2 alternatives is used it is still necessary
> to
> > forward information about each material from the RFID-reader to the
> > LMS/ILS.
> >
> >
> > Optimal way is full integration to each individual LMS/ILS for each
> > RFID
> > vendor. Unfortunately, this would be a huge workload for the ILS
> > companies
> > to do and I do not believe any LMS/ILS company is prepared to do. To
> > overcome the problem an API is the best solution.
> >
> > Best regards
> > P.V. Supa Oy Ltd
> >
> > Ivar Thyssen
> > Export manager
> >
> >
> > -----Original Message-----
> > From: Discussion List for RFID in Libraries
> > [mailto:[log in to unmask]] On Behalf Of Mick Fortune
> > Sent: 23. juni 2009 16:08
> > To: [log in to unmask]
> > Subject: Re: RFID/LMS database interaction - summary and reflections
> >
> > Ivar
> >
> > Interesting points about the integration - or lack of integration -
> > between
> > RFID and LMS/ILS at the staff workstation. There seem to be almost as
> > many
> > solutions to this as there are systems. I think it all depends on
> > whether
> > you see RFID as something "other" than day-to-day library operation
> or
> > not.
> > The simplest level of integration would seem to be to populate the
> > barcode
> > input buffer on the LMS/ILS from the RFID reader instead of the
> barcode
> > scanner. That way there is no re-training issue and all existing
> > LMS/ILS
> > systems continue to operate as before. This is an approach that has
> > been
> > successfully implemented at many sites. The only difficulty appears
> to
> > be in
> > finding a way to gain the advantage of multiple item processing that
> is
> > possible with self-service.
> >
> > An alternative is to run an RFID client alongside the LMS/ILS client
> > to
> > manage the security settings - which is also popular with suppliers
> > though
> > not so much with libraries. I really don't see why there is a need
> for
> > a new
> > standard or API. Indeed it was a request made to Leif Andresen for
> such
> > a
> > standard that set the alarm bells ringing for me in the first place.
> > Why
> > invent a new way to interact with your stock? Isn't that why you have
> a
> > library system in the first place? I am advised by at least two UK
> > suppliers
> > that they will announce multiple item handling at staff workstations
> > later
> > this year.
> >
> > Amen to not duplicating databases but the concern is that scaling up
> > smart
> > shelves for large libraries will place too heavy a demand for the
> > LMS/ILS to
> > handle - that's why at the moment the idea seems to be to use the
> > shelves to
> > take inventory during quiet hours, rather than monitor real-time
> stock
> > use.
> > That seems like a lot of investment for not much return right now but
> I
> > am
> > assured that the system can be scaled up to handle real time
> operations
> > eventually. The real point seems to me to be "who runs your library?"
> >
> > Mick
> >
> > Mick Fortune
> > m. +44 (0)7786 625544 t. +44 (0)1865 727411
> >
> >
> > > -----Original Message-----
> > > From: Discussion List for RFID in Libraries [mailto:LIB-RFID-
> > > [log in to unmask]] On Behalf Of Ivar Thyssen
> > > Sent: 23 June 2009 06:10
> > > To: [log in to unmask]
> > > Subject: FW: RFID/LMS database interaction - summary and
> reflections
> > >
> > > Mick,
> > > I fully agree to your statements that RFID-vendors and ILS (LMS)
> > > companies
> > > should co-operate for the development of intelligent shelves.
> > However,
> > > before starting on intelligent shelves, it would be very convenient
> > if
> > > we
> > > could start to co-operate for integration of staff desk solutions.
> > >
> > > The optimal solution would be either an ISO standard interface
> > between
> > > ILS
> > > systems and RFID-software for staff desks. Unfortunately, I do not
> > > believe
> > > this is possible to establish.
> > >
> > > Instead, I suggest that all ILS companies establish an API to which
> > the
> > > RFID
> > > system integrators can connect for staff desk solutions and
> > eventually
> > > also
> > > for programming of RFID-tags for new media. This solution moves the
> > > responsibility for integration to the integrator's side and makes
> > life
> > > much
> > > easier for everybody.
> > >
> > > Back to intelligent shelves I cannot see that co-operation would
> > > facilitate
> > > a solution. Presently, the industry has a good integration using
> NCIP
> > > for
> > > exchange of data between ILS and automatic systems and from our
> point
> > > of
> > > view for intelligent shelves all relevant data can be pulled from
> ILS
> > > via
> > > this protocol. Therefore, I cannot understand why a duplicated
> > database
> > > as
> > > Mick mentions in his comments, is needed.
> > >
> > > Best regards
> > > P.V. Supa Oy Ltd.
> > >
> > > Ivar Thyssen
> > > Export manager
> > >
> > >
> > > -----Original Message-----
> > > From: Discussion List for RFID in Libraries
> > > [mailto:[log in to unmask]] On Behalf Of Mick Fortune
> > > Sent: 22. juni 2009 18:21
> > > To: [log in to unmask]
> > > Subject: Re: RFID/LMS database interaction - summary and
> reflections
> > >
> > > Alan
> > >
> > > I recently watched a presentation about smart shelving and have
> > > previously
> > > seen presentations in Denmark and Italy about similar projects.
> > >
> > > It's quite a different concept from automated sorting. As you say
> > > sorting is
> > > driven by the SIP protocol at the moment and, although not
> > technically
> > > a
> > > standard, it is the nearest thing we have to one and works in the
> > > manner you
> > > suggest.
> > >
> > > No, the "smart shelf" idea uses RFID antennae built into the shelf
> in
> > > some
> > > way. Two versions I have seen use something very like a separator
> > > spaced out
> > > along each shelf - another uses a single antenna built into the
> shelf
> > > itself. The shelves themselves then become "active" and stock
> placed
> > > upon
> > > them can be "seen" by the RFID system. The possible uses for such a
> > > technology are obviously legion in number but one that has been
> > > suggested is
> > > that active shelves can be used to monitor the use of stock within
> > the
> > > library - i.e. non-circulating but potentially in high demand.
> > >
> > > There would however be difficulties in using the LMS catalogue to
> > drive
> > > such
> > > an operation. One proposal for overcoming this is to use a separate
> > > database
> > > to drive the smart shelves. This, to me, raises several more issues
> > > that do
> > > not appear to have been fully considered.
> > >
> > > Far from seeing such developments as negative however, I think they
> > > represent some really exciting thinking and potentially great
> > > innovation. My
> > > problem is that we now have two groups of companies competing in
> the
> > > same
> > > space - RFID and LMS suppliers. Rather than work together (which
> they
> > > do
> > > very successfully in some areas) they seem to be miles apart on
> > issues
> > > like
> > > this. I suspect for two reasons. Firstly because libraries ask
> their
> > > RFID
> > > companies to be innovative rather than co-operative, and secondly
> > > because
> > > the RFID companies see library operation as their domain. Which of
> > > course it
> > > is. Except that bad things can happen if libraries don't ask the
> > right
> > > questions about how such innovations might affect their day to day
> > > operation. Witness the (almost) total lack of interoperability in
> the
> > > self-service world.
> > >
> > > But as a consultant you'd expect me to say that, wouldn't you?
> > >
> > >
> > >
> > > Mick Fortune
> > > m. +44 (0)7786 625544 t. +44 (0)1865 727411
> > >
> > > > -----Original Message-----
> > > > From: Discussion List for RFID in Libraries [mailto:LIB-RFID-
> > > > [log in to unmask]] On Behalf Of Exelby Alan Mr (LIB)
> > > > Sent: 22 June 2009 16:47
> > > > To: [log in to unmask]
> > > > Subject: Re: RFID/LMS database interaction - summary and
> > reflections
> > > >
> > > > Mick,
> > > >
> > > > What is a "smart shelving project"? We at UEA do have an
> automated
> > > > returns sorter, and this sorts perfectly well for six different
> > > floors
> > > > using data sent from the LMS via SIP2 using the CL field, which
> is
> > I
> > > > believe a standard field.
> > > >
> > > > Alan
> > > >
> > > >
> > > > ==============================
> > > > Mr A.V. Exelby,
> > > > Systems/Databases Librarian.
> > > > The Library,
> > > > University of East Anglia,
> > > > Norwich, NR4 7TJ
> > > >
> > > > Tel.: 01603 592432
> > > > E-mail: [log in to unmask]
> > > > ================================
> > > > "Man, who'd have thought being a librarian could be so tough"
> > > > Seamus Harper, in 'Harper 2.0', "Andromeda".
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > From: Discussion List for RFID in Libraries
> > > > [mailto:[log in to unmask]] On Behalf Of Mick Fortune
> > > > Sent: Monday, June 22, 2009 4:39 PM
> > > > To: [log in to unmask]
> > > > Subject: Re: RFID/LMS database interaction - summary and
> > > > reflections
> > > >
> > > >
> > > >
> > > > Good afternoon all
> > > >
> > > > It would seem that no-one is yet using any of the
> > > > database-driven solutions of which I spoke last week. Well at
> least
> > > > no-one has written to me to tell me about one, apart from Ivar
> and
> > > one
> > > > other company that wrote off list to let me know that they keep a
> > > small
> > > > database to drive preferences for self-service units this way.
> > > >
> > > > However what I was alluding to was, as Ken suggested,
> something
> > > > rather more radical. Indeed there are two radical solutions - one
> > for
> > > > circulation and one for cataloguing. Since no-one has mentioned
> > > either
> > > > I
> > > > conclude that both are still on their respective drawing boards -
> > at
> > > > least as far as the UK market is concerned.
> > > >
> > > > I am however aware that at least one library has signed up
> to a
> > > > solution that appears to require duplication of the LMS catalogue
> > in
> > > > order to drive a smart shelving project. I will be really
> > interested
> > > to
> > > > see how that story develops.
> > > >
> > > > As regular readers will know the last BIC/CILIP RFID
> meeting -
> > > > which I mediated - agreed a UK Profile for RFID tags that
> > contained
> > > > only three mandatory elements (among the 16 in the profile),
> > entirely
> > > > in
> > > > line with the views of the majority that expressed an opinion on
> > the
> > > > list. Which is gratifying to say the least J. Don't forget the
> full
> > > > profile is available from either BIC or my blog.
> > > >
> > > > Part of the profile relates to the ISIL code for library
> > > > identification. This will be a mandatory element in 28560-2 and
> the
> > > > national profile but so far (having checked last week) only 9
> > > libraries
> > > > have registered with the UK's ISIL registration authority at the
> > BL.
> > > >
> > > > Thanks again for the replies to everyone that did.
> > > >
> > > > Kind regards
> > > >
> > > > Mick
> > > >
> > > >
> > > >
> > > > Mick Fortune
> > > >
> > > > m. +44 (0)7786 625544 t. +44 (0)1865 727411
> > > >
> > > >
> > > >
> > > > From: Discussion List for RFID in Libraries
> > > > [mailto:[log in to unmask]] On Behalf Of Ivar Thyssen
> > > > Sent: 18 June 2009 11:54
> > > > To: [log in to unmask]
> > > > Subject: Re: RFID/LMS database interaction
> > > >
> > > >
> > > >
> > > > HI,
> > > >
> > > > The last three comments concerning duplicated handling of
> > > > information are all perfectly right.
> > > >
> > > > We shall not save more information to the RFID-tag than
> > > > necessary. Relevant data are ID-number, library ID and
> information
> > > > about
> > > > set. All other information should already be stored in LMS.
> > However,
> > > > this does not mean that an RFID-tag may not be used for supply
> > chain
> > > > purpose, but all information used in supply chain should be wiped
> > > > before
> > > > the material is made public (obvious reasons).
> > > >
> > > > Similar, information about materials and users shall be
> stored
> > > > in the LMS and only in the LMS. That is why we have an LMS!
> > However,
> > > > the
> > > > LMS does not facilitate the interaction between RFID-components.
> > > >
> > > > Unfortunately, above statements do not provide libraries
> with
> > > > optimal solutions when it comes to utilization of the RFID. P.V.
> > Supa
> > > > has found that a lot more is possible with RFID, but we had to
> > create
> > > a
> > > > special RFID-database for information found no where else in any
> > > > existing system (the database runs in the background and manage
> > > > RFID-issues). I cannot be too specific for competitive reasons,
> but
> > > > libraries are free to contact us.
> > > >
> > > > Best regards
> > > >
> > > > P.V. Supa Oy Ltd.
> > > >
> > > > Ivar Thyssen
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > >
> > > > From: Discussion List for RFID in Libraries
> > > > [mailto:[log in to unmask]] On Behalf Of Jamie O Neill
> > > > Sent: 18. juni 2009 12:12
> > > > To: [log in to unmask]
> > > > Subject: Re: RFID/LMS database interaction
> > > >
> > > >
> > > >
> > > > Hi
> > > >
> > > >
> > > >
> > > > I'm with Gary on this. I don't see the point in
> duplicating
> > > > data or having data in yet another database which could happily
> be
> > > > stored in a table on the LMS and would have to be synched in real
> > > time
> > > > probably over a protocol like sip which most Libraries will be
> > > already
> > > > using.
> > > >
> > > >
> > > >
> > > > Also we already have units that deal with Security and Self
> > > > Service. Granted we don't get stats from the security side but I
> > > don't
> > > > think this would be very useful anyway. The Circulation data is
> > > > obviously more meaningful to Libraries. The ability to use Self
> > > > Service
> > > > and Security in one unit and gather stats from the LMS via sip or
> > > > similar is fine at the moment.
> > > >
> > > >
> > > >
> > > > Unless I'm missing the point somewhere along the line?
> > > >
> > > >
> > > >
> > > > Jamie.
> > > >
> > > >
> > > >
> > > > Jamie O'Neill
> > > > Talis System Administrator
> > > > Library Infrastructure Management
> > > > University of Central Lancashire
> > > > Office Tel: 01772 892298
> > > > Mobile No: 07961074653
> > > > Facsimile: 01772 892937
> > > >
> > > >
> > > >
> > > > >>> Gary Green <[log in to unmask]> 18/06/2009 10:41 >>>
> > > >
> > > > Hi
> > > >
> > > > Wouldn't it just duplicate the data and lead to the LMS &
> RFID
> > > > systems being out of synch? Wouldn't you also need more staff to
> > > update
> > > > the 2 separate databases? Does this mean these systems would be
> > > > expecting RFID tags to include bib data on them too, which so
> many
> > > RFID
> > > > users don't seem keen on?
> > > >
> > > >
> > > >
> > > > I know it's not the same thing, but it seems at odds with
> what's
> > > > happening in other IT areas (particularly the internet) where the
> > > > effort
> > > > is spent bringing the data together, not purposefully separating
> > it.
> > > >
> > > > Gary Green
> > > >
> > > > Technical Librarian
> > > > Virtual Content Team
> > > > Surrey County Council
> > > >
> > > > Tel. 01306-881499
> > > >
> > > > Fax. 01306-743240
> > > >
> > > > An outstanding council making Surrey a better place
> > > > Forward thinking - responsive and reliable - working with
> others
> > > > - value for money
> > > >
> > > >
> > > >
> > > > -----Discussion List for RFID in Libraries
> > > > <[log in to unmask]> wrote: -----
> > > >
> > > > To: [log in to unmask]
> > > > From: Mick Fortune <[log in to unmask]>
> > > > Sent by: Discussion List for RFID in Libraries
> > > > <[log in to unmask]>
> > > > Date: 17/06/2009 02:52PM
> > > > Subject: RFID/LMS database interaction
> > > >
> > > > I have recently been advised of two RFID solutions being
> > > > proposed that are
> > > > using a separate database from the LMS to control RFID
> units
> > > > within a library.
> > > > One controls security the other self-service.
> > > >
> > > > I had seen a schematic for a third such solution some time
> ago
> > > > but believe
> > > > that it never in fact came to market.
> > > >
> > > > This seems to be part of an emerging trend for RFID
> systems to
> > > > declare
> > > > themselves independent from the LMS/ILS and go it alone.
> That
> > > > may be an
> > > > inveitable consequence of technologicak change but at this
> > > > moment in time I
> > > > am finding it difficult however to understand or
> conceptualise
> > > > how this might
> > > > work in practice? It is not yet clear whether the scenarios
> on
> > > > offer are real or
> > > > hypothetical although both claim to have been market
> tested.
> > > >
> > > > I would very much welcome any inputs the list can offer on
> how
> > > > the two
> > > > databases might be kept in synch and any impact on
> performance
> > > > of doing so -
> > > > if anyone out there has experience of such a solution?
> > > >
> > > > Kind regards
> > > >
> > > > Mick
> > > >
> > > >
> > > >
> > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * *
> > > >
> > > > This email and any attachments with it are intended for the
> > > > addressee only. It may be confidential and may be the
> subject of
> > > > legal and/or professional privilege.
> > > > If you have received this email in error please notify the
> > > > sender or [log in to unmask]
> > > > The content may be personal or contain personal opinions
> and
> > > > cannot be taken as an expression of the County Council's
> > > > position.
> > > > Surrey County Council reserves the right to monitor all
> incoming
> > > > and outgoing mail. Whilst every care has been taken to
> check
> > > > this
> > > > e-mail for viruses, it is your responsibility to carry out
> any
> > > > checks upon receipt.
> > > >
> > > > Visit the Surrey County Council website -
> > > > http://www.surreycc.gov.uk
> > > >
> > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * *
> > > >
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > > Version: 8.5.339 / Virus Database: 270.12.85/2193 - Release
> > > > Date: 06/21/09 20:02:00
> > > >
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > > Version: 8.5.339 / Virus Database: 270.12.85/2193 - Release Date:
> > > > 06/21/09 20:02:00
> > > No virus found in this incoming message.
> > > Checked by AVG - www.avg.com
> > > Version: 8.5.339 / Virus Database: 270.12.89/2197 - Release Date:
> > > 06/23/09 05:54:00
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.339 / Virus Database: 270.12.89/2197 - Release Date:
> > 06/23/09 05:54:00
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.12.89/2197 - Release Date:
> 06/23/09 05:54:00
|
