This site contains an archive of v1.0 of the BIBFRAME vocabulary.
BIBFRAME 2.0 Resources:

This version:
Latest version:
Previous version:
Kevin Ford, Library of Congress
Ted Fons, OCLC
Contributors (in alphabetical order):
Jan Ashton, British Library; Karim Boughida, George Washington University Libraries; Alan Danskin, British Library; Corine Deliot, British Library; Ray Denenberg, Library of Congress; Nancy Fallgren, National Library of Medicine; Jean Godby, OCLC; Rebecca Guenther, Library of Congress; Reinhold Heuvelmann, German National Library; Sally McCallum, Library of Congress; Eric Miller, Zepheira; Uche Ogbuji, Zepheira; Jackie Shieh, George Washington University Libraries; Nate Trail, Library of Congress; Beacher Wiggins, Library of Congress

Status of this Document

Note: This section describes the status of this document at the time of its publication. Other documents may supersede this document.


To the extent possible under law, Library of Congress has waived all copyright and related or neighboring rights to this work. This work is published from the United States.

This document has been made available to the BIBFRAME Community for review. This is a discussion paper. It may be superseded in the future with an updated version that may represent minor corrections or major changes. In either case, access to previous versions will be maintained.

Please send general comments about this document to the public Bibliographic Framework Initiative discussion list.

Table of Contents

  1. Current understanding
  2. The "lightweight abstraction layer"
    1. Identifying BIBFRAME Authority resources
    2. Relating BIBFRAME Authorities to Works and Instances
    3. Flexibility for implementers
  3. Issues
    1. The "Direct" approach
    2. A Role resource
    3. Subject representation, specifically LCSH
    4. Bad data
    5. Classification and other unknowns
    6. The name, "Authority"
  4. Discussion
  5. Recommendations
  6. Change log

Editors' note:

This is still a "discussion paper" and meant to elicit constructive feedback. Changes, additions, and deletions stem primarily from listserv feedback, which may have offered alternate ideas, indicated confusion with the present document, and/or suggested areas in need of greater clarification and explanation.

This version, however, and in addition to the those items listed below under "Major changes," does reflect a move toward settling on the lightweight Abstraction Layer as a stable aspect of the model. To this end, a new section (Section 2) has been devoted to better defining the lightweight abstraction layer, discussing how it is expected to be identified and how it relates to BIBFRAME Works and Instances, and describing how the lightweight abstract layer can be leveraged by implementers as a flexible way to augment their own data.

Finally, class names and property names seen in the examples of this document may not reflect the classes and properties currently seen at There are various reasons for this, but what is important presently is that the examples below be conceptually illustrative of issues discussed within this document.

Major changes in this document from the previous version:

1) This revision reflects a more refined understanding of how a BIBFRAME Authority may link to a traditional library authority. This not only impacts how to best identify which "link" points to the traditional, "authoritative" library resource used as a point of control but also how to manage the representation of LCSH pre-coordinated concepts

2) This revision includes a more detailed, explanatory discussion about expectations surrounding how BIBFRAME Authority resources are identified and how they relate to BIBFRAME Work and BIBFRAME Instance resources (via a property / URI).

3) This revision removes discussion about leveraging the BIBFRAME Authority model for provider information, such as publisher, manufacturer, or producer, including where a resource was published, manufactured, or produced. Although some of the issues discussed about these aspects in the preceding version of this paper still apply, current modeling choices identify these as "events" in the lifecycle of the resource and treat them as such.

4) Based on community feedback, this revision includes a short discussion about an alternative modeling option herein referenced as "Role resource" (section 3.2).

Current Understanding

The BIBFRAME Primer document, Bibliographic Framework as a Web of Data, defines a BIBFRAME Authority as "a resource reflecting key authority concepts that have defined relationships reflected in the [BIBFRAME] Work and [BIBFRAME] Instance" (p8, also p10). People, Places, Topics, and Organizations are examples of what could be a BIBFRAME Authority. The document further explains that "BIBFRAME Authorities are not designed to compete or replace existing authority efforts but rather provide a common, lightweight abstraction layer over various different Web based authority efforts to make them even more effective" (10). BIBFRAME Authorities are used to identify authors and others associated with a Work or Instance (such as creators, editors, distributors, etc.) and subjects, including temporal and topical concepts and geographic places.

