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!

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

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”

                                                ]

                                ]

                ]

]

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.

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.

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.

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)  

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

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.

• 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?

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.

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)

Our focus in this initial exploration of BIBFRAME profiles has really been more of a reflection on what a MARC profile for music would look like.  We did this in order to answer an important question: is a single BIBFRAME profile for music adequate?   Are there enough differences in the way we treat notated music and audio recordings to warrant more than one profile?  By working with an existing set of elements, instructions and best practices within the music cataloging community we are better able to see very clearly where those differences lie.  At the same time, we will be able to reuse the data and build upon it as we build our BIBFRAME vocabulary and BIBFRAME profile.

We created a listing of all MARC fields and subfields currently used for cataloging notated music and/or audio recordings.  Next we identified whether each of the elements is used (1) exclusively for notated music, (2) exclusively for audio recordings, (3) used for notated music and audio recordings but no other formats, or (4) used for notated music and/or audio recordings as well as other formats.  Additionally, we recorded the relevant RDA instruction, FRBR entity and any other related MARC fields.  This listing is available for viewing and comments. Finally, we reviewed the MARC documentation, RDA instructions, LC-PCC PSs and the MLA Best Practices for Music Cataloging Using RDA and MARC21 to track music-specific requirements or recommendations of usage for each of the MARC fixed fields/subfields.

Our findings were not surprising but do help to evaluate the need for a single versus multiple profiles. We identified 385 MARC fixed fields and subfields (referred to as elements from this point forward) used by music catalogers for notated music and audio recordings.  This number is not exhaustive, for example, we did not count $2 Source for each field that it would pertain to, nor did we include MARC elements that may be appropriate for notated music or audio recordings but that are used very rarely or are discouraged for use by the music cataloging community of practice.  We did, however, include some fields that are no longer used with RDA but that, due to a high level of usage with notated music or audio recordings in AACR2, we felt would be necessary to incorporate, such as the 254 Musical Presentation Statement.  Of the 385 elements, only four are used exclusively for notated music compared to 22 used exclusively for audio recordings.  Twenty-four are used for notated music and audio recordings but no other formats.  Additionally, mini-profiles for music (notated and music audio recordings) exist for 006 and 008 which together incorporate 17 codes.  At least 318 elements are used for notated music and/or audio recordings, as well as other formats.  At least 50, and likely more, elements that are not limited to use for notated music or audio recordings are used for only a limited number of other formats and/or are specifically recommended for use when cataloging notated music and/or audio recordings by the PCC or MLA.

It was also noted that some MARC fields are used for multiple purposes with music materials in particular; for example, in records for works with non-distinctive titles, the 245 $a incorporates other identifying elements such as medium of performance and key; while the 245 $b is used not only for subtitles and parallel titles but also for other identifying elements for music with distinctive titles such as type of composition, medium of performance and key. Some fields, such as 240 and 246, are used across disciplines and forms but not to the extent that they are used with music resources.

The analysis made it quite clear that separate profiles for notated music and audio recordings would be preferable and would provide a more streamlined workflow within the BIBFRAME editor.

3.3.0 Sequence: introduction

The concept of sequence as manifested in bibliographic data for music resources may be divided into two areas: 1) sequence of resource components, as when the order of individual content units is important enough to be represented in data, and 2) sequence of data elements, as when ordering or adjacency bears directly on the meaning of the data. A related concern, which, for music resources, may prove the most extensive, is the correct association of a specific element of description with the corresponding individual content unit (and only that unit).

For the sequence concept, as with other music-specific data concerns in BIBFRAME, there may be a divergence of focus regarding the conversion of existing MARC data on one hand as opposed to the creation of new data on the other. In the first case, preserving and clarifying may take precedence, while in the second case, the opportunity to look at what music cataloging could do better, not only in supporting identified user tasks but in facilitating unforeseen uses of library data, may come to the fore.

BIBFRAME AV Modeling Study, in Appendix C, outlines some of the challenges associated with complex, multi-part audiovisual materials. On audio recordings, multi-part works are often presented in a sequence of tracks or content subunits. Currently, if a user is searching for subunits, he/she may only find items where the subunits have been recorded, and may not retrieve results that include the entire work. Although this may seem to be a problem of identification, it results in missed hits when sequence of subunits within a larger content unit is not recorded. Problems also arise in situations where the user has limited information about the resource. For example, a user is looking for the infamous slow movement from Mozart’s clarinet concerto. She knows it is the second movement, but does not know the title or any other musical characteristic. There is currently no controlled method of cataloging the organizational structure of multi-movement/multi-part works, making it difficult for users to find and identify the desired musical resource when searching by structural attributes. Specific elements of description, such as medium of performance, recording dates, and durations also need to be correctly associated with individual content units, and this is something current practices don’t accommodate.

3.3.1 Music resources and sequence

Categories of resources affected by the issue of sequence include:

1. Commercial or non-commercial audio recordings consisting of multiple individual tracks/content units related to one another by a sequence (e.g., a sound recording featuring all of Beethoven’s symphonies arranged in chronological order, or a sound recording of Bach compositions arranged by BWV number).

2. Commercial or non-commercial audio recordings containing a compilation of tracks/content units (e.g., a sound recording featuring a Beethoven concerto and Schubert symphony on the same instance).

3. Commercial or non-commercial audiovisual resources containing individual chapters or content units related to each other through a sequence (e.g., chapters from a feature film DVD).

4. Commercial or non-commercial audiovisual resources containing individual chapters or tracks related to each other through a compilation of units (e.g., shorts on a compilation reel).

5. Print resources containing multiple content units related to one another by a sequence (e.g., score of a Schubert song cycle).

6. Print resources containing multiple content units (e.g., score of Italian songs by various composers, or score containing the complete chamber works of a composer).

7. Multi-volume print resources related to one another by a sequence (e.g., Opera omnia / Joannes Mouton; volume 43 of complete works).

3.3.2 Use cases for sequence

• A professor is looking for a radio tape talk series recorded on ¼” reel that was broadcast in four parts, once a week over four consecutive weeks. The professor wants each segment of the series to be digitized for ease of access. As well, the recording dates are especially important since she is examining the development of the musicologist who produced the series. Unfortunately, the third part is missing. The professor plans to compile the musicologist’s broadcasts in a book with accompanying audio materials consisting of excerpts from various series. She needs as much information as possible about all four parts, including their correct sequence.

• The music librarian received a DVD of Der Rosenkavalier requested by a faculty member responsible for organizing a concert performance of specific arias from the opera for her students. She would like the students to be able to watch particular scenes to garner a sense of the dramatic context. To save her students from having to forward through the entire video, she has requested the chapter sequence of the DVD be recorded. The librarian wants to be able to provide a more granular level of description as requested by her patrons.

• An undergraduate student is looking for a recording of Régine Crespin performing songs by Gabriel Fauré. She searches with the keywords Regine Crespin Faure and retrieves a single item entitled “The voice of France.” Crespin is on the recording, but is performing “Les nuits d’été” by Berlioz, with Sylvia McNair performing songs by Fauré. Frustrated with the catalog, the student searches YouTube instead. She had to read through a lot of content notes, and wishes the library catalog provided more precise search results.

3.3.3 Current sequence practices in MARC

Current MARC handling of sequence and sequence-related data elements falls into several categories. Sequence of content units within a resource is reflected in contents notes showing the order of performed works or tracks in audio or video resources; this ordering might include associated durations, responsibility statements, etc. Print resources such as scores may also be described in terms of the order of component units. In another category, elements of description that apply to specific content units are given without any indication of this association. Examples include coded event data, such as recording dates and places in MARC 033, medium of performance information in MARC 048 and/or 382, and durations of components coded in MARC 306. In yet another category, the association of description with content may be made, but only as part of a text string (for example, “3rd, 10th works sung in Latin; remainder sung in French”) and thus unavailable for machine processing. Examples of this type include the following elements (when applying variously to individual content units and not to the entire resource): genre/form (when recorded as a note), performers, recording session information, sung language, production credits, reissue information, edition recorded, matrix numbers, medium of performance (when recorded as a note), and issue numbers pertaining to parts.

Finally, there are cases of contextual rather than precisely defined data elements—that is, cases in which sequence or adjacency of data points has semantic or associative significance. For example, an enhanced contents note relies on adjacency of subfields for correct association of data points with content units. In the case of medium of performance, MARC 382 coding requires specific ordering of subfields in order for the correct meaning to result.

3.3.4 Functional requirements

Where sequence is concerned, the BIBFRAME functionality most crucial for users of music library data falls into two categories. For content made up of constituent units which are understood on some level in terms of the order in which they occur, this sequence must be represented. For multiple content units (within an aggregating resource) each having differing attributes known to be important for user tasks, descriptive assertions must be explicitly related to the corresponding content unit. These assertions often concern performer(s), medium of performance, or genre/form, but they may also pertain to recording date or place, edition recorded, matrix numbers, or duration. Precise association of data with content is also necessary to realize the full potential of new vocabularies for medium of performance and genre/form.

Resource description interfaces must provide functionality for the representation of these sequences and relationships. Similarly, display and retrieval applications must have access to the necessary sequence and relationship information, and it should be possible to provide the user with some control of views of this information. For MARC-to-BIBFRAME conversion of existing music library data, certain MARC cases of subfield sequence or adjacency must be accounted for in any conversion process.

3.3.5 Missing parts in sequence structures

When modeling and serializing works and instances, BIBFRAME must be capable of dealing with situations in which parts of an instance are known to exist elsewhere or have existed in the past, but are missing from the resource in hand. One such case is illustrated in use case no. 1 above. Another such case might involve a music library’s acquisition of a selection of issues from a small music journal. The journal issues acquired by the library do not represent the entire run of the journal, as there are known gaps identified by the issue numbers printed on the cover and spine of the journal. How would BIBFRAME be used to model the entire run of the music journal, including the missing issues?

BIBFRAME has no recommended method of dealing with the issue of missing parts. This problem is especially troublesome for works, events, and instances that are part of a whole and that have a particular sequence. Depending on what type of vocabulary is used to describe the sequencing, the sequence might not be correctly documented or displayed if one or more of the parts are poorly described. For instance, if the parts of a whole are simply described as “next in sequence” within BIBFRAME, the gap created in the sequence will simply be filled as the two parts on either side are placed side by side.

Figure 1. Effect on the sequence of multiple parts if no placeholder is provided for a missing part.

If the metadata of the parts do not make it clear that there is a missing part, the user may never know that the sequencing does not accurately reflect the original resource.

Europeana’s Recommendations for the Representation of Hierarchical Documents in Europeana provides one approach to representing a sequence that has missing parts. The Europeana report suggests creating a placeholder in the form of a “contextual resource” (p. 24). A similar outcome might be achieved in the BIBFRAME model by creating a placeholder.

3.3.6 Other initiatives addressing sequence

Work on aggregate resources in several quarters is relevant to the question of sequence for music resources in BIBFRAME. The FRBR Working Group on Aggregates, in its final report, addressed the concept of an “aggregate manifestation” for resources embodying several expressions of different works. They noted that, in some cases, the aggregate itself constitutes a work with its own relationships (such as to a compiler) and attributes. Their model for these cases added layers for an “aggregating work” realized through an “aggregating expression,” in turn embodied in the aggregate manifestation (p. 4-5). Even though Europeana’s recommendations (introduced above) focused on compound digital objects, the property edm:isNextInSequence could serve as a model for handling the sequence of content units in music resources. Their example of a concert made up of multiple works (p. 34) is relevant to the typical audio disc situation. METS and PREMIS also provide for representation of sequential relationships. Finally, the Variations model of Work – Instantiation – Container has also addressed the questions of aggregates and sequencing for music resources.

3.3.7 Current BIBFRAME support for sequence

BIBFRAME itself does not provide directly for sequences of content units; however, the RDF Collection structure, which can represent an ordered, closed group by means of a list structure (rdf:List, rdf:first, rdf:rest, rdf:nil), may answer this need.

