OCLC Developer Network

Cooperative Platform News Archive

Syndicate content

Check out presentations and information from our panel at CIL!

Last month I had the pleasure of participating on a panel with Jason Griffey from University of Tennessee Chattanooga and Eliot Polak from Norwich University on Plugin and Play Apps. We talked about how the WorldShare Platform can enable libraries to build and share cool custom apps with one another. Jason talked provided an intro to the concepts of platforms and their power.

Six new Web services available through the OCLC WorldShare Platform

You've probably heard about the OCLC WorldShare Platform, officially launched in December—the framework, architecture and infrastructure that Karen described in previous posts. Now I am pleased to say, there are SIX (6) new Web services available through the Platform for you to experiment and innovate with, in this new environment.

Building the New York Times Bestsellers application

The last prototype application I built was the New York Times Bestseller application. This application is a riff on one of the potential Platform applications demonstrated at last year's ALA. The "Bestseller App 2.0" allows a library to select a given New York Times Bestseller list and see which items from that list the library doesn't currently own. Then a user can select which of these items should be purchased and how many copies should be purchased. An Amazon cart with these items is then created as is a WMS order.

Building the Amazon Order Application

The first application that I built off of the prototype WMS Acquisiton web service was the Amazon Order application. As I've explained in my basic overview of the Platform prototype application, the purpose of the Amazon application was to take an existing WMS order and send that order to Amazon, creating a shopping cart.

The first thing that the application does is generate a form screen which allows the user to input and existing WMS Acquisitions Purchase Order number.

Building the Alibris Application

The purpose of the Alibris application is to allow a library to upload a tab seperated file of titles available in a particular topic area from Alibris, see which titles the library does not own, and then select titles for purchase. The first thing the application does is generate a form which allows a user to input their library's OCLC symbol and upload a tab seperated (TSV) file to the server

 

Comments

A couple of suggestions

This looks like an interesting application, with potential for small libraries.  A few comments & suggestions for minor fixes, before it goes to production:

 

1) Why does the application run on the user's server, instead of on OCLC's?  This seems like a service OCLC could offer.  Would target users for this application have the technical expertise to install/maintain/secure it themselves?

2) The app asks for a TSV file.  There should be a "help" link the user can click to learn about the format required (what columns, in what order).

3) Typo: should be "separated".

Thanks --Andy

Thanks for the comments and

Thanks for the comments and suggestions. I've tried to answer your questions below

The application is designed to run on a user's servers because it was built from the perspective of a developer in an individual library. The idea was to showcase what a developer in an individual library would be able to build and potentially share the code with others via something like Github. That being said I certainly will pass along to the groups that consider new products and services internally the idea that OCLC could offer a compare this spreadsheet of stuff with a library holdings service.

Yes, the app could have some sort of indication of how to format the TSV file. As what is being consumed is an Alibris specific format that they use with their customers, this didn't go into the original planning of the application and is kind of wrong for the application is originally conceptualized. It can't take any old TSV nor should it. It has to be a TSV representing Alibris' current inventory for a given subject area. Alibris sends these spreadsheets to libraries all the time and I didn't want to ask users who had a these proprietary spreadsheets to have to do much fiddling with them to use this app. As a result the app is meant to just deal with THAT kind of spreadsheet which has not just the book metadata but also the Alibris pricing, condition and inventory numbers. Ultimately the app needs all the Alibris specific data to get the job done and a more generalized TSV wouldn't have that information.

That being said, some potential refactoring is going on with this application right now. Some of that has to do with the fact that I'd like to provide a more generic, compare this spreadsheet of stuff with a given library's holdings application, which would potentially not need to have the data submitted with particular columns. Another possibility would be to fork the code and refactor it to provide a generic create an order from a TSV tool as well. A final option would be to build a application that consumes a file of metadata for items, goes out and provides pricing and availability information from several supplies and then lets the library staff person select what should be ordered. The beauty of this model is that the application could be designed to be smart enough to create seperate orders within WMS for each vendor being ordered from.

Ultimately, there are lots of possibility. My hope in creating this was to get people thinking about the possibilities that having these types of web services available presents and to demonstrate some practical applications of what could be built.

Building three apps to demonstrate the OCLC platform

For the last three months I've been working on the project of building three applications to demonstrate the OCLC cooperative platform. The intention was for any of these applications to be installed easily in the WMS staff interface as potential part of the Acqusitions workflow. The ideas for these apps came out of a brainstorm session I had with my boss and staff who work on the Acquisitions portion of WMS.

Learn more about the cooperative platform: Infrastructure

In the second post on the cooperative platform follow up, I talked about the architecture of the cooperative platform, explaining the virtues of OpenSocial and Apache Shindig. Now I’ll give you a quick run down of the third component, the infrastructure. As a review, the three components for the cooperative platform:
• a framework to make data and business logic more available from OCLC's services

Learn more about the cooperative platform: Architecture

In my last post, I talked about the framework of the cooperative platform and how the framework will make data and business logic more available from OCLC services. Now, I’ll go into the architecture.

Learn more about the cooperative platform: Framework

In her blog post last week, Kathryn introduced the cooperative platform and shared news about how this new environment--and lots more OCLC services-- will help libraries to create innovative solutions to everyday needs. Alice compels me to mention that "cooperative platform" is simply the working title but not it's official name. Now, I'd like to follow up on that post with more information about the cooperative platform architecture and technology.

This one’s for you: Introducing the OCLC Cooperative Platform

At the recent American Library Association conference, held in late June in New Orleans, I had the privilege of presenting — with a few of your Developer Network colleagues — on OCLC’s new Cooperative Platform.

What’s that, you ask?

Follow the OCLC Developer Network:

The OCLC Developer Network supports the use of OCLC Web Services—a set of tools and APIs that expose data and services for WorldCat and our member libraries and partner institutions or companies. learn more »

© 2010 OCLC Domestic and international trademarks and/or service marks of OCLC Online Computer Library Center, Inc. and its affiliates


Powered by Drupal, an open source content management system