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