June 2009 Archives

If you're headed to ALA Annual, the American Library Association conference 2009 in Chicago in a couple of weeks, we'd love to see you at the OCLC Developer Network luncheon and the OCLC blog salon. You're invited.

OCLC Developer Network Luncheon
Sunday, July 12
12:00 noon-1:30 pm
InterContinental Hotel, Toledo Room 505 North Michigan Avenue.

Join fellow developers and tech enthusiasts for an informal luncheon. Hear an update about the OCLC Developer Network, the latest Web services and APIs available from OCLC (including authentication services like EZproxy). Brainstorm about new ways to enrich your users' experience with additional data. You'll need to register for it, please.

If you're planning to attend and would like to show off your latest code, drop us a note!

OCLC Blog Salon
Sunday, July 12
5:30-8:00 pm
Chicago Hilton, Boulevard Room C (2nd floor) 720 South Michigan Avenue.

OCLC bloggers have joined forced with the OCLC Developer Network to host the Blog Salon this year. The Shanachies are going to be the special guests, (along with Michael and Jenny) at the LITA President's Program at ALA this year, and then we'll continue the fun at the OCLC Blog Salon.

So the Shanachies (Erik Boekesteijn, Jaap van de Geer, Geert van den Boogaard) will have all their video equipment at the Blog Salon--so come out and meet them and other like-minded bloggers, tweeters, 'tubers, coders, developers and generally anyone interested in tech/social/outreach/frivolity. You may be in the next Shanachie movie!

The Blog Salon is sponsored by OCLC bloggers (official and less so) and the OCLC Developer Network.

Note: even if you're not planning to attend ALA, you can still participate in the Developer Network luncheon via WebEx. I'll post information on how to join in, closer to time.

The Third OCLC Research Software Contest is well underway, but there is still time to enter. See the contest details for complete information. The winning entry will receive $2,500 and an expenses-paid trip to OCLC headquarters in Dublin, OH. Entries are due by the end of June and the winner will be announced before the end of July.

Judging criteria includes:

* Value to libraries, archives or museums
* Use of OCLC services or data
* Originality
* Clean architecture and design

The judges are:

Kevin Clarke, Appalachian State University
Karen Coombs, University of Houston
Thom Hickey, OCLC
Tod Matola, OCLC
Jonathan Rochkind, Johns Hopkins University
Ross Singer, Talis (and the winner of the Second OLC Research Software Contest)
Roy Tennant, OCLC

Don't let this opportunity pass to pick up a cool $2,500 and the chance to have your coding prowess recognized!
Roy Tennant
OCLC Research

We added a few new features to xID service:

- xISSN now supports ISSN-L and RSSURL field, such as
http://xissn.worldcat.org/webservices/xid/issn/1095-9203?method=getMetadata&fl=issnl,rssurl

ISSN-L data is obtained from ISSN agency, and rssurl is obtained from ticTOCS. xISSN also adds values to both data set, for example, xISSN automatically adds RSSURL to all ISSNs in same group.

- xOCLCNUM now supports OCLC workid, such as:
http://xisbn.worldcat.org/webservices/xid/oclcnum/55847258?fl=owi

And you can query by workid as well:
http://xisbn.worldcat.org/webservices/xid/owi/owi718389
I highly recommend using "owi[0-9]" in its whole format when you came upon workid, this will be very helpful for identifying workid from any web pages and facilitates interoperability and mashup.

For more information, please check xISSN and xOCLCNUM API.

Marieke Guy of JISC (UK) has released the long-anticipated "Good APIs" study, in two parts:

• Report 1: JISC Good APIs Management Report: "a background to API use in the UK HE [Higher Education] sector, the potential benefits of the provision of APIs and the challenges this provision can instigate. The report also reviews potential problems developers can face when using third-party APIs."


• Report 2: API Good Practice: "provides a number of good practice techniques for provision of and consuming APIs. The content of this report is based primarily on feedback provided from the developer community."

What came through strongly for me in this report was ease of use:

"make sure that there is a low barrier to access. The maximum entry requirements should be a login (username and password) which then emails out a link.

"If you need to use a Web API key make it straightforward to use. You should avoid the bottle neck of user authorisation, an overly complex or non-standard authentication process. One option is publish a key that anyone can use to make test API calls so that people can get started straight away. Another is to provide a copy of the service for developers to use that is separate from your production service. You could provide a developer account, developers will need to test your API so try to be amenable."

On the down side, I think the framing/title, "Good APIs", leads to a conceptual confusion between the notions of "API" vs. "Web Service". In some places, the JISC discussion is about the Service -- for example, finding out what users need first. In other places, the report recommendations are clearly about APIs specifically, for example when they talk about method naming conventions.

I would argue that, to speak clearly about this domain, one needs to distinguish between these two concepts, and use the terms deliberately.

So, a Web Service is a Web-based application oriented towards machine transactions. On the other hand, an API, or Application Programming Interface (not "Program" Interface), is a well-defined method for accessing a Service. (the machine-usability characteristic of APIs is mainly a consequence of this well-definedness).

As an analogy, Web Services are like local or long-distance phone service, whereas the API is like a phone jack. A Service can have many APIs, like the various ways one might connect to long-distance phone service. Also, the mere existence of an API does not necessarily mean that the service behind it does something worthwhile, or does it with sufficient quality or reliability to meet your needs. A real, production-quality Service includes not only API(s) but documentation, a service-level agreement, performance benchmarks, and support.

Finally, it's worth noting that a Web Service, in the general sense, might be delivered to users via means we wouldn't call APIs: for example, by depositing an updated Linked Data set to a public data repository.

The problems with using "API" to mean Web Service include the following, in my opinion:

1. it confuses the wrapper for the package;


2. it tends to a view of Web Services as just simple data services, request-in and data-out -- which is only one type of WS, and often the least valuable.


3. It focuses attention on implementation detail, rather than the user- or business value of the actual service.


4. It hides the fact that a useful service might well, over time, have a number of different APIs implemented for it, as different usages, protocols, and environments emerge.


5. it tends to make people think of Web Services as just a matter of "exposing" some data or functions from an existing application.

I know, it might seem to be quibbling, to focus on terms. However, I've seen over and over that major issues are often decided in the choice of framing and vocabulary, rather than in the "actual" discussion that follows.

In any case, check out Marike's well-done and nicely consultative report, and learn more about how to make Web Services be, in Coleridge's famous phrase, "companionable forms."

Developers Bre Pettis and Kio Stark have rocketed to Web fame recently with their "Cult of Done" manifesto: 13 rules for fast building, learning, finishing, and getting onto the next do.

The manifesto, as author and work-life pundit Daniel Pink remarked, "has been flying around the productivity geek crowd on the web". (yes, there is such a crowd: see also Lifehacker.com, read Getting Things Done (WorldCat, Amazon).

Below is the manifesto, but do check out also the very cool poster accompanying it.

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you're done you can throw it away.
8. Laugh at perfection. It's boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.