Indeed, one of Elsevier’s prototypes seems more fitting for high school or undergrad classroom discussions, especially if they were to take into account Lagendijk’s points about context.

Credit: RT @atmire: RT @jimtill: #OpenAccess Elsevier going the wrong way: http://bit.ly/D16Am

At MPOW we’re hoping to migrate the library’s static HTML web site to the Drupal CMS. We’ve been using Drupal successfully for a year and a half for an offsite affiliate project and for a SEPA grant-funded project.  We have access to develop the current site using .NET when we want, but we don’t have the resources to do any significant development. Lack of PHP (and MySQL) support on campus is the only thing that has kept us from making the jump to Drupal.  While we have an ample ‘Nix VPS to host it on, I’m concerned that we don’t have the resources to maintain and update Apache or the PHP and MySQL frameworks.

Our current Drupal projects are hosted on inexpensive shared hosting which has been mostly sufficient for what we need including shell access, SVN, CVS, and Apache .htaccess capability. I don’t have to worry about updates to Apache, PHP, MySQL, or the OS.  If we were to host the library’s web site offsite as well, I’d want the best of both worlds: reliable support, a managed environment, dedicated RAM and processor cycles, but also full access to Apache’s httpd.conf.  Pair Networks is attractive for all these reasons. Also, our current host doesn’t support Java/Tomcat/Jetty which means we’d still have to host Solr separately on campus and manage access to it from other applications. Tomcat or Jetty support on the same host would be nice, but it’s not a deal-breaker.

Why do we want to migrate to Drupal? For many of the same reasons hundreds of other libraries and thousands of organizations do:

• a huge, and growing, user community,
• an overwhelming number of user-contributed themes and modules that extend Drupal’s core functionality,
• Drupal’s flexibility for modeling and displaying content,
• Drupal’s taxonomy and tagging support.

But these are all means to the end. In the end, we want our web site to deliver information well and make it easy for people to find what they want or learn how to get what they want.  David Lee King, Topeka’s Digital Branch Manager, recently offered 10 reminders that we strongly identify with.

Based on our experience with Drupal so far and conversations we’ve been having for a long time, here are some things we want to do.

• Make it easier and more enjoyable for our staff to post or update content to the web site.
• Improve how we provide news about library resources and services. Patrons can subscribe by email or RSS to various “channels”, e.g. type of content, subject, author.
• Advertise “featured” content and give our “marquee” an extreme makeover that showcases what’s happening.
• Create subject guides and more audience-oriented channels of content without unnecessarily duplicating content. Example, “you’re into pathology? Here are the best available resources for you. Oh, and here’s what’s new in PubMed and here’s a librarian to contact. In the hospital? Sure. Here’s the set of online clinical resources, image collections, and what we have on the shelves.”
• Integrate metadata from Voyager, the institutional repository (DSpace), and Serials Solutions using the Extensible Catalog Drupal toolkit to create a better discovery layer across all our resources, i.e. open up the silos.… And to put it into context with the rest of our content.
• Integrate content from other sites.
• Manage FAQ’s.
• Improve library instruction, i.e. “where-to-find, how-to-use”, without duplicating content.
• Encourage conversation and feedback by giving patrons the ability to comment on the web site or in whatever social network(s) rule the day.
• Distribute content between multiple “affiliated” sites, between the Library web site and project/partner sites.
• Support mobile devices.

We’re confident we can accomplish them with Drupal (and yes, Solr) in a relatively short amount of time.

ApacheSolr provides search and faceting.

Better still, HILCC is licensed under Creative Commons.

Ægir is a new set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

We’ve been successfully running multiple sites on a single development installation for several months.  Presently we only have a single site in production, but will likely be ramping up soon to roll out one or two others. Aegir should certainly help distribute administration of those sites.

Context sounds like another useful module. We currently use Panels module in Drupal 5 which has a very nice, yet somewhat limited, built-in context feature. I have a hate-love with Panels and would like to avoid using it in cases when I only need context without the accompanying box model.

Spaces module appears to go hand-in-hand with Context.

Spaces allows features (a blog, calendar, casetracker, shoutbox, gallery, etc.) to be enabled and customized in different configurations in different spaces…. Spaces features are essentially context definitions with some additional metadata. Once exported to code, spaces features can be bundled with exported views, implementations of the space settings class, and other niceties to create packaged, ready-to-go features.

