Music Discovery Requirements

V.H Metadata Schemes: BIBFRAME 2.0

Music Discovery in BIBFRAME and other Linked Data ontologies

Discussing music discovery in a linked data environment is difficult. The flexibility and extensibility of linked data on the one hand permits an unprecedented ability to customize the discovery experience, depending on the type of search being done. On the other hand, these same characteristics and the potentially boundless linking require the developer of the discovery interface and indexes to make a lot of choices, the biggest being where to set data boundaries—what you actually display or link to on screen.

That being said, linked data is simply a carrier of data, and basic music discovery requirements are unchanged for the user. The benefits (one hopes!) is that the user experience will be improved through more flexible search possibilities. On the flipside, this may also raise user expectations to improve our data and become even more embedded into the greater web. Initial linked data discovery as part of library catalogs will likely need to work in tandem with MARC data as well, since not all data may be converted immediately and other aspects of library systems, such as acquisitions, may need still to rely on a MARC record from which to hang ordering and fiscal data. Faceted indexing may well be the bridge, and still serve its purpose in refining searches in a user-friendly manner. That being said, it may end up that such a hybrid discovery layer will result in a catalog that looks much the same as it does now! At the start, this is not necessarily a bad thing.

The primary thing to recognize in developing discovery in a linked data environment is that there will not be a single ontology or framework to work in. While this document has only referenced BIBFRAME 2.0, that ontology, by design, is lightweight and does not include the granular vocabularies necessary for actual description. Additional subclassing is needed in places and terms for named individuals must be drawn from outside vocabulary lists, thesauri, or wholescale ontologies to fill out the description. An ontology may also be extended to provide modelling for areas not present in the primary ontology, either from established ontologies or original modelling. An experimental, though fairly conservative extension of BIBFRAME 2.0 to accommodate audio recordings is currently being developed through the Performed Music Ontology subproject of the Linked Data for Production grant. Although unfinished as yet, the ontology uses individual terms and subclasses drawn from RDA value vocabularies, RDA unconstrained properties, the Library of Congress Linked Data Service, and other sources, as well as classes, subclasses, and individuals unique to the project and the performed music domain. A discovery interface will need to accommodate potential differences such as these. Allowing for this variability is a major challenge for discovery.

As stated near the beginning of this document, BIBFRAME mapping for discovery depends a great deal on context, vocabularies used, and local implementation decisions (including use of local and pre-existing extensions). The mappings provided here are not complete, and are intended only as guidance about where to start. BIBFRAME is also still evolving and it is important to check the most current, machine-readable form of the ontology from the Library of Congress.[1] Extended notes on some parts of the ontology and the ontology in human-readable form are available via BIBFRAME Model, Vocabulary, Guidelines, Examples, Notes, Analyses. Basic tooling and mappings for the 2.0 version are in development; what is currently available may be found at BIBFRAME Implementation, Tools and Downloads.

Making the ILS linked-data friendly

Even before any wholescale conversion to linked data, it is possible to make a library system more linked-data ready, and even emulate, in a highly restricted fashion, some of the benefits of linking.

  1. Allow for the enhancement of MARC records for conversion to linked data

    Linked data links through URIs, not strings. Without existing URIs, URIs must either be created locally in the conversion process and then reconciled with existing internationally-recognized URIs, or else a look-up in the relevant authority file for every term in a bibliographic record. A better way is to add as many URIs as possible through machine-processing to either bibliographic records, associated authority records, or both. Currently, URIs are recorded in the $0 of many MARC fields in bibliographic records and in the 024 or local fields in authority records, and in the authority URI (for the authority record) and value URI (for the entity) in MODS 3.6. A MARC proposal, approved at the June 2017 MARC Advisory Committee meeting, would allow for the use of $1 as well, to record URIs for entities, as opposed to authority records which are recorded in the $0.[2]

    A library system should permit the addition and indexing of URIs in the $0 and possibly the $1 in both bibliographic and authority records. Note that for bibliographic records, potential URIs are not restricted to those generally found in ILS authority files. They may be pulled from other internationally recognized authority files such as ISNI and VIAF, or from vendor-supplied URIs, or be local in origin. The system should also permit URIs already present in records to be loaded into the system along with the rest of the bibliographic or authority data.

    Even before converting the MARC record to linked data, some inserted URIs may be put to use to explore other resources if they are active links. Potentially, a discovery interface may display the URI as an icon of some sort beside the string, and link out to other data sources beyond the library catalog.

  2. Actively use the $2 in MARC records to identify vocabularies and authority files

    Subject, genre, demographic, and many other terms recorded in MARC records come from thesauri that are specified through the $2 in the relevant 65X or 38x field. An ILS authority module should use the $2 to identify the vocabulary and be able to provide authority records for any and all vocabularies that the client wishes to load into the authority module. Currently, some systems only allow for one of these vocabularies, since the module uses the second indicator “7” rather than the $2 to separate the vocabulary.


[1] The Library of Congress. BIBFRAME Implementation, Tools, and Downloads. at http://www.loc.gov/bibframe/implementation or http://www.loc.gov/bibframe/docs/. (Click on the “RDF view”.)

[2] MARC Proposal No. 2017-08, May 16, 2017, accessed August 25, 2017, http://www.loc.gov/marc/mac/2017/2017-08.html.