LISTSERV mailing list manager LISTSERV 16.5

Help for CODE4LIB Archives


CODE4LIB Archives

CODE4LIB Archives


CODE4LIB@LISTS.CLIR.ORG


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

CODE4LIB Home

CODE4LIB Home

CODE4LIB  May 2009

CODE4LIB May 2009

Subject:

Re: [VuFind-General] long term direction

From:

Ya'aqov Ziso <[log in to unmask]>

Reply-To:

Code for Libraries <[log in to unmask]>

Date:

Sun, 24 May 2009 13:26:07 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (274 lines)

Kindest  thanks (!!)  to all those who replied to my questions. Nothing
fancy, I just lined up answers by their question so we see them on one page,
as listed below. Please note Alan's question in his reply to #6: how do we
merge patches as we keep working on an improved RC?
Yaıaqov Ziso, Electronic Resource Management Librarian, Rowan University 856
256 4804 

===============================
Replies from:
MT--Mark Triggs Systems Administrator, The National Library of Australia
[log in to unmask]
GR--Gord Ripley Systems Librarian, Trent University, Peterborough, Ontario
[log in to unmask]
DL--Daniel Lovins Catalog & metaData Services, Yale Libraries
[log in to unmask]
AR--Alan Rykhus PALS, Minnesota State Colleges and Universities
[log in to unmask]
TK--Till Kinstler, Verbundzentrale des Gemeinsamen Bibliotheksverbundes
(VZG) Göttingen     [log in to unmask]
GP--Greg Pendlebury  Electronic Services Officer (Systems Team)  University
of Southern Queensland     [log in to unmask]
 
1.  is vuFIND primarily an experiment? if not why havenıt more sites
switched to production like VU or NLA?
 
MT>> It's a year to the day that our VuFind installation replaced our
previous Voyager OPAC.  As other people have said, I suspect the lack of a
1.0 release might be scaring people from taking the next step, and something
like this does require some level of support from IT staff. That said, I
think that switching your delivery system is more than just a technical
challenge, so it's understandable that we haven't seen everyone rush to
switch.
 
GR >> I think Greg hit the nail on the head when he commented that many of
us are waiting to see how v1.0 RC1 evolves before committing to production,
or even to much experimentation. On smaller campuses (like Trent) it is all
we can do to keep Unicorn running smoothly while navigating Joomla, dSpace,
and so on. VuFind looms large, but it looms on the periphery. Still, I view
it as  more than an experiment, for this reason: if -- as we anticipate --
it proves to be slick, effective, and economical as a front end, we'll be
looking at developing our own lightweight back end. If someone beats us to
it, that would be even better.
 
DL >> We consider it "beta" but still more than an experiment. We're
planning enhancements this summer: regenerating our solr index with SolrMarc
2.0 (get spell checker, linked 880s, etc.), implement nightly syncs,
implement patron empowerment features (CAS + MyResearch module) and add
server redundancy; longer term we're planning to enhance the non-Roman
script functionality, search engine optimization, and add non-MARC metadata
(journal articles? Visual images? Government documents? We're still
debating) .
 
AR >> This is not an experiment for us. We have been in production since
August 2008. I have a development plan to increase functionality and will
have an updated version in place by August 2009.
 
TK >> We will/must have a production system based on Solr and VuFind. But
there are still some steps we must or want to take before going into real
production. About the end of this year we will have a first "production
service". By the way, maybe I should clearify a bit, what we are doing with
VuFind. We have an overview presentation (derived from a spontaneous
ligthning talk held at ELAG 09 a few weeks ago) at
http://www.slideshare.net/tillk/suchkiste-a-discovery-interface-for-dfg-nati
onallizenzen-1341949
 
GP >> I'd guess that installations put in place by Librarians who dabble in
tech are testing/experimenting and providing feedback in the hopes that v1.0
RC1 evolves in the direction they want before they go into production.
Places like VU and NLA with proper developers working on it are happy to
move to production on essentially a beta product. We are moving to
production as well, and consider this far more then an experiment.
 
2.  Is SOLR indexing satisfactory?
 
