Issue #20 of the Code4Lib Journal was just published, and I had the honor of being the coordinating editor for the issue. Being on the editorial committee of the Journal has been a heck of an experience, and I think I’ve had just a taste of what journal editors and publishers must go through to produce quality content.

My editorial focused on an issue that has banged around in my head for a while and has come up in multiple venues in recent years — how do we grow as a community while remaining responsive to the community and true to its roots. I suggest that there is a merit-based way to approach this, and I lay out my thoughts in that article.

In addition, the issue has seven great contributions from the community. The first set of articles show ways to manipulate metadata records.  In Workflow Tools for Digital Curation Andrew James Weidner and Daniel Gelaw Alemneh describe how they use AutoHotkey and Selenium IDE at the University of North Texas to automate various aspects of manipulating digital objects.  Heidi Frank show how to process MARC records from Archivists Toolkit in Augmenting the Cataloger’s Bag of Tricks; the techniques – using MarcEdit, Python, and PyMARC – are transferrable to other sources of records as well.  In Keeping up with Ebooks Kathryn Lybarger introduces a tool for updating batches of vendor-supplied records through a set of normalization routines.

Jason Clark show how Montana State University is using YouTube as a digital video platform in Developing a Digital Video Library with the YouTube Data API. Getting users what they want without extraneous hits is always a challenge, and in Better Search Through Query Expansion Using Controlled Vocabularies and Apache Solr demonstrates how to configure SOLR to make the best use of a hierarchical controlled vocabulary.  In Breaking Up With CONTENTdm Heather Gilbert and Tyler Mobley lead us through the migration of a repository to Fedora Commons using Drupal, Blacklight and Rutgers’ OpenWMS software.  And for the hardware geeks, Tim Ribaric and Jonathan Younker describe how to build a simple desk counter tied to a Google Spreadsheet in Arduino-enabled Patron Interaction Counting.

Last week I emcee’d the second Code4Lib Virtual Lightning talk session and I wanted to record some notes and pointers here in case me (or anyone else) wants to do the same thing again. First, though, here is a list of those that presented with links to the talks archived on Internet Archive.

The full session recording is also on YouTube. (If I get the time, I’d like to try a hand a cleaning up the automatically generated captions track as well.)

Here are the notes:

• The beep track was created using Audacity and its function to create DTMF tones. I’ll add the full five minute recording here in MP3 format, but next time I do this I think I’m inclined to add a minute or two to each presentation, so I’ll have to recreate the track.
• The beep track and my voice were combined in realtime my Mac using the two-channel Soundflower mixer. I was using a Blue USB external microphone, and needed the LineIn application to route the Blue microphone’s input into one of the Soundflower channels. (I couldn’t figure out how to route the USB mic input natively.)
• When you create a Google+ Event, you have the option of saying it will be via Google+ Hangout. I had set the start time of the event to 1:30 Eastern U.S. time, but wanted to open up the Hangout 30 minutes early so the presenters could come in and test the environment. I started an ad hoc hangout 30 minutes early, but right at the start time another Hangout was created and some viewers went there instead. I don’t think there is an elegant way around this, but next time I’ll set the start time of the event to include that 30 minute window and mention in the event description that it won’t really start until 30 minutes later.
• Warn the presenters about the start tones on the beep track. The start tones will cause the Hangout to focus on the em cee screen, which will have the title slide. Some presenters got eager, though, and talked before or through the beep track. Add 10 seconds to the first minute’s beep track time, then tell the presenters that leeway is built in.
• Download the MP4 recording from YouTube and split it using the QuickTime Player “Trim” feature. It helps to have QuickTime Player go fullscreen so you have a finer granularity on the editing times.
• Presentations in Prezi format did seem to work out fine.
• Remind other speakers to mute their mics when they are not presenting so they don’t steal Hangout video focus from the presenter. Hangouts-on-Air has a Cameraman app that might be useful in limiting who is seen/heard at any one time during the session. Explore this before the next session…

My employer (LYRASIS) is a member of NISO (the accredited standards organization for information and documentation in the U.S.), and as the primary contact I see and consider ballots for standards issues that impact LYRASIS member libraries. The Interlibrary Loan (ILL) Application Protocol Specification (a.k.a. ISO 10160/10161) is up for its periodic review, and there is a bit of interesting movement on this standard. ISO 10160/10161 became a standard in 1993 so it predates the modern era of the web. The group shepherding the standard realized that progress had overtaken the specification and they started work on a reformulation of inter-machine ILL standards. This ballot and its supplemental documentation gives a view of the plans.

