CMC BIBFRAME Task Force blog
Blog Home All Blogs

Open Discussion – Application Profiles for Music Resources

Posted By Kimmy Szeto, Friday, August 28, 2015

Early on, the Task Force recommended proposing two BIBFRAME application profiles (Report #5.1) , one for scores and one for sound recordings. We are now opening the discussion of application profiles.

In the same report, Anna and Catherine created a list of MARC fields that are commonly used by the music cataloging community. I would like to use the elements listed there as the basis of forming the BIBFRAME profiles. (I found a very useful list that “maps” the PCC RDA BIBCO standard record to BIBFRAME properties.)

We are mainly working on the “property template” as specified in the May 5, 2014 draft specification of BIBFRAME profiles. Our task here is to develop profiles for our community. At this time, we are not concerned about how these profiles will be serialized, or whether corresponding BIBFRAME properties exist. (In most cases, they do exist, but sometimes they have yet to be defined, such as the full implementation of medium of performance.)

After the discussion period, I envision our resulting “product” to look like the tables below (they are by no means nearly comprehensive at this point -- they are for illustration purposes only). 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!

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

 

Work – scores (DRAFT)

 

 

 

 

Property

Data Type

Value Constraint

Mandatory?

Repeatable?

(Our cataloging practice)

 

Title

Text

<none>

 

Authorized Access Point

Text

LCNAF?

 

Publication Date

Date

ISO 8601

 

Copyright Date

Date

ISO 8601

 

Composers(s)

Text

LCNAF?

 

Orchestrator(s)

Text

LCNAF?

 

Translators(s)

Text

LCNAF?

 

Subject(s)

Text

LCSH?

 

Genre/Form

Text

LCGFT?

 

Note(s)

Text

<none>

 

LC Call Number(s)

Text

LCCN

 

Dewey Call Number(s)

Text

DCC

 

Language

Text

MARC Code List for Languages 2007 Edition

 

Language / Notation Note

Text

<none>

 

Related Resource(s)

Text

URI

 

 

Medium of Performance

Text

LCMPT?

 

- Soloist(s)

Text

LCMPT?

 

- Doubling(s)

Text

LCMPT?

 

- Alternative(s)

Text

LCMPT?

 

 

Key

Text

<none>

 

Music numbers

Text

<none>

 

 

 

Instance – scores (DRAFT)

 

(Our cataloging practice)

 

Publisher

Text

<none>

 

Distributor

Text

<none>

 

ISBN

Number

13 digits ; ISO 2108

 

ISMN

Number

13 digits ; ISO 19057

 

Plate Number

Text

<none>

 

Publisher Number

Text

<none>

 

 

Format

Text

RDA 7.20.1.3

 

 

Dimensions

Text

 

Extent

Text

 

Other Physical Attributes

Text

 

System Details

Text

 

 

 

Event - sound recordings (DRAFT)

 

 

 

Data Type

Value Constraint

Mandatory?

Repeatable?

(Our cataloging practice)

 

Title

Text

<none>

 

Authorized Access Point

Text

LCNAF?

 

Publication Date

Date

ISO 8601

 

Copyright Date

Date

ISO 8601

 

Creator(s)

Text

LCNAF?

 

Conductor(s)

Text

LCNAF?

 

Performer(s)

Text

LCNAF?

 

Subject(s)

Text

LCSH?

 

Text

LCGFT?

 

Note(s)

Text

<none>

 

LC Call Number(s)

Text

LCCN

 

Dewey Call Number(s)

Text

DCC

 

Language

Text

MARC Code List for Languages 2007 Edition

 

Language Note

Text

<none>

 

Related Resource(s)

Text

URI

 

 

Medium of Performance

Text

LCMPT?

 

- Soloist(s)

Text

LCMPT?

 

- Doubling(s)

Text

LCMPT?

 

- Alternative(s)

Text

LCMPT?

 

 

[Other properties of recorded music]

 

 

 

 

Instance - sound recordings (DRAFT)

 

(Our cataloging practice)

 

Publisher(s)

Text

<none>

 

Distributor

Text

<none>

 

ISBN

Number

13 digits ; ISO 2108

 

ISMN

Number

13 digits ; ISO 19057

 

UPC Code

Text

<none>

 

Publisher Number

Text

<none>

 

 

[Other properties of recorded music]

 

 

Tags:  BIBFRAME Profiles 

PermalinkComments (0)
 

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”

 

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

## 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 <http://id.loc.gov/authorities/performanceMediums/mp2013015154>  ;

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

 

                                mpHasDoubling  [

                ## Showing bass clarinet as the doubling instrument

                                            mpLabel “bass clarinet” ;

                                            mpIdentifier <http://id.loc.gov/authorities/performanceMediums/mp2013015064> ;

                                            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 <http://id.loc.gov/authorities/performanceMediums/mp2014015002> ;

                                                              mpKey “E-flat” ;

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

                                                ]

                                ]

                ]

]

 

 

 

Tags:  BIBFRAME  BIBFRAME Task Force  medium of performance 

PermalinkComments (6)
 

6.2 BIBFRAME Agility

Posted By William R. Vanden Dries, Saturday, May 2, 2015
Updated: Saturday, May 2, 2015

Working group members: Kimmy Szeto, William R. Vanden Dries (group leader)


This group was tasked with discussing the difference between the conventional waterfall model of software development and the rapid application development as exemplified in MARC vs. BIBFRAME.

 

The terms “agile” and “waterfall” denote two very different approaches to software development. Waterfall development originated in hardware manufacturing, and preceded agile development. Waterfall development begins with a clear picture of the design requirements and advances in a linear way until the launchable product is assembled during the last phase. Waterfall development only advances from one phase to the next after the current phase is complete. Once a phase is complete, the project does not return to a previous phase, even if mistakes are found. When mistakes are identified, a choice must be made: either push forward despite the errors, or start over at the beginning. In time, many software developers adopted a more agile approach to avoid this inherent problem of waterfall development.


Agile development is characterized by shorter development phases, commonly referred to as “sprints,” and a modular design structure that includes multiple specialized groups working on different, but connected, aspects of development. At the end of each sprint a launchable, or nearly launchable, product is generated, allowing for testing and feedback at every phase. Feedback is gathered through testing and from the various development groups. This feedback influences further development, altering design requirements along the way to increase the product’s usability and to align the product more closely with clients’ needs.


