lcnetdev / marc2bibframe2

Convert MARC records to BIBFRAME2 RDF
http://www.loc.gov/bibframe/
Creative Commons Zero v1.0 Universal
89 stars 35 forks source link

Field 382 subfield a and b #66

Closed kiegel closed 6 years ago

kiegel commented 6 years ago

Field 382 (Medium of performance) has subfield a for Medium of performance and subfield b for Soloist. In MARC records, subfield coding identifies Medium of performance vs. Soloist, but this is not true in the current version of the conversion program. Since terms are drawn from the same vocabulary, one cannot tell the two functions apart. For example, in this 382 the horn is the solo instrument not the piano.

382 01 $b horn $n 1 $a piano $n 1 $s 2 $2 lcmpt

 bf:musicMedium [ a bf:MusicMedium ;
        rdfs:label "horn" ;
        bf:count "1" ;
        bf:source [ a bf:Source ;
                rdfs:label "lcmpt" ] ],

    [ a bf:MusicMedium ;
        rdfs:label "piano" ;
        bf:source [ a bf:Source ;
                rdfs:label "lcmpt" ] ] .

The mechanism of bf:status used for Doubling and Alternative medium of performance could be used for subfields a and b. From the point of view of machine processing, the presence of a data element is preferable to inferring a function based on the absence of a data element.

 bf:musicMedium [ a bf:MusicMedium ;
        rdfs:label "horn" ;
        bf:count "1" ;
        bf:status [ a bf:Status ;
                rdfs:label "soloist" ] ;
        bf:source [ a bf:Source ;
                rdfs:label "lcmpt" ] ],

    [ a bf:MusicMedium ;
        rdfs:label "piano" ;
        bf:status [ a bf:Status ;
                rdfs:label "medium of performance" ] ;
        bf:source [ a bf:Source ;
                rdfs:label "lcmpt" ] ] .
jodiw01 commented 6 years ago

instead of bf:status, should the spec use the already-defined bf:instrumentalType?

kiegel commented 6 years ago

It sounds like a good idea, but there is a problem due to the way the property is currently defined: bf:instrumentalType cannot take the place of bf:status directly because it is used with MusicInstrument, not MusicMedium. To use instrumentalType, you have to do this:

382 01 $b horn $n 1 $a piano $n 1 $s 2 $2 lcmpt

Ex:someWork

 bf:musicMedium [ a bf:MusicMedium ;
    rdfs:label "horn" ;
    bf:count "1" ;
    bf:source [ a bf:Source ;
            rdfs:label "lcmpt" ] ],

[ a bf:MusicMedium ;
    rdfs:label "piano" ;
    bf:count "1" ;
    bf:source [ a bf:Source ;
            rdfs:label "lcmpt" ] ] ;

bf:instrument [ a bf:MusicInstrument ;
    rdfs:label “horn” ;
    bf:instrumentalType “soloist” ], 

[ a bf:MusicInstrument ;
    rdfs:label “piano” ;
    bf:instrumentalType “medium of performance” ] . 

Computationally, this is not great because you must do string matching on the labels in MusicMedium and MusicInstrument to pull all of the information together.

Additionally, this type of data structure does not deal well with complexities, in particular doubling instruments. For example, in

382 __ |a soprano |n 1 |a flute |n 1 |d piccolo |n 1 |a clarinet |n 1 |d bass clarinet |n 1 |a cello |n 1 |a piano |n 1 |s 5 |2 lcmpt (OCLC #93634076)

you can't readily encode that the piccolo doubles the flute and the bass clarinet doubles the clarinet. This is obvious to humans trained in music but is not machine actionable.

To me it seems preferable to put all information about performance medium in MusicMedium so that associated characteristics can be more closely linked. The options are to continue using bfstatus or to introduce a property similar to instrumentalType that uses MusicMedium.

jodiw01 commented 6 years ago

The specs have been revised to change the wording. Further adjustments may occur in the future if the PMO terms are used.