I think it's worthwhile making a distinction between an open API and a
closed one. That is, most product APIs require you to have purchased the
product to gain access. So I don't see an API as undercutting a market, but
rather increasing the potential market space to include some who are only
interested in API access.
However, there may be a question of development resources and my guess (not
being close to it) is that the development resources for WorldCat Local are
probably focused on industrializing what is admittedly still a very new
product. At least, that's what I would do. None of this precludes the
opportunity to eventually offer API access to WorldCat Local customers in
addition to "native" access.
On 11/9/07 11:24 AM, "Joseph Lucia" <[log in to unmask]> wrote:
> 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
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Roy
> 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.
> 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.
>> Joe Lucia wrote: