Electronic Resources & Libraries 2007: thinkdigital_ -- Call for Proposals

*Please Excuse the Cross Postings*

Electronic Resources & Libraries 2007
thinkdigital_
February 22-24, 2007
Atlanta, GA
Call for Proposals
http://www.electroniclibrarian.com/call
***********************************************
ER&L Conference Program Planning Committee encourages you to submit a
proposal for the Electronic Resources & Libraries 2007 Conference to be
held February 22-24, 2007, with pre-conference sessions on February 21.
The conference location will be the Global Learning and Conference
Center, located on the campus of Georgia Institute of Technology in
Atlanta, GA.
ER&L provides a forum for information professionals to explore ideas,
trends, and technologies related to electronic resources and digital
services.
The idea of this event is to bring together stakeholders inside and
outside of the library to look at the impact the digital environment has
on library collections, access to resources, and our organizations. We
invite various perspectives and approaches to managing, promoting and
accessing electronic resources. We hope to foster collaborative,
cross-departmental, cross-community approaches to the issues e-resources
have brought to our environment
The Program Planning Committee seeks proposals for a variety of session
formats including presentations, panel sessions, and pre-conference
workshops. Proposals that have topics of interest to many areas of the
library or outside the library are of special interest to the ER&L
Program Planning Committee.

building the "next generation" library catalog

How will we, the library profession, build the "next generation"
library catalog, and to what degree will the process include vendor
support and open source software?

I must admit that there are few things that do not succeed over time
without some sort of commercial interest. Think OCLC. JSTOR. Even
NOTIS. The only exception to the rule seems to be when government
subsidizes the process.

Be that as it may, I will still advocate a large dose of grass roots
efforts lead by the library community exploiting open source software
over something created by a commercial institution. At least for now.
Moreover, when your fellow librarians say things like, "We tried
those 'homegrown' systems a long time ago, and where are they now? We
need vendor-supported software", I can give you a number of reasons
why this is not necessarily the case in today's environment:

   1. Computer hardware & software - Twenty or more years ago, when
