Objektlisten um optionale "vollständige Ausgabe" erweitern

[marians]

Bei der Ausgabe von Objektlisten über eine eigene URL, also nicht im Kontext eines einzelnen Objekts, geben wir laut aktuellem Stand der Specs grundsätzlich nur URLs von Objekten aus. Eine Liste von oparl:Meeting Objekten kann nach diesem Prinzip so aussehen:

[
    "https://oparl.beispielris.de/meeting/1",
    "https://oparl.beispielris.de/meeting/2",
    ...
]

Ungünstig ist, dass diese Liste keinerlei nutzerfreundliche Informationen bietet, die ein Client einem Nutzer anzeigen könnte. Um derartige Informationen wie den Titel der Sitzung oder den Termin zu bekommen, müsste der Client zunächst jedes einzelne Objekt mit einem eigenen Request abrufen.

Ich schlage daher eine "vollständige Objektausgabe" in Listen vor. Diese könnte für das obige Beispiel so aussehen:

[
    {
        "type": "http://oparl.org/schema/1.0/Meeting",
        "id": "https://oparl.beispielris.de/meeting/1",
        "name": "1. Sitzung des Hauptausschusses",
        "start": "2014-03-01T08:00:00+01:00",
        "organization": "https://oparl.beispielris.de/organization/1",
        "participant": "https://oparl.beispielris.de/participants_of_meeting/1",
        "invitation": "https://oparl.beispielris.de/document/1",
        "agendaItem": "https://oparl.beispielris.de/agendaitems_of_meeting/1",
        "created": "2014-01-06T12:01:00+01:00",
        "modified": "2014-01-08T14:05:27+01:00"
    },
    {
        "type": "http://oparl.org/schema/1.0/Meeting",
        "id": "https://oparl.beispielris.de/meeting/2",
        "name": "2. Sitzung des Hauptausschusses",
        "start": "2014-04-01T08:00:00+01:00",
        "organization": "https://oparl.beispielris.de/organization/1",
        "participant": "https://oparl.beispielris.de/participants_of_meeting/2",
        "agendaItem": "https://oparl.beispielris.de/agendaitems_of_meeting/2",
        "created": "2014-02-06T12:01:00+01:00",
        "modified": "2014-02-08T14:05:27+01:00"
    },
    ...
]

"Vollständig" bedeutet, dass anstelle der URL des Objekts das gesamte Objekt mit allen Schlüsseln, die auch über den direkten Abruf des einzelnen Objekts ausgegeben würden, ausgegeben wird.

Der Client aktiviert die vollständige Objektausgabe über einen URL-Parameter. Wie der heißen könnte, wäre noch zu definieren. Ist der Parameter nicht angegeben, wird die kompakte Liste mit URLs ausgegeben.

Die vollständige Objekttausgabe kann nur für Listen aktiviert werden, die über eine eigene URL abgerufen werden. Beim Abruf von einzelnen Objekten mit darin eingebetteten Listen als Werten von Eigenschaften ist das nicht möglich.

Die Unterstützung der vollständigen Objektausgabe in Listen würde ich als ZWINGEND deklarieren.

[akuckartz]

Diesem Issue liegt ein weiteres Problem zu Grunde, welches mit #165 erledigt werden kann.

[marians]

@akuckartz Du sprichst in Rätseln.

[akuckartz]

@marians

1. Es gibt mehrere Issues, die damit zu tun haben, dass je nach den Umständen zu viel oder zu wenig Daten übertragen werden. Linked Data Fragments (LDF) ist eine Lösungsmöglichkeit dafür.
2. Die bisherigen Objektlisten kann man als Antworten auf SPARQL-Queries dieser Art ansehen:

SELECT ?object
WHERE {
   <ein Subjekt> <eine Eigenschaft> ?object .
}

Damit ist dies bereits der Hauptteil eines Linked Data Fragment.

Der Vorschlag in diesem Issue würde etwas einführen was Antworten auf dieses Query entspricht:

SELECT ?object ?property ?value
WHERE {
   <einSubjekt> <eine Eigenschaft> ?object .
   ?object ?property ?value .
}

Solche Queries können bei Verwendung von LDF in LDF-Abfragen zerlegt werden (Anzahl abhängig von der Anzahl der Properties von ?object). In diesem Issue wird eine Teilmenge einer Abfrage-Sprache vorgeschlagen, die fast so "komplex" ist wie LDF, aber weniger leistungsfähig.

Dieses Feature mag für eine JSON-Ausgabe sinnvoll sein oder nicht, für eine JSON-LD Ausgabe halte ich es nicht für eine sinnvolle Alternative zu LDF.

[sterni24]

Den Vorschlag von @marians unterstütze ich voll und ganz, weil dadurch sowohl für den Server-Implementierer als auch für den Client vieles einfacher, flexibler und vor allem performanter wird.

Anm.:
Wir hätten uns dadurch viele Diskussionen ersparen können, ob z. B. eine meeting-Auflistung in das Objekt oparl:Organization hinein gehört oder nicht.

[marians]

Dieser Vorschlag ist inzwischen ins Dokument eingeflossen. Ich schließe das Issue.