The text accompanying the ballot says:

The future of this standard has been discussed by TC46/SC4 at both their 2011 and 2012 meetings. Following these discussions, a resolution was passed to “invite Danish Standards to prepare a NWIP [new work item proposal] in cooperation with other interested parties for a new ILL standard.” This proposal was forthcoming, based on discussions with representatives from USA, Canada, UK, Denmark, Finland, New Zealand, Japan, and Australia, and was presented in a ballot that ends on February 3, 2013. The proposal is expected to be approved and the new standard is intended to replace this current set of standards.

However, since the development of the proposed new standard and its subsequent implementations are expected to take several years, the committee has recommended that this existing ILL standard remain active in the interim. For this reason, it is recommended that you vote to CONFIRM this standard.

The ballot for the new work item indeed closed on February 3rd and was approved. There is now a document from the Finish Standards Association (embedded below) that goes into more detail about the plans for a new working group.

So the work begins…

I’ve put in a proposal on the importance of communities in open source software for an “ignite” session at the ALA Annual meeting in Chicago, and I’d appreciate your vote to get the talk into the program. If you have experienced the power and benefit of open source software, you know that the community is just as important as the code. In a 5-minute presentation accompanied by 20 slides that advance automatically every 15 seconds, I’ll be describing the many ways libraries can be a part of an open source community. Here is the brief description of the talk:

The open source method for developing software works best when everyone contributes a little bit to the process. Do you benefit from open source? Do you wish the open source you use was a little better? Don’t know why the community nature of open source is important? Hear what you can do to make the world a better place by nudging your favorite open source project along a path to perfection.

To get on stage I need your help! Part of the process for determining who will present sessions during the ignite times is based on votes from the community. Please log into ALA Connect and vote for my session. (If you are not an ALA member and are interested in library activities this this one, you can create an account.)

Thanks for your help in advocating for open source software in libraries.

This is a review of the Airbender Bluetooth keyboard by New Trent (model IMP38W). I have been testing this unit since January 28, 2013, and traveled with it to Code4Lib in Chicago where I relied on the combination of the Airbender keyboard and iPad for a day of presentations with writing notes and searching the web for information. I received the unit from New Trent for testing and evaluation.

Image from NewTrent.com

There is an unexpected benefit of the design when the iPad is left in the protective case but disconnected from the adjustable stand. The protective case surrounding the back of the iPad has a two-inch hole where the adjustable stand attaches, and without the stand that hole provides a comfortable place to grip the iPad protective case with the fingers of one hand while using the other hand to use the iPad. For casual iPad use without the keyboard, I have left the protective case on the iPad to take advantage of this feature.

The process of connecting the keyboard to the iPad over Bluetooth was straight forward and painless. It does take a bit longer than I expected for the iPad-keyboard connection to be established when waking up the iPad, but I do not know if this is common of all Bluetooth keyboards or if it is specific to the New Trent keyboard. The keyboard has extra buttons for controlling the iPad volume, screen brightness, and playback controls for play/pause/next-track/previous-track plus keys for going to the home screen, the iPad search screen, selecting the keyboard language and locking the iPad. The keys have a good feel despite the physical thinness of the keyboard itself, and it was easy for me (as a touch typist) to comfortably type without looking at the keys.

The keyboard charges via a standard micro USB connector using the supplied cable. The power supplied by a standard computer USB port is enough to charge the battery in the keyboard. I have used the keyboard for about 20 hours and have not had to recharge it yet.

I did have a few issues with the Airbender. The first is an unusual and unexplained problem with double letters appearing on the screen. I couldn’t reliably reproduce the problem to determine whether it was a mechanical problem with how the keypresses were being sensed or a software problem in which the software on the keyboard was sending more than one character to the iPad over the Bluetooth connection. The problem was somewhat rare — perhaps one keystroke in a thousand — which made troubleshooting even more difficult. The second issue was with the adjustable stand; the mechanism is stiff and difficult to get into the right position (although the stiffness does mean it stays put when the position is reached). I would have rather seen an unlocking/locking mechanism that would let the two parts of the stand move freely then lock into place with a lever or button. The third issue was with the manual. The illustrations were easy to read but the font used was too small and typeface too thin to read comfortably. There are key parts of the setup process that have to be read to make the Bluetooth connection between the keyboard and the iPad.