the library profession was supporting "homegrown" systems, the
hardware used was vendor-specific. Maybe you had a Prime. A Unisys.
An IBM 360. A DEC Watchamacallit. A Sun Something. Etc. These
computers had less RAM, less disk space, and less processing power
than the computer you have on your desktop right now. Each of these
computers had their own operating system and set of programming
languages used to create applications. The applications created for
these systems was not sharable between computers, and consequently is
was difficult, if not impossible, to share code between libraries.
Now-a-days the applications will be written for Unix/Linux or Java --
platforms that are not computer hardware specific. (If someone
creates a Microsoft-based "next generation" library catalog, run the

Research and Development Consultant Position Available

Re: building the "next generation" library catalog

The point of 'communication', as well as possibly computer hardward and
software (to the extent you mention sharing code between libraries) are
about NOT building it just for yourself, but coordinated efforts between
libraries.

That's the real difference---the environment that makes distributed open
source projects possible. I think that an actual distributed open source
project with buy-in from, say, at least three institutions (and
hopefully more later) has a lot more chance of being succesful than
something you really are developing just for yourself.  If you really
are just doing it for yourself (and maybe not even making the code
shareable at all!)---I'm not sure there really are enough environmental
changes to make this a winning proposition.

The problem, of course, is that you can't be sure something you are
developing yourself will result in a true open source community being
developed around it. It's a risk. But, honestly, I think it IS a risk,
and I wouldnt' want decision-makers thinking otherwise. Buying
commercial software is a risk too, of course, in many ways. The
analagous risk would be buying the first version of a software product
from a new company--who knows if they'll stay around? On the other hand,
just quite as you reduce your risk (at least that kind of risk) by
buying from an established and respected company, you reduce your risk
by using more 'established' open source software instead of starting
your own from scratch. It's important for libraries to take the risk of
starting stuff from scratch too---the environment we're in, significant
innovation is needed (another risk of staying with established
commercial vendors is getting not enough innovation). But it is indeed a
risk.

And, again, I think the changed environment is mostly about the
environment that makes distributed open source possible. If your
in-house project isn't or doesnt' become a succesful distributed open
source project---I think it's just as likely to run into the same
problems in-house software always has.

Jonathan

Eric Lease Morgan wrote:
> How will we, the library profession, build the "next generation"
> library catalog, and to what degree will the process include vendor
> support and open source software?
>
> I must admit that there are few things that do not succeed over time
> without some sort of commercial interest. Think OCLC. JSTOR. Even
> NOTIS. The only exception to the rule seems to be when government
> subsidizes the process.
>
> Be that as it may, I will still advocate a large dose of grass roots
> efforts lead by the library community exploiting open source software
> over something created by a commercial institution. At least for now.
> Moreover, when your fellow librarians say things like, "We tried
> those 'homegrown' systems a long time ago, and where are they now? We
> need vendor-supported software", I can give you a number of reasons
> why this is not necessarily the case in today's environment:
>
>   1. Computer hardware & software - Twenty or more years ago, when
> the library profession was supporting "homegrown" systems, the
> hardware used was vendor-specific. Maybe you had a Prime. A Unisys.
> An IBM 360. A DEC Watchamacallit. A Sun Something. Etc. These
> computers had less RAM, less disk space, and less processing power
> than the computer you have on your desktop right now. Each of these
> computers had their own operating system and set of programming
> languages used to create applications. The applications created for
> these systems was not sharable between computers, and consequently is
> was difficult, if not impossible, to share code between libraries.
> Now-a-days the applications will be written for Unix/Linux or Java --
> platforms that are not computer hardware specific. (If someone
> creates a Microsoft-based "next generation" library catalog, run the
> other way, very fast.) The code written for one computer will run on
> the next computer (no puns intended) without much modification, and
> this will enable the library community to collaborate to a greater
> degree.
>
>   2. Relational databases - Relational databases and the technology
> used to implement them was embryonic when libraries were supporting
> their "homegrown" systems. There were few, if any, well-supported
> best practices for managing large sets of information. And even when
> you did you sat around worrying whether or not you should allocate
> two bytes of disk space to denote the name of a state or twelve.
> These problems are far less challenging now with the cost of disk
> space and the availability of any number of relational database
> applications. The problems of storing the data is much less limiting
> than it was twenty years ago.
>
>   3. Indexing technology - Databases are great for storing and
> manipulating information. Ironically, they are poor on searching. To
> search a database you must know the underlying structure of the data.
> Indexes remove this problem. They invert the content of the database
> creating lists of words and pointers to records. No knowledge of the
> database's structure is necessary. Couple this with statistical
> analysis and indexing technology begins to appear "smart" -- think
> relevance ranking. Indexing technology has matured to a very large
> degree in the past twenty years, and there are a large number of
> freely available indexers. How many indexers were available twenty
> years ago? One, maybe. BRS.
>
>   4. Skills - Computers twenty or more years ago were expensive,
> very expensive. Much fewer people had access to computers and a
> proportional number of fewer people had computer expertise. Now-a-
> days hackers abound. [1] If they didn't we wouldn't have the email,
> Web servers, MySQL, Perl, PHP, Linux, or just about anything related
> to the Internet. Put another way, there are many many more people now-
> a-days who know how to make computers do the things they do. There
> are computer programmers around, they just don't work in libraries to
> a large degree. "Libraries are about books. Right?"
>
>   5. Communication - Communication via the telephone is dirt cheap.
> You can make long distance telephone calls for pennies. From my
> workplace here in Indiana I can talk on the telephone with people in
> the United Kingdom for .02¢/minute. At those rates it is silly not to
> pick up the telephone. The biggest thing the Internet does is
> facilitate communication. People-to-people communication. People-to-
> computer communication. Computer-to-computer communication. Twenty
> years ago the story was much different. You were lucky to have a 2400
> baud modem and you dared not make a long-distance telephone call.
> Because of our increasingly seamless ability to communicate across
> long distances, it will be easier for libraries to coordinate their
> effort and create something from the community.
>
> In short, don't let people write you off when you say, "We can built
> it ourselves." Explain to them how the computer environment is
> substantially different from previous times. Enumerate the things
> outlined above. Yes, the human challenges still exist. Building
> consensus. Setting priorities. Keeping things on schedule. Creating
> communities. Bringing people physically together. Allocating time,
> space, people, and money. But are those the things you want to pay a
> vendor for? The other things are "as free as a free kitten."
>
> Food for thought on a Friday afternoon.
>
> [1] Hackers in this context are contrasted with "crackers". Hackers
> are the good guys. They look at source code and figure out ways to
> improve it or modify it for their own purposes. Crackers, on the
> other hand, are malicious. They look for ways to exploit software for
> immoral purposes.
>
> --
> Eric Lease Morgan
> University Libraries of Notre Dame
>

--
Jonathan Rochkind, MLIS
Sr. Programmer/Analyst
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind <at> jhu.edu

Re: building the "next generation" library catalog

Re: building the "next generation" library catalog

Both Eric's email and Jonathan's response
contrasts "commercial" with "open
source."  Happily, this is not really
necessary--or for that matter, even logical.
Commercial refers to a type of company.  A
commercial product or service is one that is
produced by a for-profit company.  Open source
refers to the type of license by which software
is distributed, and has nothing to do with
whether the software is distributed by a
commercial company, an individual, a non-profit company, etc.

I am not just splitting hairs by pointing this
out.  Much of the discussion of open source
software for libraries has hidden assumptions
that are not examined and that are not true.

There are commercial companies that develop
software and distributed it under an open source
license.  Those companies also offer ongoing
support, as well as installation services,
customization services, and sponsored development.

In reality there is no need to choose between
having a commercial company to rely on and being
able to utilize open source software, with all of
its attendant advantages.  You can have the best
of both worlds by working with commercial
companies that distribute and support open source library software.

David

At 03:50 PM 09/01/2006, Jonathan Rochkind wrote:
>The point of 'communication', as well as possibly computer hardward and
>software (to the extent you mention sharing code between libraries) are
>about NOT building it just for yourself, but coordinated efforts between
>libraries.
>
>That's the real difference---the environment that makes distributed open
>source projects possible. I think that an actual distributed open source
>project with buy-in from, say, at least three institutions (and
>hopefully more later) has a lot more chance of being succesful than
>something you really are developing just for yourself.  If you really
>are just doing it for yourself (and maybe not even making the code
>shareable at all!)---I'm not sure there really are enough environmental
>changes to make this a winning proposition.
>
>The problem, of course, is that you can't be sure something you are
>developing yourself will result in a true open source community being
>developed around it. It's a risk. But, honestly, I think it IS a risk,
>and I wouldnt' want decision-makers thinking otherwise. Buying
>commercial software is a risk too, of course, in many ways. The
>analagous risk would be buying the first version of a software product
>from a new company--who knows if they'll stay around? On the other hand,
>just quite as you reduce your risk (at least that kind of risk) by
>buying from an established and respected company, you reduce your risk
>by using more 'established' open source software instead of starting
>your own from scratch. It's important for libraries to take the risk of
>starting stuff from scratch too---the environment we're in, significant
>innovation is needed (another risk of staying with established
>commercial vendors is getting not enough innovation). But it is indeed a
>risk.
>
>And, again, I think the changed environment is mostly about the
>environment that makes distributed open source possible. If your
>in-house project isn't or doesnt' become a succesful distributed open
>source project---I think it's just as likely to run into the same
>problems in-house software always has.
>
>Jonathan
>
>Eric Lease Morgan wrote:
>>How will we, the library profession, build the "next generation"
>>library catalog, and to what degree will the process include vendor
>>support and open source software?
>>
>>I must admit that there are few things that do not succeed over time
>>without some sort of commercial interest. Think OCLC. JSTOR. Even
>>NOTIS. The only exception to the rule seems to be when government
>>subsidizes the process.
>>
>>Be that as it may, I will still advocate a large dose of grass roots
>>efforts lead by the library community exploiting open source software
>>over something created by a commercial institution. At least for now.
>>Moreover, when your fellow librarians say things like, "We tried
>>those 'homegrown' systems a long time ago, and where are they now? We
>>need vendor-supported software", I can give you a number of reasons
>>why this is not necessarily the case in today's environment:
>>
>>   1. Computer hardware & software - Twenty or more years ago, when
>>the library profession was supporting "homegrown" systems, the
>>hardware used was vendor-specific. Maybe you had a Prime. A Unisys.
>>An IBM 360. A DEC Watchamacallit. A Sun Something. Etc. These
>>computers had less RAM, less disk space, and less processing power
>>than the computer you have on your desktop right now. Each of these
>>computers had their own operating system and set of programming
>>languages used to create applications. The applications created for
>>these systems was not sharable between computers, and consequently is
>>was difficult, if not impossible, to share code between libraries.
>>Now-a-days the applications will be written for Unix/Linux or Java --
>>platforms that are not computer hardware specific. (If someone
>>creates a Microsoft-based "next generation" library catalog, run the
>>other way, very fast.) The code written for one computer will run on
>>the next computer (no puns intended) without much modification, and
>>this will enable the library community to collaborate to a greater
>>degree.
>>
>>   2. Relational databases - Relational databases and the technology
>>used to implement them was embryonic when libraries were supporting
>>their "homegrown" systems. There were few, if any, well-supported
>>best practices for managing large sets of information. And even when
>>you did you sat around worrying whether or not you should allocate
>>two bytes of disk space to denote the name of a state or twelve.
>>These problems are far less challenging now with the cost of disk
>>space and the availability of any number of relational database
>>applications. The problems of storing the data is much less limiting
>>than it was twenty years ago.
>>
>>   3. Indexing technology - Databases are great for storing and
>>manipulating information. Ironically, they are poor on searching. To
>>search a database you must know the underlying structure of the data.
>>Indexes remove this problem. They invert the content of the database
>>creating lists of words and pointers to records. No knowledge of the
>>database's structure is necessary. Couple this with statistical
>>analysis and indexing technology begins to appear "smart" -- think
>>relevance ranking. Indexing technology has matured to a very large
>>degree in the past twenty years, and there are a large number of
>>freely available indexers. How many indexers were available twenty
>>years ago? One, maybe. BRS.
>>
>>   4. Skills - Computers twenty or more years ago were expensive,
>>very expensive. Much fewer people had access to computers and a
>>proportional number of fewer people had computer expertise. Now-a-
>>days hackers abound. [1] If they didn't we wouldn't have the email,
>>Web servers, MySQL, Perl, PHP, Linux, or just about anything related
>>to the Internet. Put another way, there are many many more people now-
>>a-days who know how to make computers do the things they do. There
>>are computer programmers around, they just don't work in libraries to
>>a large degree. "Libraries are about books. Right?"
>>
>>   5. Communication - Communication via the telephone is dirt cheap.
>>You can make long distance telephone calls for pennies. From my
>>workplace here in Indiana I can talk on the telephone with people in
>>the United Kingdom for .02¢/minute. At those rates it is silly not to
>>pick up the telephone. The biggest thing the Internet does is
>>facilitate communication. People-to-people communication. People-to-
>>computer communication. Computer-to-computer communication. Twenty
>>years ago the story was much different. You were lucky to have a 2400
>>baud modem and you dared not make a long-distance telephone call.
>>Because of our increasingly seamless ability to communicate across
>>long distances, it will be easier for libraries to coordinate their
>>effort and create something from the community.
>>
>>In short, don't let people write you off when you say, "We can built
>>it ourselves." Explain to them how the computer environment is
>>substantially different from previous times. Enumerate the things
>>outlined above. Yes, the human challenges still exist. Building
>>consensus. Setting priorities. Keeping things on schedule. Creating
>>communities. Bringing people physically together. Allocating time,
>>space, people, and money. But are those the things you want to pay a
>>vendor for? The other things are "as free as a free kitten."
>>
>>Food for thought on a Friday afternoon.
>>
>>[1] Hackers in this context are contrasted with "crackers". Hackers
>>are the good guys. They look at source code and figure out ways to
>>improve it or modify it for their own purposes. Crackers, on the
>>other hand, are malicious. They look for ways to exploit software for
>>immoral purposes.
>>
>>--
>>Eric Lease Morgan
>>University Libraries of Notre Dame
>
>--
>Jonathan Rochkind, MLIS
>Sr. Programmer/Analyst
>The Sheridan Libraries
>Johns Hopkins University
>410.516.8886
>rochkind <at> jhu.edu
>

David Dorman
US Marketing Manager, Index Data
52 Whitman Ave.
West Hartford, Connecticut  06107
dorman <at> indexdata.com
860-389-1568 or toll free 866-489-1568
fax: 860-561-5613

INDEX DATA Means Business
for Open Source and Open Standards
- - - - - - - - - - - - - - -
www.indexdata.com

Re: building the "next generation" library catalog

On Sep 1, 2006, at 3:50 PM, Jonathan Rochkind wrote:

> The problem, of course, is that you can't be sure something you are
> developing yourself will result in a true open source community
> being developed around it. It's a risk. But, honestly, I think it
> IS a risk, and I wouldnt' want decision-makers thinking
> otherwise. ... It's important for libraries to take the risk of
> starting stuff from scratch too---the environment we're in,
> significant innovation is needed (another risk of staying with
> established commercial vendors is getting not enough innovation).
> But it is indeed a risk.

I agree with these points (and the others in the full post).

I'm reminded though that too often in the realm of evaluating open-
source software, decision-makers are presented with, or believe there
are, two choices: using scarce in-house resources to implement an
open-source solution, or going with a vendor to implement a
proprietary solution.

As an IndexData guy reminded me at a NISO conference last year,
another very legitimate approach would be to hire a vendor to
implement or extend an open-source solution. As I understand it, you
can hire IndexData to build or extend software, but all of what they
produce is open-source code. That's a cool business model, providing
concerned decision-makers with the 'security' of the vendor-model,
while assuring that the institution and we programmers can access and
extend the code. Just as the internet has enabled open-source
projects to flourish, it has also enabled these different development
models to flourish. I worked at a place before entering the library
world where the owner began using guru.com and elance.com on projects
and pieces of projects -- another example of having the security of
access to high-quality talent while also having full-access to the
end-product.

Even as we in the library world share our code and contribute to open-
source, I think it's worthwhile to remind decision-makers about open-
source-friendly vendors and consultants to help alleviate fears. And
also to bolster demands that proprietary vendors offer us more APIs
to the innards of their systems.

-Birkin

---
Birkin James Diana
Programmer, Web Services
Brown University Library
birkin_diana <at> brown.edu

Murdering MARC

All,

I'm putting out a call to "murder MARC" (but only in the kindest way) on
my fledgling blog:
   http://kcoyle.blogspot.com/index.html

I will post various analyses there and try to stimulate some discussion
on moving forward with a new record format. I admit that we may not be
able to get very far with this communication medium, but I'm just
craving a forum for a serious discussion on this topic. Feel free to
join in.

kc

--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle <at> kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

Re: Murdering MARC

Can MARCXML offer the right mix of extensibility and backward
compatibility? I'm thinking that, with MARCXML you can do the new
things you want to do, which still being able to convert the key parts
of the record back to systems that can only "speak" MARC.

From my (outsider) perspective, the problem isn't just the format, but
the technical and legal issues with passing the information
around—Z39.50 and the potential legal issues around MARC records.
Library data is unknown outside of libraries and Amazon ubiquitous for
all three reasons—format, retrieval and licenses.

T

On 9/1/06, Karen Coyle <kcoyle <at> kcoyle.net> wrote:
> All,
>
> I'm putting out a call to "murder MARC" (but only in the kindest way) on
> my fledgling blog:
>    http://kcoyle.blogspot.com/index.html
>
> I will post various analyses there and try to stimulate some discussion
> on moving forward with a new record format. I admit that we may not be
> able to get very far with this communication medium, but I'm just
> craving a forum for a serious discussion on this topic. Feel free to
> join in.
>
> kc
>
> --
> -----------------------------------
> Karen Coyle / Digital Library Consultant
> kcoyle <at> kcoyle.net http://www.kcoyle.net
> ph.: 510-540-7596
> fx.: 510-848-3913
> mo.: 510-435-8234
> ------------------------------------
>

Re: building the "next generation" library catalog

On Sep 1, 2006, "Birkin James Diana" wrote:
>
> I'm reminded though that too often in the realm of evaluating open-
> source software, decision-makers are presented with, or believe there
> are, two choices: using scarce in-house resources to implement an
> open-source solution, or going with a vendor to implement a
> proprietary solution.

Birkin,

I think you raise an excellent point. There is not necessarily a reason to
separate the two. People need to educate decision makers about these other
options - esp. as there are more and more of them including LibLime and
Indexdata. Open Source doesn't mean only community support anymore (if it
ever did). Personally, after reading stuff or hearing presentations (and
in once case talking to personally) leaders, of library automation
companies, I think you will see a shake up - including some of the vendors
jumping to a more open system (if not an open source system) and then
focusing on support - at least for the core ILS. There just is not enough
money to be made in developing the core ILS for the vendors to put a lot
of effort into it. However, if the systems were more open, they could make
money by selling support and premium products.