Not exactly sure what that all means yet. It’s still in alpha for Drupal 6 only at this point.

FeedAPI is another developmentseed module we have been using. FeedAPI has been very handy for aggregating news from the likes of MedlinePlus, CDC, and others, and then turning those news items into nodes.  Nicely done.

Finally, the eXtensible Catalog Drupal Toolkit is not a developmentseed project, but one I’m anxiously awaiting any release of. Mlen-Too Wesley, one of the developers, gave a lightning talk in February at Drupal4LibCamp. There’s also a screencast. The XC Project just announced release of their OAI and NCIP Toolkits so hopefully the wait won’t be terribly long.

It seemed simple enough.  My first thought was to pull an RSS feed from DSpace into Yahoo! Pipes or a similar service. Then I would deploy a javascript widget from there.

Problem #1: Ideally you don’t want your RSS feeds spouting 80 items starting back in the 1990’s.

Problem #2: By default, the data in the feeds isn’t rich enough.  I need journal, volume, issue, etc.

My next go at it was to use DSpace’s OAI-PMH provider. This makes more sense than RSS. The data is rich, it’s all there, and I can specify sets or date ranges using Collection handles.

So what’s the drawback? The default metadata format for OAI in DSpace is oai_dc, i.e. unqualified Dublin Core, making it nigh impossible to distinguish published date from deposited date and publication source from handle URI.  This would exponentially complicate my simple little Pipe and make my brain hurt…alot.

The solution? Apply a Metadata Crosswalk Plugin for exposing QDC in OAI.  DSpace 1.5 even includes a preliminary crosswalk for this.  One more reason to expedite moving to 1.5.x.  We’re almost there anyway.*

*We’re still running DSpace 1.4 in production which does have a crosswalk plugin implementation known as XSLT Crosswalk but I’d rather devote my time to the upgrade.

Lucky for you and me there is very good help available. Here’s what I used:

1. Jump to Step 4 of Rails Deployment and Installation at IT.Signals. You’ll need to customize your configuration with whatever ports and IP or server address you have. I also needed to create the tmp/pids directory inside my Bibapp installation directory. Replace [path to]/testapp with [path to]/[bibapp] as appropriate. Replace environment: production with environment: development if that’s how you roll.
2. Save your new mongrel_cluster.yml to the Bibapp config directory. Start up mongrel_rails cluster to make sure its working on all the ports you expect. Stop when you get to Step 5. We need to setup the cluster so that it will be restarted when the server is rebooted. At this point, we’re going to deviate from these instructions, but you may want to return to them later if you want load balancing across your cluster. Refer to the Nginx section in Step #5.
3. Copy the mongrel_cluster Recipe kindly provided by Joyent and paste it into a new XML document named mongrel_cluster.xml. As instructed, customize the <instance/> properties for your Bibapp install. Save this file to /var/svc/manifest/network/mongrel/ on your server. This file is known as a service manifest to SMF. Unix/Linux use etc/init.d and rc scripts for defining and administering services. Solaris 10 replaced this with a new framework known as SMF. SMF is well documented on Sun’s blog. The SMF Manifest Cheatsheet is another good reference to the manifest properties.
4. Jump to Step 3.4 Create service manifest of Convert legacy_run service without reboot. Run

      1: svccfg import [path to mongrel_cluster service manifest]

5. If successful cd to [bibapp] and proceed to Step 4 for enabling your newly installed mongrel_cluster service:

      1: svcadm enable mongrel/cluster:bibapp

As mentioned earlier, once you have your cluster running it makes sense to do some load balancing for your production environment.

Good luck!

Having been a frequent reader of Deepak Singh’s business|bytes|genes|molecules blog over the last year, I was interested to see him hired by Amazon as business development manager of Amazon Web Services.  On December 04, 2008, Deepak posted to the AWS blog the announcement of Public Data Sets on AWS.  PDS on AWS is a data sharing experiment that takes advantage of Amazon’s in-the-cloud storage and computing services.

