At the recent OCLC Members Council meeting there was some strong support voiced from the floor during OCLC management's general presentation for such an API, but it is not clear where OCLC stands on the matter. The answers from OCLC officers about this were hedgy, though they hinted at some sort of development in progress.  Others may know more.   They (OCLC) are clearly focused on the market position of WorldCat Local and a robust and extensive API might undercut that -- but probably only with one market sector.  We need to keep pressing the issue.

*********
Joe Lucia
University Librarian
Villanova University
610-519-4290


-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Roy Tennant
Sent: Friday, November 09, 2007 2:11 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] [Fwd: [NGC4LIB] A Thought Experiment]

I agree with Jonathan's points below, and would suggest that a robust enough
WorldCat API should be sufficient to allow any library that has the desire
and the capacity to integrate everything available there with whatever else
they wish.
Roy


On 11/9/07 9:42 AM, "Jonathan Rochkind" <[log in to unmask]> wrote:

> Good points.
>
> "If I wanted a drop-in in one-size solution for resource discovery, from
> a "corporate" supplier, for instance, I'd have to say that WorldCat
> local looks pretty darn interesting. But the kind of locally-iterable,
> modular, extensible toolkit that I think positions libraries well for
> experimentation and innovation."
>
> There's another important reason this "kind of locally-iterable modular
> extensible toolkit" is absolutely vital, in addition to "positioning
> libraries well for experimentation and innovation." It's because we
> absolutely need to functionally integrate our various _different_
> products from differnet vendors. Even if you go with WorldCat Local, you
> still have many products from other vendors that you'd really like it to
> integrate with (both on the end-user-interface, and on the backend staff
> metadata control and other interfaces).  The path to accomplishing this
> is with that kind of "modular extensible toolkit"---dropping in an
> ostensible "one-size solution" often only creates more problems with
> lack of integration.
>
> We want "loosely coupled", but we're currently often stuck with "not
> coupled at all", which causes no end of problems.
>
> Jonathan
>
>
> Joe Lucia wrote:

--