Festlegung der Syntax für Suche in Listen

[Dr-Thomas-Tensi]

Für die Suche in unseren Listen gibt es bereits eine Basisimplementierung, die im Wesentlichen die Suchsyntax aus GitHub nachbildet.

Es sind per Leerzeichenfolgen getrennte Folgen von jeweils durch Doppelpunkt getrennten Schlüssel-Wert-Paaren. Ein Wert darf auch in Doppelapostrophen eingeschlossen sein, damit man Sonderzeichen als Wertbestandteil angeben kann (insbesondere Leerzeichen).

Diese Syntax klappt bei GitHub gut, weil dort die Schlüssel immer Worte sind; bei uns ist aber die natürliche Syntax oft eine Nominalphrase mit Leerzeichen (z.B. "Name des Geheges").

Das ließe sich auch wieder mit Quoting auflösen, aber dann wird die Syntax unhandlich. Insbesondere gibt es auch weitere Anforderungen an die Suchsyntax wie z.B. liberale Leerzeichensetzung, ODER-Junktor, Wildcards, Klammerung usw., die die Komplexität der Eingabe (und Verarbeitung ;-) nach oben treiben.

Ich biete an, eine vollständige Syntax zu überlegen, mit Euch abzustimmen und die JavaScript-Frontend- und Java-Backend-Implementierung dazu zu machen.

Meinungen?

[ejcsid]

@xdoo @dragonfly28 @rowe42 @Baumfrosch @ejcsid

[Dr-Thomas-Tensi]

Erste Überlegungen zur Suchsyntax in der Referenzarchitektur

Grammatik

-- TOKENS --
lParToken ::= "(" .
rParToken ::= ")" .
stringToken ::= <<single or double quote surrounded char sequence
	      optionally ending with "*">> .
wordToken ::= letter { letter | digit } .
orToken ::= "|" | "oder" .
andToken ::= "," | "&" | "und" .
notToken ::= "!" | "nicht" .
starToken ::= "*" .

-- Problem bei den Junktoren: deutsche Namen können auch als
-- Bestandteile von Schlüsseln oder Werten vorkommen, dann gibt es
-- Namenskollisionen ==> ggf. diese Varianten der Token weglassen

-- PRODUCTIONS --
primaryExpression ::= stringToken | keyValuePair | notToken primaryExpression
		  | lParToken expression rParToken .
keyValuePair ::= wordList equalsSymbol value .
wordList ::= wordToken { wordToken } .
value ::= literal | wordList [ starToken ] .
literal ::= booleanToken | numberToken | dateToken | stringToken .
term ::= primaryExpression [ andToken term ] .
expression ::= term [ orToken expression ] .
AXIOM ::= expression .

Pragmatik

• Es gibt für die zu durchsuchende Tabelle eine Liste "technicalHeadingSet" der technischen Namen der Spalten ("name", "animalkind", ...) und die Menge der sichtbaren Spaltennamen "displayedHeadingSet" ("Name des Tieres", "Tierart", ...). Es gibt auch eine Abbildung "displayedToTechnicalHeadingMap", die sichtbare auf technische Namen abbildet.
• Die in einem Schlüssel angegebene Wortliste wird wie folgt einem technischen Namen zugeordnet:
  • Wenn sie Länge 1 hat und in technicalHeadingSet vorkommt oder ohne Kollision ein Präfix eines dieser Namen ist, ist das der gesuchte technische Name.
  • Wenn die Wortliste in displayedHeadingSet vorkommt oder ohne Kollision ein Präfix eines dieser Wortlisten ist, ist das der gesuchte Spaltenname. Er wird über die Abbildung displayedToTechnicalHeadingMap auf den technischen Namen abgebildet.
  • Wenn kein Treffer gefunden wurde oder bei beiden Suchen Kollisionen auftreten, ist das eine Fehlersituation.
  • Ist die Wortliste leer, d.h. es gibt nur einen Wert, dann wird dieser Wert (in eine Zeichenkette umgewandelt) in allen Feldern gesucht. Dies entspricht einem Ausdruck
    (spalte1 = wert | spalte 2 = wert | ...)
  • Wird als Wert eine Wortliste angegeben, so entspricht diese einem String, bei dem die Worte jeweils durch exakt ein Leerzeichen getrennt sind. Ein Sterntoken wird direkt an das vorausgehende Wort gehängt.

Anfrage an Backend

• An das Backend wird eine normalisierte Suchanfrage gestellt. Dabei werden als Schlüssel technische Spaltennamen verwendet (für globale Suche der technische Name '*'), als Werte Strings in Doppelapostrophen oder in der kanonischen Wertdarstellung für den Datentyp. Die Operatoren werden dann in Postfixdarstellung angegeben, Klammern entfallen.

