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