After several months of gathering input and internal deliberation, we are now opening the discussion of medium of performance in this public forum. Our draft proposal is below, after the introductory text.

As always, please share your thoughts here or directly to me via email. The comment period is between now and September 20. We appreciate your input!

Let’s forget for a moment that MARC, AACR2, RDA, 382 or LCMPT exist, and we ask ourselves, what do we want medium of performance data do for us? How do we specify the way we want to describe medium of performance for musical materials?

Our task here is to develop a neutral specification for medium of performance that can be expressed in RDF and can be used in BIBFRAME or for BIBFRAME. At this time, we are not concerned about how the specification will be serialized, even though from time to time we will use codes or pseudo-codes for illustration purposes. We are also not considering how this might be displayed through user interfaces, public or backend, while keeping in mind that encoding and data manipulation will primarily be performed by machines, i.e. there will be minimal hand coding and calculations such as counting, looking up parent/child nodes, etc. After doing all this, then we look back to ensure all the current MARC 382 data can be carried over without loss during automated process. (We have earlier recommended converting strings in MARC 6XX and codes in MARC 048 into LCMPT terms in 382 prior to MARC-to-BIBFRAME transformation).

We have a good idea of what we want thanks to the experience from recent developments of MARC 382. We are proposing in this draft a few additional pieces of information about key (for transposing instruments) and range (voice range, tessitura, etc. for individual mediums), and the instrumentation/voices within groups (such as ensembles, choruses, percussion, electronics and visuals).

More specific to what this Task Force is charged to do, we want to raise several questions:

(1) Aggregates: How to handle aggregates? Entities that are aggregates ultimately link to the individual works. Through these links to the individual works, we can reach the medium of performance information for each work. The machine can then gather the information from each work and “do the aggregating” – putting it together for display or other outputs. (In theory, this can be done now with MARC recordings by tracing 7XX analytics to the 382 in the authority records, but I’m not sure if any application makes use of this method.) On the other hand, there are many situations where it makes sense to record medium of performance for the aggregate entity, as exemplified in many existing MARC records. Regardless, we will have a property to hold this information in order to meet our minimum requirement to hold legacy data for MARC-to-BIBFRAME transformation purposes. The question is how do we encourage a practice that takes full advantage of the linked data environment. This leads to the next question.

(2) Neutral structure vs. cataloging practice: While we are developing a neutral specification, the music library community will continue to maintain standards, vocabularies, and best practices. Where in the scope of our charge does this fall? Do we propose these BIBFRAME specifications *together* with a practice recommendation, or, to a lesser degree, provide instructions or examples of how we transplant our current practice to the BIBFRAME structure we now propose? Or let our expert colleagues (Content Standards Subcommittee, for example) pick up from where we leave off?

