OParl
Vorüberlegungen zum Thema Suche
Wir müssen klären, ob das Thema Suche im Standard Version 1.0 enthalten sein soll oder nicht. Mein Vorschlag ist, es nicht in den Standard aufzunehmen, trotz der damit verbundenen Konsequenzen.
Es geht auch ohne. Die Methoden zum Abruf der verschiedenen Objekte sollten natürlich bestimmte Kriterien zur Einschränkung (Filterung) der Rückgabe bieten. Beispiele: Sitzungen mit Termin innerhalb eines bestimmten Datumsbereichs, Drucksachen vom Typ "Antrag".
Suche wäre beispielsweise: Drucksachen, die den Begriff "radfahrer" enthalten.
Die sinnvolle Beantwortung einer solchen Suchanfrage erfordert auf Seite des Systems die Indexierung der Inhalte, idealerweise die Grundformreduktion (radfahrerin/radfahrers/radfahrern/... => "radfahrer"), dafür üblicherweise die Pflege von Stoppwortlisten und darüber hinaus möglicherweise die Pflege von Synonymen. Bei der Rückgabe stellt sich die Frage, wie diese sortiert sein soll (Relevanz-Sortierung? Nach welchen Kriterien?).
Alle diese Aspekte machen Suche zu einem Thema, das viel Spielraum für Interpretation lässt. Nach meiner Vorstellung sollte der API-Standard nicht zu solchen Interpretationen einladen, die fast zwangsläufig zu unterschiedlichen Ergebnissen führen. Die API sollte sich hier viel mehr neutral verhalten.
Keine Suche in den Standard zu integrieren bedeutet natürlich, dass man das Thema komplett an die Nutzer der API auslagert bzw. die Clients auslagert. Um eine Suche bieten zu können, müssen also API-Nutzer zunächst Inhalte ausgelesen und indexiert haben. Leichtgewichtige mobile Anwendungen oder beispielsweise rein JavaScript-basierte Anwendungen, die direkt auf die API zugreifen, würden es dadurch schwer haben, Nutzern eine Suche bieten zu können.
Ich sehe kein Problem, die Suche nicht explizit aufzunehmen. Entscheidend ist ein einheitliches und flexibles Format für die Repräsentation von Listen. Ein solches Format kann dann als Suchergebnisliste verwendet werden.
Das hat den Vorteil, dass Anbieter mit Suchfunktion diese Standard konform anbieten können ohne, dass es explizit drin steht.
Wenn überhaupt, dann sollte das in einem separaten Dokument spezifiziert werden. Auch das W3C ist von monolithischen "alles-in-einem-Dokument" Standards weggekommen.
Ich fände es schon schön, zumindest eine einfache Form der Volltextsuche zu spezifizieren, da das meiner Wahrnehmung nach bei Ratsinformationssystemen eine der am häufigsten genutzten Funktionen ist. Wobei ein separates Dokument wie von @akuckartz vorgeschlagen natürlich auch ok wäre. Das auf den Client auszulagern ist IMHO keine wirklich praktikable Lösung, bei umfangreicheren RISen kommt ja dann doch schnell mal ein, zwei GB an Rohtext zusammen...
Einen optionalen Suchlink als URI Template, wie im Beispiel im Kommentar zu #13. wäre ja kein Problem. Wer eine Suche hat, packt den Link rein, wer sie nicht lässt ihn weg. Das ist so wenig komplex, dass man da kein Dokument für braucht.
@jehrhardt Suche ohne Query-Sprache ist keine Spezifikation - oder jedenfalls eine ziemlich lückenhafte. Und auch zum Format der Antworten muss man sich äußern.
(Perspektivisch wünsche ich mir so etwas wie SPARQL ;-)
@akuckartz Ich verstehe dein Anliegen. Grundsätzlich finde ich es sinnvoll eine vorhandene Volltextsuche über einen simplen optionalen Link auch für API Clients verfügbar zu machen. Das ist einfach zu implementieren, sowohl auf Client als auch auf Server Seite und sollte 80 % der Use Cases erfüllen.
Alles, was darüberhinausgeht würde ich in eine eigene Spezifikation packen, gerade wenn es um so etwas wie SPARQL geht. Es gibt einen guten Grund warum die relevanten APIs der Welt (Twitter, Facebook, Amazon) SPARQL nicht unterstützen.
@jehrhardt Mich interessiert noch, wie das Format der Antworten aussehen soll.
(Ich wollte hier keine Diskussion über SPARQL eröffnen. Auf den Vergleich von RIS mit proprietären nichtoffenen Datensilos gehe ich hier deshalb nicht ein.)
@akuckartz Es bietet sich an ein generisches Format für Listen zu haben, was ein relativ einfach zu lösendes Problem ist. Beispiel:
{
"title": "Drucksachen der Sitzung ...",
"entries": [
{…},
{…}
]
}
Ein derartiges Format lässt sich natürlich noch um Links für Paging erweitern und kann überall verwendet werden, wo eine Liste zurückgegeben wird. Eine Suchergebnisliste ist also nur ein Spezialfall.
Das Dokument SPARQL 1.1 Query Results JSON Format enthält ein Beispiel an dem man sich (auch unabhängig von SPARQL) möglicherweise orientieren kann.
Ich halte es für wichtig, dass Klarheit über die Use Cases besteht.
Hier ein paar Vorschläge (sehr wahrscheinlich können nicht alle berücksichtigt werden). Suche nach:
- Sitzungen eines bestimmten Gremiums mit öffentlichen TOPs (mehrere Kriterien)
- Gemeinsame Sitzungen von mehr als einem Gremium mit öffentlichen TOPs (Kriterium mit Aussage zu Kardinalität)
- Sitzungen eines bestimmten Gremiums mit nicht-öffentlichen TOPs mit mehr als X anwesenden Mitgliedern (Kriterium mit Aussage zu Kardinalität)
- Gemeinsame Sitzungen von mehr als einem Gremium mit öffentlichen TOPs mit Anwesenheit eines bestimmten Mitglieds (drei Kriterien)
- Gemeinsame Sitzungen von mehr als einem Gremium mit öffentlichen TOPs mit Anwesenheit eines bestimmten Mitglieds die in einem bestimmten Zeitraum stattgefunden haben (vier Kriterien, darunter Datumsbereich)
- Sitzungen mit einem Bezugsort an einer bestimmten Strasse, unabhängig von Hausnummer
- Sitzungen mit einem Bezugsort im Umkreis von X Metern eines in Längen- und Breitengrad angegebenen Ortes
(Weitere Vorschläge mit weniger aber dafür schwierigeren Kriterien folgen ;-)
@akuckartz Die von Dir genannten Beispiele sind alles keine "Suchabfragen", wie ich es meinte und wie es Thema dieses Issues hier sein sollte. Die von Dir genannten Abfragen sind alle ohne Volltext-Indexierung beantwortbar (sofern denn die beispielhaft genannten Daten verfügbar sind ;-)). Damit unterscheiden sie sich grundlegend von meinem Beispiel:
- Alle Drucksachen, die den Begriff "radfahrer" enthalten.
@marians Jetzt verstehe ich worum es in diesem Issue hier geht: "nur" um Volltextsuche :-)
In Vorbereitung auf den Workshop nächste Woche schließe ich dieses Issue. Volltextsuche al Bestandteil der API ist für Version 1.0 kein Thema.
@akuckartz Hast Recht! Den Milestone "FerneZukunft" habe ich kurz danach dafür eingerichtet.
In Hydra gibt es aktuell einen Vorschlag bezüglich Volltextsuche unter Verwendung von RFC 6570. Siehe dort "hydra:search" und "hydra:freetextQuery". Siehe http://www.hydra-cg.com/spec/latest/core/
Ich ändere den Titel des Issues in "Vorüberlegungen zum Thema Suche". Die Frage im ursprünglichen Titel "Soll Suche ein Thema des Standards (Version 1.0) sein?" ist längst beantwortet und verneint.