The problem is that the current code asserts bf:part properties (such as "original" or "summary") on language entities such as <http://id.loc.gov/vocabulary/languages/eng> directly, i.e. triples like this:
This causes problems especially when converting multiple records with different language information.
The proposed fix implemented in this PR is to use a blank node as the bf:language value, and add an rdf:value property that references the LC language URI. So for e.g. a record that represents a translation from English (041 $h eng), we get these RDF triples:
The PR changes both the XSL implementing the conversion and the XSpec test, making sure that the test passes.
There are other MARC fields (e.g. 008) that also get converted to bf:language properties with bf:Language values that get LC-assigned URIs, but AFAICT no record-specific extra information like bf:part is asserted for those URIs, so there is no analoguous problem and I decided not to touch their conversions.
This is a proposed fix for issue #7.
The problem is that the current code asserts
bf:partproperties (such as "original" or "summary") on language entities such as<http://id.loc.gov/vocabulary/languages/eng>directly, i.e. triples like this:This causes problems especially when converting multiple records with different language information.
The proposed fix implemented in this PR is to use a blank node as the
bf:languagevalue, and add anrdf:valueproperty that references the LC language URI. So for e.g. a record that represents a translation from English (041 $h eng), we get these RDF triples:The PR changes both the XSL implementing the conversion and the XSpec test, making sure that the test passes.
There are other MARC fields (e.g.
008) that also get converted tobf:languageproperties withbf:Languagevalues that get LC-assigned URIs, but AFAICT no record-specific extra information likebf:partis asserted for those URIs, so there is no analoguous problem and I decided not to touch their conversions.