Monday, July 30, 2007

Scholarly Communication Metrics Must Change

I read an interesting article by Michael Jensen in the Chronicle entitled the New Metrics of Scholarly Authority a few weeks back, which spawned the stub for this post. Walt Crawford's gray literature column motivated me to finish it.

Scholarly communication before the Internet required the intermediation of publishers. Publishers would go to great lengths to validate the scholarship through peer review. Scholarly authority was then conferred upon those works that were well published, inferred by a scholar's institutional affiliation, or conferred by degrees and tenure status. Scholarly authority was accrued over time in part by the number of references made to their works. Promotion and tenure decisions were made based on these quality indicators.

In an era when the library world changes every 18 months, all too many important library related topics are irrelevant once they go through the glacier like 9-18 month publication cycle. Yet, in the eyes of promotion and tenure committees that paper I wrote in 1994 on Gopher remains to this day more important than this blog - mainly because it was peer reviewed prior to publication and quality indicators can be tracked through ISI Web of Science.

This blog, and the blogs of my colleagues, serves as a very important scholarly communication tool. (I have discussed the merits of scholarly blogging here, here, and here) This blog allows me to get concepts out there as I think of them and receive instant feedback from a qualified network of peers who may, or may not, agree with me. This blog allows any idea I present to be discussed, questioned, and debated upon by a networked peer review community through comments and referrals. Any one of my posting may go through a more thorough post publication review that any one of my print articles. (I also don't have to think of ways to inflate a topic into a 3,ooo word paper.)

We need to begin by widening the definitions of what scholarship and being published are. Promotion and tenure committees must take the time to learn about, and give credit for, the new methods of scholarly communication instead of relying on scholarly publishers as the sole tool in establishing the importance of our contributions.

The problem becomes metrics. How does one quantify the impact that a blog has? The number of subscribers? The number of comments? The number of trackback links? Each has its own set of issues, many not unique to blogging. For example, some have complained about blog cliques which comment and link to each other's posts and in effect boost their individual Technorati rankings. This is not unlike the scholar that references a colleague's work and in effect boosts their citation report. The difference being the turnaround time and ease in which the boosting can be accomplished.

Scholars in all disciplines need to work collectively on ways in which engagement and significance can be measured in the participatory spaces that are putting pressure on the traditional scholarly publication paradigm. Without an agreed upon metric for determining the scholarly value of the biblioblogosphere it appears the traditional authority metrics, and sadly the traditional methods of publication, will remain with us for another decade or so. Sphere: Related Content

Monday, July 23, 2007

Service-Oriented Library Systems Pt. 5: Final Comments

The web as we currently know it has been built using relatively simple technologies which have been proven to have scalability, efficiency and utility. The next generation web that is emerging will be an 'operating system' on which developers can create reusable and constantly updated information systems. Functionality that has been traditionally performed on systems installed and run on a local computer in a single application will be performed on the network involving many applications running on many computers.

The resulting information systems architecture is not the 'self-contained' single application structure that we have been used to. Instead, it is a Lego-like design of 'loosely coupled' systems referred to as service oriented architecture.

There is an agreement in the more general information systems world that the SOA approach is the way that applications need to be built. The adoption of SOA will not only make our library systems more flexible and agile, but will allow organizations to modernize their legacy applications.

In the “Introduction” of the 2006 issue of Library Technology Reports entitled “Web Services and the Service-Oriented Architecture” Marshall Breeding writes:

"If, in the future, libraries want to be isolated islands in the ocean of content and information, they can ignore Web services. But because much of what libraries do centers on providing information to library clientele and because information is increasingly more electronic—which causes libraries to overlap with many other organizations in the information sphere—it is necessary for libraries to cooperate and interact with a broad set of other organizations and their technical infrastructures. Web services provide mechanisms that allow libraries to expand their services in many important ways"

In order for libraries to take advantage of the benefits of SOA, some things will have to change. First and foremost, our library leaders need to refocus their collective vision. We need to rethink the services our libraries now offer and how those services are delivered. We need to realign human and fiscal resources into the development of new systems that can change and adapt as fast as our environment.

Libraries in general also need to reduce our reliance on proprietary systems. Sure, libraries can still have vendors build our systems, but we need to demand that they adopt a more open and modular approach in their designs. Our library leadership and professional organizations need to begin demanding that vendors use open standards and open up their APIs. Our library leadership and professional organizations also need to begin viewing open / community source products not only as alternative solutions, but as leverage to force vendors to adopt SOA.

For libraries to retain their market share in the networked world we need to embrace the SOA information approach, now. If libraries do not begin to adopt SOA soon we will not only remain three to five years behind the technology curve, we may never catch up.


Part One: Introduction
Part Two: What We Have Today
Part Three: Where Are We Heading?
Part Four: Challenges Sphere: Related Content

Monday, July 16, 2007

Service Oriented Library Systems Pt. 4: Challenges

In my three (1 2 3) SOLS posts I have provided a basic introduction to SOA and how it can be applied to the development of the next generation of library systems.

Historically, library information systems solutions have been built (almost) exclusively by vendors. While some libraries do build their own systems or use open source solutions, the large majority still rely upon vendors. Most of our challenges in implementing SOA are the direct result of this decision.

Commercial software developers rarely develop new products until they find a critical mass of users since they need to recoup development costs and make a profit at the same time in order to survive. The relatively limited size of the library system market makes it a difficult one for new vendors to enter. This means libraries have few choices when choosing software solutions and few libraries will switch once a significant investment in licensing, maintaining, and training support. When a library becomes so dependent on a vendor for products and services and cannot move to another vendor without substantial costs, whether real or perceived.

The first challenge to adopting SOA is that library systems vendors have created an effective paradigm that many libraries cannot afford to break away from. The vendors of key library systems understand the lock in phenomenon and libraries let them get away with it.

Many library vendors, if not most, build their solutions upon proprietary architectures. Some vendors are beginning to build their systems around some of the principles of SOA. Still, the core of what makes SOA work - the API - remains one of their their most tightly guarded core intellectual properties and revenue streams. The vendors place a death grip on those very APIs which would allow libraries to create SOLS using services provided by disparate systems.

The lack of compatibility between different library systems intentionally or unintentionally forces a customer to continue to use products and services from a particular vendor. Developers may design their products so that replacement parts or add-on enhancements must be purchased from the same manufacturer, rather than from a third party. Developers may also build in incompatibility between versions of their systems to force customers to upgrade.

The second challenge to adopting SOA is that the lack of compatibility and the API licensing fees charged to developers to create compatible products - required in SOA - creates a barrier for new vendors trying to enter the market for a particular library system. If the costs of entry or compatibility are great enough an effective monopoly can be maintained.

Libraries have built entire resource sharing networks around single vendor solutions. This results in a de facto standards. De facto library system standards are those which have been accepted for practical purposes by a significant proportion of the marketplace. What comes to mind is a significant library Internet document delivery network based on a product who's name is now a verb.

The third challenge to adopting SOA is that for work flow or legacy reasons we continue to support single vendor supplier solutions. In doing so, we create an environment where library products do not have to keep up with current technology needs, service support that does not meet expectations, and systems that will not allow for the adoption of SOA.

When one steps back and looks at it, we have nobody to blame for outdated library information systems or our inability to more readily adopt SOA except for ourselves. We keep licensing these products at a time when the number alternative approaches available to libraries has never been greater.

In the last posting in these services (no. 5) I will provide some closing remarks and observations.


Part One: Introduction
Part Two: What We Have Today
Part Three: Where Are We Heading?
Part Five: Final Comments Sphere: Related Content

Monday, July 09, 2007

Service Oriented Library Systems Pt. 3: Where Are We Heading?

This is the third (1 2) in a series of posts discussing Service Oriented Architecture (SOA) and library systems. In my second SOA post, I discussed how library systems in this environment are structured in information silos and the impact this has on the user experience.

SOA is essentially a modular software design philosophy which facilitates the flexibility and responsiveness required in a changing environment. Individual software pieces are build independently and can either be interchanged or repurposed. SOA utilizes 'loosely coupled' systems that expose their resources and content as independent 'services.' These services can be combined to create new systems and services. The most visible result of the SOA approach is the emergence of web mashups.

The best analogy I have found to get a handle on SOA is the early twentieth century automobile assembly line. It is also important that the concept of web services which is tioed to the concept of SOA not be confused with services available on the web. Web services in this context refer to a specific type of application built on an architecture that offers the promise of allowing any client to work with any server, anywhere in the world.

The graphic below depicts how just one library system, the ILS, could look like using the SOA approach. In this example, the bibliographic database, circulation, and authentication systems have been decoupled from the discovery tool and presentation layer (customer interface).

Each of the services (circulation, authentication) or the presentation layer could be replaced or updated with minimal impact on the overall system/service. For example, a library could create a social web interface to the ILS without touching the bibliographic, circulation, and authentication services. An SOA ILS would not have to rely upon a built-in circulation service, but could 'plug in' one from a commercial vendor or one that is built locally. The data collected could would not be embedded like a 'silo' ILS and could be maintained over generations regardless of the changes made to the other ILS modules.

Another advantage to the SOA approach is control over the bibliographic data. It is common for ILS vendors to 'lock' the bibliographic data into the 'silo' ILS using proprietary data systems and formats. The costs associated with the export and conversion of this data may be the single most significant reason libraries rarely switch ILS systems. With SOA, the local bibliographic database can be replaced by a web service. (This currently fictional web service could serve as the foundation for the next generation SOA ILS. Hint, hint, OCLC). The use of a bibliographic web service would not only remove the retro-conversion barrier, it eliminates the need to maintain a local bibliographic database all together!

Before the catalogers out there react to the previous paragraph, if the library wanted to create a localized database for special collections or supplemental information they could do so. They could create a database using common tools, expose it as a web service, and simply 'plug it in.' This new web service could be shared with consortia wishing to aggregate special collections resources or it can be 'mashed' together with other web services.

In my second posting, I discussed all of the various systems that our customers must navigate. The graphic below depicts the beauty, and complexity, of this approach.

With such a design, all the systems would be loosely coupled. Direct connections to each of our data sources would be available from any of our our web presences. The user experience is enhanced since they could gain access to any of the resources from any of the user interfaces. For example, one could search the course management system and receive results from the eJournals collection.

The graphic above also assumes that libraries would continue to need separate user interface sites. In theory, with SOA the library could create a single Facebook-like portal which would aggregate all networked resources. New library 'web services' could be built and simply plugged in by the customer.

This approach to the design of library systems represents a radical departure from what we have today. At the same time, it provides libraries with an unprecedented ability to create and maintain systems that can quickly adapt to the changing networked information infrastructure. It has the potential to get our resources out to where our customers are.

In part four, I will discuss the challenges with moving towards a service oriented approach to library systems.


Part One: Introduction
Part Two: What We Have Today
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content

Tuesday, July 03, 2007

Where is My Manuscript?

In late 2005, I had a manuscript accepted in a publication of a rather large New York State based publisher of paperback sized library journals. The manuscript went through all the standard review processes. I had no issues or concerns with the communications with or the time it took the editor to process the manuscript. I was informed that the journal would be published in the Summer of 2006.

That time came and went.

Wondering what happened, I looked at the publishers web site. I noticed the issue was pushed out until early 2007. No big deal to me since, for promotion and tenure purposes, having a manuscript accepted for publication is (almost) as good as being published - quality indicators aside.

Once again, that time came and went.

I went back to the publishers site, which now indicated that the issue would not be out until August 2007. The site also revealed that issue 4 was scheduled to be published before my issue (1/2). An email to the editor revealed that even they didn't know what was going on with the publisher. The manuscripts were delivered on time - years ago.

This is the second time something weird has happened to a manuscript with this publisher.

In the earlier case, my manuscript was accept by an editor and scheduled for publication. When the publication time came and went I found out that the editor changed. I contacted the new editor and was informed it was still in process and a new volume/issue was provided. When that time came and went I found out that there was yet another editor. The new editor would never return my attempts to contact them. This process took two years. The manuscript was hopelessly outdated.

If it were not for this antiquated notion that only pre-publication peer-reviewed print publications hold any value as scholarly communication for promotion and tenure purposes I wouldn't even bother publishing in print.

Blogging supports all the reasons one publishes; to communicate ideas and research, impact on profession, personal and organizational reputation. Blogging allows one to communicate ideas and receive immediate feedback. It allows one to flush out ideas. While one could argue that comments and others blog postings based on a single post are indeed peer review, blogging is problematic for promotion and tenure primarily since there is no pre-publication peer-review..

Anyone out there have a credible blogmetrics algorithm? Sphere: Related Content