Search functionnality over corpora

[PonteIneptique]

It would be great to be able to do a multiple field research (form, lemma, left_context, right_context, POS, morph) using wildcard if possible with editables rows.

Using the templates, I think it is a rather good first issues as it will make clear how the templates work in PPA as well as the routes and tests ;)

[MrGecko]

@PonteIneptique What do you mean by "editables rows" ?

[PonteIneptique]

The results should be "editable", you can most probably reuse the macro for that : https://github.com/hipster-philology/pandora-postcorrect-app/blob/b12ee25a78af8113fea74b32a1ea1b5e2391b2c5/app/templates/macros/tokens_macros.html#L6

[PonteIneptique]

Note : the definition and param names of this macro might probably be better done...

[MrGecko]

@Jean-Baptiste-Camps @PonteIneptique Which kind of combinatory and logical operator would you need to perform the search operations you want ?

At the moment, LIKE operations are possible (using * instead of the SQL %) and negations too with the ! operator :

Is there any chance * and ! would appear as tokens ? In this case we may need to be able to comment them. An other way would be to use separated checkboxes to enable/disable unitary operators.

[PonteIneptique]

Maybe it would be worth to bring in @ArianePinche who is the real user who has been testing this.

I think, we might want to have to escape characters but I am not a real user :)

[MrGecko]

Also, I suggest to add the search feature directly within the Edit Tokens page (and not create a separate page like I've done as of today).

[Jean-Baptiste-Camps]

Ok, so, clearly, !, and perhaps sometimes * could be tokens, as they are corpora with POS annotation of punctuation (for instance BFM).

[PonteIneptique]

On peut dire au gens d'échapper ceux-ci au pire (\!) comme le prévoit @MrGecko non ?

[ArianePinche]

Bonjour, à mon avis, il serait bien de garder les pages séparées entre l'édition de token et la recherche pour éviter des confusions dans l'esprit de l'utilisateur du point de vue de l'utilisation, mais aussi de la lisibilité de la page.
Pour les opérateurs, considérer que les différentes catégories sont liées par un AND permettrait d'éviter du bruit dans les résultats (situation actuelle, me semble-t-il ?). Enfin, introduire au sein des catégories des OR permettrait, je pense, d'étoffer un peu les requêtes : avec un | comme en xpath par exemple ?

[MrGecko]

Merci pour vos remarques. J'ai pris en compte l'échappement des opérateurs.
L'ajout d'un OR au sein d'une catégorie nécessiterait peut-être l'apport de la notion de groupes :

      seint|saint
      s(a|e)int
      s(a|o(i|e))nt   -> sant, soint, soent, 

Ce qui reviendrait à réellement considérer les expressions comme des arbres contenant des opérateurs et des littéraux et c'est un poil plus complexe à réaliser :)
Ou alors on considère que le premier et plus simple des trois exemples ci-dessus, sans groupe.

Qu'en pensez-vous (sachant qu'il faut prendre en compte les interactions de | avec ! et *) ?

[PonteIneptique]

Je pense que si on supporte seint|saint, c'est LARGEMENT suffisant pour la première version. :)

[PonteIneptique]

Note : avant que tu passes à l'implémentation utilisateur, on peut peut-être basculer ca sur la master en PR quand tu auras fini ? Ca permettra une derniere release avec cette fonctionnalité avant d'avoir le besoin de compte

[PonteIneptique]

Je te laisse l'honneur de fermer l'issue @MrGecko :D

[MrGecko]

Camarades, c'est avec la plus grande émotion que je clos cette issue.

[PonteIneptique]

@MrGecko en ce moment

Le reste de l'équipe

Un petit troll ne fait pas mal ;)