PALINET Discovery Tools

How many of you blog? Do you like your blogging software’s editor? If not, you have some options: if you run your own server, you may be able to install a plug-in for your blogging software that replaces the default editor with a different one. (For WordPress users, this search will find a couple of choices. Then again, if you haven’t yet upgraded to WordPress 2.5, you might want to wait until you do. The new WordPress has an upgraded editor and a full screen editing mode that are really pretty good.)

Another option, is to do what I’m doing now: write your post in Google Docs, and then upload it to WordPress. To get started, go to Google Docs and click on the Settings link. In the Documents tab, find “Blog settings”. Once there, you can enter the name of your blog, its location, and your login information. Once you’ve saved these settings, write a post and press Publish, then click on “Post to blog”. That’s all there is to it.

There are two caveats to watch out for, when you post to WordPress this way:

1. You may have to go to your blog to add a title to your post, depending on the API you are using.
   
2. There doesn’t seem to be any way to tag your post in Google Docs yet, despite a note to the contrary in the blog settings. So you may have to add tags to your post, after transferring it from Google Docs.
   

Most blogging applications have an API that will allow you to communicate with the blog from outside the application. Here’s a list from Google that shows most major blogging applications, the API they use, and the form of the URL to use in the Google Docs settings.

Finally, you can e-mail your post to your blog. Most applications allow that too. (In WordPress, look under Options/Writing/Post via e-mail.) But, of course, then you have to use your e-mail software’s editor. I don’t know about you, but I’d rather write raw HTML.

I just added a new Widget to my blog. If you click on the Random Technology Books link (under Pages) you’ll go to a random page of books from my LibraryThing collection. The cool thing is that I can limit the books you see by the tags I’ve assigned. So I can create a special Discovery Tools list, or just show everything. Right now, the page shows books I tagged “Technology”. Fun.

At the recent Code4Lib Conference in Portland and the VALE Next Generation Academic Library System Symposium at The College of New Jersey, I was involved a series of conversations with colleagues about the open source discovery tools, the new OCLC Grid Services WorldCat API, and the roles that library consortia might play in creating better library systems. Reflected in those conversations, are two apparently diverging trends that might, in fact, be brought together by new technology. On the one hand, there are libraries, tired of the limited functionality and restrictions placed upon them by their current ILS, creating new, custom, (and often open source) discovery tools on top of their ILS. Their goals include better search interfaces and functionality, integration of digital repositories and other local data, and better integration with existing library and institutional website designs. This would seem to be a trend towards greater customization of library software interfaces.

On the other hand, there is the old, but ongoing movement towards consolidation of metadata across many institutions, driven by the desire to increase access to information, and the need to reduce costs through resource sharing and economies of scale. OCLC has been working in this arena for years. But also driving this trend is the frustration many librarians feel with the expensive and yet inadequate federated search systems that are currently available. Complaints about federated search options center on performance and lowest common denominator search functionality (due to inconsistent metadata across systems and inconsistent implementation of searching standards and communications protocols.) I heard virtually the same blunt comment at both conferences, “Federated search doesn’t work.”

So, on the one hand, we have the desire for a unique interface and integration with local systems and resources, and on the other hand, we have the need to share a common metadata store. How are these trends to be reconciled? One answer is to continue to consolidate metadata in large repositories such as WorldCat, but to separate those data repositories’ data stores from their discovery layers and to connect the two with an application programming interface or API. Happily, the folks at OCLC seem to have seen the light. The new WorldCat API promises to allow library software developers to create local discovery systems that integrate local search results with search results from the vast WorldCat store of library metadata and holdings information. David Walker from California State University demonstrated just such a system at Code4Lib.* What would make the WorldCat API even more useful is if OCLC were to make available through it, metadata harvested from the many public data stores accessible on the network—such as they’ve begun to do with WorldCat Local. The ability to add (for a fee, of course) access to commercial metadata would make the API a better service yet. It’s not clear what OCLC’s plans are, in this regard, but if you are an OCLC member and you are engaged in or thinking about creating a new discovery tool for your library, now would be a good time to be talking to OCLC about this new service.

This same approach of formally separating the discover layer from the data store might be used in a consortium setting. One barrier to the successful implementation of shared systems in large consortia can be the reluctance of larger institutions (or those with significant systems support) to give up local control over their search interface. Might we see a consortium some time soon that offers a shared ILS or union catalog with both a shared discovery tool and a full-featured API that libraries could choose to use in conjunction with their own locally developed discovery tool? Or might we see a consortium that produces only an API to their system? There are various open source projects in active development now that could be enhanced to work in such a system. They include Villanova’s VuFind, The University of Virginia’s Blacklight project, and Oregon State University’s LibraryFind. What features would such an API (or set of APIs in the case of a full ILS) have to support in order for such a system to work? Where are additional APIs needed?

