Tracer Bullets: According to the Agile Dictionary, a tracer bullet is “a set of work where interfaces are developed from beginning to end of a process. These interfaces may be very simplified or may just pass through. The purpose of the tracer bullet is to examine how an end-to- end process will work and examine feasibility.” Key to any successful transition of technical services functions to linked data will be the transition of its traditional workflows as these workflows account for the dominant part of a department’s throughput. Stanford will be applying the tracer bullet principles to its fundamental workflows.
In 2014, UC Davis received an IMLS grant for a project called BIBFLOW. BIBFLOW is “a research agenda and a set of activities” to help the community understand its resource landscape and develop a roadmap for the coming years to move its technical services workflows into ones based in linked data. As part of their roadmap, UC Davis has done an excellent job in analyzing their own workflows and needs. Stanford will be building upon this fundamental work, examining its own workflows in light of BIBFLOW’s analysis and applying this roadmap in an actual production setting. Another key factor will be developing these workflows in the context of the other members of LD4P. By its nature, linked data is a communal but distributed effort. As opposed to working in the isolation of a single ILS and a few national or international authority files, basic metadata creation will be done in the context of a network of peers. In addition to the conversion of its own workflows, then, it is this fundamental shift in environment that the tracer bullet workflow projects will be exploring. Although other members of LD4P will not be able to apply these new workflows literally in their own unique environments, they will be able to take advantage of the modular approach and adapt it to their own environment. And the basic shift to working in a distributed, networked environment will be common to all.
Stanford has chosen to examine four workflows, two for traditional materials and two for digital: copy cataloging through the Acquisitions Department, original cataloging, deposit of a single item into the Digital Repository, and the deposit of a collection of resources into the Digital Repository. The tracer bullet will follow the life cycle of a resource, from its acquisition to discovery. Each process along the way will be converted to a linked data strategy. These processes simply need to be good enough to support an experimental workflow. Requirements for a full production workflow will be gathered iteratively and passed on through regular meetings to LD4L-Labs for development as described in Section 2 of LD4L-Labs proposal. The development of this skeletal architecture, however, will still demand a sizeable amount of effort. Through workflow analysis, we have determined eight key areas for initial development: implementation and enhancement of the LC MARC2BIBFRAME converter, functional installation of the LC BIBFRAME Editor, development of storage and caching mechanisms, development of a BIBFRAME bridge to the ILS, a BIBFRAME to Solr34 mapping for discovery in Blacklight35, the publishing of the linked data output to the web, integration of the BIBFRAME Editor to the Digital Repository, and development of the systems architecture to answer such questions as database of record for resource metadata.
Performed Music Ontology (PMO): The performed music ontology project is divided into four phases: use case development, MARC conversion remediation, ontology modelling, and profile development in association with the Program for Cooperative Cataloging (PCC). BIBFRAME development can be conceived of as a core ontology with additional domain-specific ontologies added for special communities. The library community maintains itself by creating metadata to very specific standards that can be exchanged with little or no additional effort. The danger in the BIBFRAME development model is that conflicting ontologies may be developed for the same domain and data exchange hindered. The PMO hopes to establish a model by which these extensions can be created and maintained by the library community without conflict. Key to this will be the involvement of the major domain stakeholders and the PCC to officially endorse the new ontology for all of its members. In this particular domain extension, the key domain stakeholders are the Music Library Association (MLA)36 and the Association of Recorded Sound Collections (ARSC).37 Both of these associations, and the PCC, have been contacted and are eager to participate. The work will be accomplished by a committee of five members drawn from these institutions, the Library of Congress, and Stanford. As refinements to the PMO are established, they will be fed directly to both Cornell and the Library of Congress, supporting their efforts in the transition of their music cataloging workflows. Most work will be conducted electronically but two face-to-face meetings are scheduled.