MT >>I think Solr is fantastic, and very well-suited to the sorts of things
that VuFind uses it for.  Faceting performance seems great under the latest
nightly builds, and where we've felt the need to be a little more
adventurous than regular search and faceting (with things like our browse
functionality, linking to full-text resources and incorporating
bibliographies from the Australian Dictionary of Biography) we've had no
trouble writing new Solr request handlers, so extensibility doesn't seem to
be an issue either.
 
GR >>I think so, from a practical point of view at least. It indexes 650,000
records for us in about an hour and a half, on a Win2003 box. That's fairly
remarkable.
 
DL >>I would say 'yes', though there's certainly a lot of customization we'd
like to do.
 
AR >>No. I've added a couple of fields. We are a consortia and I needed the
ability to allow each library to search just their records. I also have
other schema changes I use.
 
TK >>For our current use case it is. We have mostly "flat data". For use in
a general (german) library context there are a few issues that need to be
addressed: Our librarians love "hierarchische Aufnahmen" (don't know the
term in in English, it's the way they handle serials, multi issue works
etc.) and authority data. There are several ways putting that in flat data
structures like Solr (and most other indexing software as well) uses them
and they all have pros and cons and in the end none of those will be fully
satisfactionary for librarians :-).
 
GP >>I believe so. There are some adjustments to the way things were and
deficiencies identified so far, but many of those stem from a) not fully
understanding and tweaking the indexing and searching algorithms/options
enough and b) a user base that hasn't grasped the full implications of the
new interface yet (and our design of the interface needs to shift to
complement that too). Of course a) heavily influences b).
 
3.  how many staff are needed for vuFINDıs viable maintenance? for
developping/adding features?
 
MT >> Our team currently consists of three active members: one developer
(me) and two library/cataloguing/common sense experts.  None of us works
full-time on our catalogue--we all have other responsibilities that occupy
most of our time.  We generally add a few new features each month, along
with a fairly continuous stream of improvements behind the
scenes.
 
GR >>Depends, I think, whether you are committed to shrinking or expanding.
I was able to install and tinker with v1.0 RC1 in a few days, while carrying
on with my other work (and with some help from Greg). I don't see
development being part of what we would be doing in the future, and I think
that the two of us here could handle maintenance and tuning (as we do for
Unicorn).
 
DL >>We've had a project manager and programmer analyst each at 50% over the
past year, and smaller amounts of time allocated from usability, web design,
systems, and other kinds of librarians. I would say we could have used much
more (and we'll be ramping up this summer and beyond).
 
AR >>I devote at most 25% of my time toward this. I have 1 student who helps
with html and style sheets. I do have blocks where I am allowed to do
development(this summer being one)
 
TK >>We are about one and a half technical staff, I'd say. Not for keeping
our VuFind running, but for developing that whole project.
 
GP >>Very little here. Maintenance could be one part of one staff member's
job with the system in full production. We spend far more time doing
secondary tasks as a result of implementing the system. eg. the solr index
and facets highlighted just how bad portions of our marc collection were.
Cataloguers now have to spend time fixing that.
Development can consume as much time as you want to throw at it. For us it
is a small team doing things like coding (both php and html, because the
smarty templates allow that separation), quality testing, usability testing,
considering index/search algorithms, information literacy changes etc.
Coding or adding the feature is only a small part of the end-to-end process.
 
4.  do we want vuFIND to measure up to the ILS (Voyager, Aleph, III, etc.)
OPAC, or like it as an alternative, for its discovery tools?
 
MT >>I generally think it's a question of these ILS OPACs measuring up to
VuFind. I think VuFind has pretty much raised the bar in the world of OPACs.
 
GR >>Again, we're not speculating in these terms (VuFind tacked to the side
of Symphony, say). We think that VuFind couild be the public component of a
new kind of LAS, one with an emphasis on speed, economy and simplicity.
Sirsi hasn't been so bad, but the time is coming when we must part
 
DL >>As others have pointed out, VuFind is already superior to traditional
OPACs in certain ways: relevancy ranking is extremely powerful. Faceted
navigation is great, too, but there's a lot of tweaking that needs to be
done in our case. The traditional OPAC is currently better at integrating
authority files and displaying complex indexes (e.g., authors sub-arranged
by titles)
 
AR >>A few of our libraries used this as a full-time replacement for the
Aleph interface for the past year. There are quite a few more that plan on
using it in the coming year
 
