 |
 |
This is a derail, but I feel obligated to offer a different representation of DSpace. DSpace is a full-stack IR product (without a dependency on Fedora, for example), written principally in Java; it is also an Open Source project: https://github.com/DSpace/DSpace principally funded by research university libraries: http://duraspace.org/all_members/dspace ... with a publicly available governance structure: http://www.dspace.org/introducing http://www.dspace.org/governance ... whose contributors are largely employed by non-profits: https://wiki.duraspace.org/display/DSPACE/DSpaceContributors ... as is the Community Advisory Team: https://wiki.duraspace.org/display/cmtygp/DSpace+Community+Advisory+Team It's worth noting that while there is commercial hosting for DSpace: http://www.dspace.org/service-providers ... some of it is also (as Tom mentioned) non-profit hosting at DuraSpace: http://dspacedirect.org/ In short: While I don't use DSpace, I also don't think characterizing it as "commercial proprietary" is accurate in any but the most unhelpfully expansive definitions of both words together. It's a community-driven project, publicly guided by a mix of non- and for-profit service providers and installers, whose development efforts are hosted at DuraSpace. It's not commercial or proprietary in a way that distinguishes it from Samvera-née-Hydra, and (if I can briefly editorialize) it's an excellent solution for institutions that prefer to work with a hosting provider with an out-of-the-box product. - Ben On Thu, Oct 26, 2017 at 10:04 AM, Jonathan Rochkind <[log in to unmask]> wrote: > > 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 > > > > > > > > >