Rome Wasn't Digitized in a Day - Council on Library and Information ...

251
required for efficient scientific work. Even if we have focused here on the issue of publication
repositories, which, for many reasons, lie currently at the centre of most debates, it is important
to consider that this perspective is just one element with<strong>in</strong> a larger set of digital scholarly
services that have to be managed <strong>in</strong> a coord<strong>in</strong>ated way (Romary and Armbruster 2009).
Although Romary and Armbruster have suggested that the creation of large-scale centralized digital
repositories may be the best solution, the DRIVER 706 project has <strong>in</strong>stead developed an <strong>in</strong>frastructure
that supports federated access to over 249 <strong>in</strong>dividual digital repositories across Europe. Their <strong>in</strong>itial
research (Ween<strong>in</strong>k et al. 2008, Feijen et al. 2007) identified a number of issues that needed to be
addressed to create such an <strong>in</strong>frastructure, <strong>in</strong>clud<strong>in</strong>g <strong>in</strong>tellectual property rights, data curation, and
long-term preservation. The DRIVER project guidel<strong>in</strong>es mandated a standard way for repository data
to be exposed but also provided technology to harvest “content from multiple repositories and manage
its transformation <strong>in</strong>to a common and uniform 'shared <strong>in</strong>formation space’” (Feijen et al. 2007). This
shared <strong>in</strong>formation space provides a variety of services, <strong>in</strong>clud<strong>in</strong>g (1) “services needed to ma<strong>in</strong>ta<strong>in</strong> it”
so data stores, <strong>in</strong>dexes, and aggregators are distributed on computers owned by various organizations;
(2) the ability to add services as necessary; (3) a clean<strong>in</strong>g and enhancement service that standardizes
content that is harvested <strong>in</strong>to DRIVER records; and (4) a search (SRW/CQL 707 ) and OAI-Publisher
service that allows all DRIVER records to be used by external applications. Consequently, any
repository that wishes to participate can register with<strong>in</strong> the DRIVER <strong>in</strong>frastructure and have their
content “extracted, 'cleaned', and aggregated with<strong>in</strong> an <strong>in</strong>formation space for <strong>in</strong>tegrated use” (Feijen et
al. 2007). Ultimately, the DRIVER project focused on a centralized <strong>in</strong>frastructure with an extendable
service model:
S<strong>in</strong>ce the focus of DRIVER has been on develop<strong>in</strong>g <strong>in</strong>frastructure, it has not aimed to provide a
pre-def<strong>in</strong>ed set of services. The <strong>in</strong>frastructure <strong>in</strong>cludes open, def<strong>in</strong>ed <strong>in</strong>terfaces which allow
any service providers work<strong>in</strong>g at a local, national or subject-based level, to build services on
top. They will be able to reuse the data <strong>in</strong>frastructure (the Information Space) and the software
<strong>in</strong>frastructure to build or enhance their systems. Services can therefore be developed accord<strong>in</strong>g
to the needs of users (Feiijen et al. 2007).
The DRIVER project illustrates the need for and viability of a common <strong>in</strong>frastructure for digital
preservation and data storage, while also support<strong>in</strong>g the ability to develop <strong>in</strong>novative services by
different projects.
One <strong>in</strong>novative approach to support<strong>in</strong>g even more sophisticated levels of repository <strong>in</strong>teroperability
has been <strong>in</strong>troduced by Tarrant et al. (2009). Their work used the Object Reuse and Exchange (ORE)
framework 708 that was developed by the OAI to support the “description and exchange of aggregations
of Web resources” and was conducted as part of the JISC-funded Preserv 2 project, 709 which sought to
f<strong>in</strong>d a way to replicate entire IRs across any repository platforms. As the OAI-ORE specification
<strong>in</strong>cludes approaches for both describ<strong>in</strong>g digital objects and “facilitates access and <strong>in</strong>gest of these
706 http://www.driver-repository.eu/
707 SRW stands for “Search & Retrieve Web Service” and accord<strong>in</strong>g to OCLC the development of the SRW standard is part of a larger <strong>in</strong>ternational effort
to “develop a standard web-based text-search<strong>in</strong>g <strong>in</strong>terface” (http://www.oclc.org/research/activities/srw/default.htm), it has been built us<strong>in</strong>g “common web
development tools” <strong>in</strong>clud<strong>in</strong>g WSDL, SOAP, HTTP and XML. A related standard is SRU, which stands for “Search & Retrieve Web Service”, a “URLbased
alternative to SRW” where “messages are sent via HTTP us<strong>in</strong>g the GET method” and SRW-SOAP components are mapped to HTTP parameters.
The Library of Congress actively ma<strong>in</strong>ta<strong>in</strong>s the SRW/SRU standard (http://www.loc.gov/standards/sru/). CQL stands for “contextual query language”
(http://www.loc.gov/standards/sru/specs/cql.html) and it has been developed as a both human-writable and mach<strong>in</strong>e readable “formal language for
represent<strong>in</strong>g queries to <strong>in</strong>formation retrieval systems such as web <strong>in</strong>dexes, bibliographic catalogs and museum collection <strong>in</strong>formation.” It is used by SRU
as its standard query syntax.
708 http://www.openarchives.org/ore/ and for more on the development of OAI-ORE, see Van de Sompel and Lagoze (2007).
709 http://www.preserv.org.uk/