TK >>Sure we want it to measure up. In many ways it is already better than
legacy OPACs.
 
GP >>I'd say 'measuring up' and being an alternative are the same thing.
<open_source_soap_box> And yes I think it does/will, and will in fact be
better then the commercial offerings. </open_source_soap_box>. With our
intended feature list for launch in a month or two we expect to at least
equal the functionality of our old OPAC, most likely surpass.
 
5.  what is the plan B at your institution for when the vuFIND guru leaves?
 
MT >>I imagine it's similar to the plan for when our Voyager guru leaves.
Library knowledge and IT skills are a rare mix, but I don't think that's a
problem that is particular to VuFind...
 
GR >>First, guru not needed. Second, we're leaving a paper trail which my
replacement (who will doubtless have superior skills and judgment) will be
able to follow without much bother. And third, we can always go back to
giving $100,000 a year to the vendor.
 
DL >>We're planning to continue running Voyager and VuFind in parallel.
Developments are moving so fast, that it's hard to predict the landscape 5
years from now, but in the mean time, VuFind gives us an excellent open
platform both for "production" and R&D.
 
AR >>Boss's problem
 
TK >>Ask my boss... I hope he has one... But it's the same with every
system. And I imagine, it's easier to find someone who is keen in current
web general web technology (as Apache, PHP, Javascript, AJAX, maybe some
Java...) than someone who knows legacy ILS technology...
 
GP >>Good question :) We have a few different people involved now so I think
it will alleviate the issue a bit. From my own perspective as a coder I want
to make sure that any features we implement are submitted to the community
which will let the Uni. continue operating with the community product.
 
6.  do we need an someone to co-work with Andrew on the installation
package? on keeping track of development, road maps?
 
GR >>It looks as if bodies have already thrust themselves into the breach,
in open-source fashion. No need to worry, I think.
 
DL >>Great idea. I think some of my Yale colleagues who are real programmers
are planning to contribute code. I hope to contribute in other ways (e.g.,
on integration of authority files, analysis/enhancement of non-Western
language functionality)
 
AR >>hmmm.... I definitely have differences in how I implemented VuFind and
I would love to add them. I have submitted patches that are ignored. I don't
like maintaining a completely different implementation. But how do we merge
things?
 
GP >>Andrew's been pretty open about all this stuff and given a number of
people privileges to contribute on par with him. Being one of those I'd say
I just need to get off my arse more. I get pretty focused on our internal
implementation. Tools like sourceforge and JIRA already allow us to
contribute to the planning as well as code. I shall endeavour to lighten
Andrew's load a little more over the coming weeks. Scouts honour. :)
 
7.  which collections, other than the catalog and OAI/repositories have we
added ? which API to other collections have we installed?
 
MT >>We've integrated other sources of data where it was not too difficult
to do so. As I mentioned, we've incorporated biographies from the Australian
Dictionary of Biography:
http://catalogue.nla.gov.au/Search/Home?lookfor=author:"Cook,+James,+1728-17
79"&iknowwhatimean=1
We also show possibly-relevant full-text resources (from Open Library, Hathi
Trust and Project Gutenberg) and our finding aids in our search results
pages.  VuFind and Solr are very malleable if you're willing to dig in.
 
GR >>None, yet.
 
DL >>So far we've only indexed our catalog MARC data. We've done some
testing of other record sets (e.g., visual image records).
 
AR >>By August I plan to include: Course Reserves See also references for
indexing purposes (not display) A second relevancy search that is based on
subjects headings instead of title/author
 
TK >>Do you think of adding distributed search to VuFind? Or fetching data
from other sources than the ILS and indexing it in VuFind?
 
GP >>We are only using the catalogue. Next on our list would be our ERMS.
It's not really a fully-fledged ERMS, but it's an open source
(http://researchguide.sourceforge.net/) system we've customised (very)
heavily in-house and intend integrating with VuFind. It's coming up on our
project list for branding re-vamp and feature list enhancement, so we've
slotted this integration in there as well. A number of us really liked the
Encore ERMS integration we saw in a demo a while back.  Anyway, those are my
two cents. I hope others contribute. I like the list Ya'aqov.
 
 
 
 


> 
> 
> 
> 

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 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
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager