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.
>
>
>
>
|
