JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for LIB-RFID-UK Archives


LIB-RFID-UK Archives

LIB-RFID-UK Archives


LIB-RFID-UK@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

LIB-RFID-UK Home

LIB-RFID-UK Home

LIB-RFID-UK  June 2009

LIB-RFID-UK June 2009

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: RFID/LMS database interaction - summary and reflections

From:

Ivar Thyssen <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Tue, 23 Jun 2009 18:21:05 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (742 lines)

Hi,
Dave's description is exactly what can be avoided by having a general
interface between LMS/ILS systems and RFID-systems. The optimal solution is
an ISO standardized interface, but unfortunately I am afraid we will not
have it.

Therefore, an API for each LMS/ILS system is the 2nd best solution. In case
the LMS/ILS companies provide these it is easy for the RFID-system
integrators to create relevant interfaces. As RFID-system integrators will
have to create the interfaces to stay in business it is no problem for the
libraries to switch provider (actually easier).

Dave's solution to their problems sounds like the way we did it a couple of
years ago, and it is not the most secure way, but it works. Had the LMS/ILS
provider and RFID-system integrator been able to communicate together the
problems would have been avoided.

I take Mick's comments that RFID-system integrators already have made the
decisions for the libraries as a compliment. We have had to develop the
interface as the majority of LMS/ILS companies has done nothing (certainly a
few has done a great job to create good communication) or very little. Other
again has refused to do anything without huge payments from each RFID-system
integrator. 

Please have in mind that the present discussion concerns only staff desk
units and programming units. It has nothing to do with self-service systems
or the chosen RFID data model.

Best regards
P.V. Supa Oy Ltd

Ivar Thyssen
Export manager

-----Original Message-----
From: Jones, David - CULT [mailto:[log in to unmask]] 
Sent: 23. juni 2009 17:53
To: [log in to unmask]; [log in to unmask]
Subject: RE: RFID/LMS database interaction - summary and reflections

Mick and list, 

Further to Ivar's post I would agree that there is a need to consider a
way to integrate third party RFID and LMS staff client. In Norfolk we
have achieved an operational solution using a 'keyboard wedge' interface
between the RFID provider's application and the LMS application but I am
aware that it is a workaround and is not truly integrated. For example,
the security bit is set by the RFID client according to the LMS function
that is in the current window - this works most of the time but could
get out of synch e.g. the RFID client cannot detect if an issue
transaction is refused on the LMS and so security could be turned off
although the item has not been issued. Also if the LMS interface changes
we may find our solution no longer works.

Regards, Dave
__________________________________________________
David Jones, ICT Systems Manager, 
Department of Cultural Services, Norfolk County Council,
County Hall, Martineau Lane, Norwich NR1 2UA
phone: 01603 222395, fax: 01603 222055, 
mobile: 07769 642413
email: [log in to unmask]

-----Original Message-----
From: Discussion List for RFID in Libraries
[mailto:[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

Norfolk County Council - a four star authority.

The information contained in this email is intended only for the person or
organization to which it is addressed.  If you have received it by mistake,
please disregard and notify the sender immediately.  Unauthorized disclosure
or use of such information may be a breach of legislation or confidentiality
and may be legally privileged.

Emails sent from and received by Members and employees of Norfolk County
Council may be monitored.  They may also be disclosed to other people under
legislation, particularly the Freedom Of Information Act 2000.

Unless this email relates to Norfolk County Council business it will be
regarded by the Council as personal and will not be authorized by or sent on
behalf of the Council.  The sender will have sole responsibility for any
legal actions or disputes that may arise.

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

July 2019
June 2019
May 2019
March 2019
February 2019
November 2018
October 2018
August 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
August 2017
July 2017
June 2017
May 2017
April 2017
February 2017
November 2016
October 2016
August 2016
June 2016
April 2016
March 2016
February 2016
January 2016
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
April 2015
March 2015
February 2015
January 2015
December 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
April 2007
March 2007
February 2007
January 2007


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager