Closed kiegel closed 5 years ago
Thanks for the suggestions - this whole conversion program revolves around complex string matching so I don't think that's a very good rationale to change how we deal with this particular field.
We match codes to URIs for lists in ID incl. the DemographicGroup list. We'll review how it deals with those codes & terms incl. the specifications which do have a note to use bf:code for the code value, not a label.
I believe this has been addressed with commit https://github.com/lcnetdev/marc2bibframe2/commit/3868042b99673c4a26c49e726d9a51f004517059, part of the soon-to-be-released v1.4.0 branch.
In fields 385 (Audience characteristics) and 386 (Creator/contributor characteristics), subfields m and n for the demographic group term and code, respectively, are converted in an identical manner.
bflc:demographicGroup [ a bflc:DemographicGroup ; rdfs:label "385 subfield m" ], [ a bflc:DemographicGroup ; rdfs:label "385subfieldn" ]
bflc:demographicGroup [ a bflc:DemographicGroup ; rdfs:label "386subfieldn" ], [ a bflc:DemographicGroup ; rdfs:label "386 subfield m" ]
Terms and codes have different uses, that is, terms are likely for human display and codes for machines. Mixing terms and codes together as literals will force developers to do relatively complex and error-prone string matching to get what they need. It would be better to differentiate terms and codes in some way.