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