MARC development incorporated aspects of both waterfall and agile development over its long development history. During the MARC pilot project, data was shipped to participating libraries across the country on physical tapes. Feedback was gathered during the pilot project by telephone and by mail. One particularly influential piece of feedback during MARC II development was the interest displayed by libraries outside of the United States. Their interest shifted the communication model of MARC from a one to many model (i.e. the LC Distribution Service) to one that also included sharing among organizations [Avram, 6-7]. A second significant change made at the end of the pilot project was an extension of the character set for roman alphabet languages [Avram, 7]. The initial MARC design did not foresee these two changes at the outset, but approached these opportunities from an agile development perspective. Successful redirection and design was implemented in these areas without a complete redesign of the MARC system.


While MARC development was, and continues to be, agile in some respects, it resembled a waterfall development style in others. Largely due to the time constraints on the initial MARC pilot project in 1966, the MARC I format was designed to create stable records for one format: books [Avram, 5]. Additional incremental changes were necessary if the MARC format was to become compatible with not only books, but all forms of material. Over a period of several years following the MARC pilot project, specialists in several fields including serials, maps, films, and manuscripts contributed to further development of the MARC format [Avram, 10]. Unfortunately, the music cataloging community was one of the later communities to provide specialist feedback to MARC. Many limitations identified and changes proposed by the music cataloging community were never implemented, due to the inertia built up by MARC prior to this specialist feedback. This resulted in significant inadequacies in the MARC format’s ability to accurately represent the bibliographic relationships essential to understanding musical works and their instances. The choice was made: push forward despite known bugs in the code.


[Some examples of where the waterfall development of MARC has really and seriously hindered our work would be helpful to include here. Please contribute suggestions if you have any!]


BIBFRAME is a significant opportunity to improve music resource discovery by addressing MARC’s inadequate handling of printed music and sound recordings. Decades of research into bibliographic relationships give BIBFRAME a starting point far ahead of where MARC was in 1965. However, the choice between an agile, waterfall, or combined approach must still be made, making it possible to repeat mistakes made during MARC development. Hindsight shows us that MARC development benefitted more from an agile approach than a waterfall approach.


Therefore, this task force makes this strong recommendation: Keep BIBFRAME development agile. Incorporate the voice of MLA and other specialist organizations. Revisit development early and often.


The BIBFRAME Implementation testbed is comparable to the MARC pilot project. Today, just as during the MARC pilot project, institutions participating in the BIBFRAME testbed are expected to submit feedback on their experience. Feedback received through the testbed will be just as valuable as the feedback gathered during the MARC pilot project. Furthermore, just as the cataloging community continued to identify necessary changes to MARC long after the pilot project officially ended, limitations of BIBFRAME will be identified long after the implementation testbed is closed. Don’t let bugs in BIBFRAME persist because of a waterfall approach if they can be fixed by keeping BIBFRAME agile.


References:

Avram, Henriette D. MARC, its history and implications. Washington: Library of Congress, 1975.

Tags:  agile  development  MARC  testbed  waterfall 

PermalinkComments (0)
 

4.1. Experiment and Analysis: Transformation of Music Genre/Forms

Posted By Hermine Vermeij, Friday, May 1, 2015
Updated: Friday, May 1, 2015

Working group members: Anne Adams, Tracey Snyder, Hermine Vermeij (group leader)


This working group was charged to examine the MARC-to-BIBFRAME transformation of music genre and form terms in bibliographic records. Despite what we considered to be rather simple MARC coding in the 655, we found that the current mapping is highly unsatisfactory. This report will outline our methodology, findings, and recommendations.


Methodology


We limited our scope to MARC fields that explicitly refer to genre and/or form. Therefore, we did not examine subject headings, despite the fact that MARC 650 fields contain a large amount of music genre and form information. We are aware of separate projects spearheaded by MLA’s Vocabularies Subcommittee and Genre/Form Task Force that have the goals of creating medium of performance and genre/form fields from legacy subject headings and other data; we did not wish to try to duplicate their efforts.


Fields we studied:

  • 655 (Index Term - Genre/Form) - The transformation of the 655 was our highest priority; this is the field in which most controlled genre/form terms will be recorded in bibliographic records, especially as use of LCGFT (Library of Congress Genre/Form Terms) increases.

  • 008 positions 18-19 (Form of composition--”Comp” in OCLC) - Coded information from a closed list.

  • 047 (Form of Musical Composition Code) - An expansion of the coded information in the 008, used when there are multiple forms present.

  • 380 (Form of Work) - Generally used in the Authority Format, but occasionally found in bibliographic records.


We selected a sample of 20 OCLC records, all of which contained one or more of the fields listed above. Both notated music and performed music were represented in the sample set, as were both art music and popular music. The genre/form terms in 655s were a mix of (1) LCGFT terms that have identical counterparts in LCSH, (2) LCGFT terms that do not have precedent in LCSH, and (3) LCGFT terms that are identical to a variant term in LCSH.


We focused mainly on LC’s MARC to BIBFRAME Transformation Service, but we also tested transformation of some records using Zepheira’s BIBFRAME transformation service to compare the two mappings. We recorded our findings in a spreadsheet, noting the OCLC number, the content type, which genre fields were present, the genre/form terms in any 655s, the tool used, observations, and the output URL.


Findings


Both tools attempted to map the 655 field to BIBFRAME vocabulary. LC’s tool mapped all terms in 655s to bf:Topic, which appears under “Subjects” in the tool’s user interface. This is not desirable, as the more appropriate term bf:genre is available.


Additionally, LC’s tool attempted to link the LCGFT terms to an authority record. Unfortunately, the linked authority records were incorrect in all cases. We found that the tool recognizes LCGFT as the bf:authoritySource (correct), but then links them via bf:hasAuthority to LCSH (incorrect). For example, the relevant portion of RDF XML for a record using the LCGFT term Chamber music looks like this:


 http://bibframe.org/vocab/" rdf:about="http://bibframe.org/resources/gJl1429653083/ocn902815324topic16">

   http://www.w3.org/2000/01/rdf-schema#" xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#" xmlns:relators="http://id.loc.gov/vocabulary/relators/">Chamber music

   http://www.w3.org/2000/01/rdf-schema#" xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#" xmlns:relators="http://id.loc.gov/vocabulary/relators/">Chamber music

   http://www.w3.org/2000/01/rdf-schema#" xmlns:madsrdf="http://www.loc.gov/mads/rdf/v1#" xmlns:relators="http://id.loc.gov/vocabulary/relators/">http://id.loc.gov/vocabulary/subjectSchemes/lcgft

  http://id.loc.gov/authorities/subjects/sh85022422"/>


