Part two of the two-part article I wrote for Library Journal Academic Newswire entitled The Value of Innovation: New Criteria for Library Scholarship was published today.
In this part, I provide examples of the types of activities that need to carry increased weight within the academic librarianship rewards model. I adapted the criteria from used by the University of Maine New Media Department and activities contained in the criteria of Trinity University Libraries.
It is important to note that broadening the scope of what is valued that I am suggested is not in any way meant to devalue traditional scholarly models.
Instead, criteria used to evaluate the activities of academic librarians needs to be better balanced so that alternative forms of scholarly communication - scholarly activities in general - are supported and rewarded as scholarship, but not at the expense of traditional scholarship. Librarians exploring and implementing new types of services, new forms of scholarship, and alternative instructional techniques need to be properly reward
Once again, the disclaimer: While I retain copyright to the work, Reed Business has a 6-month exclusive license to publish the work in print or online. So, I'm unable to publish it on this blog until February '10.
Sphere: Related Content
Showing posts with label ILS. Show all posts
Showing posts with label ILS. Show all posts
Thursday, August 13, 2009
Friday, February 01, 2008
WorldCat Local is Here! (at Ohio State)
One of the hot topics on the library blogosphere in a past year or so has been about how the ILS is broken. I feel that the situation is of our own making since libraries continue to license monolithic and closed ILS systems, but I digress.
The Ohio State University Libraries is one of the groups that has been working with OCLC to pilot WorldCat Local. WorldCat Local creates a locally branded interface and the ability to search the entire WorldCat database. Well, there is finally something to see!
The first thing that jumped off the screen was the faceted browse! (Now, is that so hard to do?) It also presents the results beginning with items most accessible to the customer including collections from the home library, collections shared in a consortium (in our case OhioLINK), and open access collections. The system aggregates monographs, articles from databases and web resources.
After playing with Local for only 5 minutes I decided I may never use the native III interface again. Here's what a search of my name reveals. (Note: I know nothing about the role of PSD-95 in AMPA receptor clustering and synaptic plasticity or the optimization of a thermal transfer printer with ink layer reformation mechanism).
The Ohio State University Libraries is one of the groups that has been working with OCLC to pilot WorldCat Local. WorldCat Local creates a locally branded interface and the ability to search the entire WorldCat database. Well, there is finally something to see!
The first thing that jumped off the screen was the faceted browse! (Now, is that so hard to do?) It also presents the results beginning with items most accessible to the customer including collections from the home library, collections shared in a consortium (in our case OhioLINK), and open access collections. The system aggregates monographs, articles from databases and web resources.
After playing with Local for only 5 minutes I decided I may never use the native III interface again. Here's what a search of my name reveals. (Note: I know nothing about the role of PSD-95 in AMPA receptor clustering and synaptic plasticity or the optimization of a thermal transfer printer with ink layer reformation mechanism).
WorldCat Local is currently just an alternative discovery experience with OSU's III system still there in the background, with all the bibliographic data locked in. (I have always been unhappy with III. I also can't be the only one to think that the name Innovative Interfaces is a kind of a misnomer. I suspect we will see an SOA III system sometime in 2012. Once again, I digress.)
While Local still relies upon a local ILS installation, I see this as the first step in demonstrating how an ILS can be built by decoupling the pieces. With a more modular approach to ILS design, each of the services (circulation, authentication) and the presentation layer could be replaced or updated with minimal impact on the overall system/service.
With such an ILS a library could assemble a custom system built on top of the OCLCV bibliographic database. Such a system would not have to rely upon a built-in services, but could 'plug in' modules from commercial vendors or build them locally (or consortium --wide). Locally maintained bibliographic data could then be mashed up with the OCLC data and would not be embedded like a monolithic ILS, allowing it to be maintained over generations regardless of the changes made to the other modules.
Make sure to give OSU's WorldCat Local a try and please make sure to fill out a survey.
Sphere: Related ContentThursday, January 10, 2008
Who's Interested in an Open Source ILS?
As others have been reporting, Marshall Breeding's Perceptions 2007: an International Survey of Library Automation is now available. (An interactive version of the statistics is available here) The responses were sorted by current ILS vendor.
The question that interested me was:
"How likely is it that this library would consider implementing an open source ILS?"
The responses to this question were predictable, in my opinion. Those indicating lower interest in open source were those that indicated higher satisfaction with their current ILS system.
The two systems that were out of place were Circulation Plus and Winnebago. Circulation Plus responders indicted a pretty high satisfaction with their ILS but also a high interest in open source. On the flip side, Winnebago responders indicated a lower satisfaction with their ILS and lower interest in open source. I also wonder if there is a correlation between the type of libraries that license each of these products and their interest in open source.
An interesting question would have been "If your ILS were discontinued would you consider an open source ILS solution?" Sphere: Related Content
The question that interested me was:
"How likely is it that this library would consider implementing an open source ILS?"
The responses to this question were predictable, in my opinion. Those indicating lower interest in open source were those that indicated higher satisfaction with their current ILS system.
The two systems that were out of place were Circulation Plus and Winnebago. Circulation Plus responders indicted a pretty high satisfaction with their ILS but also a high interest in open source. On the flip side, Winnebago responders indicated a lower satisfaction with their ILS and lower interest in open source. I also wonder if there is a correlation between the type of libraries that license each of these products and their interest in open source.
An interesting question would have been "If your ILS were discontinued would you consider an open source ILS solution?" Sphere: Related Content
Wednesday, September 05, 2007
Where are the Library Mashups? Well....
The Krafty Librarian has asked the question: Mashups What Happened?:
If the discussion is specifically about library resource/service mashups, then unfortunately I feel the last question gets to the crux of the reason.
Libraries rely upon commercial systems from vendors that often use proprietary technologies instead of those that support open standards. These closed systems have made solutions such as mashups very difficult to build, if not impossible, primarily since our systems can not talk to one another.
There are many ways that one can build a mashup, with the most common being through RSS and APIs. The core of what makes many of the more powerful mashups 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 mashups using services provided by disparate systems. I would love to build mashups to pull information out of our III system in a more elegant way then screen scraping.
While libraries have embraced consortia solutions for most large scale purchases, for some reason we have not gotten together (projects like PINES being one exception) in open systems development that would result in new library systems based on open standards. Such systems could be built using an open architecture and shared with the library community. Community source, if you will.
At the very least, I believe our library leadership and professional organizations need to begin demanding that vendors begin using open standards and opening up their APIs. By continuing to embrace proprietary vendor solutions - as they decide to build them - we may be destined to remain two or three years behind the technology curve. Sphere: Related Content
"So what happened? Are the mashers too busy working on their latest creation to be discussing it online? Are mashups still too technical for the average person to create to be popular in the library world? Are librarians victims of their closed systems, thus limiting the amount of mashups created and used?
If the discussion is specifically about library resource/service mashups, then unfortunately I feel the last question gets to the crux of the reason.
Libraries rely upon commercial systems from vendors that often use proprietary technologies instead of those that support open standards. These closed systems have made solutions such as mashups very difficult to build, if not impossible, primarily since our systems can not talk to one another.
There are many ways that one can build a mashup, with the most common being through RSS and APIs. The core of what makes many of the more powerful mashups 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 mashups using services provided by disparate systems. I would love to build mashups to pull information out of our III system in a more elegant way then screen scraping.
While libraries have embraced consortia solutions for most large scale purchases, for some reason we have not gotten together (projects like PINES being one exception) in open systems development that would result in new library systems based on open standards. Such systems could be built using an open architecture and shared with the library community. Community source, if you will.
At the very least, I believe our library leadership and professional organizations need to begin demanding that vendors begin using open standards and opening up their APIs. By continuing to embrace proprietary vendor solutions - as they decide to build them - we may be destined to remain two or three years behind the technology curve. 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.
CONTENTS:
Part One: Introduction
Part Two: What We Have Today
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content
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.
CONTENTS:
Part One: Introduction
Part Two: What We Have Today
Part Four: Challenges
Part Five: Final Comments Sphere: Related Content
Friday, June 01, 2007
Northern Pines Open ILS
On April 17th, the British Columbia, Canada Public Libraries Service Branch (PLSB) proposed a 5-year phased implementation of the Evergreen ILS in BC. From their talking points:
- PLSB finds the risk associated with the Evergreen Open ILS to be no greater than the risk associated with the acquisition of an ILS product in the traditional marketplace. In fact, PLSB finds the risk reduced.
- The Public libraries in BC currently pay ILS vendors a conservatively estimated $700,000 annually for software maintenance. If the six federation ILS groupings and each independent public library system in BC purchased or upgraded their vendor ILS products to one of the leading products on the market by the end of 2011, PLSB estimates the total expenditure at over $10 million for the 5 year period.
- PLSB estimates implementation of Evergreen across BC at just over $2 Million over 5 years, one fifth of the cost projected for market-based solutions.
Oh, and I love their quote:
"libraries can do so much more collectively than any one library can do individually!"
Still, for some reason libraries seem to embrace this philosophy for everything but information systems. Sphere: Related Content
- PLSB finds the risk associated with the Evergreen Open ILS to be no greater than the risk associated with the acquisition of an ILS product in the traditional marketplace. In fact, PLSB finds the risk reduced.
- The Public libraries in BC currently pay ILS vendors a conservatively estimated $700,000 annually for software maintenance. If the six federation ILS groupings and each independent public library system in BC purchased or upgraded their vendor ILS products to one of the leading products on the market by the end of 2011, PLSB estimates the total expenditure at over $10 million for the 5 year period.
- PLSB estimates implementation of Evergreen across BC at just over $2 Million over 5 years, one fifth of the cost projected for market-based solutions.
Oh, and I love their quote:
"libraries can do so much more collectively than any one library can do individually!"
Still, for some reason libraries seem to embrace this philosophy for everything but information systems. Sphere: Related Content
Monday, June 19, 2006
Morgan's Technology Trends 2006
Eric Lease Morgan has presented his top library technology trends for ALA 2006. In looking the list over I found no real revelations. Then again, I find that Eric and I are generally not too far apart on our visions.
He does discuss the growing discontent over OPACs that has appeared on many blogs over the past month or so. Eric states: "library catalogs need to go beyond inventory control systems for librarians to information tools for students, instructors, and scholars." I would go one step further to say that the library catalog and web site should be combined in some fashion and presented using a meta-search interface similar to Gnosh.
Meta-search. Say, isn't that a topic Eric states has not lived up to expectations? In the context of search accross multiple legacy database/indexing systems, that is correct. However, many of the services that are "out there" make their API's available. This availability makes meta-searching across web-based services a relatively simple task. It also allows for the creation of hybrid applications, or mashups. Gnosh utilizes such APIs.
Eric closes by stating "I just can’t figure out why OCLC doesn’t try to provide open source software library application support for a fee." I wonder why OCLC does not push the concept of open source systems and champion the case for open standards for all library systems. For example, OCLC already markets/distributes the Illiad/Odyssey ILL management software. The Odyssey document delivery module is built on an open standard. So, why is OCLC not heavily promoting this as an alternative to existing proprietary solutions?
Imagine how easy meta-searching, document delivery, and library system design would be if all systems utilitzed open standards and made their APIs available.
6/20 Update: Yahoo just opened Messenger to developers and Google has made an AJAX Search API available. Sphere: Related Content
He does discuss the growing discontent over OPACs that has appeared on many blogs over the past month or so. Eric states: "library catalogs need to go beyond inventory control systems for librarians to information tools for students, instructors, and scholars." I would go one step further to say that the library catalog and web site should be combined in some fashion and presented using a meta-search interface similar to Gnosh.
Meta-search. Say, isn't that a topic Eric states has not lived up to expectations? In the context of search accross multiple legacy database/indexing systems, that is correct. However, many of the services that are "out there" make their API's available. This availability makes meta-searching across web-based services a relatively simple task. It also allows for the creation of hybrid applications, or mashups. Gnosh utilizes such APIs.
Eric closes by stating "I just can’t figure out why OCLC doesn’t try to provide open source software library application support for a fee." I wonder why OCLC does not push the concept of open source systems and champion the case for open standards for all library systems. For example, OCLC already markets/distributes the Illiad/Odyssey ILL management software. The Odyssey document delivery module is built on an open standard. So, why is OCLC not heavily promoting this as an alternative to existing proprietary solutions?
Imagine how easy meta-searching, document delivery, and library system design would be if all systems utilitzed open standards and made their APIs available.
6/20 Update: Yahoo just opened Messenger to developers and Google has made an AJAX Search API available. Sphere: Related Content
Subscribe to:
Posts (Atom)
