Feeds / Streams

[akuckartz]

Wie werden neue Informationen bekannt gemacht? Atom Feeds?

Beispiele:

• Feed für Änderung der Zusammensetzung eines Gremiums
• Feed für neue Tagesordnungen eines Gremiums

[marians]

Solche Feed-ähnlichen Abfragen (also sortiert nach "letzte Änderung") muss es in jedem Fall geben. Da wir die API-Ausgabe grundsätzlich auf JSON aufbauen wollen, sollten auch diese Methoden JSON zurück liefern. Darüber hinaus sollte es möglich sein, die Rückgabe zu blättern, um mehr als nur eine festgelegte Anzahl von Einträgen abzurufen.

[akuckartz]

Siehe also auch issue #12

[akuckartz]

Workshop: SHOULD Feeds für neue, geänderte, gelöschte/zu löschende Objekte. Ein Problem ist, dass bisher häufig weder alle Objekte entsprechende Zeitstempel haben noch gelöschte Objekte zu ermitteln sind.

[akuckartz]

Wenn man die Objekte nach einem per Parameter angebbaren Zeitpunkt liefern kann, dann kann man dabei auch alle Objekte ohne Zeitstempel mit übermitteln. Oder man schafft auch Feeds für solche Objekte, für die im RIS keine geeigneten Zeitstempel vorhanden sind.

Damit bekommt man dann auch vollständige Daten Dumps hin.

Der obligatorische Hinweis auf ein paar möglicherweise relevante Standard(-Entwürfe) darf nicht fehlen (Eselsohr für mich):

JSON Activity Streams 2.0
draft-snell-activitystreams-05
http://tools.ietf.org/html/draft-snell-activitystreams-05

The Atom Syndication Format
http://tools.ietf.org/html/rfc4287

The Atom Publishing Protocol
http://tools.ietf.org/html/rfc5023

[marians]

Der Refserver gibt nun die drei Feeds in der einfachsten denkbaren Form aus.

http://refserv.oparl.org/feeds/new/
http://refserv.oparl.org/feeds/updated/
http://refserv.oparl.org/feeds/removed/

Das Ausgabeformat ist jeweils eine Liste von IRIs/URLs. Paginierung ist da noch nicht berücksichtigt.

Zweck der Feeds ist ja die Cache-Aktualisierung auf Seite des Clients.

Im Fall von "removed" reicht das nach meiner Einschätzung aus. Der Client kann die URL nutzen, um das Objekt aus seinem Cache zu entfernen.

Bei "new" reicht die URL wahrscheinlich ebenfalls aus, denn der Client kann einfach in seinem Cache nachsehen, ob er die URL schon hat. Wenn nicht, wird er ohnehin das ganze Objekt abrufen wollen.

Bei "updated" reicht es nach meiner Ansicht nicht aus, nur die URL des Objekts zu nennen, denn dann müsste der Client das Objekt immer wieder abrufen, um z.B. am last_modified Datum zu sehen, ob seine Version im Cache die selbe ist wie auf dem Server. Daher denke ich, wir sollten fordern, dass mit jedem Eintrag in der Liste zur URL auch das last_modified Datum ausgeben werden muss. Beispiel:

[
    {
        "@id": "http://refserv.oparl.org/bodies/0/meetings/0",
        "last_modified": "2014-01-12T14:28:31+0100"
    },
    {
        "@id": "http://refserv.oparl.org/bodies/0",
        "last_modified": "2014-01-08T14:00:00+0100"
    },
    ...
]

[bschalitz]

Soll dann ein RSS-Feed im herkömmlichen Sinne im XML Format werden? Oder ist das einfach eine Abfrage über Neuigkeiten, die man an den Server stellt.

Wenn es eine Abfrage ist, könnte man doch einfach das Datum seiner letzten Abfrage mitschicken, dann muss der Server gar nicht wieder und wieder die Liste der Update/Remove und Inserts der letzten zehn Jahre schicken. Es ist durchaus Bewegung in den Daten des RIS. Mir stellt sich auch die Frage, ob der Cleint nicht genau sagen sollte welche Objektart ihn interessiert.

Reicht es wenn die URL eines bereits entferten Objektes melde, Objekt nicht mehr im Bestand, oder mussen die Eigenschaften des Objekts noch verfügbar sein.

[marians]

Aus meiner Sicht brauchen wir keinen RSS oder Atom Feed, sondern sollten ein Format wählen, das möglichst nah an den restlichen Ausgaben der API korrespondiert. Also JSON (bzw JSON-LD bzw. JSONP).