The last link is to the LCSH heading Chamber music.


This result was repeated in all cases when LCGFT and LCSH strings were identical. In cases where a term from LCGFT is not also in LCSH (e.g. Parts (Music)), the tool does not link to an authority record. In the interesting case where a term from LCGFT also appears as a variant term for an LCSH term (e.g., the LCGFT term Art music, which is a variant term of Music in LCSH), the tool links to the authority record for the preferred LCSH term.


Zepheira’s tool uses different vocabulary from LC’s; the namespaces cited in their RDF results include several vocabularies from bibfra.me, which has been developed separately from LC’s BIBFRAME project. Thus, the two tools were difficult to compare.


Curiously, Zepheira’s tool mapped terms in 655s to Genre (vb:Genre, from http://bibfra.me/vocab/lite/) when we first began testing; at some point the mapping changed and it currently maps terms in 655s twice; once to Concept and once Form (both from the same vocabulary source, http://bibfra.me/vocab/lite/). We don’t know why the change was made.


Examples from the same record, run through the Zepheira tool at different times:


<8pkdCJnA> a vb:Genre ;
   rdfs:label "Live sound recordings." ;
   vb:name "Live sound recordings." ;
   ns2:source "lcgft" ;
   ns1:sf-2 "lcgft" ;
   ns1:sf-a "Live sound recordings."


---


a vb:Form ;
   rdfs:label "Live sound recordings." ;
   vb:focus <9h6-bCQt> ;
   vb:name "Live sound recordings." ;
   ns1:source "lcgft" ;
   ns2:sf-2 "lcgft" ;
   ns2:sf-a "Live sound recordings." .


<9h6-bCQt> a vb:Concept ;
   rdfs:label "Live sound recordings." ;
   vb:name "Live sound recordings." ;
   ns2:sf-2 "lcgft" ;
   ns2:sf-a "Live sound recordings." .


LC’s tool did not attempt to map the 008 positions 18-19, the 047 field, or the 380 field.


Zepheira’s tool does make an effort to map these fields, to varying degrees of success. The 008 18-19 map to ns2:formOfComposition (from http://bibfra.me/vocab/marc/), and the codes are expanded to full terms (e.g., formOfComposition "operas" for the 008 18-19 values “op”).


The 047 seems to map to a sort of placeholder; it appears as tag-047-XX-a (from http://bibfra.me/vocab/relation/), and the codes remain in their original form (e.g., ns3:tag-047-XX-a "fm", "rc").


The 380 maps similarly, to tag-380-XX-a, from yet another vocabulary source (http://bibfra.me/vocab/marcext/).


Recommendations


Mapping the 655 correctly should be a high priority for BIBFRAME implementation. A successful mapping would:


  • Map terms to bf:genre.

  • Include bf:authoritySource (LC’s tool already seems to do this correctly).

  • Link to the correct authority using bf:hasAuthority.


The other fields we examined are of lower importance, but we still recommend they be mapped in some way to avoid data loss.


We believe the 008 18-19, the 047 $a, and the 380 $a could all be mapped to bf:genre. Expanding the codes in the 008 18-19 and the 047 to more understandable terms, as Zepheira’s tool did with the 008 18-19, would be desirable.

Tags:  BIBFRAME  BIBFRAME Task Force  genre/form  MARC 

PermalinkComments (0)
 

4.3 Final Report of the Working Group on MARC-to-BIBFRAME Transformations of Work Access Points

Posted By James L. Soe Nyun, Thursday, April 30, 2015

Working group members: Kevin Kishimoto, Lisa McFall, James Soe Nyun (group leader). 

 

The BIBFRAME Task Force working group 4.3 was tasked to examine the MARC-to-BIBFRAME transformation of uniform titles. Current conversion tools from the Library of Congress and Zepheira focus on converting metadata in MARC bibliographic records, and the group likewise focused on transforming bibliographic records.


Our tests revealed many things that worked well in one or the other converter, along with many operations that either produced erroneous results or revealed features that are not yet fully developed. We took the results to help us formulate what we think an ideal conversion tool should do.


Minimal requirements


The conversion tool needs to output a string that duplicates the original access point string in content, punctuation and order, minus the MARC subfield codes.  Map the complete output string as the object value of bf:authorizedAccessPoint.


When the source creator/title string is split between the 1xx and 240 field, the complete string for creator from the 1xx field and the complete string for title from the 240 must be reassembled into an access point string. Supply appropriate punctuation between creator and title elements. This string should then be the value for the bf:authorizedAccessPoint property.


When the access point comes from any place other than the bibliographic main entry, create a separate bf:Work statement for it. Supply the complete authority string in bf:authorizedAccessPoint. Within the main resource bf:Work statement, supply the appropriate BF property (e.g., bf:hasPart, bf:relatedResource, bf:subject) to associate the main work to the separate work.


Harvest the creator portion of creator/title strings and generate a statement for it, identified as a bf:Person, bf:Organization or bf:Event. All values for subfields associated with the creator should be harvested, retaining order and punctuation, to construct a creator string, which is mapped to the bf:authorizedAccessPoint within the statement for person, organization or event.


Reference the preceding creator within the bf:Work statement where the complete access point string resides. Use the property, bf:creator.


When the original content supplies an identifier for the access point, the identifier should remain associated with it. If possible, use an algorithm to map to bf:identifier if the identifier appears to be machine-actionable, to bf:identifierValue if not.


When the input contains 880 fields with parallel graphic representations of a single work the converter needs to associate the different forms of the access point string.


Use the presence of second indicator 2 in MARC 700, 710, 711 and 730 to map a work into bf:hasPart.

Desired functionality


Harvest external identifiers when available for each authorized access point. If an access point already has an identifier, add the new harvested identifier unless it duplicates the existing one. Supply the property bf:identifier.


Extract bf:label by duplicating bf:authorizedAccessPoint string.


When item has a 240 extract bf:Title using the original MARC elements to decide on which elements should map into the title. (Current tools are lossy.)


Map all MARC subfields that correspond directly to properties in BF: Map $r to bf:musicKey; $o to bf:musicVersion, $m to bf:musicMediumNote, $p to bf:partTitle, $l to bf:languageNote (and if possible through algorithmic matching, to a URI in bf:language). Values from the 240 should map into the bf:Work entity of the main resource; others should map into the bf:Work locations for the related or contained works.


MARC tag 383 allows for a fine breakdown of different types of music numbers associated with a resource. These types have no specific mapping within BF than to the less granular bf:musicNumber. We would like a way to be more specific, probably by linking to external, more specific vocabulary within the bf:musicNumber property. Many Bibliographic records will lack the 383 field, and it would be good to harvest values from the $n of an access point string (or imported from external Work authority records). This subfield unfortunately serves many purposes in access points for musical works, acting to define a music number, a date of creation, or the number of a part of a work. Still, if a converter can be sensitive to the punctuation of the original string, we feel that the $n could map reliably to bf:musicNumber, bf:partNumber, or bf:originDate, based on its relation to adjacent punctuation:

  • $n following a comma : map to bf:musicNumber

  • $n includes an opening parenthesis, followed by a date, followed by a closing parenthesis : map date to bf:originDate

  • $n following a period : map to bf:partNumber

In many cases it would be possible to extract more granular information from the string in bf:musicNumber based on content and how it is formulated, and it is worth further discussing how more specific properties like opus number or serial number might be detected and extracted. As with our recommendation for the 383, it would probably make most sense to link out to an external vocabulary with these more granular terms to define the type of the property.


Associate 1xx with 245 $a if no 240 is present in MARC record. Create bf:authorizedAccessPoint.


Retain or transform relationship designators when present in the source to supply work-to-work relationships. bf:hasPart can be extracted from the MARC second indicator 2, but there could be more granular information in the $i that should be preserved, probably as a link to external vocabulary within bf:hasPart. Other relationships could be recorded within the bf:relatedResource property, where the only current subproperties are precedes and succeeds, or in the bf:derivativeOf or bf:derivedFrom properties, or in the several other predefined BF properties. This could probably be accomplished by mapping certain designators to corresponding BF properties. For other, undefined relationships, prefer referring out to external vocabulary such as RDA relators rather than devising new BF terms, perhaps also harvesting external URIs for these concepts.

Future needs, possibilities


Transformation tools for authority records…


A way to round-trip metadata back into MARC, or convert natively-created BIBFRAME metadata into a usable MARC bib record… (Interestingly, the Zepheira tool brings over some information in the original MARC field- and subfield-structure. This is not so useful from a BF standpoint, but it would assure a safer return trip back to MARC.)


Algorithms could be used to mine deeper into data elements within the AAP string and form more definite relationships. A tool could possibly extract the identifiers for instruments named within bf:musicMediumNote, and then record that information in bf:musicMedium. Since some AAPs strings are based on musical forms, an algorithm could supply a fairly reliable form or genre form; there would would be false drops, so discussions would need to take place as to whether this would a desired direction to go.


Explore ways to make use of values in work AAP subfields $3 and $5.



Appendix 1: Bugs with the LC and Zepheira Converters


LC Converter:

  • The $n in 700, 710, 711 fields is appended to agent’s name access point, in addition to being in the title of the work.

  • No content from the 440 field is converted.

  • No content from the 630 field is converted.

  • The $g element extracted from the 710 AAP maps incorrectly into the bf:treatySignator statement for the main 245 Work.

  • Elements extracted from the 730 AAP map incorrectly into the statement for the main 245 Work; this includes subfields $m (into bf:mediumNote), $n (into bf:partNumber), $d (into bf:legalDate)

  • Not all identifiers ($0, $x) in work access point strings are converted. Nothing is done with $0 identifiers in 700, 710, 711, 730, 800, 810, 811 or 830; those in 240, 400, 600, 610 and  611 are converted. The $x ISSNs in 400, 410, 411, 800, 810, 811 were mapped; those in 430 and 830 were not.

  • Conversion of 130 had several problems: First, it leaves off $o; other subfields were not tested, but may have similar issues. It also creates a bf:label and bf:authorizedAccessPoint that are comprised of the first 700 author prepended before the $a of the 130; $o from the 130 is left off for sure, and other subfields may be impacted.

  • The $r from the 240 is mapped appropriately into the bf:musicKey of the main work; however it is left out of the bf:authorizedAccessPoint, bf:label and associated bf:Title statements.

  • Although the converter appears to correctly harvest associated identifiers for names and topics, it isn’t finding identifiers for works when identifiers are known to exist.

  • Language $l converts into bf:authorizedAccessPoint only from fields 600, 610 and 611. It is stripped from the bf:authorizedAccessPoint of the 240, 400, 410, 411, 440, 700, 710, 711, 730, 800, 810, 811 and 830.

  • When the converter encounters a parallel graphic representation of an access point it pulls a language code from the MARC 008/35-37 into xml:lang. This is an unreliable way to try to find what language the alternate representation is in, with catalogers supplying “zxx” (no linguistic content) for instrumental musical works. Also the language bytes are supplied by the cataloger to apply to the main resource and the language may not be appropriate for a component. The language of cataloging in the 040 also would not be a dependable source. We don’t see a reliable way to populate the attribute for language fo title.

  • In 600, 610 and 611 fields, subfields $f, $3 and $4 are incorrectly carried over into the bf:authorizedAccessPoint and the madsrdf:authoritativeLabel properties.

  • When a single MARC bib record contains multiple 7xx fields representing multiple Works by the same Creator, duplicate bf:Agent entities are created, even though the bf:authorizedAccessPoint for these Agents match exactly.


Zepheira Converter:

We didn’t test this tool as exhaustively as LC’s, but below are some of the things we noticed.


  • Extracts bf:musicKey, bf:musicMedium (incorrectly, see below), bf:language and bf:arrangedMusic. However, largely fails to map MARC into BF, with much of the original MARC subfielding carrying over into the BF output. The largest failing is that no equivalent to an authorized access point is generated that could be used for either display or matching to external identifiers.

  • The $m maps to bf:musicMedium, which expects an identifier, rather than bf:musicMediumNote, which can accommodate the strings found in $m.

  • The converter makes no attempt to match the names and works against an external name authority and extract identifiers.

  • When names are extracted from a name/title AAP, most subfields appropriate to the title portion are also placed in the name string.

  • When multiple $n occur in a single heading, the converter is inconsistent in the order which they are output as part of the rdfs:label, sometimes switching the order; this behavior seems to be unpredictable. The multiple $n do seem to be predictably retained as separate data elements in ns2:titleNumber, but not always in the order of the original heading.

Appendix 2: Working Document with Conversion Results and Comments


Forthcoming: A link to our working spreadsheet with the digested results.


Tags:  Authorized Access Points  BIBFRAME  BIBFRAME Task Force  Data Migration 

PermalinkComments (1)
 

6.1 Submitting MARC Updates

Posted By Lisa McFall, Monday, April 27, 2015

Traditionally, MARC proposals from the Music Library Association community were submitted through the MARC Formats Subcommittee, a subgroup of the Bibliographic Control Committee of MLA. These proposals were vetted by the subcommittee members and a formal discussion paper was proposed to the Machine-Readable Bibliographic Information Committee (MARBI) Committee (a group sponsored by the Association for Library Collections & Technical Services (ALCTS)) and the MARC Advisory Committee (MAC). This discussion paper included explaining the problem with the rules as they were and a proposed solution. Once the agenda for the ALA Annual or ALA Midwinter meeting for MARBI was set, the National Development and MARC Standards Office (NDMSO) released the discussion papers and proposals on MAC-L and MARC-L. Suggestions for improvements and comments were frequently offered from national libraries and other individuals to the group who submitted the paper. Further discussion and voting happened during the MARBI meeting at ALA. Once MARBI convened at ALA Midwinter or ALA Annual, the discussion papers were formally presented to get input from the MAC members. Usually at the next meeting a proposal is submitted, although occasionally a proposal is moved forward immediately if the solution seems clear due to following a set precedent. Once approved through a formal vote, these updates were incorporated with a set date of implementation. One item to note is that while MAC was involved in offering suggestions for the proposals, only MARBI representatives had voting privileges, not MAC representatives.(1)  

 

Recent changes have occurred that have modified this structure. Most notably, MARBI was dissolved in 2013, with the ALCTS/LITA Metadata Standards Committee officially replacing it(2). MAC, however, became the official voting body for proposed changes to the MARC formats.(3) The MARC Formats Subcommittee of MLA has also now been combined with the Metadata Subcommittee into the Encoding Standards Subcommittee under the restructured and renamed Cataloging and Metadata Subcommittee. It is anticipated that a sub-group of the Encoding Standards Subcommittee will work together to write proposals for change of MARC formats to continue the work that the MARC Formats Subcommittee completed in support of the music cataloging community.

 

---

(1) Content from this section based on "Demystifying MARBI ...: Making MARC Format Changes (MLA-style) by Kathy Glennan, 1999 March 19 (http://bcc.musiclibraryassoc.org/MARC/MARBI-demyst2.html) and conversations and emails with Sandy Rodriguez, 2015 March 11 and 2015 April 24.

 

(2) Machine-Readable Bibliographic Information Committee. http://www.ala.org/alcts/mgrps/cmtes/jnt-marbi Accessed: 2015 April 24.

 

(3) MARC Advisory Committee. http://www.loc.gov/marc/mac/advisory.html Accessed: 2015 April 24.

Tags:  MARC 

PermalinkComments (0)
 

4.2 Medium of performance

Posted By Kirk-Evan Billet, Friday, April 24, 2015
Updated: Thursday, May 14, 2015

Working group members: Anna Alfeld, Sophie Rondeau, Kirk-Evan Billet (group leader)

 

This section examines the current state of MARC-to-Bibframe transformation for medium of performance data.


Testing procedure

Individual members of the working group assembled test files of between 1 and 16 MARC bibliographic records, converted them to MARC-XML, and ran them through the Library of Congress transformation service available at http://bibframe.org/tools/transform/start. Several records were passed through the new MarcNext utility, showing quite similar results. Some of the test files were also passed through Zepheira’s transformation tool.


Individual test files were limited to notated music, performed music as audio, or performed music as video. Compilation records were included for both performed music and notated music, and an effort was made to address various aspects of medium of performance such as partial statements and alternative mediums. In total, 111 records were processed.


Bibframe vocabulary

In the current published Bibframe vocabulary, two properties are designated for medium of performance data: musicMedium and musicMediumNote. Both have exactly the same description: “Instrumental, vocal, and/or other medium of performance for which a musical resource was originally conceived, written or performed.” The expected value is URI for the former and string for the latter. The example given for musicMediumNote carries a string (“voices (4)”) from MARC 130 ‡m in a record for an expression for 4 recorders (http://id.loc.gov/resources/bibs/5582683.marcxml.xml). This example is consistent with the vocabulary’s placement of music medium properties in its “Title information” category; however, such placement does not reflect usage patterns for medium of performance statements (as a facet of the resource) as opposed to medium terms used as part of an access point. (No example is given for musicMedium.)


Overview of MARC-to-Bibframe mapping


MARC

MARC Subfield Codes

Bibframe

048

‡a ‡b

not retained

382

‡a Medium of performance

bf:musicMediumNote


‡b Soloist

not retained


‡d Doubling instrument

bf:musicMediumNote


‡p Alternative medium of performance

bf:musicMediumNote


‡n Number of performers of the same medium

not retained


‡s Total number of performers

not retained


‡v Note

not retained

240

‡m

bf:musicMediumNote

700

‡m

carried as part of bf:authorizedAccessPoint

650

‡a

medium information not separately treated

500

‡a

bf:note


Testing results

Analysis of RDF output from testing carefully considers statements of medium of performance as distinct from medium terms added as part of an access point. However, as can be seen in the above mapping, transformation tools do not necessarily make this distinction. This analysis also acknowledges a related project, currently underway, with the goal of programmatic conversion of strings in MARC field 650 and codes in 048 into LCMPT terms in 382. Ideally, though not necessarily, such conversion would take place prior to MARC-to-Bibframe transformation. Thus, data from MARC 382 are the main focus of this analysis.


Current transformations are generally unsatisfactory on three levels: 1) data loss, 2) failure to delimit terms, and 3) failure to distinguish medium terms as part of an authorized access point (AAP) from actual statements of medium of performance.


Data loss

  1. Soloist mediums coded in 382 ‡b are simply ignored under transformation.

  2. Semantics of subfield adjacency in 382 are lost under transformation.

  3. Doubled (382 ‡d) and alternative (382 ‡p) mediums are carried under transformation, but they are treated the same as principal mediums (382 ‡a); thus they simply appear in addition to the corresponding principal mediums. The semantic loss of the doubling or alternative relationship to the principal medium is unsatisfactory in itself; further, it results in a distortion of overall medium of performance statement.

  4. Number (382 ‡n) for each medium and total number (382 ‡s) are both ignored under transformation.

  5. Note-type data recorded in 382 ‡v are ignored under transformation.


Failure to delimit terms

While it is necessary to express medium of performance as a single statement incorporating all constituent mediums, the merging of all medium terms into a single Bibframe element without delimiting individual terms in any way perpetuates yet another string situation. It is not clear how the resulting element is intended to be used or linked. This problem is especially pronounced when a medium of performance statement includes one or more compound terms, for example:

bass voice bass clarinet double bass


Conflict between medium mapped from medium of performance statement (382) and medium term(s) mapped from portion of AAP (240 ‡m)

This conflict is most evident in arrangements that include medium of performance in the AAP. In such cases, transformation yields two bf:musicMediumNote elements—one for the original (from 240 ‡m) and one for the expression (from 382)—with no way to tell which is which.


example (ocn881522545):

240 10 Berceuses, ‡m violin, piano, ‡n op. 16, ‡r D major; ‡o arranged

382 01 clarinet ‡n 1 ‡a piano ‡n 1 ‡s 2 ‡2 lcmpt

 

violin, piano

clarinet piano


For a concerto with orchestral part arranged for piano, if coded correctly (382 for expression with soloist in ‡b), the resulting Bibframe data will have two bf:musicMediumNote elements: one for the original work and one for piano alone (because 382 ‡b is ignored). In this case, both resulting medium elements will be inaccurate.


example (ocn903519991):

240 10 Concertos, ‡m clarinet, orchestra, ‡n no. 2, op. 5, ‡r F minor; ‡o arranged

382 01 ‡b clarinet ‡n 1 ‡a piano ‡n 1 ‡s 2 ‡2 lcmpt


clarinet, orchestra

piano


This kind of conflict also results in things like the combination of 1) “instrumental ensemble” from AAP, and 2) actual instruments from the medium of performance statement (minus those in 382 subfields that are ignored).


