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