In the current BIBFRAME vocabulary, certain properties have the domain Instance (including contentsNote and duration). The BIBFRAME AV Modeling Study recommends that some of these domain restrictions should be re-examined (p. 42). For example, if some concept of an aggregating resource is in play, bf:contentsNote would need to be used for a Work, not only for an Instance. Similarly, in order to associate description elements with the proper content unit, bf:duration would need to be used for a bf:Work (RDA Expression). The AV Modeling Study also recommends adding date and dateType properties as a way of handling various kinds of dates (p. 43), such as the differing recording dates commonly associated with individual content units of an audio disc. BIBFRAME has not yet developed a thorough approach to medium of performance; these terms are only truly useful in direct association with relevant content.

3.3.8 Recommendations

• Assure that the emerging BIBFRAME data environment provides fully for representing sequence relationships among constituent content units and for associating descriptive assertions directly with those units.

• Assure that end-user applications serving catalogers and other library data workers address functionality supporting sequence of resources and unambiguous association of descriptive data.

• Assure that end-user applications serving library patrons and staff take full advantage of sequence of units and any associated descriptions in search and display.

• Because medium of performance statements are currently formulated as lists of instruments, find a way to “wrap” these into a single statement of medium of performance.

• Explore possibilities for flexibility of user views of data connected with content units in sequences.

• Provide for MARC-to-BIBFRAME conversion without loss of meaning in cases where MARC subfield sequence is significant, such as for medium of performance terms.

By Hermine Vermeij, Anne Adams, and Lisa McFall

In the development of BIBFRAME, specialized cataloging communities have extensive requirements for cataloging their materials. As a particularly complicated example, the BIBFRAME AV Modeling Study laid out some of the challenges presented by audio-visual materials: the time-based/event-based nature of the material, multiple creators and contributors playing different roles, the proliferance of aggregations and collections, and the appearance of the same content on different media types, including preservation copies, all with different dates.

Should BIBFRAME aim to accommodate these special needs with vocabulary extensions? Or should it stay as simple as possible and have specialized communities rely on external vocabularies to extend it?

Current practice

The MARC format has been expanded significantly by proposals from specialized cataloging committees. Many communities have identified their needs and submitted proposals for new MARC fields and subfields, which are then integrated into the MARC format and available for use by all. Recent audio and visual examples include the 344 (Sound Characteristics), 345 (Projection Characteristics of Moving Image), 346 (Video Characteristics), 347 (Digital File Characteristics), and 382 (Medium of Performance).

Having specialized fields in MARC offers several benefits. Cataloging committees have the opportunity to put forward their own needs and potential solutions to a centralized, standardized body. The fields make it possible for catalogers to provide granular data that can be specifically targeted by catalogs and users.

However, there are also drawbacks to our current practice. The MARC format has grown to be seen as too complicated, and the high level of granularity is often not leveraged by end-user systems. The data is not always interoperable with other data, and there are often two (or more) places to put the same information (e.g., one note field and one coded or authorized field). Additionally, MARC proposals may be intimidating for small communities with specialized needs.

BIBFRAME’s current status

The current set of BIBFRAME vocabulary is a fairly concise list. Many specialized MARC fields do not (yet?) have BIBFRAME equivalents, including (just as one example) the properties represented by the subfields in the 344 (Sound Characteristics) field: Type of recording, Recording medium, Playing speed, Groove characteristic, Track configuration, Tape configuration, Configuration of playback channels, and Special playback characteristics--data elements that would be very important for certain types of audio cataloging.

It is unclear whether BIBFRAME developers are interested in incorporating more and more specialized vocabulary into the BIBFRAME vocabulary, and public opinion on the topic seems to vary as well.

The 2012 Library of Congress document Bibliographic Framework as a Web of Data outlined BIBFRAME as a model that might have the same depth as MARC:

It is important to remember that this model, like MARC, must be able to accommodate any number of content models and specific implementations, but still enable data exchange between libraries. (Page 5)

The goal of the Bibliographic Framework Initiative is to develop a model to which various content models can be mapped. This recognizes that different communities may have different views of their resources and thus different needs for resource descriptions. (Page 15)

The AV Modeling Study also argued for a robust vocabulary, but also emphasized the need for external vocabularies:

Rather than be forced to compromise descriptive detail by making it fit into a model that is not aligned with the content type, or use vocabularies built for a specific, unrelated purpose, the cataloger should be able to easily describe any given resource using a shared model. (Page 25)

While [BIBFRAME] will not be all things to all content, it has the potential to offer a logical but flexible data model, and a strong core set of vocabularies that are extensible as needed. Modeled in RDF, BIBFRAME provides organizations the opportunity to utilize other namespaces in order to add more extensive description required in specific contexts, such as technical, preservation, and rights metadata. (Pages 25-26)

In response to the AV Modeling Study, Stanford’s Phil Schreur argued on the BIBFRAME email list for keeping BIBFRAME’s vocabulary simple:

I'd prefer seeing the BIBFRAME vocabulary remain as simple as possible and, when extensions are needed, to make use of other established vocabularies as opposed to incorporating them as part of the BIBFRAME vocabulary.  If they were absorbed, the resultant behemoth would soon become impossible to manage and keep in synch [sic] with whatever vocabulary it was derived from.

In general, the Linked Data community ethos seems to encourage as much reuse of vocabulary as possible. From the Ontology Best Practices on the Open Semantic Framework:

Reuse structure and vocabularies as much as possible. This best practice refers to leveraging non-ontological content such as existing relational database schema, taxonomies, controlled vocabularies, MDM directories, industry specifications, and spreadsheets and informal lists. Practitioners within domains have been looking at the questions of relationships, structure, language and meaning for decades. Effort has already been expended to codify many of these understandings. Good practice therefore leverages these existing structural and vocabulary assets (of any nature), and relies on known design patterns.

Options

As we move forward, we could try to continue in the tradition of MARC, including specialized vocabulary in BIBFRAME, or we could keep BIBFRAME simple and encourage the use of outside vocabularies.

Having everything in one place would be a more familiar method and point of entry to BIBFRAME for those accustomed to working in the MARC environment. There would need to be clear and accessible ways for communities to propose new vocabulary and procedures in place to keep all vocabulary current and updated. The specialized vocabulary might compromise the agnostic flavor of BIBFRAME.

If BIBFRAME is kept simple, communities could develop their own BIBFRAME-compatible vocabularies more freely. There would be the possibility for less standardization (e.g., different communities using different vocabularies for the same resource types), but also the possibility for more standardization, especially with outside communities and systems.

Recommendations

We think it should be noted that the work that has gone into the MARC format is incredibly useful and should be preserved in some way.

We recommend that all vocabularies that currently exist in MARC but not in BIBFRAME should be at least evaluated for inclusion in BIBFRAME. Some are probably appropriate and desirable for BIBFRAME; others might be moved into new, standalone vocabularies that could be used in conjunction with BIBFRAME.

If a sufficient external vocabulary for a particular domain already exists (e.g., the Art and Architecture Thesaurus, the RBMS Controlled Vocabularies), the outside vocabulary should be used rather than be incorporated into BIBFRAME in some way.

If ideal vocabularies do not exist either in MARC or in another domain, BIBFRAME should allow proposals to be made for new BIBFRAME vocabulary (e.g., some of the AV-specific properties like sampling rate and frame rate).

It may be helpful to use nesting vocabulary: generalized concepts could be incorporated into the vocabulary (e.g., keyDate), which could be augmented by more specific vocabulary (e.g., rereleaseDate, firstrecordingDate, etc.).  This would make BIBFRAME more extensible, allowing the use of other vocabularies to more fully capture the information particular to this field.

Ford’s presentation makes connections between BIBFRAME Core Classes and RDA, as well as briefly discussing BIBFRAME profiles. The first statement Ford makes in his presentation is that “the Bibliographic Framework Initiative will re-imagine and implement a bibliographic environment for a post-MARC, networked world “(slide 2). He provides an outline of BIBFRAME’s Core Classes: Work; Instance; Authority; and Annotation.

Ford begins by describing the Work, which shares a striking similarity to the Work entity described in the FRBR model; it is the “conceptual essence” of the item (slide 5). Ford compares the BIBFRAME core classes to RDA and demonstrates how they would translate into a MARC record. In drawing a comparison between BIBFRAME and RDA, the Work class parallels the RDA Work and Expression. For example, a Spanish translation of Huckleberry Finn, which is an RDA Expression, is considered part of the BIBFRAME Work core class.  

A BIBFRAME Instance shares similarities with an RDA Manifestation; it is an “embodiment of a BIBFRAME work” (slide 7). In the MARC examples, Ford highlights the Publication Statement and the Extent of the resource to illustrate the similarity between the BIBFRAME Instance and the RDA Manifestation.

An Annotation is defined as “a resource that asserts additional information about another BIBFRAME resource” (slide 12). An RDA Item is equivalent to a BIBFRAME Annotation, also described in parentheses as the HeldItem (slide 12). In the MARC example, it is highlighted as the classification number.  

The Authority class represents key concepts or things in relationship to Works and Instances, but has no illustrated parallel to RDA. Examples include person, organization, family, topic, meeting, jurisdiction, place, and temporal concepts. In the MARC examples subject (topical), name, and geographic authorized access points were highlighted within the Work core class, which left me somewhat puzzled.  A BIBFRAME Authority is defined as a representing key concepts or things in relationship to Works and Instances (slide 9).

