Limitierung und Paginierung von Listen

[marians]

Wie im Workshop besprochen, muss es per Spezifikation die Möglichkeit geben, dass die Ausgabe von Listen durch das Backend-System limitiert wird, da einige Listen (Drucksachen, Sitzungen) tausende oder zehntausende von Objekten umfassen können. Hier ein Vorschlag für die weitere Festlegung.

Durch eine Paginierungsfunktion MUSS das Backend im Fall von mehr als 100 Objekten (genauer: URLs) in einer Liste dafür sorgen, dass die Listeninhalte auf mehrere Seiten verteilt werden, so dass jeweils maximal 100 Objekte pro Listenseite ausgegeben werden.

Die Ausgabe einer so limitierten Liste muss eine URL zum Abruf der nächsten Listenseite enthalten.

Beispiel:

{
    "items": [
        "http://meinris.de/api/papers/1",
        "http://meinris.de/api/papers/2",
        "http://meinris.de/api/papers/3"
    ],
    "nextpage": "http://meinris.de/api/papers/?start=4"
}

Wie die "nextpage" URL beschaffen ist, ist dem Implementierer freigestellt.

[akuckartz]

Dass das Problem besteht und gelöst werden muss ist offensichtlich. Die konkrete vorgeschlagene Lösung gefällt mir aber noch nicht. Ich schaue, was es für Alternativen (best practices) gibt. (SPARQL queries mit "limit" und "offset" kommen ja leider nicht in Frage, da das gegenwärtig zu hohe Anforderungen an einen Teil der potentiellen OParl-Anbieter stellen würde.)

[akuckartz]

Es gibt einen Vorschlag zu Paging im "W3C Last Call Working Draft 30 July 2013" der "W3C Linked Data Platform 1.0" der sich aber nach erstem Überfliegen nicht prinzipiell von dem von Marian unterscheidet:
http://www.w3.org/TR/ldp/#paging

EDIT: Es gibt auch einen W3C Editor's Draft mit aktuellem Stand vom 06 February 2014:
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html

EDIT2: Das wurde inzwischen in ein eigenes Dokument ausgelagert:
Linked Data Platform Paging 1.0,
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html

[marians]

Noch ein Aspekt, der in die Specs muss: Die Sortierlogik der Liste wird vom System vorgegeben und bleibt selbstverständlich bei allen Abrufen der Liste bzw. der einzelnen Listenseiten unverändert. Das System SOLL für die Sortierung bestenfalls ein unveränderliches Kriterium des Objekts verwenden, wie z.B. ein Erstellungsdatum oder eine interne ID.

Begründung: Andernfalls kann es passieren, dass sich die Objektreihenfolge zwischen den Abrufen einzelner Listenseiten ändert, weil sich Objekteigenschaften geändert haben. In der Konsequenz wäre es möglich, dass Clients beim sequentiellen Abruf aller Listenseiten einzelne Objekte nicht erfassen können.

[akuckartz]

Hinweis aus dem Workshop: Bei der Reihenfolge von Parteien oder Fraktionen müssen politische Empfindlichkeiten berücksichtigt werden. Lexikografische Ordnung z.B. geht also nicht.

[csender]

Sortierung sollte m. E. über den RIS-Betreiber erfolgen und alle Listen sollten in adäquat sortierter Form (berücksichtigung persönlicher Befindlichkeiten in der jeweiligen Kommune, Alphabet, etc.) vorliegen.

[akuckartz]

In Hydra gibt es nach aktuellem Stand hydra:PagedCollection. Das dürfte für paging brauchbar sein.
http://hydra-cg.com/spec/latest/core/#collections

EDIT: Auf der Hydra mailing list wird das gerade mit dem Vorschlag der W3C Linked Data Plattform verglichen.

[akuckartz]

Spannend: Auf der W3C Linked Data Platform mailing list (http://lists.w3.org/Archives/Public/public-ldp-comments/) ist zwar ziemlich wenig los, dafür beteiligt sich Tim Berners-Lee mit kritischen Kommentaren zu diversen (potentiell auch für OParl relevanten) Details des bisherigen Entwurfs persönlich (was nicht bedeutet, dass ich ihm in allen Punkten zustimme ;-).

[akuckartz]

Hier auch der Hinweis auf RFC 5005:

Feed Paging and Archiving
https://www.ietf.org/rfc/rfc5005.txt

[marians]

Stabile Paginierung sollten wir als Anforderung definieren, aber wie sie umgesetzt wird, könnte dem Server (-Implementierer) überlassen bleiben. Hier ein Beispiel, wie es möglich wäre:

{
    "items": [
        "http://meinris.de/api/papers/1",
        "http://meinris.de/api/papers/2",
        "http://meinris.de/api/papers/3"
    ],
    "nextpage": "http://meinris.de/api/papers/?skip=http://meinris.de/api/papers/3"
}

Der Server überspringt also bei der Ausgabe der Liste bis einschließlich zu dem mit "skip" angegebene Objekt. Die eigentlich angebrachte URL-Kodierung habe ich mal gelassen, um die Lesbarkeit zu verbessern.

[marians]

Die Inhalte sind in Kapitel 4.7 eingeflossen. Das Issue wird daher geschlossen.