[xdoo]

Diese Syntax klappt bei GitHub gut, weil dort die Schlüssel immer Worte sind; bei uns ist aber die natürliche Syntax oft eine Nominalphrase mit Leerzeichen (z.B. "Name des Geheges").

Das verstehe ich nicht. Ist es nicht so, dass die Suche bei uns immer im Kontext einer Entität statt findet? D.h. wenn ich ein Gehege mit einem bestimmten Namen haben will, dann brauche ich doch nicht "des Geheges".

Bevor wir hier Aufwand rein stecken, fände ich es hilfreich zu verstehen, warum wir das brauchen. Die Behauptung, dass die natürlich Syntax oft eine Nominalphrase ist, hilft mir da nicht weiter.

[Dr-Thomas-Tensi]

Ist es nicht so, dass die Suche bei uns immer im Kontext einer Entität statt findet? D.h. wenn ich ein Gehege mit einem bestimmten Namen haben will, dann brauche ich doch nicht "des Geheges".

Du hast vollkommen recht, dass der Kontext eigentlich klar ist.
Aber wie erkennt der Nutzer einer Tabelle, dass er als Schlüssel "Vorname" oder "firstName" eintippen muss?

Die Behauptung, dass die natürliche Syntax oft eine Nominalphrase ist, hilft mir da nicht weiter.

Lass mich das ausführen, weil ich in der obigen Beschreibung etwas zu knapp war.
Damit für ihn erkennbar wird, was für Schlüssel er benutzen darf, hat er zwei gleichwertige Eingabemöglichkeiten:

• Er bekommt den technischen Namen der gewünschten Spalte heraus (also z.B. "firstName"). Mein Vorschlag wäre, dass man das z.B. als Tooltip des Spaltenkopfes anzeigt.
• Oder er nimmt einfach den Text, der im Spaltenkopf steht, als Schlüssel (also "Vorname des Tieres"). Und das ist, so leid es mir tut ;-), in der Regel eine Nominalphrase. Damit man sich die Finger beim Eintippen nicht abbricht, kann man einen Präfix dieser Phrase verwenden, solange er innerhalb der Spalten eindeutig ist, also z.B. "Vorname" oder sogar nur "V".

Das erfordert etwas aufwändige Vorverarbeitung im Frontend, aber wäre - aus meiner Sicht - eine relativ gut bedienbare Lösung.

[xdoo]

Aber wie erkennt der Nutzer einer Tabelle, dass er als Schlüssel "Vorname" oder "firstName" eintippen muss?

Im einfachsten Fall aus der Nutzerdoku. Menschen die solche Suchen (neben der freien Suche) nutzen sind ja in der Regel Poweruser. Die geben heute Schlüsselnummern ein, um Dinge zu tun. Um das zu vereinfachen haben wir #181.

Oder er nimmt einfach den Text, der im Spaltenkopf steht, als Schlüssel (also "Vorname des Tieres"). Und das ist, so leid es mir tut ;-), in der Regel eine Nominalphrase. Damit man sich die Finger beim Eintippen nicht abbricht, kann man einen Präfix dieser Phrase verwenden, solange er innerhalb der Spalten eindeutig ist, also z.B. "Vorname" oder sogar nur "V".

Das ist nicht so einfach wie es sich anhört, weil der Bezug Anzeigename und Attribut ausschließlich über eine Locales Datei (die jederzeit geändert werden kann) hergestellt wird. D.h. der Anzeigename ist vollkommen willkürlich durch die Fachdienststelle gewählt.

Sollte ein Verfahren eine spezielle Suche benötigen, dann bin ich der Meinung, dass dies durch das Projekt, genau auf die Bedürfnisse der Fachdienststelle zugeschnitten, implementiert werden sollte. Wir unterstützen mit unserer Arbeit, damit Projekte bei der INDIVIDUAL Programmierung schneller und hoffentlich auch besser werden. Zu einer Individual Programmierung gehört auch, dass bestimmte Dinge individuell für einen bestimmten Fall hergestellt werden.

[Dr-Thomas-Tensi]

[Woher kommen Namen der Schlüssel?]

[aus der Nutzerdoku, Suchdefinierer sind Poweruser]

Naja, unser Anspruch ist ja schon, dass die Oberfläche weitgehend selbsterklärend ist. Auch als Nicht-Poweruser möchte ich schnell mal eine einfache Suche hinrotzen können, ohne in einer Dokumentation nachlesen zu müssen.

[Schlüssel könnten über die Spaltenbeschriftungen gewonnen werden]

