OCLC Developer Network Blog

Going to ALA? You're invited.

2009-06-25T20:58:37Z

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.

Third OCLC Research Software Contest Underway

2009-06-12T23:23:56Z

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

xID new features

2009-06-11T19:30:50Z

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.

"Good APIs" JISC study released: on making companionable forms

2009-06-09T15:27:47Z

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:

it confuses the wrapper for the package;

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.

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

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.

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

Also, speaking of APIs separates us from the dominant technical and standards discussions, and rigorous term definitions, which center around the W3C and its Web Services program

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."

The Cult of Done

2009-06-03T07:32:35Z

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.

There are three states of being. Not knowing, action and completion.
Accept that everything is a draft. It helps to get it done.
There is no editing stage.
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.
Banish procrastination. If you wait more than a week to get an idea done, abandon it.
The point of being done is not to finish but to get other things done.
Once you're done you can throw it away.
Laugh at perfection. It's boring and keeps you from being done.
People without dirty hands are wrong. Doing something makes you right.
Failure counts as done. So do mistakes.
Destruction is a variant of done.
If you have an idea and publish it on the internet, that counts as a ghost of done.
Done is the engine of more.

A Web Services Taxonomy: not all about the data

2009-05-29T08:23:07Z

[full version of article A Web Services Taxonomy (PDF 84k)]

A Web Service, according to a standard definition, is "a software system designed to support interoperable machine-to-machine interaction over a network." 1

To put it another way, a Web Service is some useful service offered (usually) on the Internet, designed as a sort of building block you can use any way you want.

So, for example, Google Maps, a free service that dynamically draws maps of any location and locates addresses, has been used by thousands of people to build new services such as crime-report maps and real-estate listing tools,

Another way to wrap your mind around Web Services is to consider a range of well-known ones and what they do. That's what the chart below does, with services such as Paypal, Google, Twitter, and Sabre, the airline-reservations system. (click on chart to see full-size):

This chart represents a taxonomy, or classification, of Web Services, constructed by characterizing all services according to two factors:

Data quality: from simple/commodity to complex/unique

Transaction level: from basic lookup to real-world transaction.

The full version of this article, A Web Services Taxonomy (PDF 84k), defines what is meant by those terms, and discuss representative examples of Services that exhibit varying degrees of these characteristics.

Based on this, I suggest that the Services with the most usage, customer value, and/or revenues typically have more complex/unique data, and/or are more transactional.

See also the above chart in full size, or the full article (PDF 84k).

WorldCat Mashathon a huge success

2009-05-22T13:15:56Z

Thanks to everyone who participated in the Mashathon and followed us on tweets. The library press noticed, too. It is hard to believe it has already been a week since we disbanded--I think I left half my heart (and 152 photos) in Amsterdam. Certainly, I came home brimming with interesting ideas and a renewed curiosity about how OCLC can use APIs and Web services to improve the information-gathering experience for researchers.

A few people have asked what the Mashathon was for. Besides just being fun to get together, the goal of the event is twofold: one is to raise awareness of the WorldCat Search API and related Web Services freely available from OCLC and other library-related organizations. The equally important second goal is to help developers connect with fellow developers and other technology-minded thinkers to work on shared solutions to similar situations or challenges within their respective settings. We found the face-to-face interaction really helpful--even as online collaboration environments continue to improve. There are still reasons for Web-oriented people to come together: powerful connections happen that we all benefit from.

In the end, there were 9 new tools/apps/ideas presented. I will share them below in the order they were presented, with links to the YouTube videos. I know there were a whole lot more apps still being worked on that weren't presented, too. So if you didn't present yet, let me know when you're ready to share. Add your project to the sample apps page, so everyone can build on your good ideas:

Also available at a WorldCat Library
A new sidebar in the Wageningen UR Library Catalogue that uses the WorldCat Search API and the WorldCat Registry OpenURL Gateway to display a location-sensitive listing for other WorldCat libraries who also hold the item. See it in action in the development space.
Peter van Boheeme, Wageningen University, Wageningen, Netherlands

AdLib Library Gateway to WorldCat
A Web service built into the AdLib library system that uses the Worldcat Search API to add a WorldCat query component to the service, as well as an SRU-based name/author search that utilizes WorldCat Identities.
Monika Lechner and Bert Degenhart Drenth, AdLib Information Systems Maarssen, Netherlands