Die Möglichkeit, die Feeds mit einer unteren Datumsgrenze abzufragen, finde ich interessant. Allerdings ist zu bedenken, dass der Client auch ein Datum wählen kann, das sehr weit in der Vergangenheit liegt. In diesem Fall wäre es praktisch das gleiche, ob man ohne Datumsgrenze abgefragt hat oder mit. Es wird also auch noch eine Limitierung bzw. Paginierung der Ausgabe geben müssen (vgl. #66 ).

Eine Einschränkung nach Objektart ist eine gute Möglichkeit, die Anfrage so ressourcenschonend wie möglich zu gestalten. Das finde ich richtig.

Bei entfernten Objekten reicht aus meiner Sicht tatsächlich die URL.

[bschalitz]

Das der Client ein Datum weit in der Vergangenheit wählen kann ist natürlich technisch möglich. Aber immer noch besser als keins vorzusehen.

Im Prinzip müssten genau aus diesem Grund die Veränderungsinformationen ja quasi auch ewig aufbewahrt werden. Da ja immer mal mal wieder ein "lange" nicht aktualisierte Client auftauchen könnte.

Vielleicht wäre es zulässig eine Grenze festzulegen z.B. 5 Jahre (vom Implementierer?) ab wann man mit einer Api-Fehlermeldung antwortet. Dann muss der Cleint seinen Cache eventuell verwerfen oder anderes angemessen reagieren.

[marians]

Ja, ich denke, das ist sinnvoll. Wir können nicht erwarten, dass der Server ins unendliche wachsende Logs bereit hält.

[akuckartz]

Ich halte die Datenmenge für solche "Logs" angesichts der Entwicklung der Speicherpreise für unproblematisch.

Einen Ansatz, den wir in der Arbeitsgruppe des Workshops überlegt hatten verzichtet vollständig auf die explizite Parameter-Übergabe von Zeitpunkten und bietet stattdessen Logs für feste Zeitabschnitte über IRIs mit einem definierten Aufbau an, z.B.

https:/..../2013/

für alles aus dem Jahre 201, oder

https:/..../2013/05

für alles aus dem Mai 2013. Dabei kann ein Zugriff auf eine Jahres-IRI eine Liste von Monats-IRLs liefern und diese Tages-IRIs.

Mit

 https:/..../

würde man alle jahres-IRIs erhalten. (Das wird auch in 1000 Jahren noch funktionieren :-)

Datumsgrenzen gibt es dann implizit. Ein Vorteil ist, dass damit ein Caching auf Server-Seite vereinfacht wird und es eine hohe Trefferwahrscheinlichkeit gibt.

Inzwischen frage ich mich, ob man das "Löschen" von Objekten / Dokumenten wie eine "normale" Änderung behandeln kann. Die entsprechen IRIs würden danach nicht ins Leere verweisen (also einen 404-Fehler ergeben), sondern einen geeigneten Fehlerinhalt liefern (der noch festzulegen wäre). Dies entspricht auch besser der grundsätzlichen Forderung nach persistenten IRIs. Ein separater removed Stream kann dann entfallen.

[marians]

Hier habe ich mehrere Anmerkungen.

• URLs: Wir sollten den Server-Implementierern so wenig wie möglich Vorgaben in Bezug auf die URL-Gestaltung machen. Die einzige Anforderung, die wir aktuell diesbezüglich haben, ist dass ein paar reservierte Namen als URL-Parameter eine feste Bedeutung haben (callback, startdate, enddate). Was die Datums-Einschränkung betrifft, haben wir uns beim Workshop in Bielefeld darauf geeinigt, dass man bei Drucksachen und Sitzungen per URL-Parameter das Anfangs- und Enddatum unabhängig von einander einschränken können soll. Das würde mit einer Datums-URL-Struktur nicht funktionieren. Ich bin dafür, dass wir das Parameter-Schema (allerdings einseitig, nämlich auf einen Start-Zeitpunkt beschränkt), auch für die Feeds einsetzen.
• Längenbeschränkung: Ich finde es einleuchtend, dass wir mit OParl von begrenzten Ressourcen bei allen Beteiligten, auch auf Serverseite, ausgehen. Speicherpreise mögen stetig sinken. Trotzdem ist es grundsätzlich sinnvoll, sich die Frage zu stellen, wie die eigentliche Anforderung aussieht. Hier geht es ja nicht um eine Nachvollziehbarkeit aller Änderungen bis in die unbegrenzte Vergangenheit, sondern lediglich um die effiziente Invalidierung eines Caches.
• Entfernen vs. Ändern: Entfernung bzw. Depublikation eines Dokuments haben in der Praxis oft durchaus eine besondere Bedeutung. Denn wenn ein Dokument, das vorher als öffentlich deklariert war, plötzlich nicht mehr öffentlich sein soll, steht dahinter z.B. ein Urheberrechtsanspruch oder ein Beschwerde wegen Datenschutzverletzung. Insofern würde ich als Betreiber eines Caches den Feed für Löschungen evtl. häufiger abfragen als die anderen Feeds. Darüber hinaus sehe ich den Unterschied, dass - wie schon oben geschrieben - bei Entfernung die URL ausreicht. Ob es bei Änderungen ebenfalls ausreicht, die URL auszugeben, ist ein offener Punkt.
• HTTP-Status für entfernte Dokumente: Für Dokumente, die es mal gab, sollte der Server bei Aufruf der URL mit dem HTTP Status Code 410 ("Gone") antworten. Das gilt sowohl für die URL des JSON-Objekts als auch für die Datei.

[akuckartz]

RFC 2616 (http://tools.ietf.org/html/rfc2616) zum 410 (Gone) status code, finde ich gut:

10.4.11 410 Gone

The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be
considered permanent. Clients with link editing capabilities SHOULD
delete references to the Request-URI after user approval. If the
server does not know, or has no facility to determine, whether or not
the condition is permanent, the status code 404 (Not Found) SHOULD be
used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the
discretion of the server owner.

[akuckartz]

@marians Bei der Zielsetzung "den Server-Implementierern so wenig wie möglich Vorgaben in Bezug auf die URL-Gestaltung machen" sind wir uns vollkommen einig.

Der Parameter callback für JSONP ist unproblematisch, da dies nur den Datentransport betrifft, aber nicht den Inhalt der angeforderten Daten.

Die beiden Parameter für Anfangs- und Enddatum betreffen aber den Inhalt. Ich suche nach einer Alternative, die im Ergebnis genau das selbe erreicht, aber die beiden Parameter nicht benötigt. Sie wäre zwar möglicherweise mit etwas mehr Aufwand auf Client-Seite verbunden, aber nicht viel. Und Paging muss ja ohnehin vorgesehen werden.

Eine Spezifikation einer Datums-URL-Struktur ist überhaupt nicht erforderlich. Man muss nur über eine Einstiegs-URL an eine Liste weiterer (zeitlich sortierter) URLs für kürzere Zeiträume kommen. Festlegen könnte man allerdings, dass jeweils IRIs für je ein Kalenderjahr, einen Kalender-Monat bzw. einen Kalender-Tag angeboten werden müssen. Wenn zudem jeweils der Zeitraum vom Server mitgeliefert wird, dann bekommt der Client sämtliche Daten, die er benötigt - und für keinen Tag mehr !

[akuckartz]

@marians Wenn ich das richtig verstehe, dann ist der eigentliche Unterschied zwischen den beiden Streams nicht zwischen Entfernen und Ändern sondern zwischen dringend und weniger dringend. Es kann ja auch dringende normale Änderungen von Daten geben, z.B. bei einer Orts- oder Zeitangabe einer zukünftigen Sitzung - oder auch deren Absage.

[akuckartz]

RFC 5005 ist auch relevant:

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

[marians]

Inwiefern ist RFC5005 relevant?

[akuckartz]

Inwiefern ist RFC5005 relevant?

Insofern als es ein Standarddokument ist, in dem es auch um das Paging von Feeds geht. Allerdings kommt (im Gegensatz zu den Vorschlägen zu Paging von Hydra bzw. der Linked Data Platform) eine 1zu1-Übernahme offensichtlich nicht in Frage.

[marians]

Info aus dem Workshop vom 26.3.2014: Alle drei feeds (deleted, new, modified) sind EMPFOHLEN, aber nicht ZWINGEND.

[marians]

Der Abschnitt zu Feeds ist inzwischen im Dokument ausformuliert. Siehe Kapitel 4.8 bzw. https://github.com/OParl/specs/blob/master/dokument/master/chapter_6070.md . Dieses Issue schließe ich daher.

Es gibt eine Veränderung gegenüber dem Stand in diesem Thread. Nach weiterer Überlegung habe ich im Dokument bei allen drei Feeds die Ausgabe des jeweils relevanten Datums empfohlen. Also Erstellungs-, Bearbeitungs bzw. Löschungszeitraum.

Sollte es dazu noch eine Kontroverse geben, bitte das Issue wieder öffnen und kommentieren.