example:

240 10 Concertos, ‡m harpsichord, instrumental ensemble

382 01 ‡b harpsichord ‡n 1 ‡a flute ‡n 1 ‡a oboe ‡n 1 ‡a clarinet ‡n 1 ‡a violin ‡n 1 ‡a cello ‡n 1 ‡s 6 ‡2 lcmpt

harpsichord, instrumental ensemble

flute oboe clarinet violin cello


In all of the above cases, internal comma(s) within subfield ‡m are retained.


Zepheira transformation

While this analysis considers the Library of Congress transformation tool as its baseline, several differences in Zepheira output should be noted. Data loss from MARC 382 is not as severe with Zepheira: solo mediums are retained and so designated, alternative mediums retain their semantic distinction, and numbers and notes (‡v) are also retained. However, doubling mediums are ignored. Zepheira output delimits medium terms (with quotation marks), thus keeping together compounds like “bass clarinet.” Zepheira has extended the Bibframe vocabulary to accommodate several aspects of medium of performance, for example by adding the properties alternativeMedium, featuredMedium, and numberOfPerformers. Medium codes from MARC 048 are actually carried—though not mapped to any Bibframe property—potentially enabling a post-transformation conversion to LCMPT. A particularly unsatisfactory side to Zepheira transformation is the practice of grouping 382 data from multiple 382 fields together by subfield rather than keeping the elements of each 382 together.