WorldCat Identities widgets
4 small blocks of functionality that use the WorldCat Search API and WorldCat Identities/VIAF to build on each other to turn a Dutch catalog ppn number into an OCLC number, return author names, citations and related works (subject headings) in XML and JSON. The "catalog group" contributors included:
Derk-Jan Fiel, Royal Tropical Institute, Amsterdam, Netherlands
Niels Molenaar, Royal Tropical Institute, Amsterdam, Netherlands
Andreas Neumann, Bayerische Staatsbibliothek, Munich, Germany
Eric de Ruijter, IISG, Amsterdam, Netherlands
René Exterkate, Radboud University Nijmegen, Nijmegen, Netherlands
Rick Gouw, Radboud University Nijmegen, Nijmegen, Netherlands
Sjoerd Siebinga, Europeana.eu, The Hague, Netherlands
Theo van Veen, National Library of the Netherlands (Koninklijke Bibliotheek) The Hague, Netherlands
Martin Zwaal, OCLC, Leiden, Netherlands
Bruce Washburn, OCLC, San Mateo, CA USA

WorldCat on App Engine
An app that gets the WorldCat Search API running on Google App Engine to solve cross-server/cross-domain security issues. Reuses a previous Hackathon attendee's WorldCat Python module and outputs JSON results.
Etienne Posthumus, TU Delft Library, Amsterdam, Netherlands

WorldCat Identities Photos
A true mash-up of WorldCat Identities with Wikipedia photos, to help a user with quality name issues in the Credo Reference Service.
Pete Ciuffetti, Credo Reference Service, Boston, MA USA

SOLR + SRU implementation connections
A realization that face-to-face connections are still very important in a predominantly online world, this project compared notes on how to open up indexes to the world.
Lucien van Wouw, IISG, Amsterdam, Netherlands
Hicham El Kasmi, Université Libre de Bruxelles, Brussels, Belgium
André Hagenbruch, University Library Bochum, Bochum, Germany

xISSN enhancement
An addition to the xISSN Web service that will now include the RSS feed of the journal data, using the JISC national authority file information from the Journal Table of Contents Service.
Xiaoming Liu, OCLC, Bloomfield, NJ, USA

WorldCat World Tour
An app that finds artists' albums through the WorldCat Search API and uses a UK-based streaming music service to play the musical tracks online.
Julian Cheal, UKOLN, Bath, UK

