I would just like to confirm from years of practical experience that Jonathan is right - this is hard technically. Not in principle, but the devil is in the details and they are all different, and often change. The very neat addition to the JHU catalog that Eric reported on that started this thread (https://catalyst.library.jhu.edu/catalog/bib_816990) is an example of what we call secondary searching and/or enrichment.
And it is available - in our commercial software (not a plug - we don't sell it, just noting that it is not the sort of thing to try yourself on any scale - it takes a lot of resources). Our software is incorporated in the offerings of a number of the ILS and content vendors. Admittedly almost exclusively for federated searching, but the problems are the same. And Jonathan enumerates them pretty well below. So, to answer Karen's question, it can be done if the ILS vendors make the functionality available, and the libraries configure it.
Peter
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Jonathan Rochkind
> Sent: Wednesday, June 15, 2011 10:34 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] JHU integration of PD works
>
> On 6/15/2011 10:55 AM, Karen Coyle wrote:
> >
> > I've been struggling with this around the Open Library digital texts:
> > how can we make them available to libraries through their catalogs?
> > When I look at the install documentation for Umlaut [1](I was actually
> > hoping to find a "technical requirements" list), it's obvious that it
> > takes developer chops.
>
> This isn't neccesarily un-fixable. I have plans to make it easier --
> it's totally possible to make it easier (largely because Rails, on which
> Umlaut is based, has gotten so much better at being easier to
> install/deploy things and have em Just Work), I just need to find time
> (that I'm having trouble finding) to make the changes.
>
> Eric, as well as Karen, also asked why no vendors seem interested in
> supplying a product like this -- may be a bit of a chicken and an egg,
> there may not be a market for it -- I have trouble explaining to people
> why Umlaut is actually really cool in the first place, even other
> libraries. Although these conversations help me learn new ways to
> talk/think about it.
>
> So, I can definitely make Umlaut easier to install and run -- but there
> are still going to be some technical craziness, involved with dealing
> with your local metadata in all it's local idiosyncracies, and dealing
> with matching it to 'remote' data in a way that meets local use cases.
> Like I said before, this is inherently imperfect, but that means that
> there are a bunch of choices to make about what imperfect trade-offs you
> want to make, and these inevitably have to do with the nature of your
> local (mostly cataloging) metadata, and the use cases you are supporting.
>
> Really, I'm not sure I have faith in our existing vendors to be able to
> do a good job with it -- this is a really complicated thing that Umlaut
> is trying to do, in the end. (from my experience; it didn't sound that
> complicated at first, but it ends up so. Trouble-shooting problems ends
> up being incredibly complex, because there are so many different systems
> involved, and a bug or bad metadata on any one can mess things up).
>
> So I guess what I'm saying is, if you're talking about Umlaut's approach
> -- it is a technically hard problem in our existing environment.
> ("existing environment" means our really bad local cataloging metadata,
> our multiple silo's of local metadata, and our pretty awful 'link
> resolver' products with poor API's, etc -- also the third party content
> host's poor metadata, lack of API's, etc. None of these things are
> changing anytime soon). So if you're talking about this approach in
> particular, when Erik asks "is it technical or is political" -- my
> experience with Umlaut definitely definitely says 'technical', not
> 'political'. I've gotten no opposition to what Umlaut's trying to do,
> once people understand it, only dissatisfaction with how well it does it
> (a technical issue).
>
> Jonathan