The Digital Library Federation (DLF) seems to have set out to answer just those questions. At one of the sessions at Code4Lib, Emily Lynema and Terry Reese discussed a draft report from the DLF ILS Discovery Interface Task Force, which attempts to outline, broadly, a set of functional requirements and related standards that would be needed to separate discovery layer from the rest of an ILS. You can add your comments on this draft at their wiki.

*I recorded a podcast with Don Hamparian, OCLC Portfolio Manager for the WorldCat API and David Walker while at Code4Lib. Look for it, as the next in the Technology Conversations series of PALINET Podcasts.

Lately, I’ve been doing a lot of work on the PALINET Leadership Network (PLN), which is one of three MediaWiki wikis that I manage for PALINET. PLN is a resource for library leaders edited by Walt Crawford. You can see Walt’s comments on PLN in his blog, but I thought some of my experiences setting up the wiki worth noting too.

The MediaWiki software is, not surprisingly, given its origin with Wikipedia project, both open source and designed to be extensible. That is to say, its developers have made some provision for allowing other developers to add new features to the system. This is fortunate for PALINET because we need the PLN system to do some things that the MediaWiki base code does not. Many developers have written extensions for the MediaWiki software. Here’s a list of some the third-party extensions we have found most useful.

• SimpleFeed - This extension allows you to display entries from an RSS feed in your wiki. It uses the SimplePie PHP code library for processing the feeds. This extension works well, but I wish it supported Atom feeds.
• New User Notification - This one just sends an e-mail message to someone, whenever a new account is created on the Wiki.
• Poll - This extension makes it incredibly easy to add a poll to any wiki page. Unfortunately, the code is out-of-date, and installing it took some tweaks. Send me a note if you need help with it.
• Firestats - Technically, this one isn’t a MediaWiki extension. Rather it’s a web server statistics package with a web interface. But there is a MediaWiki extension for it that facilitates collecting statistics specifically for your wiki.
• PDF Export - This one adds a new link to the Toolbox that will create a PDF file without the sidebar or menu information from any wiki page. It facilitates printing and distribution of wiki content.
• NamespacePermissions - This extension makes managing permissions for protected spaces within your wiki a little easier. Permissions are still a pain to set up. The MediaWiki software was not designed to accommodate protected content.
• MWBB - This is an extension for creating forums within your wiki. It also contains optional functionality for supporting personal messages (e-mail) between wiki users.  (We’re not using that.) Unfortunately, it no longer appears to be under active development and did not install without errors and a few tweaks, but the discussion page on the mediawiki.org site does contain clues how to fix the problems.
• Category Tree - This extension allows you to display a hierarchical category structure within your wiki. It requires that AJAX be turned on for your wiki.

In addition to other people’s extensions to MediaWiki, I added one bit of functionality myself. We wanted a way to evaluate new MediaWiki accounts and to restrict access to some content to persons affiliated with the library community. Two changes were required. We needed to add one field to the login form, and we needed to allow a group of people to quickly and conveniently approve new accounts for access to restricted materials.  The solution was a system that sends e-mails to a group of approvers when an account is created, and which allows those approvers to send a reply in a format that will result in the MediaWiki user being placed into a user group that has rights to the restricted material.  I was able to use standard Perl modules and smrsh functionality on our Linux server to create the new account approval system.

Overall I’ve found the MediaWiki software to be more difficult to extend than some other open source tools–Wordpress and Firefox for example. There are a couple of issues:

1. MediaWiki extensions must be installed by a system administrator with command-line access to the server; 
2. New MediaWiki versions tend to break old extensions (more often than I’ve experienced with other software) and programming skills are required to fix the problems.

Admittedly, part of the problem may have been the extensions that I chose. Another system administrator might choose extensions with more emphasis on stability and quality and less emphasis on obtaining specific functionality. On the other hand, my experience setting up WordPress and extending that software has stood in sharp contrast with MediaWiki. More on that, in another post.

Here are some technology trends to track (taken from PowerPoint slides) that I shared with colleagues at the PALINET 07 Conference +Vendor Fair in Baltimore.

Open Source Software

• Integrated library systems (ILS)
  • Koha
  • Evergreen
• Open source public access computing workstations
• Linux isn’t just for geeks anymore (Ubuntu)

Consolidation in the Library Software Marketplace

• These concerns have led to re-evaluation of vendors and products and a lot of interest in open source solutions
• New vendors organized to sell support services for open source software
• LibLime – Koha
• Care Affiliates – Various
• Equinox – Evergreen

New Privacy Issues

• Social software (Web 2.0) products that allow anyone to publish anything pretty much instantly, no matter how ill-advised it is (MySpace, Facebook)
• RFID technology that could, if it is used inappropriately, be used to track patron borrowing
• Web-based software that provides powerful new functionality at the expense of privacy (Amazon, LibraryThing)