The following example (Example 1) reflects how a BIBFRAME Authority, which in turn relates to "existing authority efforts," and BIBFRAME Work relate to each other as described in the BIBFRAME Primer.

<!--  BIBFRAME Work -->
<Report id = "http://bibframe/work/frbr-report">
     <authorizedAccessPoint>IFLA Study Group on the Functional Requirements for Bibliographic Records.
             Functional requirements for bibliographic records: final report.
     <title>Functional  requirements for bibliographic records :</title>
     <subtitle>final report</subtitle> 
     <creator resource = "http://bibframe/auth/org/ifla" />

<!--  BIBFRAME Authority -->
<Organization id="http://bibframe/auth/org/ifla">    
     <authorizedAccessPoint>IFLA Study Group on the Functional Requirements for Bibliographic Records. 
</authorizedAccessPoint> <link></link> <hasAuthority resource="" /> </Organization>
Example 1


In Example 1, the Organization resource is referenced from the Report resource but it in turn references the traditional name authority resource at ID.LOC.GOV. The ID.LOC.GOV resource is identified as being the "authoritative" source for this BIBFRAME Authority, at least with respect to its authorized access point. The "Organization" resource in the above example is the "lightweight abstraction layer" described in the BIBFRAME Primer.

In meetings with Zepheira, the BIBFRAME Model developers, a BIBFRAME Authority was also described as a functional component introduced to facilitate indexing and display challenges.

Presently, there are nine specific BIBFRAME Authority types defined in the BIBFRAME vocabulary: Family, Jurisdiction, Meeting, Organization, Person, Place, Topic, Classification, and Temporal Concept.

The "lightweight abstraction layer"

Identifying BIBFRAME Authority resources

The current design of a BIBFRAME Authority is described as a lightweight Abstraction Layer because it is intended to function as a bridge between a BIBFRAME Resource, such as a Work or Instance, and a traditional, published library-type authority for an Entity, such as a Person, Organization, or Place. Example 1 illustrates the lightweight Abstraction Layer approach, showing a BIBFRAME Work linking to a BIBFRAME Authority which in turn includes links to ID.LOC.GOV, the latter being the authoritative source for the authorized access point. When a BIBFRAME Authority is used to link to a traditional authority resource, the lightweight Abstraction Layer introduces a layer of indirection to the model.

The BIBFRAME Authority (which effectively is the lightweight Abstraction Layer) is a resource and, as such, may be identified by a URI or blank node. Implementers are encouraged, however, to identify their BIBFRAME Authority resources with HTTP URIs (of the domain creating the resource) so that they may be referenced and linkable via the HTTP network protocol. In this way, the BIBFRAME Authority - identified with an HTTP URI - would itself function as a local access point for the person or concept. The lightweight Abstraction Layer (the BIBFRAME Authority), however, need not link to a traditional name or subject authority resource, which is especially important since there may be no traditional authority resource to link to (not all names and subjects found in current bibliographic data have corresponding authority records).

It is expected that — per implementation [ 1 ] — there would be only one BIBFRAME Authority per entity. That is, one BIBFRAME Authority per person, per topical concept, per geographic place. One BIBFRAME Authority, therefore, may be referenced by a number of different resources. For example, if a collection has four different works by Richard Dawkins, they should all link to one BIBFRAME Authority resource representing Richard Dawkins, not four. In this way, there is merely one resource to be updated should the preferred form of Richard Dawkins name change.

Relating BIBFRAME Authorities to Works and Instances

BIBFRAME Authority resources will relate to BIBFRAME Work or Instance resources via a defined property (identified with a URI) whenever possible. When relating a Person or Organization associated with a BIBFRAME Work, a property indicating the role of the entity in relation to the resource will be employed. For books this might be "author" or "illustrator," as in Example 2. For films this may be "director" or "actor."

<!--  BIBFRAME Work -->    
<Book id = "http://bibframe/work/eloise-in-paris">
    <title>Eloise in Paris</title>
    <author resource = "http://bibframe/auth/person/kay-thompson" />
    <illustrator resource = "http://bibframe/auth/person/hilary-knight" />

<!--  BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/kay-thompson">
     <authorizedAccessPoint>Thompson, Kay, 1909-1998</authorizedAccessPoint>
   <hasAuthority resource="" />

<!--  BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/hilary-knight">
     <authorizedAccessPoint>Knight, Hilary</authorizedAccessPoint> 