MetaLib Search for WorldCat
A component that uses the WorldCat Search API and employs SRU updating.
Bart Alewijnse, Groningen University Library, Groningen, Netherlands
André Keyzer, Groningen University Library, Groningen, Netherlands
(They didn't actually present, but Bart stayed late to finish it!)

WorldCat Mashathon starts tomorrow

2009-05-12T15:47:15Z

We're getting ready for the WorldCat Mashathon today. Yesterday I was traveling, and then Ralph M. from the Leiden office and I started in on the details. Oh you know, things like printing name tags and creating networking sheets so people can know who else works in Python, who prefers Java...things like that.

Here's a photo of where we'll be. It's a former cocoa warehouse, but now home to the International Institute for Social History. A beautiful setting and one to surely inspire a few creative innovations the next two days.

One interesting note: the IISH even has a "floating garden" that is part of their collection. it seems that an artist built an island out of styrofoam, planted it with plants and even built some structures on it.

I'm off to get my bearings on the rest of Amsterdam. We'll be tweeting and posting updates here during the event, so if you weren't able to come--it will be almost as good as be

Come Mash with us in Amsterdam

2009-04-08T22:19:52Z

We are pleased to announce the WorldCat Mashathon registration for Amsterdam is now open. Here is the *official* announcement:

Join fellow coders for the WorldCat Mashathon in Amsterdam, May 13-14. Sponsored by the OCLC Developer Network and International Institute of Social History (IISH), the two-day event will be held Wednesday and Thursday at IISH headquarters in Amsterdam.

The European Mashathon follows on the heels of a previous WorldCat Hackathon in New York City. Participants will spend the two days brainstorming and coding mash-ups with local systems, OCLC Web Services, and many other Web Services to embellish existing, and create new, library services.

WorldCat includes national catalogues from the Netherlands, the UK, Ireland, Iceland, Germany, Sweden, Finland, Denmark, France, Spain, Switzerland, Czech Republic, Lithuania, Russia and many more--so there are plenty of potential uses and apps just waiting to happen.

Why attend the WorldCat Mashathon?
� Brainstorm potential uses for and play with the WorldCat Search API.
� Gain development access to 1.2 billion items from more than 10,000 libraries worldwide.
� Integrate these resources with many others to create innovative new services.
� Meet fellow developers across the information industry.
� Share your creative vision and be a part of the next wave of online library development.

Ideas, outcomes and code from the Mashathon, together with a participants list, will be shared during and after the event for others to download and build on.

Learn more and register now for the WorldCat Mashathon on the OCLC Developer Network wiki.

Introduction to Information Cards

2009-03-11T14:40:54Z

Information Cards introduce a new paradigm in on-line authentication that replaces conventional Username and Password login. The new paradigm is based on the very familiar 'real world' experience of presenting credentials. When I want to purchase something and I don't have cash; I present a credit card. When I want to rent a car I pull out my driver's license and when I want to borrow a book from the library I pull out my library card. Despite the number of cards I may have in my wallet; 3 credit, 1 debit, healthcare, dental care, library, 3 museum memberships, 2 frequent flyer, etc... It is very easy and intuitive for me to select the right card at the right time.

The mechanics of trust that 'real life' cards represent is also interesting. When I present my driver's license, the 'claims' on the card; age, address, etc... are packaged in such a way that the person looking at the card can establish 'trust'. They can compare the picture on the card to my face. They can compare the age represented on the card to their view of how old I am; they can compare the eye-color listed to my eyes. Finally, they can identify the state that issued the card. The trust mechanics dictate that:

The card does not appear to have been tampered with. The photo to face matching indicates that this card was issued to this person by the State of California. I trust the State of California I can therefore trust the claims on this card.

The interesting thing to note is that there is no need for trust to be established between the person presenting the card and the person accepting the card. The person accepting the card only has to trust the State that issued the card; even though the state isn't present, or in any way involved in the transaction. This is similar with credit card processing; a shop keeper doesn't trust you to give them money 'later' ("I'll gladly pay you Tuesday for a hamburger today"), but they do trust Visa, the issuer of the card.

Information Cards bring this paradigm and these mechanics to our online experience. When you login to a web site with Information Cards (I-Cards) you are asked to select an I-Card from your virtual wallet. The analogy isn't perfect so the wallet, otherwise known as; The Card Selector, has some smarts to make things easier.

The Card Selector, which is a piece of 'secure' software running on your machine, remembers places that you have logged in before. Each time you start to log into a site that you haven't logged into before, you get an informational dialog that tells you about the site you are logging into. This largely eliminates concerns about 'phishing' attacks, scams where a site pretends to be a site it's not to get your username and password. Even if a site manages to fool you into logging in with an I-Card ; they don't get something they can use somewhere else.

When you click on the 'login' link, the site you are trying to log into tells your computer what it wants to know about you. If you are trying to leave a blog comment that might just be a nickname, if you are trying to purchase beer it might be a claim that you are over 18 years of age. When the wallet opens, only those cards that are capable of satisfying the sites 'policy' (what the site wants to know) are selectable. This interaction means that the user doesn't have to go through and select from ALL their cards every time they login, the choice comes down to selecting from one or two for any given context; Visa or American Express?

If you want to play with Information Cards the best place to start would be http://www.azigo.com/icards.html this site is provided by Parity Inc.; THE leaders in implementing this technology. If you click through the Equifax Card sign-up process you will have the Card Selector installed and get your first i-Card, one that can 'prove' you are over 18 (if you are) without exposing any other information about you. The Minuteman Library Network is the first Library Card i-Card project and probably of special interest to the readers of this blog; I am working on this project and will keep you informed of its progress.

OCLC at Code4Lib

2009-02-26T16:29:17Z

Most of my fellow OCLC Developer Network staffers are still at Code4Lib soaking up all the great ideas, making technology intersections and creating new possibilities for library development projects.

For me, I got stuck in a snowstorm on the way to the preconference session OCLC sponsored, the "OCLC Grid Services Boot Camp." So I won't tell you my reflections on the morning session, because I wasn't there. But Richard Wallis did, with a nice summary over on Panlibus.

Karen Coombs over at Library Web Chic also uploaded a video demo of the WorldCat Search API during the conference.

In the afternoon, Ralph LeVan gave an overview of SRU and CQL, and I showed off some of the social networking features of WorldCat.org...which sparked an interesting discussion about ways to help faculty and students make better use of the tools available.

In looking through the list of attendees, there were a number of Perl and Java developers--with some interest in Groovy--and lots of people keen to do more with mobile. (For example, Birkin showed me the MIT mobile site for iPhone users. How cool would it be to have library materials, right there alongside the shuttle service info?)

All the powerpoints from the session are linked off the pre-conference page above, so even if you couldn't make it to Providence, you can still see Flickr photos and participate.

One of the outcomes we talked about from the session was to think about a series of Webinars, or maybe just short video clips that show different uses of the developer tools now available from OCLC. Would something like that be helpful for you?

What is SSO?

2009-02-10T17:48:36Z

One of the hottest issues in Identity Management is often referred to as SSO; Single Sign-On. However it is a horribly misunderstood and misused term. I will try to give a brief overview of what SSO is and isn't.

What most people mean when they say SSO is the user experience of accessing multiple services and systems but only having to 'log-in' once. On the face of it SSO sounds great but there are some pitfalls that we have to be wary of. If we aren't very careful, the 'ease' of SSO is bought at the cost of privacy.

The type of SSO that I am going to explore is the "HTTP Redirect" SSO mechanisms that are widely deployed for SSO on the web. This includes OpenID, Shibboleth (Web SSO), SAML (WebSSO), FaceBook, Yahoo! and Google, to name a few. These protocols differ in many details and have different strengths and weaknesses but they all share the same underlying HTTP Redirect mechanism. The basic pattern is this:

1. Jane navigates to a web-site and she wants to log-in using a username and password that support SSO.
2. Jane clicks on the 'login' button on the page.
3. Jane has to tell the web-site who her SSO service provider is. This is known as the Where Are You From problem, otherwise known as WAYF. More about WAYF in a moment.
4. Once Jane has told the web-site who her SSO service is; a HTTP Redirect is sent to the browser to send Jane off to her SSO service.
5. At her SSO service Jane is asked to provide her UserName and Password.
6. If Jane convinces the SSO service that she is, in fact, Jane, then she is returned (via HTTP Redirect) to the original web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
7. The web-site and SSO service communicate in such a way that the web-site can validate that this is really SSO service XYZ talking AND if it knows and trusts service XYZ it can go ahead and accept that this is Jane.
At this point we have performed 3rdParty Authentication or Federated Sign-On NOT SSO.

8. Having done what she came to do Jane now navigates to another web-site.
9. When Jane arrives at the second web-site she is NOT recognized as being logged in. This site has no knowledge who she is or that she has logged in somewhere else before. If Jane wants to access 'protected' resources at this web-site she is going to have to click on the log-in button.
10. Again Jane will be asked Where Are You From and she will select her SSO service provider.
11. The web-site will then send Jane off to her SSO provider asking... "Who is this?"
12. Because Jane logged into her SSO service just a few minutes earlier the SSO service doesn't ask Jane for a UserName and Password this time, it immediately returns back to the web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
13. The using the same trust validation as above the web-site can now believe that this is Jane

And Jane only logged in ONCE... that is SSO.

Jane still had to click on login twice and still had to provide her SSO service twice but she only Signed-On a Single time.

There are variations in this flow, OpenID nicely shortcuts the double SSO service provider selection BUT you have to type in your UserName twice.

The most common expectation of SSO that is not satisfied by the flow described is "why didn't the second site just 'know' that I had already logged in and who I was?" Apart from the fact that would be technically difficult the answer is actually that REALLY you wouldn't want that behavior... Once I explain why:

If SSO worked that way, when you logged in once, everywhere you went on the internet would know who you are. Not just an IP address, they would be getting a message "here's Jane". All of the web-sites on the web could talk to each other and work out EXACTLY which sites you visited and which ones you didn't. That is generally considered to be a terrible breach of privacy. In order to avoid this privacy leak clicking 'login' remains an explicit action that the user must take. The action no longer means: "I want to enter my username and password" but now means "I'm OK telling this site who I am."

There are ways for 'closely connected' sites to shortcut this experience. Handing a user from their Local Library System to the Consortia Meta-Search interface; a handoff that is between trusted parties; Janes identity CAN be passed from one service to the other providing the 'seamless' SSO that we would love to have. But you can't be sure that Jane was OK being identified at the second system unless you make the action explicit. As a service provider you have to make very careful choices between seamless SSO and user privacy.

Rather than going on now:- You can tune in later for "SSO using Pair-Wise Identifiers to protect your privacy", "How and Why OpenID is different from Shibboleth Web SSO" , "Why you MUST trust your SSO service provider because they know a lot about you"...

Please ask questions if I haven't been clear... Please let me know if you think I have said something misleading or wrong... I'm just trying to start a conversation here.

New xISBN bookmarklets supports thousands of libraries

2009-02-09T19:07:45Z

xISBN bookmarklets now supports thousands more libraries by integration with Worldcat Registry.

The previous xISBN bookmarket supports more than 300 libraries, however, the list was manually maintained and it's challenging to keep these links up-to-date, By ingesting good Registry OPAC information into xISBN bookmarklet, we are able to support thousands more libraries in a more sustainable way.

xISBN bookmarklet automatically pulled new information from Worldcat Registry on a monthly basis, so if a library maintains up-to-date information in Registry, its data will be automatically reflected in xISBN bookmarklet. Furthermore, we have also developed mechanisms to validate and improve OPAC linking templates in Registry during the process.

The previous xISBN bookmarklet is still maintained in http://xisbn.worldcat.org/liblook/

WorldCat Registry Detail Service - Look up by OCLC symbol

2009-02-06T23:28:00Z

Written by colleague Joanna White, Product Manager of the WorldCat Registry.

Users can use a new Registry Web Service to retrieve an institution record in XML using the OCLC symbol.

For example:
http://worldcat.org/webservices/registry/lookup/Institutions/oclcSymbol/OCL?serviceLabel=content

Additional notes.
Q: What happens when no records are found?
When no WorldCat Registry record is found for a given OCLC Symbol , the web service returns "0" results in the XML response while the user interface presents options to adjust the search query.

Q: Do I need to adjust my service for searches by special characters?
Yes. Services that utilize these web services have to accommodate for special characters present in some OCLC symbols, for example symbols such as "A#2".

Q: What is included in the returned content?
If a user is not authorized, then the "public view" of the XML data is returned to the user. If the user is authorized, then the "authorized" version of the XML data is returned to the user. For example, "authorized" users will see IP Addresses for the record. More information on all the data fields is available with Data Fields Quick Reference at http://www.oclc.org/us/en/registry/support/Registryquickreference.pdf

WorldCat Registry detailed search is also available as part of our more general Registry Search web service. This SRU service returns HTML to a web browser but XML to software agents (e.g., curl)

Example of SRU search:
http://www.worldcat.org/webservices/registry/search/Institutions?version=1.1&operation=searchRetrieve&recordSchema=info%3Arfa%2FrfaRegistry%2FschemaInfos%2FadminData&maximumRecords=10&startRecord=1&resultSetTTL=300&recordPacking=xml&query=local.oclcSymbol+exact+%22OCL%22+not+local.logicalDelete%3D%221%22&x-info-6-deletedRecord=

Details about the three WorldCat Registry web services are listed here http://www.worldcat.org/wcpa/content/affiliate/default.jsp

Which Andy is that? Are you sure?

2009-01-29T21:29:33Z

My name is Andy Dale and I am a new member of the OCLC team. I am honored to have been invited to add my voice to the OCLC blogs. My title at OCLC is Consulting Software Engineer, Identity Management and Authentication.

Over the last couple of years there has been a race to put the suffix '2.0' on every concept known to man. Tim O'Rielly is often credited with first coining the term Web 2.0 back in 2003 and since then it's been a rush to the door 2.0. One of the 2.0's that I have been very involved with is Identity 2.0 and I am now starting to work to see how Identity 2.0 and Library 2.0 interact.

In my blog posts I will try to introduce some of the concepts behind Identity 2.0 and how they might be leveraged to enhance the library experience. My knowledge of Identity technology and policy is deep; my knowledge of how things REALLY work in libraries is nascent at best. I will speculate and hypothesize about the collision of the ideas that drive Identity 2.0 and the use-cases and pain-points of working libraries. I look to you, the readers of this blog, to help correct my misunderstandings and help me find the points where my particular knowledge can be leveraged to add value to library software implementation.

Some of the things that I will blog about soon are: OpenID, Information Cards, Claims Based Authorization, Single Sign-On and Federated Authentication. At times I will write high level explanations of the concepts, at times, forgive me, I will delve into the nuance of one representation of an identifier vs. another.

I look forward to this dialog with the library community. If you want to contact me you can do so through my i-name by clicking here: =andy.dale (More about i-names and contact pages soon :-) )