 |
 |
I see a whole lot of "not invented here" syndrome from IA, honestly. They seem to want to re-invent everything themselves, rather than try to use existing conventions. Even if they come up with something slightly better than SRU, is it worth the pain to developers who would like to implement client code, and can't use their existing SRU client code to do so? Seems to me, and I tried to tell Brewster this when talking to him after his keynote at the conference, if the IA is serious about trying to get external developers to engage with IA stuff (which the IA folks at the conf mentioned was indeed a goal of theirs), then there are certain things the IA should put their resources into in order to facillitate and encourage this. Mainly: 1) Documenting their interfaces. Right now as far as I can tell everything is available on a "if you happen to notice it's there and then reverse engineer it yourself, and who knows if it might change and break your code" basis. I don't really have time for that. 2) When they make machine interfaces, use existing conventions and standards in use by the community of developers they want to target. [If the community of developers they want to target is not neccesarily library programmers, and that community they wish to target doesn't in fact use SRU at all right now, I suppose that might be fair. I dunno]. 3) Best of all, actually talk to people in this community of developers _before_ developing their stuff, to see what their needs are. "User centered development", right? You don't produce a giant piece of software without talking to those who you want to use it, and then wonder why they don't seem interested in using it. When I bring this up, I'm generally told "Oh, all that is YOUR responsibility. If you wanted it bad enough, you'd deal with it. We just make it available, the rest is up to you." That's fine, like I said, they can prioritize their resource allocation however they want. But they shouldn't be so surprised when they're having trouble getting external-developer-community adoption of their stuff when this is their attitude. That's what I would have said if I had been able to make the meeting last week. So maybe they're changing their approach a bit with regard to some of these things. They did meet with library developers, at least. I don't see much evidence of 1 or 2 yet though. Jonathan Eric Lease Morgan wrote: > On Mar 7, 2008, at 8:22 AM, Emily Lynema wrote: > >> Also, there was discussion about building an Open Library API (to >> enable >> some cool integration with wikipedia), and I suggested a that >> libraries >> using an API would want the search results to include information >> about >> whether the title has a digitized copy. So I would hope the service >> that >> you're envisioning is something that would be provided by an Open >> Library API (but we don't know when that might come about). > > > I sat in on this discussion at the Meeting. It was driven by a > consultant-type who is working for Wikipedia. His desire was to > create an API that allowed people to authoritatively and consistently > cite content from Wikipedia to Open Library. Ultimately, this API > would allow a person to: > > * search Open Library via word, phrase, or key > * return list of hits > * select item > * create "citation" > * insert citation into Wikipedia article > * regularly check the validity of the citation > > Regarding the first two items I tried to suggest the use of SRU. > Regarding the last item, I tried to suggest OAI. In both cases I was > shot down. "Too complicated", at the same time, they were outlining > API's that had the *exact* functionality of SRU and OAI. I sort of > saw his point. "Library" protocols are usually overly-complicated, > yet he was totally unaware of either protocol. I also think he was > suffering a bit from the Not Invented Here Syndrome. We also got into > a bit of a religious war regarding the definition of REST-ful Web > Services. > > In the end we talked a lot about JSON and a tiny bit about ATOM. > > -- > Eric Lease Morgan > University Libraries of Notre Dame > -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu