XC Survey Report - DocuShare - University of Rochester

towerdevelopmentΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 5 χρόνια και 6 μήνες)

305 εμφανίσεις

eXtensible Catalog Survey Report

July 20
, 2007

By Nancy Fried Foster
, Jennifer Bowen, David Lindahl,

and Ryan Randall

River Campus Libraries

University of Rochester

Rochester, NY 15627

Contact: nancy.foster@rochester.edu

eXtensible Catalog Survey Report



The University of Rochester River Campus Libraries are engaged in the process of designing and
developing a set of open
source applications that will provide libraries with an alternative way to
reveal their collections to library users. This s
et of applications, called the eXtensible Catalog
(XC), will provide easy access to all library resources (both digital and physical collections) across
a variety of databases, metadata schemas and standards, and will enable library content to be
through other services that libraries may already be using, such as content management
systems and learning management systems.

XC will be open source, and available for download for free. Libraries will be able to adopt,
customize and extend the softwa
re to meet local needs. And XC will be a collaborative effort
between partners that will serve a variety of roles in its development.

Phase 1 of the XC project (2006
2007), funded by the Andrew W. Mellon Foundation, involved
the creation of a project plan
for the development of XC and recruitment of partner institutions
that will build and implement XC during Phase 2 (2007
2009). During Phase 1, the XC Team at
the University of Rochester worked
in the following six areas:


Survey and understand existing re
search on user practices


Gauge library demand for the XC system


Anticipate and prepare for the metadata requirements of the new system


Learn about and build on related projects


Experiment with and incorporate useful, freely available code


Build a community

of interest

To inform our work in several of the above areas, we conducted a survey of prospective library
users of XC to gauge interest in the XC system and readiness to implement it.

In this report, we present the findings from our survey, which we h
ave used in developing an
architecture and project plan for XC Phase 2.

General Survey Information

We designed the XC survey to help us find out what systems survey respondents currently use
for various purposes, from their integrated library systems to
course and content management
systems, institutional repositories, and so on. The purpose of this information was to help us
architect the XC system to integrate well with the best possible range of other systems.

We also asked about programming ability an
d experience in implementing open
source software
in order to design an implementable, usable system. And we asked about metadata standards, in
order anticipate and allow for a wide variety of metadata
related practices and needs.

eXtensible Catalog Survey Report


We conducted the survey f
rom January through April 2007 in two different rounds. In the first
round, the survey was sent to a representative of each institution that was invited to participate
in the first XC Partner Meeting, held February 8
9, 2007, in Rochester, NY. The result
s from
this first round helped us to prepare for the Partner Meeting and to make sure that the survey
worked in the way we planned. After the Partner Meeting, we invited an additional group of
libraries to participate in the survey. We included academic an
d public libraries of medium to
large size, as well as special collections and libraries outside of the U.S.

We administered the survey using SurveyMonkey (
). Our response rate
was about one
in four, with a total of 68 responses. A copy of the actual survey is appended to
this report.

Current Systems

OPAC Currently Used

Of the 66 survey respondents who identified their current Integrated Library System (ILS), 21
use some version of Voyager an
d 18 use an Innovative Interfaces product. Another 11
respondents reported that they use Aleph and nine that they use Sirsi. Other named systems
were Horizon, Evergreen, and GEAC Advance. Two respondents use a locally developed

With few exceptions
, respondents are not happy with their OPACs. Fifty
one respondents do
not love their OPACs, some expressing frustration or even outright hostility. Four respondents
do love their OPACs and six are neutral.

Top Issues with Currently Used OPACs

were asked an open
ended question to name their “top three gripes” about their
OPAC, and then to list additional issues if they wished to do so in a follow
up question. The
top issues expressed in these complaints were…

Difficulty of customization (42 ins

Inadequacy of search functions (31 instances)

Opacity of results and lack of grouping or faceting (27 instances)

Limitations of the user interface (16 instances)

Lack of Web 2.0 functionality (9 instances)

Backend problems (8 instances)

Lack of int
egration with databases or other systems (8 instances)

There were also multiple complaints about…

Lack of access to data (7 instances)

Difficulty finding journals and the articles in them (6 instances)

eXtensible Catalog Survey Report


Lack of updates (7 instances)

Lack of an API (applicat
ion programming interface; 6 instances)

Usability problems (6 instances)

“Dream” System

Respondents were asked in another open
ended question to name the commercial catalog
product they would buy if money were no object. Respondents clearly favored Endeca
instances). Other popular choices were III Encore and Millennium (7 instances) and
Aquabrowser (6 instances). Fewer respondents chose Evergreen (4 instances) and Primo (3
instances). Several products were named less frequently, including Aleph (2 insta
nces), Talis’s
new product (2 instances), WorldCat (2 instances), and Sirsi (1 instance). When given the
opportunity to think without being limited by financial concerns on this question, other libraries
said that they would purchase either Google (3 inst
ances) or Amazon (1 instance) if money were
no object. Amazon’s programming was even more frequently named in the respondents’
comments than in their product selections (3 comments).

The survey asked whether respondents would be likely to try a system that

would work similarly
to how we envision XC, that is, an alternative, open
source user interface that promised to solve
most of their OPAC problems and that would work alongside their existing ILS. The response
was overwhelmingly positive, with sixty posi
tive responses and four negative. Positive responses
included some libraries that are developing or already implementing alternative interfaces.
Interestingly, the most positive responses came from institutions that also indicated (on a later
survey questi
on) that they have ample

but not generous

house design and development
programs. In other words, XC is likely to hold most appeal to the wide range of “average”
libraries, as opposed to those special few libraries that already have the resources to
tweak their
existing products.

Some survey respondents volunteered concerns about using an open
source interface such as
that described above. The respondents’ biggest concern was with the new interface’s ease of
use, installation, and maintenance. This

concern was commonly voiced by respondents who also
indicated that they have limited IT resources (6 instances). Other reservations were over the
acquisitions branch of the library being willing to use an open
source product subsequent to
their testing it

(3 instances) and reservations over support issues or the ability to back out
changes if they were unhappy with the open
source product (3 instances). One such respondent
clearly stated that that the presence of paid support staff and an active user commu
nity would be
a deciding factor in implementing such an open
source system

Catalog Features

Another survey question presented respondents with a list of possible new OPAC features.
These features were chosen for inclusion in the list based upon research
conducted by the XC
Team to identify popular features in new interface products, and based upon usability problems
identified at the University of Rochester with our current OPAC.

Survey respondents were asked to envision that they had 100 raffle tickets t
hat they could
distribute among the listed features in any way that they desired. They were told to assume that

eXtensible Catalog Survey Report


if they put more than ten tickets in one box they would be “sure” to get the feature, around
eight tickets would mean that they would “probably
” get the feature, and fewer than five tickets
would mean that they would still have a chance to get the feature.

The two most popular features were:

Ability to work alongside the respondents’ existing library servers to provide new
features to end users

aceted search interface

Other popular features were:

Integrated user interface that searches across digital and non
digital resources

like search box with no need to select an index

“Did you mean…” spelling correction

Many respondent
s were also interested in seeing:

Flexible ways to view search results, including relevance, popularity, or availability

Search system that produces better results for simple keyword searches

The full list of features, along with the number of “tickets” ea
ch feature received, follows.

New OPAC Feature


Works alongside your existing library servers (catalog, metasearch, OpenURL
link resolver, authentication server, repository, course management system) to
provide new features to end users


Faceted search interface


Integrated user interface that searches across digital and non
digital resources
(books, articles, digital repositories, DVDs and more) at the same time


like search box with no need to select an index


“Did yo
u mean…” spelling correction


j潲攠oa祳⁴漠癩ow⁳敡牣栠牥r畬瑳Ⱐ楮I汵摩湧⁲敬 癡湣攬⁰潰畬 物r礬⁡va楬i扩汩瑹l


卥a牣栠r祳y敭⁴桡琠t整畲湳⁢e瑴敲⁲敳畬瑳⁦ 爠r業灬i敹w潲搠o敡牣桥r


q潯汳⁴漠s異灯u琠t桥⁦楮摩湧n⁧ 瑨敲楮本⁵獥⁡湤⁲敵s攠e
⡥⹧⸬⁒卓⁦敥摳Ⱐ扬潧sⰠ瑡g杩g本⁵ 敲⁲敶楥wsF


汩步⁳畧u敳e楯湳⁦潲⁦畲瑨敲⁴楴汥猠楮s瑥t搠潦d潮汹楮 楮i⁴漠 畢橥捴c


eXtensible Catalog Survey Report


New OPAC Feature


Optional grouping of related works in search results


"More like this" suggestions


Display of the relevant request options display based on circulation status of
the item


Support for harvesting by third parties


Browseable lists of content (for example, eJournals, Databases, new books,
and so on)


Display of the most releva
nt fields for different media on results screens


Advanced search options made easier to use


defined email notifications


defined communities with custom views


Authoring and collaborative environment for the creation and use of


Personal showcase pages for institutional/faculty
created content


Usability Issues

When asked whether they regularly conduct
usability testing

in their library, more than half (56
percent) of respondents answered yes.

When asked w
hether they had done user research aside from usability testing, the most common
response was that they had done focus groups for various reasons (8 instances). The next most
commonly performed forms of user research were search log analysis (4 instances)
participation in LibQual (
) (3 instances). Other types of research
conducted included user behavior, needs, expectations, and satisfaction, orientation surveys of
users’ previous library experience, interviews of faculty cyber
frastructure needs, exit surveys,
and space use surveys. One respondent additionally uses metrics to measure use of their web
pages and has recently implemented the American Customer Satisfaction Index for its website.

Current and Planned Metadata Schemas

Respondents were asked what metadata schemas they currently use or plan to use in the near
future for their
general non
digital collections
, selecting all that apply to their library from a
supplied list of schemas
. MARC21 was clearly the most popular (58
instances). The next most
popular were MARCXML (19 instances), Dublin Core (19 instances), and EAD (18 instances).

The two most popular metadata schemas for respondents’
specialized non
digital collections

were EAD (46 instances) and MARC21 (45 instances)
. Dublin Core (21 instances), MARCXML
(17 instances), VRA Core (10 instances) and MODS (9 instances) were the other commonly
used metadata schemas.

eXtensible Catalog Survey Report


For their
institutional repositories
, respondents use Dublin Core most commonly (42
instances). The second t
ier of schemas used for institutional repositories includes MODS (22
instances), METS (20 instances), and EAD (19 instances). Other commonly used schemas are
MARCXML (15 instances), PREMIS (15 instances), MARC21 (12 responses), and VRA Core
(10 instances).

For their
other digital collections
, respondents favor Dublin Core (39 instances) as their
metadata schema. Other popular schemas are EAD (33 instances), MODS (29 instances),
MARC21 (25 instances), and METS (23 instances).

Respondents use or plan to use a

variety of
other metadata schemas
. The most common is
MARCXML (14 instances), closely followed by Dublin Core, EAD, METS, and PREMIS (12
instances each), and MODS (11 instances).

Respondents favored using METS for storing
digital objects

(23 instances).

any responding libraries indicated that they expect to increase their use of

within the next three years. They plan to

move away from home
grown schemas
toward using accepted, robust

standards such as METS, MODS, MADS, PREMIS, EAD, VRA

Core, and

Dublin Core. Several responding libraries mentioned that they

plan to

move toward
using a wider variety of metadata schemas in the near future, and will focus on


schemas to facilitate interoperability and metadata harvesting. In
dividual respondents also
mentioned an interest in the potential use of

DIDL, EAC (Encoded Archival
Context), and PatREST (for social metadata).

When asked what metadata schemas they use for purposes besides resource discovery, such as
vation and rights management
, many respondents report that they use PREMIS (18
instances), followed by METS (7 instances).

When asked if they reuse any other
descriptive metadata from other sources
, respondents
most commonly report using metadata in MARC2
1 (7 instances). Other sources of descriptive
metadata use ONIX (4 instances), DC and MODS (3 instances apiece).

Only a few libraries provided information regarding changes to their use of


from other sources over the next 24 months. Th
ose that did respond mentioned
obtaining more descriptive MARC metadata from vendors, such as YBP and Serials Solutions,

from publishers and aggregators for the resources contained within their products. Syndetic
Solutions, as a source for enriched des
criptive metadata, was also mentioned. Several libraries
expressed an interest in using ONIX data from publishers as a source for descriptive metadata,

commented that they expect to be ingesting metadata in multiple formats in the near future.
One resp
ondent commented that "Re
use of existing metadata and transformation of

from one format to another will become commonplace and routine."

The clear majority of respondents use
OCLC’s Connexion

client or browser as a part of their
current catalogin
g/metadata operations (44 instances).

eXtensible Catalog Survey Report



Respondents were asked about their
experience with open
source software
. All of those who
answered had installed open
source software in their library (62 instances; 6 skipped this
question). Those who h
ave experience with open
source software tend to install it frequently,
with many having installed software within the last year (18 instances). Of these 18, three
respondents had done so the day of the survey and three within the previous week. Another fi
respondents had installed open
source software in their libraries during 2006, and three had
done so in 2004 or 2005. Commonly installed open
source software includes DSpace, Drupal,
Lucene, various wikis, and dotProject.

installation of the open
urce software

was most commonly done either by the library’s
IT department (12 instances) or the library staff (9 instances). Occasionally the installation was
performed by software programmers or developers (6 instances) or by a university’s IT

(5 instances).

The survey asked whether the technological infrastructure of the libraries was generally
control of the libraries

themselves or under control of a central ITS department, in order to
determine what sort of restrictions libraries might

have on implementing an open
source system
such as XC within the library. In most cases (50 instances) it is under the control of the libraries
themselves, while in a few cases (7 instances) it is under the control of a central ITS department.

The respon
dents whose IT is centralized outside of the library were asked what

arise with regards to implementing and working with an open
source library
centric application
like XC. Common issues were staff availability, server access, and development
issues, each cited
by two respondents. Other issues were security, expertise, central support for specific
applications, storage space, and coordinating the installation of security patches across

When all respondents were asked what

to downloading, installing, and using
a product like XC they could anticipate at their institution, the most common concerns were
personnel availability for installation and maintenance (7 instances) and lack of resources to
customize the product

(6 instances). Time (5 instances) and expertise/training (4) were the next
most common concerns. After that came access/authorization, performance load/need for
dedicated servers, resistance to something new, and security (3 instances each). Platform and
dependencies issues were also common (3 instances). Compatibility issues and lack of
administrative understanding of the reinstallation’s priority were other common concerns (2
instances each).

A majority of respondents said that they would want to
build a
dditional applications

on XC’s
platform beyond a supplied user interface (54 instances). Nine respondents skipped this
question, and five said directly that they would not build additional applications. The additional
applications that respondents would be

most commonly interested in building on top of the XC
platform are course management integration and federated searching (3 instances apiece).
Integration with existing library resources or campus authentication systems were also common
potential applicat
ions (2 instances), with respondents considering integration with existing
grown e
reserves, Open URL, and ERMS systems, with Sakai and other systems, with
ILL, e
journals, and image databases, and with campus authentication and related customization

eXtensible Catalog Survey Report


based on the identity of user population. Customization in other ways was also a common
interest, with respondents desiring to make custom end
user interfaces to non
MARC databases,
personalized collections and interfaces, customized ILL, e
journals, datab
ases/Open URL, and
image databases.

Specialized subject portals were also considered a potential development, such as pulling
together digital sources or giving different faces or catalogs for different media types.
Respondents were also interested in col
laboration tools, widgets, request/delivery services for
remote storage, syndication of content in other discovery environments, linking with Content
Management Systems, linking with their own digital repository ERM module, web
applications for searc
hing, instruction, and researching, creating new mash
ups as needed,
leveraging content of objects in addition to their description, data mining, statistical reporting,
and an OAI data provider. Also, one respondent would develop the ability for XC to sear
three catalogs at three different locations as if they were a single catalog. This respondent hoped
that this would be a built
in feature because they were certain that programming this feature
themselves would take a long time due to their limited reso

Libraries report their
highest level of programming proficiency

Java, Javascript, and XSLT. They have the
largest number of programmers

in CSS, XML,
PHP, PERL and Javascript, with strength in XSLT, Java, and C++.

Most respond
ents (81 percent) believe that they would be able to dedicate
enough resources

download, install, and support XC. In addition, about half (53 percent) would have the resources
to customize the interface or build new user features and about a third (35 p
ercent) would even
consider increasing their programming staff in order to do this.

Technical Requirements

When asked whether their library department had any
platform preferences
, the most common
responses were Solaris (24 instances) and Linux (20 instan
ces). The next most common were
RedHat ES and Windows (11 instances each).