<hasAuthority resource="" /> </Person>
Example 2


An equally appropriate property will be used for subjects, such as seen in Example 3.

<!--  BIBFRAME Work -->    
<Book id = "http://bibframe/work/early-italian-masters">
    <title>Early Italian masters</title>
    <subject resource = "http://bibframe/auth/topic/engraving-italian" />

<!--  BIBFRAME Authority -->
<Topic id="http://bibframe/auth/topic/engraving-italian">
     <authorizedAccessPoint>Engraving, Italian</authorizedAccessPoint>
     <hasAuthority resource="" />
Example 3


Flexibility for implementers

Because BIBFRAME Authority resources are designed as abstraction layers, this can easily enable implementers to augment entities for People, Organizations, Places, and Topics with information from other sources while still providing a means to offer implementers a way to leverage and make use of traditional, controlled library authority data.

The RDF snippet in blue text of Example 4 shows how it is possible to import variant labels of Charles Darwin's name. The snippet in red demonstrates how it is possible to link this BIBFRAME Authority resource to other resources. In this example one link goes to VIAF and the other the Deutches Nationalbibliothek (DNB). The snippet in green illustrates that it is possible to import information from external sources, in this case DBPedia and Wikipedia. The example includes information about what fields Darwin worked in, a web location where one can read a short biography, and a representative image of him.

xmlns:foaf="" xmlns:dbprop="" xmlns:bf=""> <!-- BIBFRAME Authority --> <bf:Person rdf:about=""> <bf:authorizedAccessPoint>Darwin, Charles, 1809-1882</bf:authorizedAccessPoint> <bf:hasAuthority rdf:resource="" /> <bf:variantLabel>Darwin, Charles Robert, 1809-1882</bf:variantLabel> <bf:variantLabel>達爾文, 1809-1882</bf:variantLabel> <bf:variantLabel>تشارلز داروين, 1809-1882</bf:variantLabel> <bf:viafLink resource="" /> <bf:dnbLink resource="" /> <bf:bioSource rdf:resource="" /> <dbprop:fields rdf:resource="" /> <foaf:depiction rdf:resource="" /> </bf:Person> </rdf:RDF>
Example 4



The "Direct" approach

The Direct approach, which is also the "ideal" Linked Data approach and which most stakeholders have been conditioned to expect, would be to associate a traditional, library-type authority directly with a Resource, such as a Book or a BIBFRAME Work as in:

<!--  BIBFRAME Work -->
<Report id = "http://bibframe/work/frbr-report">
     <title>Functional requirements for bibliographic records :</title>
     <subtitle>final report</subtitle>
     <creator resource = ""  />
Example 5


Example 5 illustrates the Direct option: the report's creator is identified with a URI (an identifier) of a traditional, library-type authority, in this case it is the name authority resource published at ID.LOC.GOV. No "lightweight abstraction layer" required. There really is no BIBFRAME Authority. The resource reflecting the bibliographic entity simply points to the "authoritative" resource directly.

The Direct approach presents a stricter way to associate traditional authority data with BIBFRAME Works and Instances and introduces, potentially, a degree of variability to the model since it will often be necessary to accommodate data that does not exist in traditional authority files. For example, not all names in current bibliographic records are represented in authority files but these would nevertheless need to be accommodated. The lightweight abstraction layer approach provides one single way to manage description, especially in the absence of a pre-existing URI for a resource, while providing a means to augment data to specific implementer's needs or desires.

  1. Are the benefits of the lightweight approach over the limitations of the direct approach sufficient to justify its adoption?
  2. If using the Direct approach, what happens when there is no URI for a resource?

A Role resource

Another modeling option — especially one that provides maximum flexibility — is to investigate abstracting Role into its own resource, effectively creating a layer between a BIBFRAME Authority and a BIBFRAME Work or BIBFRAME Instance. This was an issue, and proposal, described in community feedback. [ 2 ] Example 6 represents this idea:

<!--  BIBFRAME Work -->
<Book id = "http://bibframe/work/eloise-in-paris">
     <title>Eloise in Paris</title>
     <agentRole resource = "http://bibframe/role/abcdef" />

<!--  BIBFRAME Authority -->
<Role id = "http://bibframe/role/abcdef">
     <relationToResource>author of</relationToResource>
     <relatedPerson resource="http://bibframe/auth/person/kay-thompson" />

