Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paging Problematik #172

Closed
akuckartz opened this issue May 29, 2014 · 12 comments
Closed

Paging Problematik #172

akuckartz opened this issue May 29, 2014 · 12 comments

Comments

@akuckartz
Copy link
Contributor

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.

@akuckartz akuckartz added this to the 1.0 Freigabe milestone May 29, 2014
@sterni24
Copy link
Contributor

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

@akuckartz
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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

@akuckartz
Copy link
Contributor Author

@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
Copy link
Contributor

@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
Copy link
Contributor Author

@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
Copy link
Contributor Author

Hier gibt es aus meiner Sicht nichts mehr zu tun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants