News

If you're looking for a quick, hourlong introduction to OCLC Web Services, reserve the 2:00-3:00 p.m. Central Time slot TODAY--April 1, 2010. You'll hear Karen show the various services in action like the WorldCat Search API, the WorldCat Basic API, WorldCat Registry APIs, xISBN, xISSN, WorldCat Identities and more. The OCLC Web Services Webinar is part of WiLS's long-standing "Library Open Solutions" series, and it's open to anyone who would like to attend. (WiLS and MINITEX members get an even better rate.) There is a fee to attend--but it covers the registration and recordings for all 6 of the sessions, and one seat can be shared for a whole library. So in this way, it brings the cost down to a reasonable amount per person.

Note: the following post was submitted by Andy Dale, our resident expert on all things identity management and authentication. Electronic chickens and eggs keep chasing each other through the internet evolutionary cycle. In this latest evolution, Federated Identity Technology that has been maturing over the last 5 years now has a nascent trust infrastructure that will make it not only functional, but, usable. I have written here previously introducing some concepts of Single Sign-On and Third Party Authentication; these are facets of Federated Identity. I often say that an Identity Federation is one third technology and two thirds legal agreements. It is vital that members of a federation have interoperable technology otherwise nothing works. However the actual glue that makes an Identity Federation useful is the legal agreements that govern behavior of the members. This lets members trust each others' identity assertions, like logins. These legal agreements have to be deeply crafted so that they can satisfy the federation members in the complex regulatory frameworks in which they operate. The InCommon federation has legal agreements that let US academic institutions federate identity infrastructure within the Family Education Rights & Privacy Act (FERPA) regulatory framework. OpenID and InformationCards have been flourishing as internet scale identity technologies that have been embraced by companies like Google, VeriSign, PayPal, Verizon and many more. All of these companies have been willing to issue 'portable identities' to their users but few of them have been willing, or able, to accept identities from other providers. The technology has been there but the legal infrastructure has been missing to make this all useful, in this wider context. Last week at RSA; the premier annual online security conference in San Francisco, the formation of a new organization was announced: Open Identity Exchange (OIX). OIX will establish a framework of 'standard' interoperable legal agreements. These agreements will be vetted and accepted by members of OIX and used to establish 'networks of trust'. OIX does not try to establish a single network of trust as the legal agreements for different types of activities will clearly need different legal agreements. Health Record sharing has different demands than Photo Sharing. The first trust network that has been established will enable people with OpenIDs or InfoCards issued by Google, Equifax and PayPal to access US government web sites. OCLC is a founding member of OIX and holds an advisory board seat. We are there because we see the potential for OIX to provide the library community a vital piece of infrastructure. Over time we see the possibility that the OIX infrastructure can be used provide identity trust between libraries, consortia and content providers and greatly lower the barriers of access to content. The promise is a world in which a patron can log in to their library, large or small, K-12, Public, academic or special and gain direct access to all of the resources that they should be able to access. We will keep you informed as this exciting new space evolves.

Roy, Alice and I are here at code4lib 2010 to teach a preconference, OCLC Web Services and Lightning Talk Demos. I'm also presenting a session tomorrow (Tuesday) before lunch, 7 Ways to Enhance Library Interfaces with OCLC Web Services. If you are going to be at code4lib, we'll see you here in Salon C1. If you're not able to attend, follow the conference tweetstream. You can download the presentations at least.

One of the most common questions folks ask me when I tell them I'm the Product Manager for the OCLC Developer Network is "so what do you do?" I can understand this. The Developer Network is a relatively new endeavor for OCLC and it's not a product in the traditional sense. Which makes people wonder why OCLC hired me and what it is that I do. Primarily my job is to help build a community of developers (library and non-library) around OCLC's Web services (present and future). So my title might be just as fitting as the "OCLC Developer Network Community Advocate," but since that wasn't available as a job title, "Product Manager" was the closest fit. So as the person within OCLC who is looking out for your needs as a developer, there are a variety of broad activities that I am tasked with:

• I do outreach to developers to teach them about the Web services, to get their comments and to try to make things better. Sometimes this means teaching actual workshops or putting together Web tutorials. Sometimes it's just one-on-one work, answering questions on the DevNet list [WC-DEVNET-L], Twitter, blogs, etc.
  Dispelling misinformation and misconceptions about OCLC's Web services is another big part of job. I try to help folks get access and take feedback about when there are problems. There are two big things I'm learning that people don't know:
  1. First, nearly all the OCLC web services are in some fashion completely free to anyone for noncommercial use. Some have daily usage limits for anyone (like xISBN, xISSN), but others like the WorldCat Registry and WorldCat Identities have no usage limits whatsoever. Oh sure, the WorldCat Search API requires some qualification...but if you don't qualify for whatever reason, use the WorldCat Basic API. Or let us know what you're working on and make the case for why your app deserves access. (Never hurts to ask!)
  2. Second, OCLC Web services operate in a very beta mindset. There are advantages to this, like the ability to be responsive to requests for changes in a relatively speedy fashion. However, it also means that the Web services can occasionally be rough around the edges. This is especially true for the Experimental Services like Terminologies, Metadata Crosswalk, Dewey.info.
  
  
• I write lots and lots of documentation. It's pretty much impossible to have developers use your Web services without effectively documenting it. So one of my big tasks is to make the DevNet Web site better by adding more thorough documentation. Right now I'm working on documentation for the WorldCat Identities Web service.
  Writing documentation also means engaging and interacting with the staff at OCLC who are more directly responsible for the Web services. I get to learn from the people who know them best, which is pretty darn cool. Right now I'm also learning about Linked Data from some folks in OCLC Research and a few external colleagues. It's interesting and challenging--I haven't figured out exactly what to do with it yet. What are you doing with Linked Data that the Developer Network can help support you on?
• I write demo code. There are lots of reasons for this. One is so I can answer questions and make suggestions to you, when you're using the Web services. Keeping my coder skills in shape is essential to serving you effectively. I also write demo code so that I have something to teach and present from.
  Seeing real world examples makes a huge difference when presenting to others. I try to create demonstrations that show of the power of OCLC Web services and how they can be combined with data from other Web services. If you want to see the best of my demos in action, look for my presentation at code4lib 2010.
  


• I test web services (both OCLC and others) and provide feedback to develop new services from OCLC. Testing the Web services also puts me in the unique position of being able to evaluate the services before they are deployed--which means I get to critique and take a critical look and what works and doesn't work.
  Case in point, the last two weeks I've been playing with the soon-to-come JSON output for the WorldCat Search API. I want to make sure it works for as many use cases I can think of, and that the structure is as simple as it can be while providing the most robust information. While some of my feedback is my own, based on my own experience working with the service and my knowledge of development and other web services, the most important feedback that I can pass along is that which comes from you, the members of the OCLC Developer Network. I need your input to help guide what comes next. Which is why getting feedback about service performance, methods of access, formats, data provided and its structure is important to my serving you and doing my job well....
  

All and all I have my hands full, but I wouldn't want it any other way.