<!--  BIBFRAME Authority -->
<Person id = "http://bibframe/auth/person/kay-thompson">
     <authorizedAccessPoint>Thompson, Kay, 1909-1998</authorizedAccessPoint>
     <hasAuthority resource="" />
Example 6


The property "agentRole" may not be the perfect name, but it points to the challenge involved with unambiguously identifying the relationship between the Work and the Role that, in turn, points to a Person Authority. Also, "relationToResource" could reference a URI versus being a Literal.

Without leveraging additional properties of Role beyond "relationToResource" and "relatedPerson," the Role resource not only adds a layer of unnecessary complexity (because the requirement to associate a Work and Person could be met with a simple property) but it also weakens the roles relationships play in the overall model. Example 6 would also address the "bad" data issue described below in section.

  1. Is the added flexibility, particularly the ability to handle controlled role information and uncontrolled role information worth the overhead?
  2. If a simple property could be used to associate a BIBFRAME Work and BIBFRAME Authority in 95%+ of all cases, is the complexity presented with the Role-as-resource option worth it?
  3. Are there additional properties that could be asserted as part of the Role resource beyond the two presented in Example 6?

Subject representation, specifically LCSH

The representation of subject information with respect to the lightweight Abstraction Layer may require careful thinking, especially for Library of Congress Subject Headings. LCSH employs pre-coordination to generate more specific concepts with which to describe resources. Pre-coordinated strings are created by assembling terms, all of which after the leading term are subdivisions. The order of terms constituting a pre-coordinated heading is important. Because it is possible to construct any number of headings from combinations of terms and subdivisions, LCSH is an infinite system. With only about 415,000 entries, the LCSH file maintained by the Library of Congress does not include all authorized LC Subject Headings; it contains authorized terms and authorized subdivisions, the combinations of which can be used to create an authorized heading. This file is published as linked data at ID.LOC.GOV and each concept given its own URI. Therefore, and in conjunction with the limitations mentioned about the LCSH file maintained by LC, URIs exist for most of the parts that would be used to construct a heading (either a single term heading or a pre-coordinated one). However, because the LCSH file does not include all possible or existing authorized headings, there are no URIs in existence for the vast majority of LC subject headings.

The lightweight Abstraction Layer permits a way to easily link to (that is, identify) an "authoritative" resource — either by HTTP URI or blank node — that can be leveraged to capture, and maintain in order, the components of a pre-coordinated subject heading. This would ease the transition to BIBFRAME in that little, or no, further foundational work would be required with respect to library authority management. The Direct option would require a URI for all existing LCSH headings found in bibliographic records.

Example 7 shows how a pre-coordinated heading can be represented in a BIBFRAME Authority.

<!--  BIBFRAME Work -->
<Topic id = "http://bibframe/authority/www--social-aspects--united-states">
      <authorizedAccessPoint>World Wide Web--Social Aspects--United States</authorizedAccessPoint>
     <madsrdf:ComplexSubject xmlns:madsrdf="">
         <madsrdf:authoritativeLabel xml:lang="en">World Wide Web--Social aspects--United States</madsrdf:authoritativeLabel>
         <madsrdf:componentList rdf:parseType="Collection">
               <madsrdf:authoritativeLabel>World Wide Web</madsrdf:authoritativeLabel>
               <madsrdf:authoritativeLabel>Social aspects</madsrdf:authoritativeLabel>
               <madsrdf:authoritativeLabel>United States</madsrdf:authoritativeLabel>
Example 7


The <hasAuthority> property identifies - via blank node in this example - a MADS/RDF representation for "World Wide Web--Social Aspects--United States." The MADS/RDF supports the identification of the three types of individual headings that have been pre-coordinated (two topics and a geographic) as well as a means to maintain their order.

Bad data

