CMC BIBFRAME Task Force blog
Blog Home All Blogs
Search all posts for:   


View all (26) posts »

Open Discussion - Medium of Performance

Posted By Kimmy Szeto, Friday, August 28, 2015

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”



                totalNumberOfPerformers {non-negative integer}    

## also to hold 382 $s during conversion

                totalNumberOfEnsembles {non-negative integer}    

## also to hold 382 $t during conversion


                                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.)

## nested in this property are other mpCompnents

## Is this a good name for this property?

  * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~ * - ~  

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…

                mpComponent [

                ## Showing primary part clarinet, doubling on bass clarinet and sopranino clarinet

                                mpLabel “clarinet” ;

                                mpIdentifier <>  ;

                                mpNote “clarinet, doubling on bass clarinet and E-flat piccolo clarinet”


                                mpHasDoubling  [

                ## Showing bass clarinet as the doubling instrument

                                            mpLabel “bass clarinet” ;

                                            mpIdentifier <> ;

                                            mpNote “bass clarinet, doubling of the clarinet”

                                ] ;


                               mpHasDoubling   [

                ## Showing the D clarinet as the doubling instrument, and has an alternative E-flat clarinet ; the D piccolo clarinet has no LCMPT term

                                           mpLabel “piccolo clarinet in D” ;

                                           mpIdentifier “”;

                                           mpKey “D” ;

                                           mpNote “D clarinet, doubling of the clarinet”


                                           mpHasAlternative [

                ## Showing the E-flat clarinet is an alternative to the D clarinet

                                                              mpLabel “sopranino clarinet” ;

                                                              mpIdentifier <> ;

                                                              mpKey “E-flat” ;

                                                              mpNote “D clarinet can alternatively be played on an E-flat clarinet”








Tags:  BIBFRAME  BIBFRAME Task Force  medium of performance 

Share |
Permalink | Comments (6)

Comments on this post...

Damian S. Iseminger says...
Posted Monday, August 31, 2015
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?
Permalink to this Comment }

Damian S. Iseminger says...
Posted Monday, August 31, 2015
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.
Permalink to this Comment }

Damian S. Iseminger says...
Posted Monday, August 31, 2015
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.
Permalink to this Comment }

Damian S. Iseminger says...
Posted Monday, August 31, 2015
mpKey and mpRange: These values would come from MARC 382 $v, correct? I don't think we would want to take a term for range or key from the mpLabel, would we?
Permalink to this Comment }

Damian S. Iseminger says...
Posted Monday, August 31, 2015
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?
Permalink to this Comment }

Kimmy Szeto says...
Posted Thursday, September 03, 2015
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.
Permalink to this Comment }


Music Library Association 1600 Aspen Commons Suite 100 Middleton, WI 53562

608-831-8200 FAX
About MLA

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.