Just two weeks after Deepak’s post, Clint Boulton at eWeek confirmed that Google had axed its own Research Datasets project along with other projects of questionable value to Google’s bottom line.  While sharing data across the web, publicly or not, will surely become more common among researchers, milking copious amounts of ad revenue from that sharing is less likely.

The storage and computation of large datasets appears to be more in line with the AWS business model and perhaps Amazon has the lead on scalable architecture to support cloud computing.   Even if large numbers of researchers and research projects store and crunch their data on the web, that in itself won’t score big in the social web scene.  Programmers, analysts, and machines are more likely to be interfacing directly with the data than are the research investigators themselves.

It’s yet to be seen what Microsoft’s strategy for data storage might be in the recently released Azure platform, but they obviously have eyes on the educational and research markets.  Products like live@edu and SharePoint are increasing Microsoft’s reach into the academic computing world.

The Microsoft Research group quietly released a beta version it’s own repository software, running on .NET and SQL Server of course, but this isn’t just a reformulation of Dspace using Microsoft ingredients:

“The platform focuses on the management of research assets-such as people, papers, lectures, workflows, data, and tags-as well as the semantic relationships between them.”

Sounds like they’re paying attention.  And they’re beginning to appeal in ecumenical fashion to the larger research community by offering things like OfficeSWORD and taking part in discussions about open research repositories.

What is most interesting from the perspectives of the library and the university’s research office is how these services will redefine our notion of the “institutional repository”.  On one hand, many IT services such as web hosting and email have been commoditized to the point that institutions, especially smaller publicly-funded campuses, are unable to resist the cost savings and agility that come from hosted services like live@edu.  Why not commit fully to the .NET architecture and have your institutional repository software and data hosted on Azure as well?

On the other hand, why not take advantage of AWS’ flexibility and scalability for storing data or running our repository application?

Regardless of the platform(s) we choose, our notion of “institutional repository” is going to be stretched as we want to aggregate data and services from multiple platforms.  How will our Dspace service reflect our data stored in AWS?  The building blocks are already in place to support more complex relationships between our repositories, services, and data.  The time has finally come to put them to work.

…the popular search engines perform full text searches of unstructured text but enterprise content is much more structured than content in the Internet at large, it often contains fielded data in databases, and it is often hierarchically organized. Federated search vendors that want to sell into the enterprise need to consider this important difference.

True. However, Google isn’t new to enterprise search and they’re quick to point out that the algorithms they use for web content aren’t the same as for the GSA. Nevertheless, I am curious to know if it’s Google or MuseGlobal doing the relevancy math.

Sol also makes an interesting prediction about the impact the product will have on the market:

For better or worse, I think this offering will get many potential customers to view federated search as a commodity. Thus, it will force the high-end federated search vendors to work even harder than they do now to differentiate themselves from their low-end competitors. I can see it now: prospective customers will start using Google as a reference for product comparisons and will expect vendors to provide cheap and simple solutions.

My information, including an article at Information Today, says the AAC will run, in most cases, at least $50,000 plus over two years. That’s in addition to the cost of the Google appliance. I’m not sure which competitors or price tags Sol considers low-end in the federated search space. I wouldn’t consider this low-end. In my experience, such a price point might actually hit a sweet spot where only a couple of vendors exist now, especially for organizations that have already invested in Google search.

OpenCollection

collections management and online access application for museums, archives and digital collections.

Sophie

software for writing and reading rich media documents in a networked environment.

SEASR/NEMA

rich media analytics for humanists and artists.

Policy Archive, policyarchive.org

DSpace repository using the Manakin XMLUI. A comprehensive digital library of public policy research.

IMS Learning Tools Interoperability (LTI) v2.0

guidelines for the interaction of tools with learning/course management systems. This is really about decoupling functionality from any single LMS. It would create a more pluggable model, enabling faculty or students to be application producers and Learning Management Systems and other applications to be consumers.

Fluid Project

collaborative project for developing and distributing a library of sharable customizable user interfaces designed to improve the user experience of web applications. Fluid is not only developing component libraries, but is also churning out research, education, and outreach about how to design user experiences.

VIVO at Cornell

discover who at Cornell is working on a particular research topic; what they’ve taught or published recently; where facilities might be and what online tools are available to expedite research. Powered by RDF and Semantic Web technologies.