Umlaut search not working with ?name parameter in /subject endpoint

[acka47]

Reported by @Phu2 on twitter: https://twitter.com/herr_tu/status/656453267631665153:

Kann es sein, dass es Probleme mit Umlauten gibt? Mit ID ok http://lobid.org/person?id=121096262 mit Namen kein Treffer http://lobid.org/person?name=böldl.

[Phu2]

Betrifft nur den ?q-Parameter und meine Verwirrung vorhin: Das hat anscheinend etwas mit den Codierungen zu tun. http://lobid.org/person?q=%22B%C3%B6ldl,%20Klaus%22 funktioniert nicht http://lobid.org/person?q=%22Bo%CC%88ldl,%20Klaus%22 funktioniert

Das Gemeine ist, dass der Browser beides nach http://lobid.org/person?q="Böldl, Klaus" auflöst. Deshalb war ich vorhin auch so verwirrt ...

[acka47]

Wir könnten schauen, inwiefern API-seitig verschiedene Codierungen unterstützt werden können. Allerdings wüsste ich vorher gerne, ob das überhaupt nötig ist.

@Phu2 Meinst du, die API sollte verschiedene Codierungen unterstützen? Oder ist das derzeitige Verhalten für dich als API-Nutzer in Ordnung?

[Phu2]

Nein, für mich ist das ok so. Ich habe die API einer Kollegin über den Browser gezeigt, deshalb ist mir die unterschiedliche Codierung erst gar nicht aufgefallen.

[acka47]

Ok. Dann schließe ich das Ticket.

[Phu2]

Aber mit dem ?name-Parameter stimmt doch was nicht ... http://lobid.org/person?name=%22Bo%CC%88ldl,%20Klaus%22 funktioniert nicht http://lobid.org/person?q=%22Bo%CC%88ldl,%20Klaus%22 funktioniert

[acka47]

Achja. Diesmal war ich verwirrt. @fsteeg wird sich darum kümmern, wenn er wieder da ist.

[fsteeg]

Scheint ein Problem auf Datenebene zu sein, denn grundsätzlich klappts, z.B.:

http://lobid.org/person?name=böll http://lobid.org/person?q=böll

Der konkrete Eintrag für den Böldl scheint komisch zu sein, siehe RDF-Serialisierungen hier:

http://lobid.org/person?q=Böldl

Statt normale Umlaute hat der offenbar Diakritika (die zudem bei uns in den RDF-Serialisierungen auf den falschen Buchstaben bezogen werden). Die Anfrage oben funktioniert auch nur wie sie da steht, mit diakritischem Zeichen, nicht mit normal getipptem ö (vgl. auch die URL-encodeten Varianten).

Das Ganze erinnert mich an die Geschichte wegen der @jschnasse auch neulich eine Diskussion auf der DNB-Datenformate-Liste angestoßen hatte. Was das für uns heißt weiß ich nicht. Mich erstaunt speziell dass nur speziell der Datensatz das so macht. @dr0i: Sind die GND-Updates inkrementell?

[dr0i]

Die GND wird in ES einmal wöchentlich komplett neuindexiert, das ist der alte hadoop workflow.

[jschnasse]

I do this java.text.Normalizer.normalize(rdfObject,Normalizer.Form.NFKC)) . How do you handle diacritics.

[fsteeg]

Thanks Jan. We're currently not handling diacritics at all. Do you normalize before storing in the index?

[jschnasse]

Normalization is done directly after receiving the data from dnb - before indexing, yes. I'm a bit surprised that you do not handle diacritics at all. You must do it elsewhere since the bibliographic titles under lobid/resource look pretty normalized.

[dr0i]

The subject endpoint is not specifically processed, in contrast to the resource endpoint.

[fsteeg]

@dr0i That sounds like you'd know where and how to tackle this issue. Want to assign to yourself?

[fsteeg]

See also https://github.com/hbz/lobid/issues/255, which is probably related.

[acka47]

@fsteeg, sound slike we should keep an eye on this problem also for 2.0...

[fsteeg]

Corresponding issue for 2.0 is fixed (https://github.com/hbz/lobid-gnd/issues/33), closing.