[nicht so einfach: der Bezug Anzeigename und Attribut wird ausschließlich über eine (flüchtige) Locales Datei hergestellt]

Wir haben, wenn ich das richtig verstanden habe, noch nicht letztgültig definiert, ob die Abbildung von "Attributname" bzw. "technischer Spaltenname" im Front- oder Backend stattfindet. So etwas hängt von der Komplexität der Oberfläche ab und ob man beispielsweise ohne Backendzugriff Sprachumschaltungen zulassen will und vieles mehr.

In den meisten unserer Fälle wird die Lokalisierung - und so verstehe ich Deinen Einwurf - aber mit Hilfe einer Locales-Datei im Frontend gemacht werden, d.h. dort findet die Abbildung von technischem Attributnamen auf die angezeigten Spaltenbeschriftungen statt.

Im obigen Vorschlag hatte ich geschrieben, dass es eine Abbildungsmethode "displayedToTechnicalHeadingMap" gibt; die würde genau die Information der Locales-Datei benutzen. D.h. wir haben hier kein Wartungsproblem. Es könnte höchstens sein, dass der Fachbereich mal für unterschiedliche Spalten dieselben Beschriftungen vorsieht; dann klappt die Heuristik des obigen Algorithmus natürlich nicht mehr...

Für AdHoc-Suchen trägt der Ansatz mit der Suche mit Spaltenbeschriftungen; bei vorgefertigten Suchen, die über längere Zeit funktionieren müssen, sollten eher die technischen Namen verwendet werden: dann ist man von der Lokalisierung unabhängig.

Ich gebe schon zu, dass in meinem Vorschlag viele Verarbeitungsschritte bereits im Frontend ausgeführt werden müssen. Aber wenn ich mir das zutraue, das selbst in Javascript zu implementieren, dann kann es sicher nicht megaschwierig sein ;-)

Sollte ein Verfahren eine spezielle Suche benötigen, dann bin ich der Meinung, dass dies durch das Projekt, genau auf die Bedürfnisse der Fachdienststelle zugeschnitten, implementiert werden sollte.

Hmm, wir beide vertreten die verschiedenen Enden des Spektrums: Du bist eher für ein Gerüst, das durch den Entwickler gefüllt wird; ich bin für die Maximalgenerierung. Bei der Suche denke ich, sollten wir schon eine Engine vorgeben, damit man etwas hat, was für viele Belange taugt.

Es spricht ja nichts dagegen, diese Suche durch individuelle Lösungen ersetzen zu können.

Klingt nach Diskussion in der Gruppe oder wir treffen uns mal auf einen Kaffee?

[rowe42]

Also ich finde den Vorschlag von @Dr-Thomas-Tensi sehr gut und umfassend. Und es ist ja tatsächlich im aktuellen Beispiel so, dass es bei den Enclosures eine Spalte gibt, die "Name des Geheges" überschrieben ist. Und da wüsste ich als Nutzer jetzt nicht ohne weiteres, was der technische Schlüssel im Suchfeld dafür ist.

Ich kann auch nachvollziehen, dass wir das Mapping von Spaltenüberschriften auf technische Feldschlüssel über die Information in der locales-Datei machen können.

Aber: Ich schätze das als relativ komplex ein, das zu implementieren. Das wird nix für Meilenstein 1 und meiner Meinung nach ist das auch für Meilenstein 2 schwer zu bewältigen (@ejcsid weiß hier mehr, da sie sich schon mit der Suche im Backend beschäftigt hat). Wenn du dir das aber zutraust, fände ich das nicht schlecht.

Was meinen die anderen? @Baumfrosch @ejcsid @dragonfly28

[DirkGern]

Wenn ich es richtig verstanden habe, setzen wir im Backend Lucene ein. Ich hätte erwartet, dass wir die Lucene-Parser-Syntax mit möglichst wenigen Veränderungen an die Oberfläche bringen. Damit hätten wir wenig Aufwand, aber die Mächtigkeit von Lucene. Konkret vermisse ich

1. die Wildcard-Suche (*, ?)
2. Fuzzy Search
3. Ranges [ ]

-- Problem bei den Junktoren: deutsche Namen können auch als

-- Bestandteile von Schlüsseln oder Werten vorkommen, dann gibt es

-- Namenskollisionen ==> ggf. diese Varianten der Token weglassen

Hier würde ich wie Lucene auf Großbuchstaben setzen, evtl. in Englisch. Erspart Internationalisierung und ist man vom Outlook-Client gewohnt ;-)

Die Schlüssel würde ich auch von den Headern trennen, um flexibler zu sein. So könnte man Kürzel z.B. einführen. Sie sollten aber zu 90% identisch sein.

Ich hoffe, das hilft erstmal.