Preservation Problems

• How do you preserve an online experience that is constructed with data from many different systems mashed together, when you own only part of the data?
• Proliferation of data standards for digital objects, some proprietary, which will require preservation of software and hardware as well as data in order to maintain accessibility
• Global warming
  • Will your library be under water in 10 years?

Applications that Migrate

• Google Apps and other software that originates on the web, but can migrate to the PC and be run even when you have no internet connectivity

Software as a Service

• More software available as a service
• Do you really need to host your own catalog?
• Should you host your own catalog (or website), when you could farm out that function more cheaply?

New Discovery Tools

• Searching interfaces that are independent of the ILS system
  • WorldCat
  • VuFind
  • LibraryFind
• Open source indexing and development libraries (software) that make development of sophisticated search interfaces relatively easy

The Public Library as Publisher

• Digital collections, book reviews, local history archives
• All made possible by the internet, inexpensive or free software, and commodity hardware

Easy Machine to Machine Communication

• Amazon APIs
• OCLC lightweight services (xISBN)
• OAI (XML)

Mobile Computing

• Ability to search anywhere, anytime
• New Services Based on RFID and Ubiquitous Connectivity
• Such as a resource notification service based on proximity and a user profile that sends notices to your cell phone when you enter a room

Very Low Cost Computers

• 100 dollar laptops (soon)
• Inexpensive lightweight terminal devices that can run OpenOffice off a Linux server and don’t have any moving parts to break

Does your library website need improvement? Do you work at a public library? If the answer to both these questions is yes, you might want to know about Plinkit. Plinkit is a toolkit for creating a public library website using the Plone open source content management system (CMS). It provides a really easy means for public libraries to create and maintain a high quality, well-designed, website, with some interactive features.

A demonstration version of a Plinkit library site is available at the Collaborative’s website.

Right now, four states have joined in a cooperative to support Plinkit development, documentation, training, and support: Colorado, Illinois, Oregon, and Texas. At a LITA presentation given by Darci Chapman Hanning (Oregon), Kristi Lindsey (Colorado), Sharon Morris (Colorado), and Tine Walczyk (Texas) on October 6, I learned that nearly 100 libraries have already set up websites using this toolkit. But the Plinkit Collaborative is actively looking for more sponsors to help them expand their coverage area, and is open to sponsors besides state libraries or library commissions. If you’d like to see this toolkit available in your area, please let me know. I’d like to track interest in it.

Yesterday I attended a session at the LITA National Forum in Denver entitled “Library 2023: Provoked Discussion on the Future of Libraries” which was ably led by Gregg Silvis of the University of Delaware Library. Gregg asked us to imagine a world in which there were 100,000,000 texts available for free, online. What would it mean to libraries, to scholarly publishing, to copyright? Least you wonder if we will reach that mark, Andrew Pace cited an Economist article that says Google is scanning 27,000 books per day. While few are comfortable with the idea of reading books online, I suspect that most in the room were willing to assume that there will a fix for this problem, whether it be an implantable device as Gregg suggested or low cost, eyeglass-mounted, head-up displays. So what is the library’s role in such a world? Some suggested that the library would become more virtual–a set of web-based services offered by librarians to a public largely unaware of the work being performed behind the scenes to make those services available. Others felt that the library would still be an important social place to visit, even if the resources there were largely digital.

One of the most salient points, to my mind, suggested during the discussion, was that while there are increasingly good tools for indexing and searching full text, high quality metadata is still essential to the discovery of pictures, video, and other multimedia objects. Digital repositories will produce lots of organizing and indexing work for those involved in their creation. Is your institution building a digital repository? If so, is your library involved in the project? It should be.

Here are the PowerPoint slides from a presentation I did on low cost web development techniques for creating an interactive website at WVLA, October 4, 2007 and again for PaLA on October 15. Mostly, the presentation was demonstration, but the slides list the various websites and software packages I used: Drupal, WordPress, and MediaWiki as well as services from Bloglines and Google. This is a demonstration version of a three day workshop I do regularly for PALINET.

Here are the PowerPoint slides from a presentation on social software that I gave at the West Virginia Library Association Conference held in Morgantown, West Virginia, October 2, 2007. In it I gave an introduction to social software, various web sites, online safety and privacy, and policy issues for libraries. I also included sample screens from MySpace, Facebook, and Flickr.

I recently have an informal talk entitled “Open Source: A Community Approach to Software Development” at PALINET. Some of the topics covered were

• Open Source Communities
• Open Source vs. Free
• Common Open Source Technologies
• Common Questions
• The Bottom Line
• Attitudes

I even included a little quiz at the end. Perhaps it may be of use.