 |
 |
> 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. While certainly true on the surface, I think the real issue is going to be the maintainability and sustainability of such a project that is essentially already solved with a platform like DSpace. Rolling your own, in such a piecemeal way is likely to introduce loads of uncertain complexity. On Thu, Oct 26, 2017 at 8:06 AM, Jason Bengtson <[log in to unmask]> wrote: > Hi Josh, > > Yes and no. Certainly a lot of work has been done in separating the layers > of activity/service so that stacks could be built that would be uniquely > useful to a particular organization. Here at K-State we've done a little > investigating of using blacklight as our presentation layer and having it > interact with DSpace through its extremely useful RESTful API, but given > our other workload we haven't had much time to pursue that. We're seeing > variations on Blacklight, Hydra, and Fedora based stacks out there . . . I > haven't worked with those tools but I'd like to. However, all of these > approaches still seem to bundle a particular set of services together as an > IR. As others have pointed out, that certainly isn't essential, at least > hypothetically, as long as those services are served to users in a way that > either brands them together relatively seamlessly, or delivers the overall > service set of an IR successfully through other modalities. > > Best regards, > > *Jason Bengtson* > > > *http://www.jasonbengtson.com/ <http://www.jasonbengtson.com/>* > > On Thu, Oct 26, 2017 at 9:53 AM, Josh Welker <[log in to unmask]> wrote: > > > Jason, > > > > To your knowledge, have any libraries approached IR as a set of services > > divorced from a particular software platform? In my albeit limited > > experience, the IR and the platform used to host the IR are used almost > > synonymously. That is perhaps a barrier to entry for smaller libraries > who > > could do the service work of collecting objects, creating metadata, etc, > > but do not have the resources to invest in DSpace or Digital Commons. > > > > 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:27 AM, Jason Bengtson <[log in to unmask] > > > > wrote: > > > > > Josh, > > > > > > If you have funds (or you anticipate saving enough funds by ending > local > > > dspace support), a SAAS platform like what Tom suggests is worth > > > considering, so it's worthwhile to throw contentDM into the mix. I'll > be > > > honest; I never cared for it (the platform lacked flexibility to me), > but > > > we had it at one library I've worked at, and, if your needs are modest, > > it > > > might meet them. It's completely hosted, so the local hosting overhead > is > > > eliminated. There's also Digital Commons, although I've also found them > > too > > > limited for my uses in the past, and since their recent change in > > ownership > > > I would regard them dubiously. The thing I would be most careful with, > > for > > > both of those products, would be having a plan in place to migrate your > > > data out of them should circumstances change. I've heard of some > > challenges > > > on that front in Digital Commons (although I have no direct experience > in > > > that area, and things may have improved since I heard that feedback), > and > > > I'm not sure what the migration options look like in contentDM. > > > > > > Here at K-State we use DSpace, but we host our instance on Amazon Web > > > Services rather than through local physical or virtual boxes. My > systems > > > folks have been very happy with this move, which, while keeping us in > > full > > > control of our boxes, has eased some aspects of their management and > > > provided us with enhanced reliability. > > > > > > All that having been said, I really like what you, Jonathan, and Tom > have > > > said about looking at looking at an IR as a set of services and > > > 'interrogating' what that means and how those services might be > > delivered. > > > I think we, as a profession, need to do that for a variety of products, > > > including IRs and catalogs. > > > > > > Best regards, > > > > > > *Jason Bengtson* > > > > > > > > > *http://www.jasonbengtson.com/ <http://www.jasonbengtson.com/>* > > > > > > On Wed, Oct 25, 2017 at 1:51 PM, Josh Welker <[log in to unmask]> wrote: > > > > > > > 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 > > > > > > > > > >