ntra00
commented
10 years ago Are catalogers consciously making this kind of semantic distinction when they create enhanced 505 notes? Yes, I believe it's track titles, chapter headings, etc volumes, each of which are works in their own right. When contents are not broken out nicely, we don't have enough info to build a work, so it's a literal text field, hence the contentsNote. "Also, in the current conversion, the first subfield $g is getting omitted, which throws off the numbering . " I'll fix this. Your last point about the 020's is interesting. I did the work to break out the instances, but I don't think I finished the linkage between 505s and 020s. [note to self: look for "experimental 505a matching to isbn".] In your case, there's not an exact match in the text of the 020 and the 505 to make a link, although a human can figure out that "9788579020018 (vol. 4)" matches "4." from 505$g . I think I made it work in some cases but it resulted in too much crud in others. I'll revisit that code, and maybe have a toggle for "attempt to link 020 and 505", so that systems can opt in if they know they have clean data.
kiegel
Currently, titles from an enhanced 505 contents note (subfield $t) are being mapped to
bf:contains/bf:Work. Subfield $g is being mapped tobf:note.I have a record for a book set that has six volumes:
When I run the conversion, I get a top-level
bf:Workfor the set, and then sixbf:contains/bf:Workelements for the individual volumes. In this case, it seems to make sense to model the individual volumes asbf:Work, but will that always be the case? Are catalogers consciously making this kind of semantic distinction when they create enhanced 505 notes? Non-formatted 505 notes are not being modeled asbf:Work, but are mapped tobf:contentsNote.Also, in the current conversion, the first subfield $g is getting omitted, which throws off the numbering (i.e., the first
bf:contains/bf:Workbelow should have<bf:note>1.</bf:note>, not<bf:note>2.</bf:note>):Finally, this record contains an 020 field with an ISBN for each volume. Each 020 causes a new
bf:hasInstance/bf:Instanceelement to get generated. However, there is no correlation between these instances and thebf:Workelements generated from the titles in 505 $t. It seems incorrect to assert that each individual volume is an instance of the top-levelbf:Work. Shouldn't the instances in this case be mapped to thebf:contains/bf:Workelements? There may not be a reliable way to do this, but with this record, at least, the volume numbers following the ISBNs could be matched to the designators in subfield $g.