search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

Eigenschaften als URL-Parameter für alle OParl-Objekte #174

Closed sterni24 closed 10 years ago

sterni24 commented 10 years ago

Um gezielte Abfragen bestimmter Daten vorzunehmen, halte ich es für sinnvoll die Liste der reservierten URL-Parameter (siehe Spezifikation 4.13) um weitere objektspezifische Parameter zu erweitern.

Für die Implementierter bedeutet dies keinen nennenswerten Mehraufwand.

Beispiel: Abfrage aller oparl:Meetings für ein Gremium ab einem Startdatum "https://oparl.ratsinfo.de/body/0/meeting/?organization=13&startdate=2014-01-01"

akuckartz commented 10 years ago

Das ist genau die Art von "Abfragesprache" deren schleichende Einführung ich nach dem Beschluss zur Einführung der startdate- und enddate-Parameter bereits befürchtet hatte (ein Grund weshalb ich diese nicht begrüßt habe). Ich bin nicht begeistert von einem Vorgehen, bei dem nach und nach Teile einer solchen "Abfragesprache" spezifiziert und dann natürlich auch implementiert, getestet und validiert werden müssen.

(Was den Aufwand betrifft: Ich finde es in jeder Hinsicht einfacher schlicht eine SPARQL 1.1-Schnittstelle zum Bestandteil von OParl zu machen. Dennoch würde ich eher eine Umsetzung von #165 befürworten - wobei auch dafür das Problem besteht, dass die bis zur Freigabe von OParl 1.0 vorgesehene Zeit knapp ist !)

akuckartz commented 10 years ago

Siehe auch #176

akuckartz commented 10 years ago

Für das Beispiel "Abfrage aller oparl:Meetings für ein Gremium ab einem Startdatum" würde nur der Parameter startdate benötigt, wenn die meeting-Eigenschaft des Objekts für das Gremium auf "etwas" zeigt was mit dem Parameter startdate aufgerufen werden kann.

Ein Problem dabei: Bei einer oder wenigen Sitzungen sind die Werte einzelne Sitzungen und nur wenn es ein Link auf eine Liste ist, dann könnte der Parameter bei der Zusammenstellung der Elemente der Liste berücksichtigt werden. Möchte man dann prophylaktisch auch bei einer einzelnen Sitzung den Parameter anhängen? Denn nach aktuellem Stand der Spezifikation sind ein Link auf eine einzelne Sitzung und ein Link auf eine Liste von Sitzungen erst nach einem Zugriff darauf zu unterscheiden. Das würde zu unschönem IRI-/Parameter-Wildwuchs führen.

Eine denkbare Lösung bestünde ich der Ergänzung alternativer Eigenschaften wie meetingList, die (nur) für Links auf Listen verwendet werden. Dies würde aber aufgrund der betroffenen Eigenschaften zu erheblicher zusätzlicher Komplexität führen. Diese Problematik wird auch in der Hydra-Community diskutiert: Siehe https://github.com/HydraCG/Specifications/issues/41 und https://www.w3.org/community/hydra/wiki/Avoid_that_collections_%22break%22_relationships

sterni24 commented 10 years ago

Den ersten Satz verstehe ich nicht. Bitte zeigen Sie mir folgenden Lösungsweg auf: Ein Client möchte für ein Gremium, dessen ID ihm bereits bekannt ist, alle zukünftigen Termine auslesen. Wie sieht die Anfrage an den Server und wie sieht das Ergebnis in JASONP aus?

akuckartz commented 10 years ago

@sterni24 Die Aussage ist im ersten Satz ist nur, dass zur Angabe des Gremiums kein Parameter verwendet oder vorgesehen werden muss, da es selbst durch eine URL (bzw. IRI) identifiziert und zugreifbar ist. Vom Server muss das JSON-LD-Objekt für das Gremium geholt werden. Und wenn das Gremium eine meeting-Eigenschaft hat, dann kommt man darüber an die Sitzungen. Der Rest des Kommentars geht auf ungelöste Probleme bzgl. der Werte der Eigenschaft sowie Filterung und Paging ein. JSONP hat darauf keine Auswirkung.

sterni24 commented 10 years ago

@akuckartz Genau so habe ich mir das nicht vorgestellt!

Ein Client zieht sich ein Gremium und bekommt in diesem Objekt eine Objektliste aller Termine. Nun darf sich der Client aus einer Liste von z. B. 76 Einträgen die 4 zukünftigen Termine ermitteln. Siehe auch #167.

Wenn ich das richtig verstanden habe, müssen hier 76 Anfragen an den Server gesendet und die Ergebnisse vom Client geprüft werden. Das wäre wohl nicht im Sinne der OParl-Erfinder, oder?

marians commented 10 years ago

Ein Zwischen-Feedback: @akuckartz und ich haben uns am vergangenen Freitag über das Problem ausführlicher ausgetauscht.

Aktuell ist es so, wie Sie (@sterni24) schreiben. Der Client müsste das entsprechende oparl:Organization Objekt haben oder abrufen. Über die Eigenschaft meeting käme der Client an alle Sitzungen der Gruppierung. Ist diese Liste kurz, kann der Server sie "inline", also direkt im Objekt ausgeben. Ist sie lang, sollte sie über eine eigene URL abrufbar sein. Um das Datum der jeweiligen Sitzung herauszufinden, müsste der Client jedes einzelne Objekt abrufen. (Das ist auch aus meiner Sicht unbefriedigend.)

Wie könnte es besser funktionieren? Hier ein paar Ausführungen, die auf dem aufsetzen, was wir bisher haben.

Für die "inline"-Ausgabe der Sitzung-URLs direkt im oparl:Organization-Objekt fällt mir keine Möglichkeit ein, die Liste durch den Client einzuschränken.

Bei der Ausgabe der Sitzungen-Liste über eine eigene URL wäre es dagegen recht einfach, eine Einschränkung durch den Client vorzusehen. Man könnte hierzu beispielsweise die schon vorgesehenen URL-Parameter startDate und endDate verwenden, die sich bei der Abfrage auf den Sitzungszeitpunkt beziehen würden. Diese Abfragemöglichkeit könnte per Spezifikation für alle Listen, die oparl:Meeting Objekte enthalten, vorgesehen werden. In diesem Fall müsste das sogar besonders performant sein, da das Abfragekriterium und das Sortierkriterium (Sitzungstermin) identisch sind.

Nun ist noch dafür zu sorgen, dass der Server diese Listen, die eine dynamische Abfrage ermöglichen sollen, ZWINGEND über eine eigene URL anbietet. Damit vermeidet man, dass der Server die Liste "inline" ausgibt und damit die Abfragemöglichkeit nicht greift.

Damit wäre für mich der Anwendungsfall "Sitzungen einer bestimmten Gruppierung in einem bestimmten Zeitraum abrufen" für mich befriedigend gelöst.

Weiterhin ist zu klären, welche derartigen Abfragemöglichkeiten noch benötigt werden. Ich bin bislang der Auffassung, dass wir Server-Implementierern einen Gefallen tun, wenn wir hier nur eine stark begrenzte Flexibilität einfordern. Schließlich muss jede einzelne Eigenschaft, nach der performant gefiltert werden soll, Server-seitig irgend eine Art von Index haben.

akuckartz commented 10 years ago

Ich verschiebe dieses Issue auf die Zeit nach 1.0. Die Erfüllung der Anforderung wird dann voraussichtlich auf allgemeinere Weise mittels Linked Data Fragments erfolgen können (#165).

Die Verwendung der URL-Parameter startDate und endDate für Listenobjekte gehört zu #176.

akuckartz commented 10 years ago

Aufgrund der Diskussionen in den letzten Tagen behandele dieses issue unter dem Milestone "JSON-LD Version" als Anwendungsfall von #165 weiter. Es hat für mich auch eine höhere Priorität.

marians commented 10 years ago

Speziell für den Anwendungsfall "Sitzungen eines bestimmten Gremiums", auf Wunsch auch mit Beschränkung mit startDate und/oder endDate, ist dies im Entwurf für 1.0 gelöst. Ich schließe daher das Issue.