Closed jschnasse closed 8 years ago
We need to fix this (as well as https://github.com/lobid/lodmill/issues/735) asap. The problem here is the label (not the incorrect use of preferredNameForThePerson
).
From the source (snippet):
<datafield ind2="1" ind1="b" tag="200">
<subfield code="k">Bayern</subfield>
<subfield code="b">
Bayerisches Landesamt für Gesundheit und Lebensmittelsicherheit
</subfield>
<subfield code="9">(DE-588)16030343-6</subfield>
</datafield>
Obviously, subfield b
isn't taken into account in the transformation.
Another example is http://lobid.org/resource/HT016048134. We should concatenate subfields k
and b
with a period and space in between. E.g. "Bayern. Bayerisches Landesamt für Gesundheit und Lebensmittelsicherheit" in http://lobid.org/resource/HT016048134 and "Nordrhein-Westfalen. Ministerium für Inneres und Kommunales" in http://lobid.org/resource/HT016048134.
Ah, yeah I was about to ask "Should fields be concatenated like in https://github.com/hbz/lobid/issues/179 ? Or has it nothing to do with it?"
Also, interesting documentation is https://wiki1.hbz-nrw.de/display/VDBE/GND-2+-+Neue+Unterfeldstruktur+in+BIB . k
denotes the name of the corporation, b
is the name of the subordinated corporation. Thus, we would have not only concatenate k, h
but k. b, h
. Yes?
+1
i hope everything works now. Please inform me as soon as index is ready.
Thus, we would have not only concatenate k, h but k. b, h . Yes?
No. h
seems to be mostly acted as an location addendum to k
, thus it was wrapped liked in <h>
, not comma separated. Thus, with the new commit we have the following precedence and structure:
k <h>. b
, k. b
, k <h>
, k
.
Hope this makes sense.
Looks good to me.
+1
Deployed tp production, closing.
I found this data attached to the resource
If you look at http://d-nb.info/gnd/16030343-6, this seems to be wrong.