Recommendations

  1. Ideally, conversion of strings in MARC 650 and codes in 048 into LCMPT terms in 382 should occur prior to MARC-to-Bibframe transformation.

  2. Transformation rules should be adjusted so that data elements and semantics currently lost under transformation are carried.

  3. If medium terms are to be carried into a single Bibframe element, individual terms should be delimited in some way so that matching terms to their corresponding URIs will be possible. It may also be worthwhile to explore the possibility of incorporating such an enrichment process into transformation.

  4. Some way of preserving the meaning conveyed by subfield adjacency within MARC 382 should be sought. For example, an alternative medium immediately following a solo medium should be recognizable as an alternative solo medium.

  5. MARC-to-Bibframe transformation should distinguish between statements of medium of performance and medium terms as part of access points. This recommendation does not discount the possibility of other use of medium terms from access points.

  6. If “round-trip” transformation back to MARC becomes a desired option, it will be necessary to extend the Bibframe vocabulary, since current transformations map both statements of medium of performance and medium terms given as part of an access point to the same Bibframe property (bf:musicMediumNote).

  7. MARC-to-Bibframe transformation also needs to distinguish between a complete medium of performance for the musical work/expression (382 01) and a partial medium of performance statement (382 11).

  8. The issue of sequence associated with medium of performance must also be considered during transformation. Linking specific medium of performance statements with their respective works is essential to achieving the full potential of these vocabularies. It must be acknowledged, however, that these links are not present in current MARC data. For a detailed discussion on the issue of sequence, see Report 3.3 Sequence.

