Paging Problematik

[akuckartz]

Es gibt das gut begründete Interesse an einem in OParl durchgehend verwendbaren Paging Mechanismus. Es gibt gegenwärtig jedoch keinen außerhalb von OParl vollständig spezifizierten und standardisierten Mechanismus dafür.

Zwei potentielle zukünftige Kandidaten dafür sind in Entwicklung: Linked Data Platform Paging (https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html) und Hydra Collections (http://www.hydra-cg.com/spec/latest/core/#collections). Nach aktuellem Stand sind beide bisher jedoch nicht als ausreichend stabil anzusehen (siehe z.B. den Thread http://lists.w3.org/Archives/Public/public-hydra/2014Apr/0044.html). Eine der Komplikationen - die sich in OParl ebenfalls ergibt - hat @lanthaler aufbereitet: https://www.w3.org/community/hydra/wiki/Avoid_that_collections_%22break%22_relationships

Es besteht nun die Problematik, dass wir für OParl eine spezielle (Insel-)Lösung schaffen, die nicht mit zukünftigen Entwicklungen kompatibel ist und erhebliche Aufwände bei Entwicklung und Integration nach sich zieht - die vermeidbar wären, wenn die zukünftigen Standards bereits jetzt bekannt wären. Mangels Zeitmachine scheint dieses Problem unvermeidbar zu sein, allerdings sollten die Auswirkungen soweit möglich bewusst begrenzt werden.

[sterni24]

Für welche Objekte kommt Paging überhaupt in Frage?

[akuckartz]

@sterni24 Nach aktuellem Stand für alle Eigenschaften bei denen es mehr als 100 Werte geben kann (die Zahl 100 ist dabei willlkürlich gewählt. Siehe auch #144 ). Grundsätzlich muss man vermutlich annehmen, dass das alle Eigenschaften sind, für die mehr als ein Wert angegeben werden darf, also mit entsprechender Kardinalität.

[sterni24]

Ist Paging wirklich erforderlich? Um welche Datenmengen geht es hier überhaupt? Müssen die umfangreichen Redundanzen in den Objektlisten überhaupt sein?

Hier ein fiktives Beispiel, um auch die m. E. umfangreichste Tabelle auszulesen:

{
    "@object": "https://oparl.ratsinfomanagement.net/paper/",
    "@liste": [
        "1234"
        "1235"
        "1246"
        ...
        "85497"
    ]
}

Bei theoretisch 20.000 Einträgen eines OParl-Mandanten wären dies ungepackt ca. 200 KB. Oder liege ich hier völlig daneben?

Zudem würde eine solche Ausgabe viel Entwicklungszeit auf allen Seiten ersparen.

[akuckartz]

Ich bin nicht unbedingt die richtige Person für die Entscheidung, ob Paging wirklich erforderlich ist, da für meine Zwecke eine Umsetzung von #64 ausreichen würde ;-)

[lanthaler]

Ich geh davon aus dass wir Hydra’s Paging Desgin in den nächsten Wochen finalisieren können und es damit dann als stabil angesehen werden kann. Zusätzlich Features wie client-controlled pages sizes etc. sind da natürlich noch nicht dabei, können aber leicht später hinzugefügt werden.

[akuckartz]

Sandro Hawke (W3C) hat gestern einen ganz anderen Ansatz vorgeschlagen: "TCP backpressure instead of paging" http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jun/0026.html

Wie er selbst schreibt ist das jedoch auf absehbare Zeit nicht verwendbar.

[akuckartz]

Nachdem ich mir die PagedCollection-Lösung von Hydra weiter angesehen habe schlage ich nun explizit vor diese zu verwenden: http://www.hydra-cg.com/spec/latest/core/#collections

Vorteile:

• es ist keine OParl-spezifische Lösung
• Entwickler müssen sich nicht um spezielle http-Codes kümmern
• wird bereits erfolgreich für LDF verwendet

Damit ist eine weitgehende Rückkehr zu der ursprünglich von @marians vorgeschlagenen Lösung verbunden. Der einzig wesentliche Unterschied dürfte in der Verwendung des Hydra-Vokabulars bestehen.

[sterni24]

@akuckartz Wer bestimmt die itemsPerPage? Was beinhaltet member, eine IRI-Liste oder eine Auflistung der Objekte mit den einzelnen Eigenschaften?

[akuckartz]

@sterni24 itemsPerPage wird vom Server bestimmt. Eine standardisierte Möglichkeit zur Äußerung von Wünschen durch Clients ist bisher nicht vorgesehen. Ich gehe davon aus, dass das noch kommen wird - vermutlich aber nicht rechtzeitig für OParl 1.0.

member ist eine Eigenschaft deren Werte JSON-LD Objekte sind. Dies ist ein Beispiel aus der Hydra-Spezifikation:

  "member": [
    {
      "@id": "/comments/429"
    },
    {
      "@id": "/comments/781",
      "title": "Properties may be embedded directly in the collection"
    },
    ...
  ]

Für OParl ist nur @id ZWINGEND. @type sollte aber meiner Meinung ebenfalls als ZWINGEND oder zumindest SOLL aufgenommen werden. Von der Lieferung anderer Eigenschaften durch Server können wir explizit abraten, sollten dies aber nicht absolut ausschliessen.

[sterni24]

@akuckartz Dann muss der Client die Objekte gemäß member einzeln nachlesen? Das wäre nicht sehr performant!

Bekomme der Client auch ohne Paging, weil totalItems <= itemsPerPage, auch eine memberlist?

[akuckartz]

@sterni24 Wir haben an mehreren Stellen das grundsätzliche Problem, dass der Server je nach Bedarf des Clients zu viel oder zu wenig Daten schickt. Auch deshalb mein Interesse an Linked Data Fragments (#165).

Wenn es zu wenig (< 100) Elemente einer Eigenschaft gibt, dann wird nicht auf eine separate Objekt-Liste verwiesen, sondern alle Elemente (jeweils nur die URL) werden zwischen [ und ] ausgegeben. Das ist der "normale" Weg mit JSON-LD ohne Paging.

Ein Extremfall: Ein Client merkt sich die URL einer langen Objekt-Liste (> 100), dann werden auf dem Server alle oder fast alle Elemente gelöscht und danach greift der Client auf die URL zu. Die Objektliste wäre dann schlicht kurz und würde in eine "Page" passen.

[akuckartz]

Hier gibt es aus meiner Sicht nichts mehr zu tun.