This weekend is a very important one for anyone that has hopes or an
interest in an open source ILS. The success or failure of Evergreen,
fairly  or not, is going to go a long way to having more Open Source
systems in the future, or for there to be a new barrier to others trying
it. I can just imagine an administrator somewhere saying to me "Georgia
tried it and they couldn't do it, so what makes you think you can?"

Knowing what my college and some others pay for commercial ILS contracts
(and what little support and development they actually get in return)
shows me that a very small group of libraries could pool there resources
to make a viable open source ILS and save money at the same time. This is
especially true now that we have functioning systems such as Koha and
Evergreen to use or, at least, base our systems on. With more and more
open source indexing and other tools available, it won't only get easier
to develop the next generation OPAC system. What we need is people willing
to take a risk like the folks in Georgia are doing now and the Horowhenua
Library Trust did in 2000. I think the building blocks are there and the
time is right. All it will take is some leadership in this area. I know
there are systems people in libraries who want to take the challenge and
all they need is to get the decision makers to help out. Once we get a
small but noticeable number doing it, more will jump on board. I have
confidence with this as I have seen it happen to a smaller scale with
using LTSP on public computers in New Jersey public libraries. Once two or
three started using it and library directors started to talk, more and
more went with this solution very quickly.

Godspeed Evergreen!

Edward