Vraag Onno aan Han, maart 2016:
"Ik heb een vraag over zoeken naar N-grams over annotations. Was dit eerder niet ook mogelijk in de Multiple Layer Search? Ik meen me zoiets te herinneren, maar het is nu weg. Is er een reden om het daar niet ook te hebben? Het zou voor ons superhandig zijn, omdat we dan kunnen zoeken naar bv. zinnen (1 annotatie) die overlappen met bv. twee gebaren (twee annotaties)."
Reactie Han: "Volgens mij niet. Ik kan het me in ieder geval niet herinneren en ik zie ook niets hierover in de release notes, noch in de manual. Ik ben bang dat het (betrouwbaar) zoeken naar 2 annotaties binnen 1 andere annotatie een "echte" oplossing nodig heeft, met aanpassingen in de UI en in de zoekmachine zelf."
Gerelateerde vraag Onno aan Han: "Is er een manier om te zoeken naar ‘een of meer annotaties tussen string 1 en string 2? Met een reguliere expressie? Ik vind in de handleiding wel de wildcard #, maar niet ‘een of meer #’. (Voor die wildcard can ik ook de reguliere expressie .* gebruiken. Of is er een verschil?)"
Reactie Han: "# geeft ongeveer maar niet helemaal dezelfde resultaten als . (heb ik even uit moeten proberen om te zien). Het kan uitmaken of je n-gram binnen of over annotaties hebt geselecteerd. Daarbij kun je # makkelijk combineren met substring of exact match (met reguliere expressies kan dat ook maar is dat wat lastiger).
Ik zou niet hebben kunnen voorspellen of 1 of meer annotaties tussen A en B zou lukken met reguliere expressies, maar het lijkt erop van niet. Je zou iets verwachten als 'A (.)++ B' of 'A (.)+? B', maar ik geloof dat de query in stukjes wordt gehakt en dat elk volgende stukje gematcht wordt met een volgende annotatie. 'A # # B' lijkt hetzelfde te vinden als 'A . .* B' en 'A # B' iets anders dan 'A # # # B' (in multiple layer kun je dan wel weer makkelijk naar '1 of meer annotaties' ertussen zoeken)."
@ocrasborn This seems like a rather elaborate enhancement to develop. We better sit down and discuss this.
My concerns:
Do you want a complete new search mode or just an enhancement of an existing one?
How flexible do you want the new search mode (or whatever) to be? The more flexibility, the more it boils down to some kind of query language instead of a tailored UI.