Tags:  BIBFRAME  Data Migration  MARC  medium of performance 

PermalinkComments (0)
 

4.X MARC transformation testing - preliminary questions

Posted By Kimmy Szeto, Thursday, March 12, 2015

I hope we have all recovered from MLA! We met in person (thanks Beth for the photo!) and discussed a few things:

  • Our next report target will be April 24.
  • We want to make our BIBFRAME model analysis uniform --
    • For the three areas of BIBFRAME conversion analysis (genre/form, medium of performance, uniform title), we will first need to agree on our methods / ways to proceed:
      • Which converter(s) will we test?
      • The list of MARC fields we want to focus on. (Can/should include fixed fields and 0XX?)
      • Shall we use a consistent reporting format? (Like...spreadsheet with the same columns?)
    • The questions we are trying to answer:
      • Does the transformation make sense? How do BIBFRAME elements reflect the original MARC data? Are we losing any information? Will new MARC proposals play well with BIBFRAME?
      • Are there situations / exceptions in MARC that we should fix in MARC before the transform?
      • What works well? What does not make sense? How do we want it to work better for us? Make the recommendation in this report.
      • Taking all the 4.X reports together, which aspects can we keep, and which aspects do we want to take full control of? Be bold and be visionary here. 
      • Kevin's idea: What about BIBFRAME to MARC?
