 |
 |
In general, I think we all agree that standards should be used where possible---a proliferation of APIs that our client software needs to talk to leads to much harder to maintain client software than re-using APIs. However, if the standards are truly too hard to work with, sometimes the 'correct' decision is indeed to design a new one. However, I guess some of our concern is that from observation, it kind of looks like the OpenLibrary team didn't even consider SRU, it wasn't considered and dismissed based on technical evaluation, but rather ignored from the start. This is rather distressing, especially for a project with as ambitious goals as OpenLibrary. For the project to be successful (which most of us observers want very much), it's very important to understand the existing technology landscape and how to fit into it. Now, to be sure, it may be that the existing _library_ technology landscape is not particularly of interest to OpenLibrary, that they are more interested in connecting with the larger technology world and see library technology infrastructure as a tiny and irrelevant backwater. :) That's up to them to decide this sort of strategy, and may be valid, and would justify simply ignoring technology which is _mainly_ (but not exclusively) adopted by the library world---but would of course be distressing to us in the library technology world hoping we can connect to the OpenLibrary project. It's also nice to say "it's open source, if you want it you can add it." And it DOES matter that it's open source, and this is HUGELY good. But most of us are already working on multiple open source projects, many of which _we_ are trying to recruit people too also. It's a small pond of library developers, and a big need for open source library software. If OpenLibrary becomes as succesful as we all hope, then it will attract open source contributions, from library developers and others. If the OpenLibrary team wants to _get_ it to that succesful point, than in my view it would be wise to spend OpenLibrary resources on components that will make it easy for library and other developers to interface with it. I'm sure they agree--which is why it has an API at all, rather than just leaving it API-less and saying "hey, it's open source, if you want one add one!". That would obviously be counter-productive to the goals. Again, I don't know enough about SRU to to know if it's suitable. I've certainly encountered other library 'standards' that are over-engineered and hard-to-adopt enough to justify abandoning them and creating something new. All I'd hope is that the OpenLibrary team actually _knew about_ SRU and gave it a serious evaluation---it is adopted enough to justify that. It's also worth saying that when you DO abandon an existing standard to write something new---it's a lot more productive to building a sustainable tech infrastructure if you try to make your 'something new' at least a potential de facto standard, rather than a custom thing only for your product. Jonathan Walker, David wrote: >> Nobody in the *library world* uses >> it, much less non-libraries. >> > > Ironically, I was just checking email in between using the WorldCat SRU server. > > In addition to the systems Rob mentioned, there are also article databases like JSTOR and Springerlink that implement SRU, and every metasearch system in use in libraries today consume SRU web services. > > But I think the folks at OpenLibrary should implement an OpenSearch interface. I mean come on! OpenLibrary, OpenSearch. A match made in heaven! ;-) > > --Dave > > > ------------------- > David Walker > Library Web Services Manager > California State University > http://xerxes.calstate.edu > > ________________________________ > > From: Code for Libraries on behalf of Casey Durfee > Sent: Wed 5/7/2008 1:12 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Latest OpenLibrary.org release > > > > SRU is crap, in my opinion -- overengineered and under-thought, > incomprehensible to non-librarians and burdened by the weight of history. > The notion that it was designed to be used by all kinds of clients on all > kinds of data is irrelevant in my book. Nobody in the *library world* uses > it, much less non-libraries. APIs are for use. You don't get any points > for idealogical correctness. A non-librarian could look at that API > document, understand it all, and start working with it right away. There is > no way you can say that about SRU. > > Kudos to the OpenLibrary team, whatever the reason was, for coming up with > something better that people outside the library world might actually be > willing to use. > > > On Wed, May 7, 2008 at 12:55 PM, Dr R. Sanderson <[log in to unmask]> > wrote: > > >> I'm the only non-techie on the team, so I don't know that much about >> >>> SRU. (Our head programmer lives in India, and is presumably asleep at >>> the moment, otherwise I'd ask him!) Is it an interface that is used >>> primarily by libraries? We are definitely hoping that our API will be >>> used by all kinds, so perhaps that's the reasoning. >>> >>> >> It's designed to be used by all kinds of clients on all kinds of data, >> but is from the library world so perhaps the most well defined use cases >> are in this arena. Have a look at: >> http://www.loc.gov/standards/sru/ >> >> But this is an Open Source project, so if anyone would like to volunteer >> >>> to build an SRU interface... you can! Please do! :-) >>> >>> >> I feel a student project coming on. :) >> >> Rob >> >> > > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu