 |
 |
> As another repository person, with a tidal wave of headache-inducing migrations from homegrown systems approaching me Alas, using established systems does not neccesarily protect you from headache-inducing migrations. I don't know about commercial proprietary solutions like DSpace, but hydra/samvera sufia/hyrax implementers certainly have had their fair share of headache inducing migrations. I'm curious what prompted your migrations from homegrown systems, and what made them headaches. Were you moving from a homegrown system you no longer wanted to maintain, to a proprietary or otherwise common solution? Jonathan On Thu, Oct 26, 2017 at 1:46 PM, Brandon Weigel <[log in to unmask]> wrote: > Hi Josh, > > As another repository person, with a tidal wave of headache-inducing > migrations from homegrown systems approaching me, I would like to second > the notion that a homegrown approach seems like a lot more work and more > difficult in the long term. Perhaps another approach would be worth > exploring? > > An option that helps limit the work and the costs is to join a > consortial/collaborative IR with other institutions — that is, if such a > thing is available to you. Collaborative IRs are becoming quite the thing > in Canada — Arca <http://arcabc.ca/> in BC supports 14 (and growing) > small-to-medium colleges and universities <http://arcabc.ca/arca- > repositories> for very low annual costs, and members have a robust, > attractive, fully-functional Islandora repository with many committing > between zero and one FTE to the job. Arca is coordinated by BC’s > post-secondary library consortium, BC ELN. The Ontario Colleges Library > Service is working on the same thing <https://www.ocls.ca/services/core>. > > If there’s no consortium you can work with that is doing that sort of > thing (or could be persuaded that this sort of thing would be valuable and > worthwhile), it could be done on a smaller scale, by exploring partnerships > with other universities to share an IR. Another BC example - Vancouver > Island University and Royal Roads University share a DSpace repository < > http://www.royalroads.ca/news-releases/post-secondary- > partnership-showcases-research-0>, and do it very cost-effectively. Two > institutions sharing a repository might have to compromise a little on > specific features/customizations, but they gain a lot of value for nearly > half the work. (Some extra governance work to manage the sharing, of > course, but it’s not that bad.) > > Such partnerships may or may not be available to you, but it could be > worth investigating. > > Cheers, > > Brandon Weigel > Coordinator and Arca Technical Lead > BC Electronic Library Network > Phone: 604.401.1794 > Email: [log in to unmask] > Web: https://bceln.ca, http://arcabc.ca > > > On Oct 25, 2017, at 9:33 PM, Tom Cramer <[log in to unmask]> wrote: > > > > Josh, > > > > None of those pieces is an IR, but do you think > > that when taken as a whole they could comprise an IR? > > > > Yes. I think it’s very healthy to think of the IR as a set of services, > rather than a single software product. And I really like the idea of using > your catalog as the discovery environment. (That’s what we do…) That said, > I have to say that... > > > > a. your approach doesn’t sound like less work overall (and in fact it > might be more?) > > b. it raises the question of how your institution might support this > over the longterm > > > > It might still be viable, especially if it jibes with your institutional > technology strategy and staff capacity. > > > > Have you also considered moving to a cloud IR, such as DSpaceDirect< > http://dspacedirect.org/> or hosting from Atmire<https://www.atmire.com/ > services/dspace-hosting>? > > > > - Tom > > > > > > > > On Oct 25, 2017, at 2:16 PM, Josh Welker <[log in to unmask]<mailto:welker > @UCMO.EDU>> wrote: > > > > Hi Bryan, > > > > I agree that a repository is more than documents, and in this model we > > would still do metadata, indexing, etc. It would just be handled by a > > different piece. Instead of having one system that does it all (like > > DSpace), we'd use the library catalog for metadata and indexing, backup > > tools for preservation, and this homegrown solution just for hosting > > publicly accessible files. None of those pieces is an IR, but do you > think > > that when taken as a whole they could comprise an IR? > > > > Joshua Welker > > Information Technology Librarian > > James C. Kirkpatrick Library > > University of Central Missouri > > Warrensburg, MO 64093 > > JCKL 2260 > > 660.543.8022 > > > > > > On Wed, Oct 25, 2017 at 3:59 PM, Bryan Brown <[log in to unmask]<mailto: > [log in to unmask]>> wrote: > > > > Josh, > > > > > > Theres nothing wrong with what you are describing if its all your > > institution needs, but I would be careful about promoting that as an IR. > An > > IR is much more than a bunch of documents. The metadata modelling, > > preservation features and indexing that you want to leave out are what > > makes it a repository. Also, the infrastructure you are describing may > lack > > flexibility in the future if you decide you want to add new features to > it. > > > > > > Bryan J. Brown > > > > Repository Developer > > > > Technology & Digital Scholarship Division > > > > Florida State University Libraries > > > > ________________________________ > > From: Code for Libraries <[log in to unmask]<mailto: > [log in to unmask]>> on behalf of Josh > > Welker <[log in to unmask]<mailto:[log in to unmask]>> > > Sent: Wednesday, October 25, 2017 2:51:34 PM > > To: [log in to unmask]<mailto:[log in to unmask]> > > Subject: [CODE4LIB] Lightweight IR infrastructure > > > > We're a mid-sized university library (10,000 fte) trying to get an IR off > > the ground to showcase student and faculty research. We've had a DSpace > > instance running for several years, but we use so few of its features > that > > DSpace ends up being more trouble than it is worth. In particular, it's > > very frustrating to deal with metadata editing, file management, the > Handle > > URL system, and HTML/CSS theming. > > > > I am considering leaving the DSpace model in favor of our "IR" just > being a > > glorified FTP site that MARC records in our catalog can point to. I might > > even build a tiny frontend using some scripting language to add IP > > authentication, URL redirect stuff, or a Google Scholar interface, but > > that's really it. No metadata modelling, no preservation features, no > > indexing. > > > > Does anyone have experience using a very small, file-based (as opposed to > > database-driven) application as a foundation for an IR? Are there any > > problems I should anticipate? > > > > Joshua Welker > > Information Technology Librarian > > James C. Kirkpatrick Library > > University of Central Missouri > > Warrensburg, MO 64093 > > JCKL 2260 > > 660.543.8022 > > > > >