3 Functional Requirements for Bibliographic Records (FRBR)

MEI header information may refer to different levels of description of the encoded work: Some information may apply the work in all its various forms and realizations, e.g., the name of its composer. Other information may describe a certain version of the work, or a source such as the printed first edition, or only a single copy of that source. Core MEI limits the header information to two such levels of description: work and source, respectively.

However, when the FRBR module is available more detailed descriptions are possible. With certain limitations, mainly due to the musical nature of the works encoded in MEI, the FRBR module adapts the Functional Requirements for Bibliographic Records (FRBR) as recommended by the International Federation of Library Associations and Institutions (IFLA) [ http://www.ifla.org/publications/functional-requirements-for-bibliographic-records].

The IFLA’s FRBR model distinguishes four levels of abstraction, or entities:

Work
FRBR defines a work as a "distinct intellectual or artistic creation", an abstract entity because there is no single material object one can point to as the work.
Expression
An expression is defined as "the intellectual or artistic realization of a work in the form of [...] notation, sound, image, object, movement, etc., or any combination of such forms". Expressions are also abstract entities.
Manifestation
A manifestation is defined as "the physical embodiment of an expression of a work", including, for instance, manuscripts, books, sound recordings, films, video recordings, CD-ROMs, multimedia kits, etc. The manifestation represents all the physical objects that bear the same characteristics, with respect to both intellectual content and physical form.
Item
A single exemplar of a manifestation is called an item, e.g., a specific copy of a printed score. With manuscripts, item and manifestation levels are nearly identical. A manuscript may be regarded as a manifestation having only one item.

3.1 FRBR Entities in MEI

When the FRBR module is available, MEI offers four elements corresponding to the FRBR entities:

  • workProvides a detailed description of a work, specifically its history, language use, and high-level musical attributes: key, tempo, meter, medium of performance, and intended duration.
  • expressionIntellectual or artistic realization of a work.
  • sourceA bibliographic description of a source used in the creation of the electronic file.
  • itemSingle instance or exemplar of a source/manifestation.

The names of the MEI entities generally follow those of FRBR: the work element is a container for description at the FRBR "work" level, expression is for description at the FRBR "expression" level, and item holds FRBR "item" level description. The source element, however, is the MEI equivalent to FRBR "manifestation" level description. The name "source" is used because it is both shorter and more familiar than "manifestation" to users of existing bibliographic markup schemes.

The work element has an optional child element to hold the expression elements:

  • expressionListGathers bibliographic expression entities.

As expressionList is a container element for descriptions of different expressions of the same work, it may contain only expression elements.

The content model of expression is similar to that of work. It does not, however, permit expressionList and audience elements. But it adds elements that aid identification and description of specific versions of a work:

  • extentUsed to express size in terms other than physical dimensions, such as number of pages, number of records in file, number of bytes, performance duration for music, audio recordings and visual projections, etc.
  • scoreFormatDescribes the type of score used to represent a musical composition (e.g., short score, full score, condensed score, close score, etc.).

Since expressions, like works, are abstractions, their titles are often nebulous. Usually, however, the title of an expression is the same as the work it represents. When the relationship between a work and an expression is encoded hierarchically, the expression’s title element may be omitted with the assumption that it will be inherited from the work. If no title is provided for an expression, distinguishing characteristics must be provided in other elements, such as perfMedium, as in the following example:

<work>
<titleStmt>
<title>Pavane pour une infante défunte </title>
</titleStmt>
<expressionList>
<expression>
<perfMedium>
<perfResList>
<perfRes>piano </perfRes>
</perfResList>
</perfMedium>
</expression>
<expression>
<perfMedium>
<perfResList>
<perfRes>orchestra </perfRes>
</perfResList>
</perfMedium>
</expression>
</expressionList>
</work>

Programmatic concatenation of the work title and one or more characteristics of the expression can be used to provide identification for the expression. For example, the expressions above may be identified by "Pavane pour une infante défunte (piano)" and "Pavane pour une infante défunte (orchestra)". In some cases, it may be helpful to assign a descriptive title to the expression, as illustrated below. The carrier of the manifestation is often a good source of this kind of descriptive text.

<work>
<titleStmt>
<title>Pavane pour une infante défunte </title>
</titleStmt>
<expressionList>
<expression>
<titleStmt>
<title>Version for piano </title>
</titleStmt>
<perfMedium>
<perfResList>
<perfRes>piano </perfRes>
</perfResList>
</perfMedium>
</expression>
<expression>
<titleStmt>
<title>Version for orchestra </title>
</titleStmt>
<perfMedium>
<perfResList>
<perfRes>orchestra </perfRes>
</perfResList>
</perfMedium>
</expression>
</expressionList>
</work>
<work>
<titleStmt>
<title>Sonata No. 2 </title>
</titleStmt>
<expressionList>
<expression>
<titleStmt>
<title>Live recording at Carnegie Hall </title>
</titleStmt>
</expression>
<expression>
<titleStmt>
<title>Studio recording </title>
</titleStmt>
</expression>
</expressionList>
</work>

The itemList element provides functionality similar to that of expressionList; that is, it can be used to group descriptions of individual items (exemplars) of the parent source. Just like expressionList, which can only hold expression sub-components, itemList may only contain item elements.

  • itemListGathers bibliographic item entities.
  • itemSingle instance or exemplar of a source/manifestation.

<source>
<titleStmt>
<title>Trois trios pour le piano-forte violon, et violoncelle </title>
</titleStmt>
<itemList>
<item label= "Copy at Stanford">
<physLoc>
<repository>
<corpName>Stanford University Library </corpName>
</repository>
</physLoc>
</item>
<item label= "Copy at Dresden">
<physLoc>
<repository>
<corpName>Dresden, Sächsische Landesbibliothek - Staats- und Universitätsbibliothek </corpName>
</repository>
</physLoc>
</item>
</itemList>
</source>

3.2 Component Parts in FRBR

Each of the four MEI elements corresponding to FRBR entities may contain a list of constituent parts. All four entities utilize the same element:

  • componentGrp(component group) – Container for components of a bibliographic entity.

However, the child elements of a component group must be the same type as the group's parent. This allows for a more detailed description than is possible using the core MEI contents element. For example, a work element’s componentGrp element can only contain work elements, etc. In this way, the componentGrp element may be employed to describe composite works, as in the example below:

<work>
<titleStmt>
<title>Der Ring des Nibelungen </title>
</titleStmt>
<componentGrp>
<work>
<titleStmt>
<title>Das Rheingold </title>
</titleStmt>
</work>
<work>
<titleStmt>
<title>Die Walküre </title>
</titleStmt>
</work>
<work>
<titleStmt>
<title>Siegfried </title>
</titleStmt>
</work>
<work>
<titleStmt>
<title>Götterdämmerung </title>
</titleStmt>
</work>
</componentGrp>
</work>

This technique can also be applied when a single intellectual source is comprised of multiple physical parts. In the following example, the choral parts were published in four physically separate "signatures":

<source xml:id= "source.printed_choral_parts">
<titleStmt>
<title>Printed choral parts </title>
</titleStmt>
<pubStmt>
<publisher>Horneman & Erslev </publisher>
<pubPlace>Copenhagen </pubPlace>
<date isodate= "1871"> 1871 </date>
</pubStmt>
<componentGrp>
<source>
<titleStmt>
<title>Soprani </title>
</titleStmt>
<physDesc>
<extent unit= "pages"> 4 </extent>
</physDesc>
</source>
<source>
<titleStmt>
<title>Alti </title>
</titleStmt>
<physDesc>
<extent unit= "pages"> 4 </extent>
</physDesc>
</source>
<source>
<titleStmt>
<title>Tenori </title>
</titleStmt>
<physDesc>
<extent unit= "pages"> 6 </extent>
</physDesc>
</source>
<source>
<titleStmt>
<title>Bassi </title>
</titleStmt>
<physDesc>
<extent unit= "pages"> 6 </extent>
</physDesc>
</source>
</componentGrp>
</source>

3.3 FRBR Relationships

FRBR defines a number of terms that describe how the basic entities relate to each other. MEI provides the following elements for this purpose.

  • relationListGathers bibliographic relation elements.
  • relationA relation element describes the relationship between its parent and the object referenced by the relation element's target attribute.
  • rel Describes the relationship between the current entity and the target entity.

Each of the four FRBR entity equivalents – the work, expression, source, and item elements – allows a list of such relationship descriptions as its last child element. relationList provides a container for individual relation elements. The nature of the relationship must be specified by the rel attribute and the target of the relationship must be identified by the target attribute. The values allowed by rel follow those defined for FRBR at http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf.

Since relations are bidirectional, they may be defined on both entities involved, using pairs of oppositely-directed relation descriptors. The following FRBR relations are allowed in MEI as values of the relation element’s rel attribute (shown in pairs for clarity):

  • hasAbridgement / isAbridgementOf
  • hasAdaptation / isAdaptationOf
  • hasAlternate / isAlternateOf
  • hasArrangement / isArrangementOf
  • hasComplement / isComplementOf
  • hasEmbodiment / isEmbodimentOf
  • hasExemplar / isExemplarOf
  • hasImitation / isImitationOf
  • hasPart / isPartOf
  • hasRealization / isRealizationOf
  • hasReconfiguration / isReconfigurationOf
  • hasReproduction / isReproductionOf
  • hasRevision / isRevisionOf
  • hasSuccessor / isSuccessorOf
  • hasSummarization / isSummarizationOf
  • hasSupplement / isSupplementOf
  • hasTransformation / isTransformationOf
  • hasTranslation / isTranslationOf

Some of these relationships are already implicitly expressed by the MEI structural model: FRBR defines an expression entity as a realization of a work, but as this relation is implied by the expressionList element’s child relationship to its parent work element, the hasRealization/isRealizationOf relation does not need to be explicitly declared. Likewise, it is not necessary to specify by means of relation elements that an item is an exemplar of the source described by its parent source element. This resembles the FRBR model, which allows 1:n relationships both between works and expressions, and between manifestations and items.

However, as FRBR allows n:n relations between expressions and manifestations (in MEI: sources), a hierarchical model based on the strucutre of XML is clearly insufficient to express all possible expression / manifestation combinations. It is therefore required to declare these relations explicitly. In FRBR terms, a manifestation / source is an embodiment of an expression.

<source>
<titleStmt>
<title>Score, first edition </title>
</titleStmt>
<relationList>
<relation rel= "isEmbodimentOf" target= "#version_for_orchestra"/>
</relationList>
</source>

Within the componentGrp element, the order of child elements implicitly describes a hasSuccessor/isSuccessorOf relationship between components, i.e. it defines a certain sequence such as the movements of a work. In other cases, relation elements may be needed to explicitly encode relationships not otherwise defined by encoding order or hierarchy. For instance, the hasReproduction/isReproductionOf relationship may be used to indicate that one source is a reprint of another.

<source>
<pubStmt>
<publisher>Horneman & Erslev </publisher>
<pubPlace>Copenhagen </pubPlace>
<date isodate= "1874"> 1874 </date>
</pubStmt>
<relationList>
<relation rel= "isReproductionOf" target= "#source.printed_choral_parts"/>
</relationList>
</source>

Moreover, the use of componentGrp implicitly defines a hasPart/isPartOf relationship between the componentGrp element’s parent and its child elements. Using the relationList and relation elements to define their relationship, the four component works in the "Der Ring des Nibelungen" example above could alternatively be encoded as sibling work elements to the "Ring" work element.

<workDesc>
<work xml:id= "theRing">
<titleStmt>
<title>Der Ring des Nibelungen </title>
</titleStmt>
<relationList>
<relation rel= "hasPart" target= "#rheingold"/>
<relation rel= "hasPart" target= "#walkuere"/>
<relation rel= "hasPart" target= "#siegfried"/>
<relation rel= "hasPart" target= "#goetterdaemmerung"/>
</relationList>
</work>
<work xml:id= "rheingold">
<titleStmt>
<title>Das Rheingold </title>
</titleStmt>
<relationList>
<relation rel= "isPartOf" target= "#theRing"/>
</relationList>
</work>
<work xml:id= "walkuere">
<titleStmt>
<title>Die Walküre </title>
</titleStmt>
<relationList>
<relation rel= "isPartOf" target= "#theRing"/>
</relationList>
</work>
<work xml:id= "siegfried">
<titleStmt>
<title>Siegfried </title>
</titleStmt>
<relationList>
<relation rel= "isPartOf" target= "#theRing"/>
</relationList>
</work>
<work xml:id= "goetterdaemmerung">
<titleStmt>
<title>Götterdämmerung </title>
</titleStmt>
<relationList>
<relation rel= "isPartOf" target= "#theRing"/>
</relationList>
</work>
</workDesc>

Relations may also be used to point to external resources. For instance, each of the individual component works of the "Ring" could be encoded in separate files, with relations pointing to them.

In the file "ring.xml":

<workDesc>
<work>
<titleStmt>
<title>Der Ring des Nibelungen </title>
</titleStmt>
<relationList>
<relation rel= "hasPart" target= "rheingold.xml"/>
<relation rel= "hasPart" target= "walkuere.xml"/>
<relation rel= "hasPart" target= "siegfried.xml"/>
<relation rel= "hasPart" target= "goetterdaemmerung.xml"/>
</relationList>
</work>
</workDesc>

In the file "rheingold.xml":

<workDesc>
<work>
<titleStmt>
<title>Das Rheingold </title>
</titleStmt>
<relationList>
<relation rel= "isPartOf" target= "ring.xml"/>
</relationList>
</work>
</workDesc>