Ford’s presentation also includes a section on BIBFRAME profiles. A Profile (aka “spec”) is described as “an information model and reference serialization to support a means for identifying and describing structural constraints” (slide 21). A BIBFRAME Profile is further described as a document or set of documents that assigns a Profile (local cataloging practices) to a broader context (BIBFRAME Profiles, retrieved at http://www.loc.gov/BIBFRAME/docs/BIBFRAME-profiles.html). In simple terms, it is a cataloging tool intended to guide the cataloger in creating or modifying a BIBFRAME record. Profiles can also be used with content standards such as RDA. The BIBFRAME structure could be described hierarchically as a set of resource templates, which are further defined by a set of property templates, which may involve “value constraints” that define or constrain the values associated with the profiles (slide 23).

http://www.loc.gov/bibframe/media/updateforum-jun29-2014.html

In this 78 minute long video of the Bibliographic Framework Initiative (BIBFRAME) Update Forum from the ALA Annual Meeting 2014, reports were given by Beacher J. E. Wiggins, Sally Hart McCallum, Kevin Ford, Phil E. Schreur, and Andrea Leigh. Each provided an update on a different aspect of BIBFRAME.

The first speaker was Wiggins, the Director for Acquisitions and Bibliography Access at the Library of Congress. He provided an introduction to the session, highlighting things such as the release of the BIBFRAME editor, the beginning of a pilot by LC beginning in the fall of 2015, and highlighting the efforts within the Library of Congress to help provide others with an easier method of understanding the technicalities of BIBFRAME.

McCallum discussed the reorganization of loc.gov/bibframe, with its links to bibframe.org. The site has been updated to include information about the how authorities and relationships are viewed in BIBFRAME and profiles. The BIBFRAME editor was also made available in April, which can be used by people on their own.

Ford talked extensively on the structure of BIBFRAME and the differences between how metadata is recorded in it vs. in MARC. For anyone who is unclear on this, watching his session (specifically from 14:00-27:00 of the video recording) would be very helpful. He also had clear diagrams in his slides that illustrated how the systems function different. Ford discussed how those working on BIBFRAME plan to work with PCC and the Library of Congress to work on both visual and written tutorials on how to use the new editor.

Schreur’s presentation, titled “Stanford and BIBFRAME: Big Data, Big Issues, Big Solutions,” highlighted the work that Stanford University has been doing with BIBFRME, based partially on a grant that they received from the Andrew W. Mellon Foundation in conjunction with Cornell and Harvard. Stanford is working to create an ontology that can work both for metadata recorded in MARC and non-traditional metadata. As part of this, they are also hoping to create a system that handles editing, display and also serves as a discovery system. As part of this system, they are also hoping to provide users with the ability to incorporate external data, such as that found in DBPedia, taking full advantage of the possibilities of linked data and the flexible nature of BIBFRAME.

Leigh, from the Library of Congress’s Packard Campus for Audiovisual Conservation discussed the BIBFRAME AV Modeling Study, in which they were involved with Zepheira and AVPreserve. This study particularly targeted some of the challenges of dealing with concepts such as “work” when you are also dealing with the fixed nature of a sound recording being one instance that could be seen as an “event.” Additional information on this should be available in the BIBFRAME study, which was to be released later in 2014.

The MARC to BIBFRAME Transformation and Comparison Services are online tools that give us the ability to evaluate MARC Bibliographic data in the BIBFRAME model. Simply put, the Comparison Service allows us to compare a MARC record to a BIBFRAME presentation of that record while the Transformation Service provides the ability to submit one or more MARCXML records and view and search them as BIBFRAME records in Exhibit mode.  The services are available online, however, the transformation software underlying these tools is also available for download.  It is important to note here that while the services can be used now, they are still under development.  Additionally, there is currently a lag time between updates to the BIBFRAME vocabulary and the changes made to the transformation tool code to incorporate the updated vocabulary.

The MARC BIBFRAME Comparison Service has a simple and intuitive interface.  In order to run the comparison, you will need a Library of Congress BIBID, which is found in the MARC 001 field of an LC bibliographic record.  You enter the BIBID into the search box and click on the “Run Comparison” button. If you enter an invalid BIBID or a BIBID for a record not included in the source database, the message “Record not found. Try another” will appear along with a new search box. A successful result will display two tabs, one for the MARC record and one for the BIBFRAME record.

The comparison is useful to get a sense of what a BIBFRAME record might look like and to see the existing BIBFRAME vocabulary in context, as well as to identify where the gaps in the MARC to BIBFRAME mapping exist. Currently, the BIBFRAME record that displays is not downloadable, though one could potentially copy the record and paste it into a text editor.

As stated above, the tool is still under development and is likely to become more powerful as the testing and implementation of BIBFRAME progresses.  Detailed documentation on how to use the tool is lacking.  At this early stage, you will note that only LC records can be accommodated in the comparison.  You will also find that not all LC records are able to be found.  Through some initial experimentation with the comparison tool, it appears that the “Record not found. Try another” response generally occurs with records added the LC catalog in 2010 and later. 

The MARC BIBFRAME Transformation Service has a simple interface and intuitive but assumes the user has access to a MARCXML file.  Unlike the Comparison Service, it is not limited to using Library of Congress records. You may submit a link to a MARCXML file via the External URL File Transformation tab or by pasting the full MARCXML file into the Paste-in MARCXML Transformation tab.  Those with little experience with MARCXML or access to tools for grabbing MARCXML records may find it helpful to use this tool with Library of Congress MARC records.  Simple copy a record’s permalink, paste it into the External URL File Transformation box and add /marcxml to the filename then click on Submit URL. A successful transformation will lead you to a page with a link to your BIBFRAME model representation and a warning that you should copy the link for your future use and that the data will be deleted periodically. Error messages will appear if the transformation fails.  You may transform a single MARCXML record or a set of records.

The result currently displays a primary BIBFRAME Work record, and any related Work records, linked to BIBFRAME Instance records.  Related names and subjects are treated as BIBFRAME Authorities that appear as text strings and, in some cases, link to ID.loc.gov.  Sorting options are available and a search box as well as facets for Creator, Subject and Carrier Type appear in a left-hand navigation column to allow for navigating through the dataset.  The entire set of data may be downloaded as MARC/XML, BIBFRAME RDF/XML or Exhibit JSON. Additionally, Work records may be generated in BibTeX, HTML Table, Exhibit JSON, RDF/XML, Semantic wikitext, Tab Separated Values or Generated HTML and copied to a clipboard.  In addition to submitting your own MARCXML datasets, there are demonstration datasets available from the BIBFRAME Implementation & Testing site. 

As stated above, the tool is still under development as is the BIBFRAME vocabulary so there are some limitations of the Transformation Service.  Documentation and instructions on how to use the tool are lacking as are regular updates on the changes being made every few weeks.  The transformation is still very lossy so the first few results that you look at may leave you thinking that the transformation did not work.  Rest assured, when there is an error you will get a message that the transformation was not successful.  The error messages, however, do not offer a great deal of detail on what has caused the error.

http://dcevents.dublincore.org/IntConf/dc-2014/paper/view/312/331

Eric Miller's talk was divided into three sections: the past, the present, and the future.

The Past

20 years ago the thinking was that every standard we built had to encompass everything; one of the things Dublin Core recognized was that in fact lighter weight standards and modules of vocabularies can coexist nicely. One standard to serve everyone is a big challenge. That was a radical change at the time. Now the notion of application profiles is becoming more and more mainstream, and it’s going to be critical as we move forward.

The Present

The web is the most successful platform ever conceived for sharing information and services. Most webpages now are designed for humans to look at. But from a machine perspective, they can’t act on much in html; they can only identify sections as bold, underlined, italics, heading, etc. But that is changing; the new norm is moving from not just a human readable web to a machine actionable web.

The visible web – Google and Facebook. Both are using linked data. The Google global knowledge graph – the box on the right you see for certain searches--uses RDF to aggregate information from different sources. The Facebook graph search can execute searches such as “Find me all the people who like Albert Einstein near me.”

Identifier wars - If you “like” Albert Einstein on Facebook, it’s a different identifier from the Google global knowledge graph, VIAF, id.loc.gov, etc. Generally, the things that are easy to link to win. Google and Facebook are making it easy, but the library community is making it difficult to link to things.

The invisible web - the library community. We have a tremendous amount of information that is not visible to the web.

BIBFRAME is trying to make library data of the web. Using the web identifiers, using the way to web talks as a way of representing the data that the library community is curating.

The application profiles can be thought of as taking a set of LEGOs (not the whole world of LEGOs) and making them into small, useful shapes that very specialized communities can benefit from.

Zepheira's Linked Data training gives people tools that allow them to load or add data in their repositories. People want to make sure that if they convert MARC to BIBFRAME, they don't lose everything. (Which implies that they know what they have, which often they don't.) The tools tell you the frequency distribution of the MARC tags you're using, etc. 200 MARC records convert to 1400 resources. It's broken into topics, people, organizations, genres, etc. that are linkable. In the process of linking to those resources, we will increase the visibility of these things.

Then we can make our identifiers as easy to link to as Google's is. Open Refine is a data cleaning tool. It can, for example,  match a spreadsheet of authors against authority files. 

There's an opportunity to recognize Linked Data patterns and make recommendations for "micro-patterns" that will support Linked Data interoperability. 

The Future

The library community has not done a great job making our resources visible on the web. If you do a search on The Great Gatsby, you need to go past page 100 of Google results to get something about a library. We've put a lot of effort into producing data and making it available, but it doesn't have enough other resources linking to it to increase visibility. If only 10% of our libraries pointed to the same thing, it would be an enormous SEO improvement.

All of the pieces are in place; the invisible web is increasingly being built on Linked Data standards. The front end search engines are able to consume this. 

All libraries have some unique things that should be showcased; we can do more to make them visible.

http://libhub.org

The Kansas City Public Library, in partnership with a number of other organizations, created a website that utilizes Semantic Web ideas to “view connections between people, places, groups and events” [1] relating to the Missouri-Kansas Border War (1854-1865). The Missouri-Kansas Conflict website offers an interactive visual representation of these connections, as well as an interactive timeline, interactive maps, scholarly essays, digitized historical documents and photographs, lesson plans for educators, and keyword/faceted searching. The various features are seamlessly integrated through the use of linked data. For example, when viewing a digitized letter on one of the website’s pages, the website’s “relationship viewer” displays people, groups, places, and events directly related to the selected letter.

The relationship viewer itself resembles the visual arrangement of entities illustrated in many linked data models, including those in the BIBFRAME report. Entities are represented as large icons, and the relationships between entities are represented by arrows overlaid with a succinct text tag (e.g. Lived In, Inhabited By, Fought Against).

Figure 1. Selected example from the Missouri-Kansas Conflict website's relationship viewer.

Clicking on any of the large entity icons in the viewer rearranges the icons. The selected icon shifts to the middle of the viewer and becomes the nucleus of a new linked data graph.

There is one notable difference between the Missouri-Kansas Conflict project’s linked data model and the BIBFRAME model. The Missouri-Kansas model is centered on four primary entities: people, places, events, and groups. The Missouri-Kansas relationship model does not include creative works as primary entities. Instead, creative works and other evidential records are included as “proof” of the relationships between the four primary entities. By clicking on the text tag that describes any given relationship, the title of the historical document proving that relationship is displayed as a link that takes the user to a page with more metadata about the document. For example, if the user were to click on the text “Fought In” between “Charles R. Jennison” and “Price’s Raid” in the illustration above, links to two documents are displayed: “From James Griffing To My Dear Wife” and “Report On Price’s Raid.”

Even though historical documents and creative works are not used as primary entities in the linked data graph, these documents could be linked out to external bibliographic and authority data. It is unclear if the project is already using Library of Congress, VIAF, or any other authority data. However, as the library, archive, and museum communities increasingly implement linked data, it would greatly benefit the users of the Missouri-Kansas site if the project’s linked data is integrated with external linked data. A soldier’s data on this site could link out to the same soldier’s data on a U.S. military site. The timeline data on this site could link out to other Civil War timeline data in a “mash up” site. And, while there were few references to music on this site, some of the soldiers that fought in the conflict might have been musicians. Perhaps their data could be linked with linked open historical musician data.

[1] Quote taken from the Missouri-Kansas Conflict website: http://www.civilwaronthewesternborder.org/content/relationship-viewer (accessed December 12, 2014)

2.4--BibFrame AV Modeling Study

This report, written by Kara Van Malssen of AVPreserve with contributions by Caitlin Hunter and Andrea Leigh of LC, identifies some special requirements for the description and discovery of audiovisual resources, and explores ways that these needs could be met within BIBFRAME by proposing a generic content model which would slightly alter bf’s current content model and profiles.

The report is divided into five sections:

In the introduction, the common types of moving image and recorded sound resources held in library and archive collections are listed, demonstrating the variety of content that is encompassed in this broad category. While the content of these resources can vary greatly, several shared characteristics of audiovisual resources should be considered in description, discovery, and access: 1) time-based nature, making apparent the relationship to events and necessity of machine playback; 2) tendency to have multiple creators and contributors; 3) higher occurrence of unique or unpublished content; 4) tendency be aggregates and collections, often with repurposed content; 5) specialized preservation and migration requirements.