(3) Other topics specific to each property are posed in the notes (after ##) below

Notes about this proposed BIBFRAME set of properties for medium of performance

- This is a schematic. It is not written in any kind of encoding.

- Let’s say for a flute duet (2 flutes), the machine doesn’t distinguish between if you say in one single assertion: “flute (2)” or in two separate assertions: “flute” “flute”

mediumOfPerformanceWrapper

totalNumberOfPerformers {non-negative integer}

## also to hold 382 $s during conversion

totalNumberOfEnsembles {non-negative integer}

## also to hold 382 $t during conversion

mpComponent

mpLabel {literal}

## legacy – to hold 382 $a or $b during conversion

mpIdentifier {URI}

## also supply URI based on the value of 382 $a or $b during conversion

numberOfPerformingForces {non-negative integer}

## Please help come up with a more elegant term!

## The number associated with the medium. This number can possibly be used for the number of individual performers of the same medium, the number of ensembles of the same kind. – also to hold 382 $n $e during conversion ; also to hold the number of parts for mediums like “piano,” “xylophone,” “electronics” and “percussion” such as the number of hand-parts, the number of drums in a set of timpani, the number of devices, etc

## This property is the counting of the number of the same entity – so there is probably no need to split it up, that is, to type it like: numberOfPerformersOfSameMedium, numberOfEnsemblesOfSameKind, numberOfElectronicsSetUps, numberOfScreensForVisuals, etc., because you can only use them one at a time: if you use one, all others MUST be empty.

mpType {“individual”, “ensemble”}

## legacy – value is set during conversion according to whether MARC 382 $e or $n was applied to $a or $b

mpIsSoloist {“Yes”, “No”}

## also value is set during conversion according to whether MARC 382 $a or $b was used

mpKey {literal}

## the transposition of the instrument, etc.

mpRange {literal}

## the range of the medium, e.g. high/medium/low for voice, “c-c4” for xylophone, “E-c” for timpani, etc.

mpNote {literal}

## also to hold 382 $v during conversion

mpSourceOfTerm {literal}

## legacy – to hold 382 $2 during conversion

mpSourceOfTermIdentifier {URI}

## legacy – supply URI based on the value of 382 $2

mpHasDoubling {literal}

## legacy – to hold 382 $d during conversion

mpHasDoublingIdentifier {URI}

## URI of a medium of performance ; look up URI from MARC 382 $d during conversion

mpHasAlternative {literal}

## legacy – to hold 382 $p during conversion

mpHasAlternativeIdentifier {URI}

## URI of a medium of performance ; look up URI from MARC 382 $p during conversion

HasEnsemblePart {literal}

## To specify instrumentation of a group (ensemble/chorus/percussion/electronics/visuals/etc.)

Medium of performance example – [from recent chamber arrangement of Mahler’s Das Lied von der Erde by Michel Galante] the clarinet part (doubling on bass clarinet AND piccolo clarinet). The piccolo clarinet part was originally written in D but can be played on a more common E-flat instrument. This is basically MARC 382 $a clarinet $d bass clarinet $d piccolo clarinet in D $p sopranino clarinet $n 1 .

## In schematic

mediumOfPerformanceWrapper [

## This is demonstrating one of the many mpComponent within the wrapper…

Comments on this post...

For mediumOfPerformanceWrapper and mpComponent, are you planning on treating these as URI nodes or as blank nodes? It looks like in the schematic that these would be blank nodes, but has that been settled or are you still discussing it?

Aggregates: From looking at some MARC to BIBFRAME transformations for aggregates, I think the simplest course of action would be to consider all of the individual 382 statements to be medium of performance statements that are linked to the aggregate work. Perhaps I'm being pessimistic, but I doubt there is a way to reliably link a MOP statement to the individual work within an aggregate work, just by using the bib record.

Neutral structure vs. Cataloging Practice: I think it would be appropriate for this Task Force to show how applying this schema in a BIBFRAME environment would differ from the MARC serialization. However I don't think we want to get into situations where BIBFRAME (or some other serialization) is the tail wagging the dog on best practices for providing access to medium of performance. Our responsibility as librarians is to figure out what our users need and then to make that happen, whether that be in MAR, Dublin Core, or BIBFRAME.

I feel like there is a mismatch between the schematic and the example following it when it comes to doubling and alternative instruments. In the schematic you have a property for mpHasDoubling and mpHasDoublingIdentifier and the same idea is true of Alternative instrumentation. However in the example, it appears that you are using mpHasDoubling and mpHasAlternative as wrappers to hold the subproperties already defined under mpComponent. Since you are defining mpHasDoubling and mpHas Alternative in the schematic to have a literal value, it appears that the example you have provided would not be valid. Or is the schematic wrong?

Thanks for pointing that out! The schematic should say: mpHasDoubling {another mpComponent} and mpHasAlternative {another mpComponent}. And, doing this will render mpHasDoublingIdentifier and mpHasAlternativeIdentifier moot. Thanks for the correction!

As for key and range, these are meant to be the property of that specific part (e.g. "D" for a clarinet or “c-c4” for a marimba) -- I don't think these are currently coded anywhere in MARC. We want to include the possibility of recording these two pieces of information in the future.

Serialization/Blank nodes - We'll cross that bridge when we get there -- Right now, we are focusing on specifying our requirements, like you said, what our users need. For the longer term, we are working with LC on a possible BIBFRAME serialization -- and yes, there will be examples / use cases, and they will look quite different, with possibilities to express a few things that we currently cannot do in the MARC environment.

The Music Library Association is the
professional association for music
libraries and librarianship in the United
States. Founded in 1931, it has an
international membership of librarians,
musicians, scholars, educators, and
members of the book and music trades.
Complementing the Association’s national
and international activities are eleven
regional chapters that carry out its
programs on the local level.