Na gisteren een BK-tree gemaakt te hebben waarmee we kunnen zoeken op
woorden, en daarbij ook typfouten kunnen ondervangen, verbeteren we dit
vandaag door middel van een combinatie van het fonetisch algoritme Soundex en de Burkhard-Keller tree.
In een boom opslaan van de Soundex waardes Voor het opslaan van de Soundex waarde doe ik hetzelfde als gisteren voor
de normale waardes; we gebruiken dus weer Levenshtein om de distance op
te slaan. We kunnen dan gelijkklinkende woorden vinden door een query uit
te voeren op de tree:
Nu kunnen we meerdere dingen doen om fouten in zowel spelling als uitspraak
te vinden:
Alleen zoeken op soundex van de invoer van de gebruiker
Alle woorden vinden met een distance van 1; en hier soundex op toepassen
(als je 'Driese Wetering' intikt, krijg je bijv. 'Drielse
Wetering'; op elk van deze resultaten doe je een query in de Soundex
Tree)
Alle resultaten in de soundex vinden met een distance van 1 ('Wiboukstraat'
resulteert in 'Wibautstraat')
Het resultaat van elk van deze benaderingen varieert nogal per dataset,
maar voor onze implementatie hebben we voorlopig gekozen voor 1., maar
2. staat nog ter discussie. De implementatie is immers verborgen in de
BK-tree, en we kunnen dus makkelijk schakelen.
Hierarchisch zoeken Gebruikers kunnen met komma's zoeken op hierarchie:
Hierbij zijn twee problemen:
Hoe vinden we hierarchie als de gebruiker geen komma's gebruikt;
maar bijv. Pijp Amsterdam intikt?
Hoe vinden we snel en vooral efficiënt de hierarchische parents?
Geen komma's? Wanneer een gebruiker geen komma's gebruikt, zoeken we eerst naar
resultaten die precies matchen ('Pijp Amsterdam'), als deze geen
resultaten geeft, dan berekenen we alle mogelijke queries die we kunnen
maken als we de spaties vervangen door komma's (in dit geval 'Pijp
Amsterdam' en 'Pijp,Amsterdam') met de volgende code:
Hierna voeren we alle mogelijke queries nog een keer uit.
Wel komma's Na de eerste keer geen komma's gehad te hebben, parsen we de query
('Pijp, Amsterdam') van de gebruiker naar dit model:
En we zoeken nu met de standaard-zoekcode naar alles waar 'Pijp'
in voorkomt. Hieruit komt bijvoorbeeld 'Oude Pijp', 'Nieuwe
Pijp' en 'Pijperring'. Omdat elk gebied een 'Parent'
property heeft, kunnen we dit gebruiken om te controleren of er ooit een
parent is van het huidige gebied die matcht tegen de invoer van de gebruiker:
De lijst is nu gefilterd, en 'Pijperring' is verwijderd; daar
deze in Delft ligt!
Morgen Het laatste deel in deze serie: aantallen woningen, caching en Protocol
Buffers.
There are 8 comments on this article, read them on
Coding Glamour.