The second section is a “Comparative analysis of existing content models” in which various models’ treatments of content and carrier are discussed. The section compares how FRBR, RDA, FIAF, OLAC, Variations3, PBCore, EBU Core, and indecs each define concepts like Work, Expression, Manifestation, Item, Agent, Event, Place, and Content. A strong point is made that most of these models 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.

The third section covers the “Requirements for moving image and recorded sound content at the Library of Congress.” Since LC is the world’s largest audiovisual archive with many diverse types of resources, the requirements of the MBRS Division could provide a good illustration of the requirements for audiovisual description of the various communities at large.

In the fourth section, the authors propose a generic content description data model that would allow one to describe content based on a work or an event or both, depending upon the type of resource and needs of the cataloger / institution, and also allow more technical data about the carrier to be recorded.

No matter what the content or the organizational context, the option to capture any or all of these aspects involved in the creation of the resources must be available to the cataloger and other humans or machines that may want to contribute descriptions and relationships over time. [...] Rather than be forced to compromise descriptive detail by making it fit into a model that is not aligned with the content type, or use vocabularies built for a specific, unrelated purpose, the cataloger should be able to easily describe any given resource using a shared model. [page 25 of report]

The report also gives examples with diagrams of various resources depicted using this generic model.

In the final section, the report  makes recommendations for the BIBFRAME model to better accommodate the description of the various types of moving image and recorded sound resources.

• Position BIBFRAME to not be exclusively work-centric, but optionally event-centric, or straddle the line between the two as needed;

• Create a super-class for bf:Content;

• Make clear that several types can be designated for a bf:Work and bf:Instance;

• Modify domain restrictions on some properties, and add additional domains for others;

• Consider adopting technical attributes for moving image and recorded sound instances;

• Annotation should be extended to include some of the FRBR/RDA item attributes;

• Consider adding date and dateType properties;

• Investigate ways of enabling sequences;

• Investigate support for including time-stamps in descriptions of audiovisual content.

The BIBFRAME Editor [BFE] is a utility to allow for experimentation using the BIBFRAME vocabulary. There are two versions currently available: a web-based “Demo” version and a downloadable version of the software. The downloadable version allows for greater flexibility and manipulation but also requires a high degree of technological expertise and capacity.

