Hi Ross and Amy,
Thanks for your replies - ILL software was in fact our first thought (channeling everything through ILLiad) but we wanted to apply automation and metadata enrichment more efficiently than we could within the available web interface.
As for multiple requesting, Ross, you're right, that's the weird part. It's really driven by special collections - we want a user to be able to collect as many diverse objects as they'd like and review them *before* they submit (partly to have an opportunity to make decisions given request limits and restrictions information not available in the finding aid). These then need to be routed to various physically (and administratively) separate special collections units. For most special collections this aggregation would be handled in the finding aid, but we have some that are cataloged in the ILS and requested through the OPAC which does not natively handle any type of multi-requesting, necessitating this function in the requesting interface. As for why multi-requesting - it was in the project requirements for two separate projects and requested by another unit in GC Access Services around the same time so it seemed like the resolver + cart for physical items was the most reusable approach.
Hope this informs a bit about why it might be useful in our case?
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Ross Singer
Sent: Friday, March 6, 2015 2:10 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Get It Services / Cart
Actually it doesn't seem like a terribly obvious use case: how would a user be in a position to send multiple things for enrichment? What happens after they're enriched?
Ümlaut seems kind of a perfect intermediary for this, but you'll need to work out the before and after (mainly the use case!)
On Friday, March 6, 2015, Smith, Steelsen <[log in to unmask]> wrote:
> Hi All,
> I'm new to this list, so if there are any conventions I'm ignoring I'd
> appreciate someone letting me know.
> I'm working on a project to allow requests that will go to multiple
> systems to be aggregated in a requesting interface. It would be
> implemented as an independent application, allow a "shopping list" of
> items to be added, and be able to perform some back end business logic
> (availability checking, metadata enrichment, etc.).
> This seems like a very common use case so I'm surprised that I've had
> trouble finding anyone who has published an application that works
> like this - the closest I've found being Umlaut which doesn't seem to
> support multiple simultaneous requesting (although I couldn't get as
> far as "request" in any sample system to be certain). Is anyone on the
> list aware of such a project?
> Steelsen Smith
> Fulfillment Systems Specialist
> Enterprise Systems Group
> Yale Library IT