Everyone please pitch in in the next few days. Leaders (Hermine, Kirk-Evan, Jim) - we will be in touch next week to finalize the report format.

Tags:  BIBFRAME Task Force 

PermalinkComments (0)
 

4.2. Medium of performance testing: preliminary report

Posted By Kirk-Evan Billet, Wednesday, February 25, 2015

(Kirk-Evan Billet, Anna Alfeld, Sophie Rondeau)

This section will focus on evaluating the current state of MARC-to-Bibframe transformation for medium of performance data. Primarily, the working group will assess the Library of Congress Bibframe transformation tool, but we may turn also to MarcEdit and Zepheira conversion utilities.

 

In the current MARC environment, medium of performance data occurs as coded statements, as part of access points, and in notes. Recognizing that there is a project underway to develop a programmatic method for generating LCMPT terms from MARC 6XX (as well as from MARC 048) for use in MARC 382, we will not address medium as expressed in LCSH; at the same time, it must be acknowledged that, for some older or briefer records, MARC 650 may contain the only medium information in the record. Medium in notes is considered a trivial case, since it is expected that these will be simply retained as Bibframe notes. Therefore, our main task will be evaluating current transformation of coded medium of performance data in light of functional requirements identified in earlier task force and BCC work. Though we will be testing MARC-to-Bibframe transformation, we hope to keep in mind an ideal for newly-created data in Bibframe.

 

Certain challenges are already apparent. MARC 048 codes will require mapping to LCMPT, either prior to or as a step in transformation. MARC 382 subfielding relies on adjacency for meaning, and the field may include some note-type information. Other questions concern the need for medium of performance at the work and expression levels and to what extent the Bibframe vocabulary may need to be revised in order to fully embrace medium of performance data.

 

Each member of the working group will compile test files of MARC records and convert them to MARC-XML as necessary. We will look first at score records and then at audio-visual records. After individual members have run tests, we will compile results, evaluate, characterize the current state of transformation, and formulate recommendations.

 

Tags:  BIBFRAME  Data Migration  MA  medium of performance 

PermalinkComments (1)
 

Report 3.1 -- Event in BibFrame

Posted By Kevin S. Kishimoto, Friday, January 30, 2015

by K. Kishimoto, T. Snyder, and K. Szeto 

 

In the BIBFRAME vocabulary as it currently stands, the term “event” is used in a number of distinct ways. In the Instance class, it is used in the context of the provider property, which has subproperties production event (bf:production), publication event (bf:publication), distribution event (bf:distribution), and manufacture event (bf: manufacture). Completely apart from this use of the term “event” in the labels for these familiar properties in the Instance class, there exists an “Event Entity” (bf:Event, a class of resource all its own, just like a Work or an Authority) as well as an “Event associated with content” property (bf:event). The event property [lowercase e] is in the domain of Work, whose range, or expected value, would be a bf:Event [capital E]. The Event Entity (bf:Event) also has its own properties--eventAgent, eventDate, and eventPlace--that identify the agents, dates, and places associated with an established Event. Together, these elements of the vocabulary (bf:Work, bf:event, and bf:Event) would relate a Work to the Event. Presumably, the Work and Event could be related in a number of ways, although it is unclear if the event property would allow the assignment of a more specific relationship than “associated with.” The written description of bf:event is somewhat vague: “Information about the geographic area/or time period covered by an event (e.g., a report).


In addition to these formal uses of the term “event,” there are a number of BIBFRAME concepts which are event-like. The creation of an intellectual work is an event-like concept, as well as the creation or modification of metadata describing the Work or its Instance. The Agent type bf:Meeting is another event-like concept. [See Appendix A (below) for a list of events and event-like concepts found in the current BIBFRAME vocabulary.] Other types of event-like concept commonly used by catalogers, such as birth or death of a person, are not covered in the BIBFRAME vocabulary at this time.




The BIBFRAME AV Modeling Study, completed in May 2014, articulates the complexities of audiovisual resources that pose difficulties for modeling. In particular, in its analysis of existing content models the likes of FRBR/RDA, indecs, and others, the report asserts that although entities such as agent, subject, and place are interpreted similarly across the models, the Event concept stands out as being interpreted in significantly different ways. For example, events in FRBR/RDA are generally related to the subject matter of a work, whereas in indecs, they can take the form of “creating” events, “using” events, or “transforming” events. Although indecs is found to be an event-centric model (in contrast to the work-centric model in FRBR/RDA), and therefore “more aligned with the needs of the largely event-based creation of audiovisual content,” the report makes the point that most of the models examined are not able “to describe an event as the content itself” in cases when the content is “not a work in the mind of a creator.” The report emphasizes that an ideal content model would allow both work-centric and event-centric approaches for description. Such a content model would accommodate standard works of Western art music for which a single composer displays intent and is assigned sole agency as well as the huge body of musical content that does not easily fit this mold.


The report contains lists of examples of moving image content and recorded sound content that serve to demonstrate the great variety in the artistic and intellectual content represented by audiovisual resources. The lists make immediately apparent the time-based nature of audiovisual content, and the ensuing discussion of this aspect of audiovisual content reminds readers that a series of smaller events, initiated by a number of different people in different roles, must occur from performance to recording to production/publication, etc. in order for these resources to exist. The examples, which encompass both musical and nonmusical content, range from obviously intentional creative works like feature films and studio albums to documentation of live performances, historical events, interviews, ethnographic material, and natural phenomena. Of course, in today’s web-enabled creative environment, there can also be an almost infinite proliferation of mashups, remixes, etc., as well as variant versions thereof.


