Report on a meeting convened to evaluate
possible implementation paths for a registry of digital
monographs and serials
Held at the DLF Forum, Pittsburgh, PA, on November 16,
2001
Notes by D Greenstein
12/7/01
Present: Judy Ahronheim (Michigan), Meg Bellinger
(OCLC), Dale Flecker (Harvard), Daniel Greenstein (DLF), Anne
Kenney (Columbia), Abby Smith (CLIR), Pat Stevens (OCLC), Taylor
Surface (OCLC), John Price Wilkin (Michigan), Marty Withrow
(OCLC), Bob Wolven (Columbia)
The group met to identify an implementation path for a
registry for digital monographs and serials, and next steps to
realize that path through some prototype development stage.
Deliberations were based upon a functional
requirement developed for the registry in June 2001 and
comments on that functional requirement.
During the meeting, the group
- reviewed the functional requirement in light of comments
received, making certain modifications;
- discussed other issues arising from the review;
- agreed a preferred solution;
- identified next steps for prototyping the preferred
solution
I. Review of functional requirement
The following was agreed
Bibliographic data. Bibliographic records for
the registry will be derived from existing records wherever
possible
Precise holdings. Precise holdings information
remains a goal for the registry. It is recognized, however, that
a registry initiative is not a place to resolve complex issues
surrounding mechanisms for precise recording of serial holdings
(e.g. at the issues and article level). Where serials are
concerned the registry should permit reference to issues and
volumes and develop practice guidelines that, for example, permit
summary references (e.g. Vols 1-4) to be interpreted as including
all issues.
The registry may not be the place where precise holdings data
are gathered and maintained. Instead, the registry might link to
such information as it may be available from the site that
maintains the digital objects in question.
Information about the use copy. Maintaining
up-to-date registry information about access terms and conditions
and about access software requirements could be complicated as
these conditions and requirements may change. It may be
preferable for such information to be maintained by the
institution that is responsible for managing the digital object
in question and linked to by the registry.
There will be advantage in developing a pick list of list of
technical formats so that formats won't have to be described in
so much redundant detail.
Information about archival master copy. Here as
elsewhere, the information in the registry may exist in the form
of a link pointing to information (in this case about the
archival master copy) that is maintained at the site that manages
the digital object in question.
Again, a pick list of technical formats will be
beneficial.
Statement of intent/queuing. Queuing is a
problem when queues aren't maintained; that is, when items
entered in the queue remain there for long periods either because
they aren't digitized as intended or because they are digitized
but not recorded as such in the registry. None the less, those
investing in digital reformatting should be encouraged to use the
queue. In addition, funding agencies that invest in digital
reformatting (IMLS, NEH) should encourage their grant holders to
use the queue (as NEH encouraged those microfilming with NEH
grants to queue their microfilming intentions)
II. Issues arising from the review
Reducing barriers to use. The registry should be
developed in such a way so as to lower the barriers to and
minimize the costs involved in data entry. Facilities that enable
batch loading of institutionally maintained records will be
especially important and will:
- reduce burden on libraries operating at production
levels;
- enable registry to quickly capture information about a
relatively sizable and diverse legacy of existing digital
content
Reducing barriers to record maintenance. The registry should
be developed in such a way as to lower the barriers to and
minimize the costs involved in maintaining records once entered
into the registry. IN this respect, facilities that enable
frequent batch updating of institutionally maintained records
will be important.
Layers of service. Registry services may be developed at
different levels. A level of core services are described in the
functional requirements document (as revised), will meet the
needs of the library community, and will have the lowest possible
barriers to use. In particular, the registry should enable
libraries to:
- locate existing digital content (including content that is in
a queue and as such about to become digitized)
- register content they have digitized (or intend to
digitize)
- access registered digital content, e.g. so that it may be
included in local library collections
Additional services may be offered by the registry provider,
for example, for example, as a means of generating revenues
sufficient to maintaining the service. Such services and the
business models that may sustain them are for the registry
provider to discuss and consider
Minimum requirement for a registry entry.
Registry entries may be relatively lightweight. At a minimum,
they will:
- refer to a digital object claiming that it exists or that it
is "in production"
- maintain a verifiable pointer to a use copy
- include a statement about the existence of a persistent
master
Additional information may also be available, much of it as
pointers
Quality control Quality control over registry
entries will necessarily be lightweight.
Inter-relationship with other registries. The
registry will need inter-relate with (load from, export to) other
registries (e.g. worldcat, microfilm registries, etc)
Next steps: need to evaluate impact on stakeholders .... Would
our plans mean for people intended to play specific roles (viz
builder, user, record supplier)
Need to look at migration path for existing large legacy
collections (Chicago, Virginia, JSTOR, etc)
Prototype phase should have carefully selected players to test
some of the issue (information from multiple sources, precise
holdings, etc)
Registry of what? The registry was initially
conceived as a vehicle for recording information about persistent
digitally reformatted monographs and serials. It is possible that
the registry's scope may be extended to include such information
objects irrespective of whether they are digitally reformatted or
born digitally.
It was agreed, therefore to review the registry's functional
specification and to extend the registry's scope to include
digital monographs and serials (irrespective of whether they are
born in printed or digital form) if by extending the registry's
scope, the function is not fundamentally altered.
Need for good practice guidelines.
III. Preferred solution
OCLC presented a number of solutions. After discussion, the
following emerged as the preference of the group
- DLF and OCLC should work jointly on a prototype registry
service
- The prototype should be built upon WorldCat as WorldCat is
redeveloped over the next few years.
- The prototype should be built in a way that lowers the
barriers to data entry and provides incentives to institutions
that create and manage digital masters to enter information about
those masters into the registry. In particular it should permit
batchloading and frequent batch updating of records thereby
keeping down costs of record creation and record maintenance.
This will require a greater degree of openness on OCLC's part
with respect to an institution's access to its records. The
present inflexibility is partly a pricing problem but also partly
a library work-flow and staffing problem.
- The prototype's development will occur in phases so that it
can take full advantage of a the redeveloped WorldCat. An initial
phase will focus on populating the registry and offer a basic
level of services. As WorldCat is redeveloped other features will
become available such as batchloading, regular batch updating,
ability to associate multiple records
- The prototype will permit variation in serials holdings
statement but guidelines will be developed to encourage good
practice
- Development of a business model should be an empirical issue
to be investigated during the prototype
IV. Next steps
- Report on meeting (DG, asap)
- Revise functional requirement incorporating modifications and
potential inclusion of monograph and serial content that is born
digital (Dale Flecker, 1/1/02)
- Develop succinct statement about aim, objective, and
implementation path of prototype (OCLC, 1/1/02)
- Internal discussions in OCLC (OCLC, 1/1/02)
- Meet at ALA midwinter to review statements and to identify
and begin recruiting participants in prototype development (all,
mid-January 2002)
- Recruit participants in the following groups (to be
determined, mid-January 2002 to mid April 2002)
- Registry data suppliers including commercial data creators
(e.g. NetLibrary(!), Oxford press, Chicago press, Elsevier,
Proquest) and libraries and other not-for-profits involved in
digital reformatting (JSTOR, Cornell, Michigan, Chicago, CIC
Wright fiction project, Virginia)
- Users - including those interested in using a registry to
avoid duplicative digitization, and those interested in using the
registry as a collection development tool (e.g. for access to
digital content)
- Initial briefing meeting with prototype participants at CNI
(all, April 2002)
return to top >>
|