The online version allows users an opportunity to become familiar with BIBFRAME vocabulary in a somewhat familiar and fairly intuitive interface. The online Demo has no back end storage at this time so any data entered cannot be saved. What the Demo does not at this time convey is the power of linked data. While some of the fields in the template feature a “lookup” service, basically a Google-like prediction service based on keywords, it can currently only look at the Library of Congress’s ID.LOC.GOV. The lookup feature works only with authority data, not bibliographic data. Not all the relevant entries are displayed and those that are displayed seem to be in no particular order.

The online version of the BFE currently has only two profiles: “simple monograph” and what they literally call the “Kitchen Sink Profile.” The Kitchen Sink Profile includes all of the BF vocabulary, including the vocabulary that will be used to describe music. It also contains a lot of other information that is irrelevant to most music librarians such as would be used for describing cartographic resources or 3-dimensional objects. While overwhelming, this will help to select elements to include when creating specific profiles, such as for a musical score or recording.

The downloadable version of the BFE allows for greater flexibility and manipulation but also requires a high degree of technological expertise and capacity. It can be configured to use a datastore so that information can be stored and retrieved. Within the Download, one can modify the base Profiles to fit specific needs, such as a musical score or recording. Developers using the Download can utilize other Linked Data lists and services to increase the lookup capabilities.

Both profiles are organized around BIBFRAME Model’s core classes: Creative Work, Instance, Authority, and Annotation. Work and Instance both have their own subsidiary template within the larger profile. Annotation is labeled HeldItem in the Kitchen Sink profile and Holding in the Simple Monograph profile. Authority is built into the sub-templates for Work and Instance. The four sub-templates are New HeldItem (or Holding), New Instance, New Work, and New Work, Instance, & HeldItem.

The BFE is still being developed. The designers were more concerned with functionality than the user experience. One aspect they concentrated on was the “lookup” ability: in certain fields (such as those we currently think of as “controlled vocabulary”) you can enter data and suggestions will appear in a drop-down list. Currently the online demo can only compares the entered data with the LC’s ID.LOC.GOV while the downloadable version can be configured to search other linked data sources. The suggestions given are few and in no discernable order which makes it extremely difficult (or impossible) to find the one you are looking for if you are cataloging, for instance, the opening movement of Beethoven’s “Moonlight” sonata. It also does not look up Instances (RDA manifestations) particularly well; the most obvious way to look up a book, the ISBN, does not work. These issues are all being worked on and are expected to improve.

The Deutsche Nationalbibliothek was one of the early experimenters of Bibframe, joining the group in 2012.  Reinhold Heuvelmann has made two ALA midwinter presentations (in 2013 and 2014), and most recently a presentation at the 2014 ALA annual conference in Las Vegas,  updating the United States library community on the status of their work.

