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