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