The Orbis Cascade Alliance's Collaborative Tech Services Team has been charged with implementing "a Shared Best Practices working group to develop guidelines for effective technical services policies and operations that support the Alliance goal of a shared ILS (Integrated Library System)."
At our team's first meeting, I was charged with taking a shot at what an ideal Alliance shared ILS might look like. I am supposed to produce a white paper on this topic for consideration by the Team.
The work of the Shared Bibliographic Database Task Force serves as a good starting point in this thinking process. Their report points out many of the potential implications of a shared ILS as well as advantages and drawbacks (scenario 3).
Perhaps the most common notion of a shared ILS would be all 36 Alliance members piling on board a traditional ILS software package that was designed for large, complex organizations (but might not be designed to handle as many separate and large organizations and sub organizations as comprise the Alliance). A big advantage in doing this would be savings on system maintenance, local system administration and hardware costs.
To make this happen successfully, member libraries would have to standardize their operations around certain system settings like circulation loan rules because the system simply couldn't handle as much local variation as is in place now. This standardization might create efficiencies in itself in that it would promote common best-practices workflows around the shared settings. A shared system could also create efficiencies through the reuse and sharing of data. For example, by sharing bibliographic records, we could reduce the overall time and effort required for database maintenance.
The big disadvantage in sharing a system this way would be a potential lack of flexibility to tailor the system to the each institution's needs: whether this customization came in the form of special loan rules, distinct subject headings, etc. Another issue might be that the system would simply become unwieldy for staff to use because data from all the institutions would overload user interfaces for staff. Imagine having to wade through hundreds of item records for a given bibiliographic record (of course these effects could be mitigated by special views, etc.) And finally another disadvantage would be the potential red tape needed to make any change to system settings.
Another model of a "shared ILS" would provide every library with an independent "virtual" ILS delivered in a Software As a Service (SAAS) fashion. Because the software would be delivered over the web, we would "share" the underlying software and computing infrastructure. We'd be "sharing" an ILS with other Alliance members (and perhaps whomever else the vendor contracted with) but we wouldn't even know it. By doing things this way, we wouldn't lose any independence and we'd still potentially save money on system maintenance (both vendor supplied and via our own staff). But we wouldn't be gaining any potential benefits possible through the sharing of data.
The third option would be a hybrid of the two above and is the one that probably corresponds to the most likely reality. The ILS would be shared where there were benefits to be gained, separate where there were not. For example, in circulation every library could have their own patron types and loan rules, but those patron types and loan rules would map to higher consortial levels of abstraction in order to support borrowing between institutions (kind of like they do now in Navigator but in the same system). In acquisitions, data about what materials were on order at each institution would be shared, but fund data wouldn't. In cataloging, we would share bibliographic records but perhaps control some of our own fields. In e resources, both individual and group purchases and licenses would be supported.
Another twist, of course, is the notion of sharing the ILS on a global level, which is more or less the vision of OCLC webscale management services. This creates the need for an even higher level of abstraction than at that of the consortium.
In coming up with a model for an ideal shared ILS for the Alliance, I'll be considering all of these scenarios.
Showing posts with label OCLC. Show all posts
Showing posts with label OCLC. Show all posts
Monday, February 15, 2010
Wednesday, September 9, 2009
WorldCat Local Review
I've written a fair amount in the abstract about the benefits of WorldCat.org and WorldCat Local.
At Watzek, we launched "L&C WorldCat" around July 1. Here are some thoughts based on my experience with the implementation.
At Watzek, we launched "L&C WorldCat" around July 1. Here are some thoughts based on my experience with the implementation.
- There is already a sense developing at our school that "everything" is in or should be in WorldCat Local. People expect all articles and books to be there (even though they aren't). I may post more on this later.
- Compared with launching an III OPAC, the process of bringing WCL up is refreshingly simple. They have consciously limited customization to the very basics (logo, colors, etc.)
- Even so, as I've said before in this blog, I'd prefer a greater level of customize-abilty, kind of on the level of Blogger. Give me full access to the stylesheet. Let me add code snippets.
- It's backward that the software pulls in live holdings data for print items from your ILS, but can't pull in links to digital content from your link resolver. When students come upon an article, they want the direct link to it up front, not a click or two away. OCLC should scrape resolvers like they do ILSs to embed link resolver links in records for articles.
- I'm excited about the idea of OCLC partnering with content providers like EBSCO and indexing their content in WC. One thing I speculated on when writing the Digital Libraries book in '06 was that following on the success of search engines, meta indexing services for library content would eventually emerge. We now see that with Serials Solutions Summon and WorldCat.
- The idea of also incorporating in traditional real-time meta-searching seems like a backward compromise: OCLC should be firm with content providers and resolve to only incorporate content that they can put into their index.
- The stats module for WCL is basically a commercial web analytics package slapped onto WCL with a few limited custom reports. Basically, you can look at your site traffic and search terms being used.
- I like the idea of using standard web analytics software on WCL, but please let me drop the code snippet in for Google Analytics.
- If they did some url rewriting so as to map some of the search/browsing activity to clean URL paths (eg "/author/" "/title/" "/facet/video/") web analytics software becomes more useful because you can collate together like activities based on url paths.
- For a minute, I was thinking that to provide access to an e book package we purchased through WCL, all we'd need to do is "flip the switch" and activate our holdings for those records in WCL, forget about ILS records. But then I remembered: the URLs to that package need to go through our proxy server so they need to be drawn from our ILS. WCL is not making our lives easier yet.
- A little off the subject, but now that OCLC owns EZproxy, aren't they in a great position to develop some better, more graceful form of remote authentication than proxy? OCLC could act as a trusted third party and provide single sign on to content provider websites.
Thursday, July 23, 2009
funding models for digital projects
Thanks to Liberal Education Today for the reference to an Ithaka report called "Sustaining Digital Resources: An On-the-Ground View of Projects Today." We've been having discussions on how to sustain our comparatively tiny accessCeramics digital project and came up with a similar list of options offered in this report, including: subscription, licensing to publishers and users, custom services, corporate sponsorship, author fees, endowment, and grants. Not surprisingly, it doesn't have any easy answer regarding which one is best.
The report is very critical about relying too much on what can be the invisible support of parent institutions.
To some extent, I think one just has to accept that these kind of projects can be somewhat transitory in nature. The report appears to be reaching for some kind of formula for permanent sustainability. But, indeed, if a project has a viable life for a decade and then its content migrates along to a new home, all is well.
The Symposium on Teaching with Digital Collections in the Liberal Arts in May at Reed College had a few cases of small scale digital projects at liberal arts colleges. In most cases, they revolved around supporting a research and teaching interest of a particular faculty member. The product would be used in instruction at a local institution, but at the same time had a global reach. Lafayette College's image collection of Taiwan under Japanese Colonial Rule, co curated by a historian at the school and the library's special collections unit was one example. Claremont had several others. In these kinds of cases the institution is really supporting the work as part of faculty teaching and research and the library is acting as a kind of institutionally-sponsored laboratory.
I wonder if there are system-wide solutions that could make it easier for small scale digital projects to create revenue streams. Should digital collections software like ContentDM make it possible to sell high quality images, for example? Should it facilitate donations or sponsorship of collections?
OCLC now offers the ability to post local digital collections into WorldCat. But what if a library wants to license out some of its digitized content? A player like OCLC could develop pools of topically oriented, "premium" digital content from member libraries and charge for it. I have to believe that libraries will strive to keep their digital projects open and free.
The reality is that we get a lot of information on the open web for free now. But what incentive is there to pay that back by contributing something ourselves?
The report is very critical about relying too much on what can be the invisible support of parent institutions.
To some extent, I think one just has to accept that these kind of projects can be somewhat transitory in nature. The report appears to be reaching for some kind of formula for permanent sustainability. But, indeed, if a project has a viable life for a decade and then its content migrates along to a new home, all is well.
The Symposium on Teaching with Digital Collections in the Liberal Arts in May at Reed College had a few cases of small scale digital projects at liberal arts colleges. In most cases, they revolved around supporting a research and teaching interest of a particular faculty member. The product would be used in instruction at a local institution, but at the same time had a global reach. Lafayette College's image collection of Taiwan under Japanese Colonial Rule, co curated by a historian at the school and the library's special collections unit was one example. Claremont had several others. In these kinds of cases the institution is really supporting the work as part of faculty teaching and research and the library is acting as a kind of institutionally-sponsored laboratory.
I wonder if there are system-wide solutions that could make it easier for small scale digital projects to create revenue streams. Should digital collections software like ContentDM make it possible to sell high quality images, for example? Should it facilitate donations or sponsorship of collections?
OCLC now offers the ability to post local digital collections into WorldCat. But what if a library wants to license out some of its digitized content? A player like OCLC could develop pools of topically oriented, "premium" digital content from member libraries and charge for it. I have to believe that libraries will strive to keep their digital projects open and free.
The reality is that we get a lot of information on the open web for free now. But what incentive is there to pay that back by contributing something ourselves?
Labels:
accessCeramics,
digital projects,
mobilize,
OCLC,
Reed,
specialize
Thursday, April 30, 2009
Springtime in Ohio
OCLC has had some interesting announcements over the last few weeks regarding the WorldCat platform. Their new partnership with Ebsco will really enrich WorldCat Local as an article discovery tool and bring it closer to being a kind of Google for libraries. It'll be interesting to see how much full text content they index vs. citation level indexing. This could be a huge step forward in the search fragmentation problem that federated searching has been trying to solve for a long time.
Andrew Pace commented recently in his blog on the spring weather in Ohio. Perhaps the warmer temperatures have those folks in Dublin thinking that they are in Northern California, looking out at the golden rolling hills around Silicon Valley rather than the verdant hills of central Ohio. His next post announces OCLC's plans to give away WorldCat Local for free (sort of)! Do these folks think they are running a Web 2.0 start-up company or what?
The bigger announcement was that OCLC is entering the ILS fray with a "web-scale" library management system. OCLC's description of the product makes the distinction between a SAAS model and what they are trying to achieve.
The point that people miss here is that this endeavor is not about competing against other library management systems. It's about making libraries relevant in the broader, Google- centered information ecosystem. There are big problems with the way libraries work currently when viewed from the perspective of the modern day web:
Beyond making existing processes more efficient, the network level ILS should be an agent of change for the way that libraries purchase, license, and provide information. Its infrastructure and data should support more sophisticated arrangements with content providers (I think the aforementioned Ebsco arrangement demonstrates this).
In Karen Coyle's article on this initiative, she points out the connection between this project and some of the findings of the Working Group on the Future of Bibliographic Control:
Furthermore, rather than competing with other library sector technology vendors, OCLC should build the infrastructure that allows those vendors to build services on top of the WorldCat platform in the same way that Flickr works with partner companies who add value to their services. I know this is a tricky process, but it probably starts with open APIs.
Andrew Pace commented recently in his blog on the spring weather in Ohio. Perhaps the warmer temperatures have those folks in Dublin thinking that they are in Northern California, looking out at the golden rolling hills around Silicon Valley rather than the verdant hills of central Ohio. His next post announces OCLC's plans to give away WorldCat Local for free (sort of)! Do these folks think they are running a Web 2.0 start-up company or what?
The bigger announcement was that OCLC is entering the ILS fray with a "web-scale" library management system. OCLC's description of the product makes the distinction between a SAAS model and what they are trying to achieve.
OCLC's vision is similar to Software as a Service (SaaS) but is distinguished by the cooperative "network effect" of all libraries using the same, shared hardware, services and data, rather than the alternative model of hosting hardware and software on behalf of individual libraries.I think they are on the right track. The important idea here is that the OCLC community can aggregate library management data together and gain huge advantages. OCLC has holdings data and bibliographic data, which they have put to use effectively in WorldCat.org searching. Circulation data, e resource usage data, license data, etc. could bring major improvements in workflow and business intelligence.
The point that people miss here is that this endeavor is not about competing against other library management systems. It's about making libraries relevant in the broader, Google- centered information ecosystem. There are big problems with the way libraries work currently when viewed from the perspective of the modern day web:
- resource fragmentation-we have too many silos of data for searching; people want the kind of big indexes that Google provide
- the finite collection-if people want to read any article or a book, they should be able to click to it and have it appear; there is an expectation of this on the web, in the blogosphere, etc.; waiting a day for an article that is already digitized somewhere to be scanned and sent over ILL is too long; libraries are still tied to this notion that they provide their patrons access to a finite physical and licensed collection
- walled garden effect-often you have to be going through the library's web gateway to benefit from its resources
- Web/library sector content divide-our systems are often only aware of information resources within the products we provide--there is a disconect with the broader web that tools like Google Scholar bridge
- local value-what kind of local customization are libraries providing regarding information resources? I think often we fall short in providing enough added value to justify our existence as middlemen
Beyond making existing processes more efficient, the network level ILS should be an agent of change for the way that libraries purchase, license, and provide information. Its infrastructure and data should support more sophisticated arrangements with content providers (I think the aforementioned Ebsco arrangement demonstrates this).
In Karen Coyle's article on this initiative, she points out the connection between this project and some of the findings of the Working Group on the Future of Bibliographic Control:
A report from the Working Group on the Future of Bibliographic Control (www.loc.gov/bibliographic-future/news/lcwg-ontherecord-jan08-final.pdf) noted that libraries spend a great deal of time on repetitive tasks, such as cataloging best-sellers, while ignoring the most valuable aspects of their collections: the archives, the rare items, the unique collections. The report urged libraries to "transfer effort into higher value activity" and separately called for libraries to embrace the web as the primary technology infrastructure.The web scale library management system should provide the tools for libraries to do this higher value work, including synthesizing and specializing resources for a local environment.
Furthermore, rather than competing with other library sector technology vendors, OCLC should build the infrastructure that allows those vendors to build services on top of the WorldCat platform in the same way that Flickr works with partner companies who add value to their services. I know this is a tricky process, but it probably starts with open APIs.
Labels:
mobilize,
OCLC,
specialize,
synthesize,
worldcat
Tuesday, March 24, 2009
thinking more about OneBoxing WorldCat Local

I just checked with our implementation guy at OCLC about including some code in the header of our WorldCat Local instance that would allow us to add customized widgets into WorldCat Local search result screens. Sounds like it's a no go for now. WorldCat Local has a refreshingly simple branding customization options compared to what we're used to with Innovative's OPAC. But that simplicity will keep us from inserting some magic Javascript to achieve the OneBox effect.
I'm not sure if I was clear enough about what I'm interested in. Another way of looking at this is analagous to Google Ads. Google has established that placing context sensitive ads alongside search engine results is an effective way to drive traffic to advertiser websites.
If WorldCat Local becomes our library's search engine, shouldn't our library be able to put context sensitive "ads" next to results? These "ads" (or OneBoxes) would appear based on the search term and offer things like:
- links to library created research guides that seem relevant to search at hand
- links to course reserves if a prof's name is searched
- results from a site search of our library's site
- image results from ARTstor (ala Google images)
- results (if any) from the library's digital collections
The WorldCat API is nice and all, but who (besides Terry Reese) wants to build an entire interface from scratch using it?
Click on the image above for an illustration of the WorldCat Local OneBox concept.
Labels:
Google,
OCLC,
OneBox,
specialize,
WorldCat API,
WorldCat Local
Tuesday, March 17, 2009
OneBoxes for WorldCat Local
In thinking through the options for placing the searchbox for WorldCat Local on our website, I'm inclined to argue for a single search box on the homepage rather than the somewhat confusing tabbed box that we have now. After all, WCL should get us to our "catalog" content, journal titles, and provide a general article search.

The problem with offering a single search box to patrons is that we miss content that they might want from a library site search: links to research database, course reserves, library hours, librarian contact info, etc.
WorldCat Local might be improved if it had the option to integrate Google style "OneBoxes" in its results display. A little box off to the side might highlight items like course reserves or matches from a site search.
I have a feeling, I'll probably lose the argument regarding a single search box on our website. After all, even Google offers users multiple silos of content to search (Books, Web, Blogs, News, etc.).

The problem with offering a single search box to patrons is that we miss content that they might want from a library site search: links to research database, course reserves, library hours, librarian contact info, etc.
WorldCat Local might be improved if it had the option to integrate Google style "OneBoxes" in its results display. A little box off to the side might highlight items like course reserves or matches from a site search.
I have a feeling, I'll probably lose the argument regarding a single search box on our website. After all, even Google offers users multiple silos of content to search (Books, Web, Blogs, News, etc.).
Monday, April 14, 2008
OCLC's competitive advantage
In a previous post, I mentioned the "cloud computing" aspects of the WorldCat.org platform when used in the form of WorldCat Local or WorldCat Group to replace an ILS based catalog. A couple weeks ago, I got some more thoughts together on this, but some other distractions pulled me away.
Last year, as part of my work with the Orbis Cascade Alliance's Catalog Committee, I got to survey the market for next generation library catalogs/discovery systems. In my mind, OCLC's WorldCat Group/Local option stands out against both the open source and commercial competition. Why? Because of network effects.
Competitors making products like ExLibris's Primo and Innovative Interface's Encore simply don't have access to the data that OCLC does, and neither does the open source community. OCLC's holdings data lets them do relevance ranking by the number of libraries that own the item. Its global database allows the potential of expanding a search beyond a single library or group of libraries to a global database with built-in ILL. WorldCat offers records that are updated and improved over time by shared cataloging, and the possiblity of enrichment of those records by web-scale social networking (reviews, tags, etc.). WorldCat is a living organism that can't simply be replicated on someone else's server.
These advantages are byproducts of the cataloging and resource sharing networks that OCLC has had in place for years. They are more about a community committed to sharing resources than about technology.
It's also about exclusive access to data, which fits in nicely with Tim O'Reilly's Web 2.0 tenant, data is the next Intel Inside.
Another way to think about this is that OCLC is in a position to be a sort of EBay for libraries. EBay is valuable precisely because of its wide user base. It is the dominant player in online auctions because it offers the widest possible marketplace for buyers and sellers. That same comprehensiveness and global scope also has value when building a search system for books and doing resource sharing.
Traditional ILS vendors have little tradition of sharing data between their customers. I really can't imagine Innovative Interfaces putting together any kind of product that involves mixing customers data (that weren't part of a consortium doing direct business with them). The whole idea of mixing customer data seems like it would run counter to traditional notions of enterprise level systems, and would really be hard for a longstanding software company to grasp (though I have to point out that Talis is very much an exception). Most customers buying enterprise software wouldn't want to share their data with peers anyway, right?
But that is really a non-issue for libraries, and precisely what this Web 2.0 world calls for, and what OCLC has been doing for a long time. OCLC has this valuable data, and great potential to develop things with it, as well as a general current towards network-level computing moving in its favor. When libraries compare OCLC's products with that of a traditional ILS vendor, they need to see that the OCLC product is more than technology. Rather, it is an extension of a community, a network. The commercial vendors just can't offer that.
OCLC doesn't really have a monopoly on bibliographic data. But they definitely are one of the largest players out there, and their data could put them way out ahead. They are in a position to create an impressive platform with their WorldCat.org line of products. As they do this, they should build it so that it's open enough that other companies and organizations can build products on top of it.
The model I'm thinking of is Flickr. Flickr is a great global platform for photo sharing, but through their API, Yahoo also lets other firms get in there and add value to it. OCLC should be build WorldCat as an information ecosystem that allows the library community to have a healthy marketplace of technology products. (They sort of have this model going with ILL, but there aren't too many competitors out there to OCLC's ILL management product, ILLIAD.) OCLC's new APIs for WorldCat are a sign that they are moving in this direction.
OCLC's competitive advantage in holdings data and shared cataloging applies largely to print materials. They really don't have any such advantage in the realm of electronic information: e journals, digital collections, etc.. They might be going after this with acquisition of companies like Openly Informatics and the ContentDM software, but even so, they are not in possession of data that gives them a competitive advantage in the same way as their cataloging and resource sharing networks. Many companies like ExLibris and Serials Solutions have e-serials holdings data. And data about library digital collections is generally open for harvesting/crawling.
Even in print material, Google Books could be a viable competitor to OCLC in the library search arena, especially because they have the advantage of full text searching. They have lots of data that OCLC doesn't. It would even be possible now with the Google AJAX search API to create a Google Book Search that linked back to your library catalog for books held in your library.
Last year, as part of my work with the Orbis Cascade Alliance's Catalog Committee, I got to survey the market for next generation library catalogs/discovery systems. In my mind, OCLC's WorldCat Group/Local option stands out against both the open source and commercial competition. Why? Because of network effects.
Competitors making products like ExLibris's Primo and Innovative Interface's Encore simply don't have access to the data that OCLC does, and neither does the open source community. OCLC's holdings data lets them do relevance ranking by the number of libraries that own the item. Its global database allows the potential of expanding a search beyond a single library or group of libraries to a global database with built-in ILL. WorldCat offers records that are updated and improved over time by shared cataloging, and the possiblity of enrichment of those records by web-scale social networking (reviews, tags, etc.). WorldCat is a living organism that can't simply be replicated on someone else's server.
These advantages are byproducts of the cataloging and resource sharing networks that OCLC has had in place for years. They are more about a community committed to sharing resources than about technology.
It's also about exclusive access to data, which fits in nicely with Tim O'Reilly's Web 2.0 tenant, data is the next Intel Inside.
Another way to think about this is that OCLC is in a position to be a sort of EBay for libraries. EBay is valuable precisely because of its wide user base. It is the dominant player in online auctions because it offers the widest possible marketplace for buyers and sellers. That same comprehensiveness and global scope also has value when building a search system for books and doing resource sharing.
Traditional ILS vendors have little tradition of sharing data between their customers. I really can't imagine Innovative Interfaces putting together any kind of product that involves mixing customers data (that weren't part of a consortium doing direct business with them). The whole idea of mixing customer data seems like it would run counter to traditional notions of enterprise level systems, and would really be hard for a longstanding software company to grasp (though I have to point out that Talis is very much an exception). Most customers buying enterprise software wouldn't want to share their data with peers anyway, right?
But that is really a non-issue for libraries, and precisely what this Web 2.0 world calls for, and what OCLC has been doing for a long time. OCLC has this valuable data, and great potential to develop things with it, as well as a general current towards network-level computing moving in its favor. When libraries compare OCLC's products with that of a traditional ILS vendor, they need to see that the OCLC product is more than technology. Rather, it is an extension of a community, a network. The commercial vendors just can't offer that.
OCLC doesn't really have a monopoly on bibliographic data. But they definitely are one of the largest players out there, and their data could put them way out ahead. They are in a position to create an impressive platform with their WorldCat.org line of products. As they do this, they should build it so that it's open enough that other companies and organizations can build products on top of it.
The model I'm thinking of is Flickr. Flickr is a great global platform for photo sharing, but through their API, Yahoo also lets other firms get in there and add value to it. OCLC should be build WorldCat as an information ecosystem that allows the library community to have a healthy marketplace of technology products. (They sort of have this model going with ILL, but there aren't too many competitors out there to OCLC's ILL management product, ILLIAD.) OCLC's new APIs for WorldCat are a sign that they are moving in this direction.
OCLC's competitive advantage in holdings data and shared cataloging applies largely to print materials. They really don't have any such advantage in the realm of electronic information: e journals, digital collections, etc.. They might be going after this with acquisition of companies like Openly Informatics and the ContentDM software, but even so, they are not in possession of data that gives them a competitive advantage in the same way as their cataloging and resource sharing networks. Many companies like ExLibris and Serials Solutions have e-serials holdings data. And data about library digital collections is generally open for harvesting/crawling.
Even in print material, Google Books could be a viable competitor to OCLC in the library search arena, especially because they have the advantage of full text searching. They have lots of data that OCLC doesn't. It would even be possible now with the Google AJAX search API to create a Google Book Search that linked back to your library catalog for books held in your library.
Labels:
Google Book Search,
III,
Innovative Interfaces,
OCLC,
WorldCat Local
Farewell INNREACH, Hello WorldCat
It was just announced that the Orbis Cascade Alliance is moving its Summit union catalog to an OCLC platform.
This is great news and a truly bold move for the consortium considering how comfortable it has been using Innovative Interface's INNREACH product. Indeed, INNREACH, has served the Alliance well over the years.
The replacement product might sound a bit confusing: "a consortial borrowing solution based on the integration of WorldCat.org, VDX, WorldCat Resource Sharing and a new circulation gateway. " Here's a primer
This is great news and a truly bold move for the consortium considering how comfortable it has been using Innovative Interface's INNREACH product. Indeed, INNREACH, has served the Alliance well over the years.
The replacement product might sound a bit confusing: "a consortial borrowing solution based on the integration of WorldCat.org, VDX, WorldCat Resource Sharing and a new circulation gateway. " Here's a primer
- WorldCat.org is the search interface and global bibliographic database and can be scoped into group (union) and Local catalogs; the Alliance will be creating a group catalog that will act like a union catalog for its member's holdings, but some members may opt to buy WorldCat Local.
- VDX is a product that handles materials workflow between libraries
- The "circulation gateway" is a yet-to-be developed product by OCLC that will connect VDX to the circulation systems of various ILSs, in our case III
- WorldCat Resource Sharing is OCLC's system of moving ILL requests between libraries
Labels:
Innovative Interfaces,
OCLC,
Orbis Cascade Alliance
Wednesday, April 2, 2008
Lorcan Dempsey on The Big Switch
Lorcan Dempsey has just posted some thoughts on Carr's The Big Switch. I like this quote:
Meanwhile, I must confess that I have yet to read The Big Switch, just excerpts from it on the web. I've put a hold on our library's copy of it (I think I know who has it checked out).
The 'big switch' is going to be a major issue for libraries over the next few years. They spend too much time getting their systems to work, and not enough time putting them to work.Thanks to him for linking back to synthesize-specialize-mobilize.
Meanwhile, I must confess that I have yet to read The Big Switch, just excerpts from it on the web. I've put a hold on our library's copy of it (I think I know who has it checked out).
Tuesday, March 25, 2008
bibliographic utility computing
As OCLC re-invents itself from a staid bibliographic utility to a company that can provide "next generation" library services, it's funny how that old fashioned term "utility" takes on a new meaning.
I was at the Orbis Cascade Alliance Council meeting last week as the group was discussing the possiblity of a partnership with OCLC for a group catalog on the WorldCat.org platform. As I reflected on the consortium's potential move from an isolated, server based union catalog, to one that lives in the cloud I thought about how this decision parallels those that many organizations will be making in the next few years as they make what Nick Carr has dubbed, The Big Switch to utility style computing. OCLC likes to call this "moving to the network level," but I think it's also just as much a move to "cloud" or utility style computing.
I'd heard most of what the OCLC sales force had to say at the meeting before. But one thing that struck me was how they explained the point of worldcat.org. OCLC believes that libraries need a "presence" on the web like EBay, Amazon, or Google. And that presence needs to be two-way, meaning users interact with the site and their interaction improves it.
If WorldCat is able to become a real "presence", maybe more database vendors will be open to representing their content in it and it will become a federated search killer. Maybe libraries can have more control over the digital content they give their users vs. just sending them off to an external, commercial website.
Where does local customization and control play in this potential juggernaut? Hopefully OCLC will keep opening up their APIs, and let libraries still have the ability to customize their own records in various ways.
I was at the Orbis Cascade Alliance Council meeting last week as the group was discussing the possiblity of a partnership with OCLC for a group catalog on the WorldCat.org platform. As I reflected on the consortium's potential move from an isolated, server based union catalog, to one that lives in the cloud I thought about how this decision parallels those that many organizations will be making in the next few years as they make what Nick Carr has dubbed, The Big Switch to utility style computing. OCLC likes to call this "moving to the network level," but I think it's also just as much a move to "cloud" or utility style computing.
I'd heard most of what the OCLC sales force had to say at the meeting before. But one thing that struck me was how they explained the point of worldcat.org. OCLC believes that libraries need a "presence" on the web like EBay, Amazon, or Google. And that presence needs to be two-way, meaning users interact with the site and their interaction improves it.
If WorldCat is able to become a real "presence", maybe more database vendors will be open to representing their content in it and it will become a federated search killer. Maybe libraries can have more control over the digital content they give their users vs. just sending them off to an external, commercial website.
Where does local customization and control play in this potential juggernaut? Hopefully OCLC will keep opening up their APIs, and let libraries still have the ability to customize their own records in various ways.
Labels:
Big Switch,
III,
Innovative Interfaces,
OCLC,
utility computing,
WorldCat Local
Tuesday, November 20, 2007
OCLC and network level services
OCLC is loading up on the big names in the digital library world. Of course, they've had Lorcan Dempsey for awhile. They recently picked up Roy Tennant and most recently, they hired Andrew Pace as Executive Director of Network Level Services. That job title makes me think that Dempsey had something to do with designing the job. An old OCLC hand out here in the Pacific Northwest recently referred to him as "Lorcan our prophet." Apparently he really does have a hand at shaping company strategy.
I know Andrew Pace some from the '06 Frye institute and offer my congratulations to him. I always used to see his columns in Computers in Libraries and think he was just another dork writing about library technology. At Frye, I discovered that he's a pretty enjoyable and interesting guy to listen to and in person is always dropping this funny, sometimes southern flavored aphorisms when describing various dilemmas and situations in the library world. I guess "lipstick on a pig" might be an example. I think he'll do a bang up job in this new position. As much as he's a thinker and observer, I know he's also a doer, as the NCSU catalog demonstrates.
In my humble opinion, OCLC has a lot of work to do on their "network-level" services. Here's a few areas where they could stand to improve:
I know Andrew Pace some from the '06 Frye institute and offer my congratulations to him. I always used to see his columns in Computers in Libraries and think he was just another dork writing about library technology. At Frye, I discovered that he's a pretty enjoyable and interesting guy to listen to and in person is always dropping this funny, sometimes southern flavored aphorisms when describing various dilemmas and situations in the library world. I guess "lipstick on a pig" might be an example. I think he'll do a bang up job in this new position. As much as he's a thinker and observer, I know he's also a doer, as the NCSU catalog demonstrates.
In my humble opinion, OCLC has a lot of work to do on their "network-level" services. Here's a few areas where they could stand to improve:
- ILL: the current mish-mash of products for managing interlibrary loan is pretty lame and is a real time sucker for library systems people. In most situations, these include an ILL management system (Clio/Illiad) for workflow management and patron interaction, a system for sending and receiving documents (Ariel), and the OCLC resource sharing network. There's no reason that OCLC shouldn't be able to provide a comprehensive ILL management suite including document exchange, workflow, and patron interaction as an entirely web-based, hosted tool, and offer it as a basic part of their ILL service.
- Digital collections software: ContentDM is a relic from the 1990s. It's a strange hodgepodge of C code and PHP, is clunky as hell, not to mention that it produces the ugliest looking URLs and no page titles, making it terrible for search engine crawling. Someone good at Ruby on Rails could build a better piece of software in a weekend. (Perhaps I'm just a little annoyed with it right now because I've been working on getting a Google Search Appliance to index our ContentDM collections) OCLC should be offering a fully hosted, web scale digital asset management system with web-based client software on par with somthing like Flickr. They could offer migration from ContentDM
- Semantic web strategy: OCLC needs to follow the Talis into the semantic web space. They need to be designing systems that share data in an open fashion.
- WorldCat Local: This is where OCLC has got it most right recently, in my opinion. If they add an API, and make the UI more customizable, and allow for localized versions of records, they'll be in business.
- Partnerships with large-scale players: OCLC is positions to make partnerships with big players in the information space like Google. They've found ways to bring library assets into Google's space, perhaps there are ways to bring Google assets like Scholar and Books into the library space (a Google Books/WorldCat Local integration?).
- Data exchange: if you've ever had to get your data up to OCLC in batch form, you've most likely experienced pain on par with visiting the dentist for a minor procedure. Their procedures for doing things like local data record uploading are horrendously slow and bureaucratic. WorldCat will never truly be a universal catalog for library assets if OCLC can't streamline methods for updating data in WorldCat.
Subscribe to:
Posts (Atom)