There will be instances when not only is it undesirable to lose valuable information, but also unacceptable. Therefore "bad" is not meant in a pejorative sense but to describe data that is so poor as to defy programmatic identification and manipulation. A case in point is the $e (relator term) of the 1XX (or 6XX or 7XX or 8XX) name fields in the MARC Bibliographic record format. Subfield "e" is designed to capture, in lexical form, the relationship between the entity identified in the 1XX and the resource itself. "Author," "editor," "director," and "artist" are examples of what may be found in $e. Technically, $e is a free-text field and not controlled in most applications, although the new RDA rules instruct catalogers to select from a controlled list of values (a process that will still subject $e to misspellings, typos, etc.). Although it is possible to analyze the data found in $e of today's MARC bibliographic records and bring the information under some form of control (perhaps by associating the terms in $e with relators codes), it will be impossible to manage this in every case because of variation, misspellings, typos, etc. A human may be able to interpret the meaning, but not necessarily a computer. It would be unconscionable to lose such a crucial piece of information. The BIBFRAME Authority's lightweight Abstraction Layer construct can help to mitigate this problem.

<!--  BIBFRAME Work -->
<Play id = "http://bibframe/work/Quatuor-pour-trois-violons-et-violoncelle">
     <title>Quatuor pour trois violons et violoncelle</title>
     <associatedAgent resource = "http://bibframe/auth/person/franklin" />
     <creator resource = ""  />

<!--  BIBFRAME Authority -->
<Person id = "http://bibframe/auth/person/franklin">
     <label>Franklin, Benjamin, 1706-1790</label>
     <resourceRole>supposed compeser.</resourceRole>
     <hasAuthority resource="" />
Example 8


Example 8 shows how it is possible to capture poorly entered $e data that is easily human understandable (and, in the future, fully correctable). Because the lightweight Abstraction Layer is itself a first-class resource, it provides a flexible model that readily accommodates the addition of properties. As seen in Example 7, a property associated with BIBFRAME Person Authority - resourceRole - could capture the information from $e.

In such cases when this is necessary (and it is expected that these will be a very, very small percentage of the whole), it will be necessary to generate a distinct BIBFRAME Authority resource for a given entity. Therefore, based on Example 7, there could be two BIBFRAME Authority resources representing Benjamin Franklin within one implementation - one BIBFRAME Authority without a "resourceRole" property, because Franklin's role with respect to the resource was determinable and captured as a relationship between Work and Authority, and another where a $e contained data that defied programmatic action but which should not be lost. This is not an ideal solution, but, with an eye to future cataloging, hopefully a temporary issue that can be fully addressed in updated cataloging interfaces.

It is by no means difficult to find an example of bad data. It is much harder, however, to quantify how widespread the issue may (or may not) be. The Abstraction Layer construct can assist with this issue.

An alternative to this solution, though heavier, is presented in section 3.2 above.

Classification, and other unknowns

Since the publication of the BIBFRAME Primer and after initial experimentation, there are aspects of bibliographic data that are not accounted for in the draft model but which will not only need to be represented but may also fall under the rubric of "Authority." Classification is one such case in point. In the current vocabulary draft, a class of resources was created called "Classification." It is designed to capture classification information found in current bibliographic records.

If library classification data were published as Linked Data (Dewey Decimal Classification is; parts of Library of Congress Classification are published with more to come), then it may be possible to employ the Direct approach with classification data, as one could with names and subjects. However, the very fact that classification was not initially accommodated in the draft model suggests it would be prudent to proceed with some caution, not knowing what else may require similar treatment but which has not yet been fully analyzed.

That said, because classification numbers may be constructed, it may not be possible to provide a URI for every conceivable classification. This would be an argument against the Direct approach and in favor of the lightweight abstraction layer. The lightweight abstraction layer provides a means to capture the classification, as constructed, without there being a pre-existing URI. It would be possible, of course, to link the BIBFRAME Classification resource to closely related and managed classification resource.

The name, "Authority"

Although the name "Authority" does not align perfectly with the traditional understanding of authority in libraries, it was chosen as a means to promote libraries and other cultural organizations as curators of authoritative information. It expresses, subtly or not so subtly, the opportunities libraries and other cultural organizations have in re-asserting credibility on the Web along with providing new means for connecting and contextualizing users to content. The word "Authority" (along with managing "authoritative" information on People, Places, Organizations, etc.) is more valuable and accurate in a larger Web of interconnected data. Nevertheless, because a BIBFRAME Authority is not conceptually identical to the notion of a traditional library authority, the name - Authority - may be confusing and distracting to traditional librarians and their developers. For example, A BIBFRAME Authority may not be controlled in quite the same way as authority records have been, such as the community has in the NACO program. The NACO file, for example, contains entries for names in agreed upon forms to ensure uniqueness within the bibliographic universe (except for undifferentiated names), which are then used in the description of resources. A BIBFRAME Authority can take information from a traditional library authority (such as the controlled label) but it does not have to, and yet the BIBFRAME Authority continue to serve as an authoritative resource within a particular implementation. It is important, therefore, that the word Authority be preceded by the word "BIBFRAME" as an adjective to best mark the distinction. Bearing in mind the definition of BIBFRAME Authority from the BIBFRAME Primer document, it is not meant to compete with the notion of a traditional library authority, but it is meant to empower libraries and other cultural institutions in the eyes of their patrons.

