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

Reply via email to