 |
 |
Benjamin, I don't think anyone in this thread means to disparage DSpace. I agree that considering it commercial or proprietary is not accurate. DSpace is a turnkey solution, just as you said. My contention is that maybe we don't really need a turnkey IR solution. The technology needed for an IR is pretty simple: a place to put files, a way to discover files, a way to submit files, a way to describe files. It's the kind of thing that a university's in-house IT department could put together pretty easily with some web forms. I feel like we misrepresent the goals and requirements for having an IR if we promote the mentality that an IR requires an all-in-one, out-of-the-box solution that does every aspect of the IR workflow. Joshua Welker Information Technology Librarian James C. Kirkpatrick Library University of Central Missouri Warrensburg, MO 64093 JCKL 2260 660.543.8022 On Thu, Oct 26, 2017 at 9:50 AM, Benjamin Armintor <[log in to unmask]> wrote: > 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 > > > > > > > > > > > > > >