ResourceSync — a joint effort of NISO and the Open Archives Initiative (OAI) team with work funded by the Sloan Foundation — has published a draft specification that I urge members of the library technology community to look at. Building on the OAI-PMH strategies for synchronizing metadata, this project is modern web architecture technologies to enable the synchronization of the objects themselves, not just their metadata. From the abstract of the draft specification:

This ResourceSync specification describes a synchronization framework for the web consisting of various capabilities that allow third-party systems to remain synchronized with a server’s evolving resources. The capabilities can be combined in a modular manner to meet local or community requirements. The specification also describes how a server can advertise the synchronization capabilities it supports and how third party systems can discover this information. The specification repurposes the document formats defined by the Sitemap protocol and introduces extensions for them.

This specification is a beta draft released for public comment. Feedback is most welcome on the ResourceSync Google Group. I’m closing comments on this post, and urge you to send ideas, suggestions, and criticisms to the Google Group.

Last month’s HathiTrust newsletter had an interesting technical tidbit at the top about access to out-of-print and brittle or missing items:

One of the lawful uses of in-copyright works HathiTrust has been pursuing is to provide access on an institutional basis to works that fall under United States Copyright Law Section 108 conditions: works in HathiTrust that are not available on the market at a fair price, and for which print copies owned by HathiTrust member institutions are damaged, deteriorating, lost or stolen. As a part of becoming a member, institutions are required to submit information about their print holdings for fee calculation purposes. We have also been requesting information about the holdings status and condition of works, to facilitate uses of works where permissible by law (specifications for HathiTrust holdings data are available at http://www.hathitrust.org/print_holdings).

As of December 2012, we are using the holdings status and condition information submitted by United States member institutions, in combination with information about the market availability of works stored in the HathiTrust rights database, to determine whether or not access to applicable in-copyright works in HathiTrust is allowed. The specific terms of access are as follows:

• Access is only available to users affiliated with HathiTrust member institutions in the United States, and only from U.S. soil.
• In order to gain access, users from member institutions must be authenticated into HathiTrust via Shibboleth using their institutional login.
• Print copies of the works in HathiTrust must be owned currently or have been owned previously by the institution’s library system.
• The number of users who can access a given digital copy at a time is determined by the number of print copies held (or previously held) in the library system. If a library system only has one print copy, only one user at a time will be able to access the digital copy.

A general scenario for how out of print determinations are made and communicated to HathiTrust is available in the HathiTrust rights database documentation: http://www.hathitrust.org/rights_database#op. Additional information on the service is available at http://www.hathitrust.org/out-of-print-brittle.

It is the first three conditions (in the first two bullets) that I find interesting: that access is only available to affiliated users, that access is available only from “U.S. soil”, and that users must authenticate using a HathiTrust member institution’s Shibboleth identity provider. The only way I can think for HathiTrust to enforce the first two conditions is to use Shibboleth. Only through Shibboleth would HathiTrust have assurances that the user is a member of the community and is at a particular place. ¹ Libraries more commonly use rewriting proxy servers, like EZproxy, to facilitate access to restricted or licensed material. Rewriting proxy servers effectively hide the location of the user because to HathiTrust the user’s location would appear to be where the proxy server is.

I dug a little deeper to see if I could find a definition of “affiliated” — does it mean “only students, faculty and staff” or other looser forms of affiliation like “alumni” or “parent” or “guest”? One of the great strengths of Shibboleth (generally) and the identity management federations like InCommon (specifically) is that they have fairly rigorous definitions of “member” and “affiliated” — piggybacking on the eduPerson eduPersonAffiliation attribute definition. I didn’t find a firm linkage to those defined eduPerson terms, but I did find an interesting declaration in HathiTrust Digital Library Access and Use Policies: “Users must be authenticated members of a HathiTrust institution or individuals using a computer on a HathiTrust institution’s library premises.” That would both seem to simultaneously make the Shibboleth requirement redundant in cases where access came from an on-campus IP address and the question about the definition of affiliation moot — by that statement, anyone using a library terminal would have access even if they weren’t otherwise a member of the campus community. Hmmm, I wonder how they are resolving that contradiction?

Digging a little deeper, I found the HathiTrust Shibboleth technical details page where they talk about the kinds of attributes required to use the service. They do require ‘eduPersonScopedAffiliation’², so they can see the types of membership someone has with an institution. It is also refreshing that the only other element they require is eduPersonTargetedID — the “persistent, non-reassigned, privacy-preserving identifier” known only to the institution and the service. (The eduPerson definition goes on to say: “This attribute is designed to preserve the principal’s privacy and inhibit the ability of multiple unrelated services from correlating principal activity by comparing values. It is therefore REQUIRED to be opaque, having no particular relationship to the principal’s other identifiers, such as a username or eduPersonPrincipalName. It SHOULD be considerably difficult for an observer to guess the value that would be returned to a given service provider.”) It is great to see HathiTrust using the privacy-enhancing aspects of Shibboleth like they were meant to be used. Because they are using targetedID, a prosecuting party would need to subpoena records from both HathiTrust (to get the eduPersonTargetedID of the person they were interested in) and the member institution (to see who that eduPersonTargetedID was assigned to) to pin research activities to a specific individual.

Footnotes

1. Let’s set aside for a moment the relatively trivial ways that IP address geolocation can be fooled: VPN services, web proxies, etc. If you want to know more, just Google “how to bypass geographical restrictions”.
2. eduPersonScopedAffiliation is nearly the same as eduPersonAffiliation; it just tacks “@<institution>” on the end.

On December 6, 2012, the Audience and Participation workstream met at the Roy Rosenzweig Center for History and New Media at George Mason University. About two dozen colleagues participated in person and remotely via Google+ Hangout to talk about processes and strategies for getting content into the DPLA (the content hubs and service hubs strategy), brainstormed on the types of users and the types of uses for the DPLA, and outlined marketing and branding messages that aligned with the goals and technology of the DPLA while getting content contributors and application developers excited about what the DPLA represents. I’m happy to have been invited to take part in the meeting, am grateful to DPLA for funding my travel to attend in person, and came away excited and energized about the DPLA plans — if also with a few commitments to help move the project along.

Emily Gore, DPLA’s Director of Content, started the first topic by describing the mechanisms being set up to feed metadata to the DPLA database. The first version of DPLA will be an aggregation of metadata about objects various services and cultural heritage organizations around the country. The DPLA will leverage and promoting metadata coming through hubs, where a hub can be an existing large gathering of stuff (“content hubs” — think Harvard University, Smithsonian Institution, National Archives and Records Administration) or a hub can be a meeting point for state or regional content (“service hubs”). From the perspective of the Audience and Participation workstream, the service hubs are probably the most interesting because that will be how information about an institution’s content gets into the DPLA.

Just about every state in the country is covered by a state or regional digital library program, so the infrastructure is already out there to help organizations. The DPLA itself is aiming to be a small organization of about five to ten people, and at that scale it would be impossible to have a one-on-one relationship between the DPLA and all the possible organizations in the country. So the DPLA Service Hubs will offer a number of services in a region: aggregation of metadata from local repositories, help with new digitization and creation of associated metadata, and engaging participants in the region around different uses of the content in the DPLA. By the April 2013 launch of the DPLA site, the goal is to have seven service hubs operating and a similar number of content hubs. Some of the state and regional collaboratives have already reached out to the DPLA to join, and DPLA is working on updating a list of collaboratives that was created a few years ago. One path of outreach is through the Chief Officers of State Library Agencies (COSLA) group. Talking to state library agencies makes sense because there are indications that IMLS — who grants money to state library agencies — is aligning its LSTA funding with the goals of participating in DPLA. State humanities councils and ALA can also be venues for getting the word out. The ALA Washington Office can be especially useful for getting word to legislators about the importants and value of collaboration with the DPLA.

We talked about how there are technical tasks involved with adding new hubs to the DPLA — it isn’t as easy as just ingesting and indexing new metadata. There will be iterations of mapping adjustments, tuning the weighting of fields in the index, and other tasks, so DPLA will need to set expectations about how fast it can add new hubs to the service. It was noted in the meeting that the service and content hubs will in one sense be customers of the DPLA and in another sense will be providers to the DPLA. This relationship will be akin to a business-to-business relationship, and it will be important that the DPLA can provide adequate “customer support” to the hubs to make the relationship work out best.

The focus at launch is on cultural heritage objects, books, and manuscripts. The common denominator is that the metadata must be sharable under a Creative Commons Zero (CC0) license, allowing for the free reuse and remixing of the metadata. In this form, the DPLA will be an index of descriptive metadata that leads the searcher to where the item is stored at the contributing institution. That institution can specify other rights on the reuse of the digital object itself. Interestingly, the CC0 policy for metadata is a source of concern for some potential DPLA participants. Where libraries have less of a sense of ownership over the metadata describing their objects, the museum community has a higher sense of ownership because of the extra effort they put into creating and curating this metadata.

We talked for a bit about the impact that the visibility of DPLA will have on desires for organizations and even individuals to digitize, describe and electronically mount their content. (“If they have stuff like that, I have stuff like that, too, that I want to add.”) The DPLA can be helpful by providing clear pipelines for the processes for content to be added to places that will be harvested and integrated into the DPLA. Perhaps even bringing digitization “to the masses” by going through the local historical societies where there will be opportunities for conversation about what is good to keep and how to do it.

This discussion of what content will be in the DPLA lead into talks about the kinds of people using the DPLA and what they will want to use it for. The goal is to create “personas” of DPLA users — fictional representations that encompass research about the users, their motivations, and their desires. (As examples, we briefly looked at the HathiTrust personas and the earlier work on DPLA Use Cases.) The driving goal is to give these personas to the contracted developer (iFactory) for use in creating the initial front end website. As an aside at this point, the heart of the DPLA at this stage will be the aggregation, enhancement, and serving of descriptive metadata to software applications that remix and display results to users. One way, but not the only way, this will happen is via the http://dp.la/ website interface being created by iFactory.

What the #dpla behavior post-it notes look like. twitter.com/DataG/status/2…

— Peter Murray (@DataG) December 6, 2012

We brainstormed the possible labels for personas: Casual Searchers, Genealogy, Hardcore Enthusiasts, Wikipedia / Open Source Folks; info nerds, Small business / startups, Writers / Journalism, Artists, Students, Public School Teachers, Home schoolers, Scholars, Other Digital Libraries, State Libraries, Public Libraries / Public Librarians, Museums, and Historical Societies. We also brainstormed a whole slew of behaviors that these personas could do (several hundred post-it notes worth), and then grouped them into broad categories:

• Finding Specific Knowledge: school research, curricular-related; local/personal history; specific “laser-like” focus; open-ended, on-going activity; awareness of a body-of-knowledge problem
• Learn: skill-acquisition (things that take longer, as a project)
• Harvest and/or reuse: visualizations, build new collections
• Contribution: contribute content; enhance metadata (DPLA needs to be able to answer the question “I want you to add X”)
• Sharing/Connecting: outwardly-focused; using DPLA as a point to go out to other people, find partners, start a book group, sharing something cool with, friends; building community; connecting institutions, see what other libraries are doing, sharing content with other libraries
• General, accessibility: featurish-type notes

After a little more refinement in sorting and labeling, these behaviors will then be used to create the characteristics of the personas.

The last activity was talking about branding and marketing — how to get organizations and individuals excited about using the DPLA. A backdrop of this discussion is making people — especially funders — aware of how DPLA is an enhancement to every library’s services and collections, not a replacement for them. That the DPLA will be seen as complimentary to the local library came out strongly in the October DPLA Plenary session. Among the discussion of “what’s in a name?” (‘dp.la’ or ‘library.us’ or something else) and what is it that DPLA wants to pitch to users (the metadata platform, a single-entry homepage at http://dp.la/, or an app store of DPLA-enabled application), was a fascinating discussion about getting developers interested in the DPLA platform and programming interface. We talked about getting library school, college, and high school classes interested in building DPLA apps as term projects. We also talked about the role of existing organizations like Code4Lib and LITA in introducing and supporting developers creating applications using the DPLA platform.

In the end what emerged is a possible thread of activities from the midwinter meeting of the American Library Association (ALA) through the Code4Lib conference into South-by-Southwest and the annual ALA meeting. The thread goes something like this:

1. Petition LITA to form an interest group for DPLA activities at the ALA Midwinter meeting, and possibly hold a forum there for interested librarians.
2. Hold a half-day preconference tutorial at the mid-February Code4Lib meeting in Chicago covering example uses of the DPLA API, effective ways to process and remix JSON-LD data (the computerized format of information returned by the DPLA platform), and discussions of the content available in DPLA.
3. Use the Code4Lib meeting to launch a four to five-week contest for teams of developers to create interesting applications around the DPLA platform.
4. Show the entries at an already-arranged presentation at the South-by-Southwest conference in mid-March, and announce a winner.
5. Arrange for space at the ALA Annual meeting in June in Chicago for a more in-depth discussion and exploration of DPLA.

The hook for developers is showing them a new, vast store of liberated data that they can use to remix with other data, create absorbing visualizations of the data, and facilitate user engagement with the data. The DPLA is going to become a huge set of liberated data, and we think that can be attractive to not only library developers but also developers outside the traditional library and cultural heritage community.

And with that we ended the meeting at George Mason University. As I said in my previous post recounting the November Appfest meeting in Chattanooga, these are exciting times when the reality of the DPLA vision can start to be seen. I’m eager to see, and participate as much as I can, in the effort.

The Digital Public Library of America held an AppFest gathering at the Chattanooga Public Library on November 8-9, 2012 for a full day of designing, developing and discussion. About 40 people attended from a wide range of backgrounds:

• Public libraries, academic libraries, companies, library consortia and other groups.
• Designers, user experience professions, metadata specialists, coders, and “idea people”.
• A variety of U.S. states and Canadian provinces.

One of the primary purposes of day was to test the DPLA application programming interface (API) to see if it could answer queries from programs that would do useful tasks. The quick answer to that challenge would seem to be “yes!” and there were a lot of positive feelings coming out of the meeting.

The goal of the DPLA is a little unusual. Although there will be a public web-based interface to the DPLA content, the overriding desire is to build the back-end services that will enable DPLA content to be used through local libraries, archives and museums in a variety of interfaces. In this way, DPLA is like a traditional publisher: it will gather content from a variety of sources (authors), add new value (copyedit, create an index), and send out content through a variety of streams (libraries, local bookstores, internet retailers and other venues like convenience stores and airport shops). The DPLA will gather content from regional and subject hubs, enhance it, and make it available to websites, mobile applications, and other tools. So the AppFest was a way to figure out if the early technology designs of the DPLA could meet those goals.

The AppFest started on Thursday evening with a recorded video welcome from John Palfrey and a recording of Emily Gore from DPLA Midwest introducing the DPLA Digital Hubs Pilot Program followed by a brief introduction to developer productivity tools Git and GitHub by Andromeda Yelton. The evening ended with people pitching ideas for projects that participants would work on the next day. The ideas were ones previously recorded on the DPLA wiki page or were spontaneously created at the meeting.

Sign-up sheet for Appfest Projects

Friday morning started with an introduction to the DPLA API by Jeffrey Licht of Pod Consulting and a review of the possible projects. The project titles were put up on a wall and people self-selected what they wanted to work on for the day. I picked the project that wanted to create a map interface with pins that corresponded to the position of resources in the repository, and other choices were distributed reference services, visualization techniques to see collection content in context with the whole repository, and a new-content notification service. The teams presented their work at the end of the day to the other participants and a panel of judges. We even had a presentation from a remote participant show his work over a Skype video call. After much deliberation, the judges picked the “DPLA Plus” project as best of the AppFest; that project focused on the need of public users to discover what is in the repository.

I think most would agree that the AppFest was a success. The API lived up to the challenge, both in terms of robustness of functionality and its technical ability to respond to queries from the projects. The records returned from the DPLA data set show the challenges of aggregating metadata from disparate sources. In our project we had problems with nonsensical geo-located records that could be filtered, checked and enhanced by automated routines at the central hub. We also ran into the classic difficulty of having reasonable thumbnails to display to users. Web addresses to thumbnail images are not a common part of metadata since they are usually created by the repository system itself. Having a DPLA service to augment records from hubs with URLs to real thumbnail images would be a very helpful addition.

The AppFest was more evidence that the DPLA is definitely pulling itself up by its bootstraps. Coming a month after a successful Midwest plenary session and two months after formal incorporation and installation of its board of directors plus announcements of new rounds of grant funding from IMLS, NEH, and the Knight Foundation, the DPLA is making steady progress towards fulfilling its mission. The next major event is slated to be the unveiling of a public interface to the DPLA collection in April 2013.

In September, Carl Grant wrote a blog post on the ownership of library data (“We have a problem… another vendor appearing to need education about exactly WHO owns library data“) that has been rolling around my own thoughts for, well, months. The spark of Carl’s post was a Twitter conversation where a major library system vendor appeared to be taking steps to limit what library/customers can do with their own data.

SerialsSolutions sez: we own the data you entered into 360. You can’t share it with a competing Discovery vendor.#VendorLove

— Wally Grotophorst (@grotophorst) August 15, 2012

Awful! Seriously…RT @grotophorst SerialsSolutions sez: we own the data you entered into 360. No sharing data!#VendorLove

— ASERL (@ASERLJEB) August 16, 2012

@aserljeb Awful but true. And I spoke with the VP of Discovery at SS.To quote: “well, there is a competitive advantage in that data.”

— Wally Grotophorst (@grotophorst) August 16, 2012

This harkens back to the OCLC records use policy furor of 2008-2010. (In case you don’t remember, the heart of the matter was a proposed transition to a policy that seemed to significantly limit the reusability of descriptive information in WorldCat, particularly in light of new desired use cases like library linked data. I was one that was in favor of a more open policy.) There is a critical difference to note, though. In the OCLC records use policy case the feedback prompted the cooperative’s board of trustees to create a public forum for debate and rough consensus building. The result was a revised policy that was true to the needs of the cooperative while enabling new uses of data to be tried and implemented. In fact, we see tangible results of this effort in the recent announcement of library linked data embedded into WorldCat.org pages.¹

What we have here is something quite different. The case that Carl points out involves a private company making a decision about a library’s data. And I don’t think this is limited to the named vendor; there can easily be other cases where vendors want to treat library data as a competitive advantage and make getting it difficult to keep that advantage. The channels to make the company’s management respond are limited and narrow. In fact, a public calling out may not be sufficient to get action. Carl’s post has suggestions on what libraries can do to protect themselves. I’d like to add one other possibility: the creation of model language that libraries can use at subscription or renewal time that spells out their expectations and desires for their data.

When I entered the library profession about 20 years ago, it was somewhat common for libraries to put software escrow clauses in their contracts; in the event the company no longer provided support for software the library purchased to run on its own systems (whether due to bankruptcy or other reasons), the library had the right to access the source code and internal system documentation stored with a third party. It was a form of protection for the library such that it could continue operations in the event of a failure of the software company. Such clauses fell out of fashion, coinciding somewhat to the move from purchase to subscription service models. This is one form of precedent for libraries managing technology risk.

A more recent example is the NISO Shared Electronic Resource Understanding (SERU) best practice. This is an agreement between content distributors and content licensors that covers the common cases of uses of digital information under copyright law without the overhead of getting lawyers involved in complex and detailed license negotiations. Representatives from distributors and licensors came together to forge this common understanding for the benefit of all.

Yet another contemporary example is the data liberation portal set up by Google staff. Through this portal you can see instructions on how to access data in various Google services in the event you want to transfer that data to another service.

What is called for in this case is some combination of these three exemplars. I think what we need is:

1. clauses in legal agreements with providers that govern the ability for libraries to access their own data about their own operations;
2. combined with a process through which representatives in the profession come to agreement on the best model language for contract clauses;
3. plus the transparency of commitments an process exemplified by data liberation.

This could be a project that goes through the formal process of best practices work in a forum like NISO. Or it could start as an ad hoc effort using the Code4Lib wiki plus a mailing list to manage discussion. Or some other mechanism the community creates.

I’m interested in this from two perspectives. First, as a library professional I think it is an important way for a library to mitigate risks to it operations. Second, as someone employed by a not-for-profit providing Software-as-a-Service options to libraries I want to ensure any model language is workable for the service provider.

Are you interested? Comment here, link to this post with thoughts from Twitter, Facebook, Google+, Tumbler, Pinterest, a mailing list or your own blog, or get in touch with me personally.

Footnotes

1. As an aside, I was critical about the lack of openness to the process, but I’ll readily acknowledge that the output of the process is a a great compromise. The clarification about linking with an OCLC URL being sufficient to denote attribution in linked data contexts is particularly helpful. In retrospect, the process worked well.