> I don't know about commercial proprietary solutions like DSpace,
My mistake, DSpace is of course not commercial or proprietary! Sorry!
I actually know almost nothing about DSpace and have no experience with it,
I should have just said "I don't know about Dspace specifically". I think I
got it confused with ContentDM. Sorry!
On Thu, Oct 26, 2017 at 2:04 PM, 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-reposit
>> ories> 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-partn
>> ership-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
>> >
>> >
>>
>
>
|
