Vorüberlegungen zum Thema Suche about spec HOT 18 OPEN

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.

from spec.

Wenn überhaupt, dann sollte das in einem separaten Dokument spezifiziert werden. Auch das W3C ist von monolithischen "alles-in-einem-Dokument" Standards weggekommen.

from spec.

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...

from spec.

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.

from spec.

@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 ;-)

from spec.

@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.

from spec.

@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.)

from spec.

@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.

from spec.

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.

from spec.

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 ;-)

from spec.

@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.

from spec.

@marians Jetzt verstehe ich worum es in diesem Issue hier geht: "nur" um Volltextsuche :-)

from spec.

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.

from spec.

Eventuell besser auf Milestone 2.0 oder FerneZukunft setzen?

from spec.

@akuckartz Hast Recht! Den Milestone "FerneZukunft" habe ich kurz danach dafür eingerichtet.

from spec.

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/

from spec.

Eventuell relevant: http://www.opensearch.org

from spec.

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.

from spec.