The BIBFRAME AV Modeling Study, and specifically its analysis of the concept of Event, has attracted deserved attention in the cataloging and metadata community, in particular on the BIBFRAME-L email list. In August 2014, Phil Schreur voiced his support for elevating the concept of Event in BIBFRAME, especially as the cataloging world moves more and more toward cataloging complex media resources. In September 2014, Kelley McGrath stated:


I am not completely convinced that there is no work in a collection of recordings of birdsongs or congressional hearings. From one point of view, a FRBR work is an intellectual or artistic creation that is bound up with intention and that can be contrasted with a straight act of recording. On the other hand, I think the idea of intellectual or artistic creation could be interpreted broadly enough to include essentially all human artifacts. Even with a plain recording, someone set up the camera at a certain angle and chose a start and stop point.


In December 2014, several participants on the BIBFRAME-L list contributed to a thread about events in BIBFRAME. (See the December 2014 BIBFRAME-L archive.) The initial inquiry, from Cornell’s Steven Folsom, had its roots in the idea of using the BIBFRAME vocabulary to relate the hip hop flyers from the Cornell Hip Hop Collection to the parties and other events that they advertise. Among the responders was LC’s Nate Trail:


Steven, we have been looking at bf:Event a little , as a result of the AV paper. They suggested that Events could be thought of as Works, and I think we're moving in that direction, ie., subclassing Work for an event, which gives you the ability to describe it much more thoroughly than just date, time, place.  There is some confusion with overlapping concepts like the provision event, where something is published or manufactured or whatever, where you really don't want or need to go much beyond date/time/place.
You could then have bf:Event be the range of bf:subject.


This is encouraging in the long run. However, changes to the BIBFRAME vocabulary will not occur until later in 2015, possibly in conjunction with LC’s upcoming BIBFRAME pilot. (See the recent joint publication of LC and OCLC on linked data models.)




MARC encoding allows a few ways in which one can record event data. A common method for including event data in bibliographic records for music resources is through the use of the MARC 518 field in which the cataloger can create a “Date/Time and Place of Event Note.” The 518 note most commonly records the date and place of recording or broadcast. In 2010, new subfields were defined for this field allowing one to create more granular data, but the 518 is still a note field containing literal text. A more precise method to record event data is through the use of the MARC bib 033 field, but this coding is somewhat complex (requiring one to cross reference LC Class G). For creation of work events, the MARC bib 045 or the MARC authority 046 fields are used. The MARC encoding which is closest to the A/V Modeling Study’s concept of event as content is probably the MARC 111 (or 110) field which names a meeting or conference. Unfortunately, this type of “corporate body” has not often been used to describe musical performances (except in rare cases, like some music festivals). [See Appendix B (below) for a chart listing content (work / event) description practices for typical music resources.] Named events can also be established as subject headings, but this use case would not apply to most music resources.




The authors of this report believe that there are some specific music resources whose discoverability would benefit greatly from an event-centric description in BIBFRAME. In fact, due to their time-based nature, most (if not all) types of music media could use better and more detailed event data, a combination work+event descriptive practice being ideal.


Audio and video recordings of live performances in which multiple works are performed is the most obvious case for an event-centric description. Concerts and recitals often lack formal titles, especially those recorded and collected locally by an institution, and thus the creation of a proper work-centric access point is difficult and, if possible, often meaningless. Recordings of masterclasses and field recordings of musical events are two other types of music resources which would be better described as events rather than works.


  • concert / recital (principal performer) = performer + date/time + place

  • concert / recital (multiple performers) = date/time + place + [event type?]

  • masterclass = teacher + date/time + place

  • field recording = performer(s) + recordist + date/time + place


The ability to describe content using a combination of work and event data would enhance the description and discoverability of numerous types of music resources:


  • jazz (single tune) = song + composer + performer + date/time + place

  • oft-recorded classical piece = work + composer + performer + date

  • traditional / folk music song = song + performer + date/time + place

  • studio-recorded cast album for musical = work + composer + librettist + date of stage production + place of stage production + [event type?]

  • selected music from television / radio show = name of show (work) + date/time of original broadcast + song (work) + performer

  • television / radio show featuring music = name of show (work) + date/time of original broadcast

  • [bonus] variant versions of classical work (such as Gluck’s Orfeo) = work + composer + date of first performance of version + place of first performance of version


Perhaps the addition of a Type of Event property would enhance event-related description for music resources. In conclusion, the BIBFRAME model holds real potential for robust description of a wide array of inherently time-based audiovisual content, but much work still needs to be done to fully develop this mechanism.






Appendix A: Events and event-like concepts in current BIBFRAME vocabulary


Resource type

  • Event entity (bf:Event [capitalized])


Properties used with Work

  • Creation of work event (bf:originDate, bf:originPlace)

  • Creation of metadata event (bf:creationDate)

  • Modification of metadata event (bf:changeDate)

  • Dissertation event, i.e. degree conferral date [?] (bf:dissertationYear)

  • bf:event [lowercase] (bf:eventAgent, bf:eventDate, bf:eventPlace)

  • Conversion of data from another format event (bf:generationDate)

  • Legal event (bf:legalDate)

  • bf:temporalCoverageNote [?]


Properties used with Instance

  • Modification of metadata event (bf:changeDate)

  • Creation of metadata event (bf:creationDate)

  • Custodial history (bf:custodialHistory)

  • Conversion of data from another format event (bf:generationDate)

  • Legal event (bf:legalDate)

  • Provider event (bf:provider, bf:providerDate, bf:providerPlace, bf:providerRole)

    • bf:distribution

    • bf:manufacture

    • bf:production

    • bf:publication


Authority types

  • bf:Place + bf:Temporal

  • bf:Meeting (type of Agent)


Properties used with Annotation

  • bf:assertionDate (including review, summary)






Appendix B: Content description for typical library music resources (Work / Event)

[click link to see chart]

Tags:  AV Modeling Study  BIBFRAME and vocabularies  events 

PermalinkComments (1)
 
Page 1 of 3
1  |  2  |  3
Contact

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

608-836-5825
608-831-8200 FAX

mla@areditions.com
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.