 |
 |
Hi Kelsey, Good luck! I’m not sure I’m prepared to comment on the suitability of Drupal for your purposes, but as someone who was recently at a small, scrappy institution, we found that we were able to get affordable hosting for an Islandora instance from LYRASIS; if cost is the main issue, you might try looking into their service. For what it’s worth, I’ve been discovering over the past few years (Ha! As though I’m the only person who ever figured this out) that even just handling the metadata for a repository is a lot more work, probably by an order of magnitude than I expected. So I guess I’d say, whatever you choose, be gentle with yourself? I am super excited about the possibilities of Hydra-in-a-Box (although we’re an Islandora shop ourselves at present), but I haven’t kept up enough to know what the timeline for *ready* is, so that might be a consideration for you as well. Like I said, good luck! Let us know what you end up with, Megan On 5/5/16, 8:32 PM, "Code for Libraries on behalf of Tom Cramer" <[log in to unmask] on behalf of [log in to unmask]> wrote: >Kelsey, > >If you’re looking for a web-based app where you can capture metadata, store files, and find and retrieve them again, Drupal seems totally workable. But I think the issue that might concern me most about using Drupal for a document repository is that it’s relatively fluid. In my experience document repositories last a good decade or more and migrating them is a pain, and not undertaken lightly. Drupal evolves relatively quickly, and persistence isn’t one of it’s focal points. (This is why Fedora is Islandora’s special sauce, from a Drupal perspective.) > >If you are interested in Hydra-in-a-Box, there will be some (doubtless smashing) presentations and maybe even a demo at Open Repositories<https://www.conftool.com/or2016/index.php?page=browseSessions&search=hydra+in+a+box> next month. There is much work left to do, but it’s beginning to take shape. > >In addition to the videos Mark cited, we’re sending regular updates to the Hydra lists; you might find [log in to unmask]<mailto:[log in to unmask]> or [log in to unmask]<mailto:[log in to unmask]> worth joining. (Cary—you might also like to join if you’d like to keep current. We have a good set of discussions and information exchange going on with many in the Islandora community.) > >Best, > >- Tom > > > > > >On May 5, 2016, at 5:08 PM, Mark A. Matienzo <[log in to unmask]<mailto:[log in to unmask]>> wrote: > >Hi Cary, > >Hydra-in-a-Box has already started development as of the last week of >March. To that end, we've released demo videos on a weekly basis at the end >of each of our sprints, which we've posted to YouTube: >https://www.youtube.com/playlist?list=PLDs5eqwVjfb7dIA6KWffdUlSASYMtZQcL > >Best, > >Mark A. Matienzo <[log in to unmask]> >Project Manager, Hydra-in-a-Box >Director of Technology, Digital Public Library of America > >On Thu, May 5, 2016 at 7:15 PM, Cary Gordon <[log in to unmask]> wrote: > >To be clear, Hydra-in-a-box is in the planning stage at this point, and >has not AFAIK, begun development. While planning to offer a much friendlier >install than earlier incarnations of Hydra, is still a Fedora-based >solution, and won’t come with a Fedora-expert-in-the-box. It will address >metadata management issues, but exactly how that will happen is not yet >defined. > >The good news is that both Islandora, the tool I work with, and Hydra will >be moving to Fedora 4, and that will make them both easier to use in many >respects. In fact, they should become interoperable. > >Thanks, > >Cary > > > > >On May 5, 2016, at 2:38 PM, Kerchner, Daniel <[log in to unmask]> >wrote: > >Although you might not have the level of technical expertise required to >support Fedora-based applications in their current incarnations, you >might >want to keep an eye on progress on the Hydra-In-A-Box project. >Hydra-In-A-Box is meant to provide the benefits of Hydra but would >actually >be easy to install (i.e. not requiring a software developer on staff) >and/or can be used as a hosted solution. I think a major driver is to >provide a solution that is just as much an option for "small, scrappy >institutions" :) > >http://hydrainabox.projecthydra.org/ > >- Dan > > > > > > > >*Dan KerchnerSenior Software Developer, Scholarly Technology GroupThe >George Washington University LibrariesGelman Library2130 H Street, >NWWashington, DC [log in to unmask] <[log in to unmask]>* > > >On Thu, May 5, 2016 at 5:15 PM, Kelsey Williamson < >[log in to unmask]> wrote: > >Hi code4lib, >I was hoping to get some input on this. My small, scrappy institution is >considering using drupal as a repository, primarily via the Biblio >module. > >Obviously this is not ideal, but for reasons I won't get into, our tech >environment won't support ePrints or dspace, and hosted services are >not an >option either. We do not really have the level of technical expertise >required to support any fedora-based applications, and cannot hire any >additional support. There's a chance existing staff could stretch to get >there, but it would not be a pretty process. > >With all that said, do any red flags come to mind? I looked through both >code4lib and drupal4lib listserv archives and poked around google, but >didn't find much evidence of anyone else using drupal in this way. Seems >suspicious. While my gut tells me it's a bad idea (metadata! standards! >preservation!), I'm having trouble articulating this to my group in a >way >that sticks, because using Biblio would be easy. I would appreciate >hearing >any other thoughts or opinions on this. > >Thanks! >Kelsey > > >