Their work over the past two years can be summed up by the statement on their website (available in English at http://www.dnb.de/EN/Wir/Projekte/Laufend/bibframe.html ):  “The main objective of the first phase of the BIBFRAME project was to contribute to the BIBFRAME point papers and to glean experience from a prototypical conversion of the German National Library data into BIBFRAME format.”

The DNB uses Pica+, an internal metadata format used by the OCLC EMEA regional council.  Thus far they have been working on reciprocal conversion of Pica+ and MARC records, and now from Pica+ to BIBFRAME (a one-way conversion). The initial mapping work is done in a Microsoft Access database, and then handed off to programmers, who code in the metafacture format.

By the time of the midwinter ALA meeting in 2014, DNB had successfully mapped Pica+ authority and bibliographic records to BIBFRAME.  In a press release dated 11 February 2014, the DNB announced that they had successfully developed access to the bibliographic record in a BIBFRAME format via a link on the in the bibliographic information on the library portal.  In viewing the record here: http://d-nb.info/994548060 you can see on the right hand side options to save the record, print it, view it in MARC21-XML or RDF/XML formats (both of these links have been there for some time), or to view it in BIBFRAME format. The link uses the BIBFRAME logo, which should enhance the link’s recognizability for the user.  The user can also follow links to documentation on Linked Data and Project BIBFRAME.

The DNB has continued to collaborate with the early experimenters group and to reach out to the community via presentations and articles about their work with BIBFRAME.  As of December of 2014, Reinhold Heuvelmann has confirmed that the DNB has not been as active in recent months.  Although the icon of the BIBFRAME link has changed, they have not yet synchronized their work with the BIBFRAME 1.0 vocabulary.  Their plan for the near future is to continue to map between Pica+ and BIBFRAME for authority and bibliographic records, as well as addressing holdings records after that. They will also be exploring the possibility of bulk downloads and representing relationships between BIBFRAME works and instances.

A BIBFRAME profile specifies structural and syntactic constraints on bibliographic data in the context of a given usage pattern, such as a specific community’s resource description practices. In this way, profiles balance the intentionally under-specified nature of the BIBFRAME vocabulary with needs at the community level for greater degrees of specificity. Carried in a document or set of documents, a profile addresses functional requirements that have been identified, or any domain model that exists, for the target usage pattern.

The draft specification for BIBFRAME profiles, which to some extent parallels that for Description Set Profiles under Dublin Core, dates from May 5, 2014; as of December 2014, it was still in a public review phase. Profiles are independent of BIBFRAME itself and are envisioned as potentially shareable rather than destined for single implementation. When implemented, they should be accompanied by human-readable documentation of best practices and guidelines.

In general, the function of a profile is to leverage a particular subset of the BIBFRAME vocabulary that is central to a specific usage pattern, along with possibly bringing in parts of other vocabularies, while remaining semantically compliant with the overall model. Effectively, the profile brackets off the full complexity of the model in order to streamline end-user work in a specific context and ensure adherence to a community’s established constraints. In practice, for example, an application might be created that calls a profile or set of profiles in order to yield a cataloger interface customized for a particular workflow. In such a context, profiles might also provide a means for adding and coordinating external authority services, for targeting a particular content category of music library item, or for displaying end-user prompts in a different language. Another likely BIBFRAME profile context is that of navigation interfaces for library users. The scope of a profile might be discipline-wide or at the level of a consortium, institution, department, working language, or individual.

The structure of a profile is built up in large part by an array of resource templates, each of which specifies a resource, such as a category of library item or a class of entity to be referenced by value constraints. Property templates, in turn, specify the ways in which attributes of given resource are expressed. Finally, value constraints place limits on expected values for a given property—for example, by requiring a literal value to conform to a certain syntactic convention or by limiting values to those in a pre-selected list. Through value template references, a value constraint may call on resource templates associated with the profile as part of defining expected values for the property. Individual templates in an array specify URIs, which carry out the important function of maintaining the profile’s connection with global models.

Green & Thompson

See: http://dcevents.dublincore.org/IntConf/dc-2014/paper/view/314/344

In their presentation at the DCMI conference in October 2014, Peter Green & Timothy A. Thompson from Princeton University Library talked about their first six months of BIBFRAME testing, April to October 2014. At their library, there has been a decrease in the number of professional catalogers over the years; additionally, catalogers have undergone a change in their job titles, from catalogers to metadata librarians.

The core group of staff members testing BIBFRAME included the head of cataloging, an electronic resources librarian, a metadata librarian (with Spanish and Portuguese specialties), and a cataloging and metadata technical specialist. Their unit’s interest in testing BIBFRAME was motivated by desire to contribute, learn, give feedback, stay relevant, and stay busy.

In April 2014, the process began with an introduction to BIBFRAME for professional catalogers, in which they learned about Linked Data and the BIBFRAME model. A BIBFRAME testers group was formed, composed of 11 professionals with specialties in music, rare materials, and non-Latin materials. This group held weekly meetings, and the core group mentioned above also met as needed. Tasks were decided upon on a week-by-week basis and included the following:

·         Test marc2bibframe and submit issues

·         Analyze model

·         Test BIBFRAME editor (at LC)

·         Read/discuss BF forum listserv

·         Read/discuss AV study

·         Create profiles

·         Check MARC records enriched with URIs

·         Create use cases

The group developed a few tools locally, including a web page with useful links, a spreadsheet for tracking issues, and local web service to generate links used in test records. The group also experimented with several tools to search, explore, and visualize RDF data, including Fuseki, Pubby, Snorql, LodLive, VisualRDF, and RelFinder.

Outcomes achieved include:

·         Reported marc2bibframe issues

·         BF Editor feedback

·         Contributions to listserv discussions

·         Interesting internal discussions

·         Experimentation toward pilot projects

·         Initiated collaborations with Library Systems, Digital Humanities Center

Challenges encountered include:

·         Time

·         Steep learning curves

·         Silence in meetings

·         Core Group as instructors

·         Technology (esp. BFE output + input)

·         (Ironic) sense of testing in isolation

Phase 2 pilot projects are planned for December 2014. These include:

·         Latin American Periodicals input project

·         Large-scale MARC enrichment (URIs)

·         Create original descriptive data for small projects

·         Visualizations

·         Training

·         Collaborations with interested parties from other institutions

The Music Library Association was added to the BIBFRAME Implementation Testbed Register on November 7, 2014. The LC correspondent is Ray Deneberg (rden (at) loc.gov).

We contact Ray for any updates on the description that appears on the register. As for reporting our findings and generally communicating with the testbed community, there are two ways:

(1)    The testbed  listserv.  (bftestbed (at) listserv.loc.gov) Let me know if you want to be subscribed.

(2)    The discussion on GitHub concerning BIBFRAME conversion issues.  See https://github.com/lcnetdev/marc2bibframe/issues

Information sent to Ray Denenberg for the initial registration:

BIBFRAME Implementation Register

Music Library Association (MLA)

Description: The Music Library Association is working to examine aspects related to music in the Library of Congress’s MARC to BIBFRAME Transformation Service as part of a broader effort to develop BIBFRAME profiles for music. We plan to provide feedback on conversion issues, use cases, and functional requirements, as well as to contribute to the BIBFRAME vocabulary and data model.

Our pilot project begins with an in-depth look at how medium of performance is handled in the MARC-to-BIBFRAME conversion process. We will examine technical issues such as grouping, ordinality and cardinality, and how these aspects translate to musical designations such as soloists, accompaniment, number of players to a part, instrumental and voice doubling, and instruments sharing.

Contact: Kimmy Szeto (kimmy.szeto (at) baruch.cuny.edu)

Report 0.1 - Project Background

Kimmy Szeto

DRAFT 12/9/2014

The Music Library Association has been a leader and a partner in developing the Machine Readable Cataloging (MARC) formats, authorities and vocabularies, and has been following the development of Bibliographic Framework Initiative (BIBFRAME) since its launch in May 2011. In the 1960s, the Library of Congress led the effort to develop and implement MARC for electronic sharing and exchange of bibliographic data. The way we practice cataloging and use MARC continued to evolve to the present day, but the MARC data format itself has remain unchanged through a substantial period of stability. Looking forward at the networked information landscape, the Library of Congress realized a new model will be needed to continue sharing and exchange on the web, a foundational design for the future of bibliographic description that integrates libraries with the wider information community.

This new, proposed model, BIBFRAME, aims to become the entry point for the library community to the larger web of data. Thus, with a general audience in mind, the model’s development focuses on clearly describing and differentiating conceptual entities and physical carriers, drawing and exposing relationship between entities, and lending the data to machine interpretation. One of the challenges in this initial stage concerns developing tools to extract and enhance information already present in the vast amount of existing bibliographic data in the MARC format. Thus, for the music library community, our concerns are twofold: to participate in the development process towards the optimal model for bibliographic data for music, and to develop appropriate MARC-to-BIBFRAME conversion techniques in light of current and future cataloging practice.

The goal of the task force is to recommend a strategy for providing a voice for the music library community in the Bibliographic Framework Initiative. For the duration of the task force, we gain experience in this process through monitoring, evaluating, and testing various BIBFRAME implementations, focusing on aspects such as medium of performance, genre/form, authorities, developing a BIBFRAME profile, and communicating feedback to the Library of Congress and its development partner Zepheira. In the report that follows, we summarize the current status of BIBFRAME, analyze aspects of the BIBFRAME schema and MARC-to-BIBFRAME converter, and propose appropriate steps to address BIBFRAME development.