As for
, the most popular was Sun (16 instances), followed by Dell (13 instances). The
next level of popularity included HP/Compaq (5 instances), Apple and IBM RS6000 (3 in

, respondents favored MySQL (27 instances) or Oracle (26 instances). These were
distantly followed by Postgres (6 instances), MS SQL Server (4 instances), and Sybase (1

Other common preferences included JAVA (10 ins
tances), Tomcat (6 instances), Apache and
PERL (5 instances each) and PHP, Spring, and Ruby on Rails (3 instances each).

The two most commonly used
database servers

are MySQL (96 percent) and Oracle (79
percent). These were followed by Microsoft SQL (50 pe
rcent) and PostgreSQL (31 percent).
DB2 and Sybase each were used by 9 percent of respondents.

eXtensible Catalog Survey Report


The majority of respondents would not need to display a
ser interface in a language other
than English

(67 percent). Of those who needed non
English language su
pport, the top need
was for Spanish (12 instances). CJK (Chinese, Japanese, and Korean) was the second most
needed selection. These languages were separately indicated as well, with four respondents
needing Chinese, three needing Korean, and two needing Ja
panese. Other common language
requests include Arabic (5 instances), French (4 instances), Hebrew (2 instances), and “All
Including Non
Roman” (2 instances). Respondents indicated that French was mandatory for
Canadian Government institutions, which by law

must provide services in both English and
French. Single responders additionally needed Cyrillic, Danish, German, Italian, Tagalog, and

When asked which
repository or eprint systems

they use, the respondents cited DSpace most
commonly (46 perc
ent). Other popular systems were ContentDM (34 percent), Sakai (21
percent), Fedora and Greenstone (19 percent each).

When asked what, if anything, they need their existing
institutional repository

to do that it
does not already do, the new features mentio
ned included support for long
term archiving, an
interface that is easy to customize and will not require revisiting with each upgrade of the
software, the ability to offer different levels of access to materials in a manner that is easy to set
up and main
tain, accept and deliver a variety of interactive materials such as websites, web page
capture and archiving, management interface, security access, control provisioning, statistics for
search/indexing/reports/usage, streaming content from repository, vers
(editing/changing records after submission), integration with all other applications, and
integration with UMI for theses and dissertations. Many respondents also desired various
specific improvements, such as to the search interface, ingest workflo
ws, access layer, federated
searching, and the user interface.

The most commonly used
authentication system

is LDAP (83 percent). The second most
common were Ezproxy (70 percent) and VPN (60 percent). After those, Shibboleth (38 percent)
and CAS (10 percen
t) were most common. Fifty
six percent of respondents said that a single
authentication system was not used across their catalog, interlibrary loan, and IR systems. Of
those 44 percent who did use a single system, 65 percent said that it is the same system

that the
campus uses.

Metalib (ExLibris) is the most commonly used
metasearch software
, with about half (54
percent) of responders using it. WebFeat (22 percent) and Serials Solutions Central Search (19
percent) are the next most commonly used software, w
ith MetaFind (5 percent) and LibraryFind
(3 percent) far behind.

Of those respondents who use an
open URL resolver
, the majority use SFX (Ex Libris) (62
percent). The next most commonly used are Article Linker (Serials Solutions) (26 percent) and

(III) (6 percent).

Respondents were asked what types of

to their library catalog they currently provided.
Of these, the most commonly reported were electronic resources management software (73
percent) and products such as those provided by Serial
s Solutions (58 percent). Other popular
ons were offsite storage management software (23 percent), cover images (21 percent),
scheduling or calendaring software (13 percent), and user interface add
ons like Grokker, Primo,

eXtensible Catalog Survey Report


or Aquabrowser (10 percent).
Others specified in the comments section were electronic reserves
and tables of contents.

When asked what
digital library products

they used besides their ILS, respondents largely
reported using course management systems. WebCT (34 percent) and Blackboard
(37 percent)
were the most common of these. Drupal and Sakai (16 percent each) were also commonly

Respondents were asked if they routinely send copies of their bibliographic and holdings data to
regional database or consortium
, and if so, to b
riefly name the steps in the technical
process. This question was included in the survey to provide us with a sense of how difficult it
would be for libraries to extract a copy of their ILS data, and what level of experience libraries
already have with thi
s type of metadata processing. Nine respondents did not send their data
elsewhere, and 28 did. Of those 28, 15 sent their data to OCLC, five to INNREACH, and two
to CDL. The data were sent in a variety of ways, including hourly batch exports, exposing EAD

finding aids and digital content via OAI
PMH, flagging the records to send using a local
application that writes record IDs to Oracle tables, processes that extract the MARC records
using a combination of local programs (to update the Oracle tables) and V
oyager programs (to
extract the MARC records), transferring by FTP, and running PERL scripts and sending that to
WRLC. Time intervals included real
time, hourly, nightly, weekly, and when new items are
entered into the home library’s catalog.

Respondents w
ere asked what

features they have currently implemented in
their library websites. The ability to notify patrons when new material matching a patron’s
interests (saved searches) is cataloged was the single most common feature, with four ins
Of these, three notify patrons by email and one by RSS alerts. Personalization and circulation
information were other common features. Additional features included tagging, reviews, rating,
and commenting on items, as well as having personalized e

When asked how they are using
RSS feeds

in their library websites, the largest group of
respondents said they were using it for news feeds or events (12 instances). Second most
common was the use of RSS to inform patrons of new items being added
to the catalog (9
instances). Other uses include publicizing library hours, publicizing when open
access research
papers have been deposited into an institutional repository, feeding course reserves into Sakai,
using OpenSearch interfaces, for subject guid
es, and for a database of databases.

Respondents were asked how they are making applications that focus on
cell phone or PDA

users. Many do make the library catalog accessible in this way, with 3 respondents using III’s
“AirPac” and two reporting that thei
r library’s ILS makes a stripped down version of the online
catalog and stripped down webpage with library hours or other useful information. Other uses
include RSS feeds for searches, renewal of books, and using SMS to get catalog records to cell
Two respondents also mention that their health science libraries make resources
available for cell/PDA users, including using PubMed for handhelds, WISER for first
responders in hazardous materials instances, and AIDSinfo for PDA tools. One respondent
tionally mentions using iPod for distributing course reserves material, and one respondent
mentions Cocoon

eXtensible Catalog Survey Report



Respondents were asked questions about their potential participation in XC.

Only a small percentage of respondents (9 percent) curren
tly have a contract in place for an
alternative interface to their library resources and just under half (45 percent) feel that they will
be under pressure to sign a contract for such an alternative interface within the next 24 months.

Most (92 percent) w
ould still consider implementing XC if its support were done by contract
with a commercial vender and about two thirds (67 percent) would consider implementing XC if
no support were available. All respondents would be willing to implement some change in da
load or metadata workflows in order to gain improved search capabilities for their users.

Respondents were asked whether they have any concerns that if they installed and ran XC they
might lose out on anything they currently get from their OPAC vendor b
ecause of contractual
obligations. Most said no (28 respondents). Five said they were not sure, four said yes, three
gave conditional answers, three said that the loses would be minimal because of their high
dissatisfaction with their OPAC, and one said th
at they would abide by their contract. Concerns
were raised over whether or not the vendor could claim that XC interfered with system
functionality, as well as the significant change from having an even minimally supported product
with defined expectations

for problem resolution, upgrades, enhancements, bug fixes, etc. to an
unsupported product. Respondents also mentioned concerns for the possible loss of “24x7”
tech support, a defined enhancement request process, and error reporting.


We learne
d from libraries that responded to the survey that they want a system that will provide
better functionality to their users than their ILS currently provides, and that will not require
them to migrate away from their ILS. They want to be able to easily cu
stomize their catalogs,
and to integrate searching across both digital and non
digital resources. They want to provide
their users with faceted search results, Web 2.0 features, and links that will allow them to bring
library metadata into content managem
ent systems

We have concluded that there is indeed a significant demand for a system such as XC, which will
provide more user functionality and flexibility than most current ILSs, but will not require a
library to migrate away from their ILS. Based upon
these survey results and other feedback
from potential XC users, we have refined the scope of the XC project, the functional
specifications for the software, and the technology that we will use to build XC

all to closely
reflect the needs of the library

The University of Rochester eXtensible Catalog Team heartily thanks the libraries and other
institutions that responded to the XC survey, thus enabling us to inform the future development
of the XC system.

eXtensible Catalog Survey Report


Appendix I. Responding Institutions

he largest group of responding intuitions was large, public universities in the US (34 percent),
followed by medium
size private universities (11 percent) and large private universities (10
percent). Small private colleges and universities and private tech
nical institutions and large,
public, technical institutions (5 percent in all categories), along with religiously affiliated
universities (3 percent) constituted the remaining US educational institutions.

US universities made up ten percent of the res
pondent group.

sponsored libraries also responded to the survey, including both US (3 percent)
and non
US (5 percent) government
sponsored libraries.

The remaining respondents were library consortia (3 percent) and special institutions (2 percen

eXtensible Catalog Survey Report


Appendix II. Survey Questions