Should the name, however, pose an unavoidable obstruction to adoption and clear communication, then another way to approach this issue would be to ask, "What is it," where "it" is currently the thing called BIBFRAME Authority. "BIBFRAME Access Point" has been suggested as a possible name. It has the benefit of accurately capturing the notion, but potentially at the loss of inflection for libraries and other cultural organizations.

  1. Is the name a problem?
  2. Is there a better alternative?


The examples derived from the BIBFRAME Primer represent data constructs conforming to the proposed BIBFRAME Model. The issues stem from evaluating the proposed model while considering future or current practices (known or ideal) with respect to library data management.

In order to handle local indexing and other needs, the Direct approach would strongly suggest all implementing institutions require a local copy of the linked-to authority resource (the entire file may not be required, but a copy of each resource referenced in its catalog data). This is probably a manageable problem, but it should nevertheless be noted that not all BIBFRAME implementers will be the same. They will not all be large institutions capable of supporting their own authority infrastructures (such as LC and national libraries) and they will not all be large utilities (such as OCLC) that also have means to support their own authority infrastructures.

The single leading promise of the Direct option is true authority control, because, in so far as libraries use one single source, all records would point to a super node for authority data. And, because the Direct approach relies exclusively on a URI and probably an authority super node, the second most promising outcome is ease of maintenance of authority data since there would be no strings in the BIBFRAME resources to update.

To be clear, however, implementing the Direct approach at the risk of losing important information is simply not endorsed. The Direct option could also be short-sighted. There may be an instance when expansion is needed with respect to these types of entities and the Direct solution is discovered to be too restrictive, if not a hindrance to expansion. For example, the above issues and examples discuss only the most common situations - in the Anglo-American cataloging community, most libraries use LCSH and most use either LCC or DDC. The reality is far more varied, especially when considering the non-English, fully international landscape.

LC has maintained source lists for years of codes to be used in specific MARC fields. There is a list, for example, representing subject heading and term codes to identify the source of the heading or term: "lcsh" is for LC Subject Headings; "aat" is for Getty's Art and Architecture Thesaurus, "fmesh" is for the French version of MeSH, the Medical Subject Headings file maintained by the US National Library of Medicine. There are currently 294 codes, representing an equal number of subject heading or term lists, on the Subject Heading and Term Source Codes list. [ 3 ] There are presently 150 codes on the Classification Scheme Source Codes list. [ 4 ] Not all of the subject heading and term systems and classification systems will have been, or will ever be, published as Linked Data, making the Direct approach impossible for records employing many of the coded subject heading, term, or classification systems. Importantly, the number of codes indicates that the universe is much larger than just LCSH and a few other popular sources (MeSH, AGROVOC, etc.) for subjects and LCC and Dewey for classification. Most readily recognize this, but it would be folly to forge ahead without factoring in the very wide and encompassing MARC universe. The lightweight Abstraction Layer provides a means to manage this variety in a relatively simple manner, especially in the absence of published Linked Data for all authority data.

Nevertheless, the Direct method remains attractive, but there would be considerable hurdles. It would be possible to implement the Direct approach even given the pre-coordination challenge presented by LCSH, but that will require minting a URI for every existing subject string (and a commitment to create a URI for each new subject string). Likewise, not every name in current bibliographic records is represented in the NACO file. In both of these cases, a URI would have to be created for these entities (subjects and names).

