 |
 |
I guess I don't understand why you'd prefer SRU to an API. The ideal (in my mind) is that by having the API available, you have your cake and eat it too. Can a SRU (or OpenSearch or OpenURL or whatever) service not be built on top of the API? However, if there was no API available, only a SRU service, wouldn't you complain about something else that SRU didn't do? I don't know, personally I don't think it's the OL or IA's job to build interfaces that they don't personally need. I am much more interested in them building functionality to the OL itself. If a SRU interface is important enough to somebody, they'll build one (or pay IndexData to do it). If the foundation is there, the standards can be built upon them. -Ross. On Thu, May 8, 2008 at 10:59 AM, Jonathan Rochkind <[log in to unmask]> wrote: > 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 >