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

1. Report on meeting (DG, asap)
2. Revise functional requirement incorporating modifications and potential inclusion of monograph and serial content that is born digital (Dale Flecker, 1/1/02)
3. Develop succinct statement about aim, objective, and implementation path of prototype (OCLC, 1/1/02)
4. Internal discussions in OCLC (OCLC, 1/1/02)
5. Meet at ALA midwinter to review statements and to identify and begin recruiting participants in prototype development (all, mid-January 2002)
6. 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)
7. Initial briefing meeting with prototype participants at CNI (all, April 2002)

return to top >>