The Direct solution also presents a control/domain problem with respect to authority data and a problem for RDA's idea of making persons, families, or corporate bodies points of access for users to locate information specific to the entity, such as relationships it may have to another person, family, or corporate body, not just cultural material. If for example, a regional consortium, or even an individual library, employs the Direct solution and it has its own catalog, but relies on VIAF for persons, then that consortium may not have a URI for persons in a domain it controls. This becomes a technical challenge for the library or consortium that would like to create a local point of easy access for a person or corporate body in its collection. The URI it has goes to VIAF. The Abstraction Layer - by definition local - would likely be referenced by local identifier (perhaps an HTTP URI that would resolve to a page within the organization's catalog domain featuring information about the entity, thereby making it a point of access for a user). Libraries may prefer greater independence and not be tied too directly to an authority provider, especially if that means a library's patron would be ported to another site for information about the entity. Also, the Abstraction Layer provides a means for a local library to aggregate URIs to other sources about the entity, not to mention create a local Annotation point.

Conversely, always requiring the Abstraction Layer may be cumbersome, especially when it is measurably simpler to use a property to associate a resource with a "traditional" library authority resource.

A combination of the Direct approach and the Abstraction Layer is attractive except such a solution could introduce a level of unpredictability that would require implementers to perform multiple and costly if/else evaluations for each resource. There are rules the community might implement to mitigate the if/else issue, but the combination approach feels like a compromise that might lead to developer and system frustration that could be simplified over the long term by a more consistent approach (e.g. "always use the Abstraction Layer") now, even if that approach seems more cumbersome at this time.

The Direct and the Abstraction Layer approaches also raise significant technological considerations. The Direct solution potentially introduces a single point of failure. If the authority node goes down, then it may be impossible to dereference the URI. That does not even begin to address issues such as network latency and the significant cost to support both reliability and latency on a scale needed by the library community. To mitigate those issues, an entire copy of the authority file could be stored locally, but that may be a burden (especially in the near term) to smaller organizations. (Local storage of at least the "authoritative" labels would be needed for search purposes anyways, regardless of institution size.) The Abstraction Layer alleviates the most prominent technological issues associated with the Direct method, but introduces a maintenance issue that would have to be addressed (how best to ensure that the authorized labels of BIBFRAME Authority resources reflect their "authoritative" relations). Heading/name maintenance could be a time-based synchronization/update process that happens daily, weekly, or monthly depending on need. As such, the Abstraction Layer approach does not necessarily remove the dependency on authority nodes, but it does remove them as a real-time dependency.

The future benefits of the Abstraction Layer and the low implementation cost, versus the high implementation costs of the Direct solution and loss of flexibility, strongly favor the Abstraction Layer option.

As for the name — BIBFRAME Authority — one might interpret it, generously, as referring to that which a BIBFRAME Authority is designed to associate/aggregate. That is, a BIBFRAME Authority is designed to associate a piece of bibliographic data with a resource representing a controlled access point. Alternatively, one might be able to view a BIBFRAME Authority - as indeed Zepheira did during development - as an entity that exists to facilitate the indexing or display of information. If the Abstraction Layer solution is used to capture transcribed labels and if the Abstraction Layer is used to import authorized access labels, then it might be worth exploring a name that more closely aligns with those functions (display, indexing). "IndexEntity" might be appropriate; it certainly alters the notion of what is currently a BIBFRAME Authority.

However, these are library-specific, practical considerations that focus on domain-specific nomenclature at the expense of promoting a broader mindset with the library and cultural heritage communities. The word "Authority" may strike librarians as broader than has been traditionally understood, but it can also assert that libraries as purveyors of authoritative information to outsiders while simultaneously underscoring the important role libraries have to play to those working within them.


  1. Continue to strengthen, refine, and, if necessary, expand the definition of BIBFRAME Authority to reflect advanced thinking about BIBFRAME Authority since the BIBFRAME Primer was originally published in November 2012 and as updated in this document from previous versions.
  2. Accept the lightweight Abstract Layer as mandatory.
  3. Investigate maintenance issues and needs to support the Abstraction Layer approach. Investigate the impact of the abstraction layer to existing systems.
  4. Leverage meaningful properties (i.e. defined relators properties) whenever possible.
  5. Explore URIs for all existing and future LCSH concepts.
  6. Continue to experiment with using BIBFRAME Authority resources also for traditionally non-controlled aspects, such as publishers.
  7. Pending community reaction, keep the name "Authority." Use "BIBFRAME" as an adjective before the word to create distinct meaning.


Minor formatting fixes; syntactical corrections to examples 1, 4, 5, and 6; added changelog section
Publication of major rewrite
  1. A single library may constitute a single "implementation" or a consortium of libraries may constitude a single "implementation."
  2. This particular email neatly sums up this proposal and points to a modeling precedent: