If you are at ALA, make sure you attend the OCLC Symposium: The Mashed-Up Library at 1:30 on Friday 6/27 that includes a great keynote speaker and panel that will discuss developing new library services by mixing data and functionality from several sources.
The keynote speaker with Michael Schrage, author of Serious Play and Shared Minds—The New Technologies of Collaboration and columnist for CIO and MIT’s Technology Review.
The panel includes Susan Gibbons, Associate Dean, Public Services & Collection Development, University of Rochester (NY) River Campus Libraries David Lee King, Digital Branch & Services Manager, Topeka & Shawnee County (KS) Public Library, and Mary Beth Sancomb-Moran, Librarian, University of Minnesota, Rochester.
Any librarian that is concerned about how their organization can remain relevant in the time of technological change and how we can establish services where our customers are should attend.
Sphere: Related Content
Showing posts with label mashup. Show all posts
Showing posts with label mashup. Show all posts
Thursday, June 26, 2008
Monday, June 23, 2008
Will the Next Generation of Library Systems be Customer Generated?
I have been lurking in on an OhioLink task force discussing "next generation" discovery layers. One of the latest postings to the group was by Peter Murray , who highlighted a report from the Next Generation Summit Search Interface Working Group of the Orbis/Cascade Alliance.
The report supports several concepts I have been pushing for a couple years now, including the idea of consortia to support library systems development. However, the more important concept is included in the report’s recommendations:
Aha. Without using the geek terminology what they are describing is actually Service Oriented Architecture. However, what I am really excited to read is the desire on the part of the Alliance to break library culture and control over bibliographic information and to let the customers play with it. The number of applications that make use of the Google Maps shows how creative customers can be in seeing new connections between information sources.
I could see a customer building a new system in which leverages OPAC data in a weekend which could take a library organization a year to work through. Libraries should be building and licencing systems which exposes our content and data. Let the customers can play with it. Let them mash it up. Let them create systems that fit their immediate needs.
The challenge is that libraries do build systems and services with our (librarian) needs in mind. Our need for control. Our need for perfection. Our need for process. A library information system (or service) that uses a development process that does not meet our internal cultural needs is almost immediately classified as being a failure. We then focus way too much energy doing a post mortem on what went wrong in the development process in an effort to "do it right the next time."
It's no wonder that library systems of tomorrow are really just library systems of yesterday.
It seems to me that as a profession we are stuck in a bad relationship with our systems and vendors. We just can't figure out a way to get out of it. Are we happy that III will not give us APIs? Are we so insecure with our relationship with them that we are content to take what they give us? Do we feel we are that powerless?
The approach that the Alliance has outlined in their report is a extremely positive sign that some finally have had enough and are willing to make the hard decisions required for information system independence.
Photo: "REST eye for the SOA GUY" by psd. Creative Commons. Sphere: Related Content
The report supports several concepts I have been pushing for a couple years now, including the idea of consortia to support library systems development. However, the more important concept is included in the report’s recommendations:
Regardless of who provides the Alliance’s next generation OPAC product, one of the deliverables that must be available as part of any solution is API or web services access to the catalog. Access at this level is important for two reasons:
... All major ILS vendors but III provide their customers a web services or HTTP REST API access to their systems, allowing for continued development around the catalog. Lacking such access, the Summit catalog will continue to be marginalized within the consortium’s academic campuses as tools and services are developed that take advantage of web service friendly applications.
... The Alliance should strive to create a resource that encourages users, libraries, and campuses to develop services around the Summit catalog. The library community has recognized that our patrons want social tools, which we tend to identify as tagging, commenting, etc. However, Web 2.0 applications like Flickr are popular because of the API access that they provide to their users as well. This access has enabled other web services, individuals, and organizations to develop different methods for exporting and utilizing the images placed within the Flickr photo archive. The Alliance should strive to make the Summit catalog open in this way, so that users and members alike are free to enhance Summit to meet individual, campus, or consortial needs.
Aha. Without using the geek terminology what they are describing is actually Service Oriented Architecture. However, what I am really excited to read is the desire on the part of the Alliance to break library culture and control over bibliographic information and to let the customers play with it. The number of applications that make use of the Google Maps shows how creative customers can be in seeing new connections between information sources.
I could see a customer building a new system in which leverages OPAC data in a weekend which could take a library organization a year to work through. Libraries should be building and licencing systems which exposes our content and data. Let the customers can play with it. Let them mash it up. Let them create systems that fit their immediate needs.
The challenge is that libraries do build systems and services with our (librarian) needs in mind. Our need for control. Our need for perfection. Our need for process. A library information system (or service) that uses a development process that does not meet our internal cultural needs is almost immediately classified as being a failure. We then focus way too much energy doing a post mortem on what went wrong in the development process in an effort to "do it right the next time."
It's no wonder that library systems of tomorrow are really just library systems of yesterday.
It seems to me that as a profession we are stuck in a bad relationship with our systems and vendors. We just can't figure out a way to get out of it. Are we happy that III will not give us APIs? Are we so insecure with our relationship with them that we are content to take what they give us? Do we feel we are that powerless?
The approach that the Alliance has outlined in their report is a extremely positive sign that some finally have had enough and are willing to make the hard decisions required for information system independence.
Photo: "REST eye for the SOA GUY" by psd. Creative Commons. Sphere: Related Content
Friday, April 25, 2008
Is Your Library Trapped in a 'Phantom Zone' ?
About a year ago David Lee King posted his change the unchangeable rant. I believe that there are many libraries and library leaders out there trying to change their organizations. However, too many are doing so while maintaining the same organizational structures and paradigms they have used for the last half century.
As I talk to many librarians on this topic it simply seems to me that too many libraries are stuck in a 'Phantom Zone', like that in Superman comics. In the 1978 movie, Jor-El supervises the conviction of three criminals caught attempting to overthrow the planet's government. The dome of the planet's capital city opens and an extra-dimensional pyramid - the Phantom Zone - tumbles out of the sky and absorbs the three criminals into an eternity in dimensional limbo through space.
Many of the cultural rules that exist in libraries today are based on the traditional functions that libraries perform including buying, processing, and organizing materials as well as providing services at a desk within a building. The degree of change that the staff embraces, from incremental to radical, leads to a modification or replacement of these rules. The organizational tension between the agents of change and the agents of the status quo become apparent since staff generally has a tendency toward the routine while external influences on the structure create a need for disruption of those routines.
In his 1996 book Deep Change: Discovering the Leader Within, Robert E. Quinn discusses how deep change differs from incremental change in that it requires new ways of thinking and behaving. Deep change is a major movement and is discontinuous with the past and generally irreversible. It distorts existing patterns and involves risk taking.In the 2003 article Resistance to Change in Libraries: Application of Communication Theories (Access depends on your local license), Sharon Gray Weiner applies this to libraries:
"Discontinuous change means that there is no previous experience, no model of the process, and no consensus about how change should be handled. It invalidates the rules and assumptions that determine an organization's operating procedures. Technology is an important source of discontinuous change. Disintermediation is a concept that has arisen in relation to information technology and institutional change. It means the obsolescence of all institutions that function as intermediaries. Institutions are seen as encumbering and static, imposing an outdated order, and existing only to resist change and to postpone their own demise."
This is not a new idea being presented to libraries. In fact, Charles Lowry wrote about this approach nearly a decade ago.
To meet today's challenge of continuous change simply requires the mobilization of all library staff through the creation and support for a continuous learning environment as well as a real engagement in organizational problem solving. A library that is encouraged and accepts change will result in an organization that is closer to Ranganathan's "the library is a growing organism" and characterized by adaptation and evolution.
There is a way out of the library Phantom Zone, but it requires a significant cultural shift that needs to be started from the top down and supported from the bottom up. A library organization that is not challenged and chooses to resist environmental/cultural change will result in one that maintains traditional service activities. It will also experience growing tensions as the expectations and the need to change results in an increasing amount of internal conflict.
Sphere: Related ContentWednesday, 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
Wednesday, August 29, 2007
GooglePhone OS to be Released in Early Sept?
Word from Engadget is that the much anticipated Google mobile device platform may finally be revealed in early September. Rumors suggest that Google has plans to invest $7-8 billion in its development, although there has been no confirmation from the company.
The word is also that Google isn't necessarily working on a hardware device of its own, but instead is working with OEMs and ODMs to get them to put the linux-based platform on upcoming devices. Speculation that they may build their own device increased after Google acquired startup Android Inc., along with founder Andy Rubin. One of his companies launched the mobile Hiptop device, marketed as the T-Mobile sidekick. So, they do have the talent to make a device.
This also sheds some light on Google's release of the Short Message Service (SMS), which sends text-based localized information to mobile users from sports scores, driving directions, to weather forecasts. Sphere: Related Content
The word is also that Google isn't necessarily working on a hardware device of its own, but instead is working with OEMs and ODMs to get them to put the linux-based platform on upcoming devices. Speculation that they may build their own device increased after Google acquired startup Android Inc., along with founder Andy Rubin. One of his companies launched the mobile Hiptop device, marketed as the T-Mobile sidekick. So, they do have the talent to make a device.
This also sheds some light on Google's release of the Short Message Service (SMS), which sends text-based localized information to mobile users from sports scores, driving directions, to weather forecasts. 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
Wednesday, June 20, 2007
Create Your Own Mashup
Last week at the Library 2.0 Seminar I was asked about Yahoo Pipes. I had heard about Pipes but hadn't played around with it to know how it worked. Yahoo Pipes allows individuals to create their own mashups or "pipes." The process involves dragging and dropping prebuilt modules, and then create connections between them.
The Pipes method of building mashups does require some time to learn. (I spent 15 minutes, which admittedly is not a great deal of time. Yet, that would seem to be a reasonable threshold if they want the 'average' person to use it to create mashups) They use terminology and structure that is used may turn away many potential mashers that have a
non-technical orientation. I had hoped to use Pipes has a tool to teach librarians about SOA and Web Services. It is going to take some time to figure out if it can be used for teaching.
The number of sources from which to build mashups is limited at this time which limits creating mashups relevant to libraries. The also seems to take quite a while for the tool to load the sample Pipes. I learned HTML by tearing apart other people's code and hope I can learn Pipes using a similar method.
Microsoft's Popfly is another plug-and-play mashup tool. Like with Pipes, one can drag prefab building blocks. mashup that you can add to an existing Web page or turn into its own site. For example, one can produce a mashup that grabs pictures from a site like Flickr and then displays them in a rotating cube. As with a growing number of new tools, PopFly is invitation based and requires a WindowsLive ID.
Photo: "The Pipes, The Pipes" by Steve Garfield. Published through Creative Commons license. Sphere: Related Content
The Pipes method of building mashups does require some time to learn. (I spent 15 minutes, which admittedly is not a great deal of time. Yet, that would seem to be a reasonable threshold if they want the 'average' person to use it to create mashups) They use terminology and structure that is used may turn away many potential mashers that have a
non-technical orientation. I had hoped to use Pipes has a tool to teach librarians about SOA and Web Services. It is going to take some time to figure out if it can be used for teaching.The number of sources from which to build mashups is limited at this time which limits creating mashups relevant to libraries. The also seems to take quite a while for the tool to load the sample Pipes. I learned HTML by tearing apart other people's code and hope I can learn Pipes using a similar method.
Microsoft's Popfly is another plug-and-play mashup tool. Like with Pipes, one can drag prefab building blocks. mashup that you can add to an existing Web page or turn into its own site. For example, one can produce a mashup that grabs pictures from a site like Flickr and then displays them in a rotating cube. As with a growing number of new tools, PopFly is invitation based and requires a WindowsLive ID.
Photo: "The Pipes, The Pipes" by Steve Garfield. Published through Creative Commons license. 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)
