Dokumentation | Code-Beispiele mit ../vocab/..

[sterni24]

Was muss der Serverimplementierer tun, um solche URL anwenden zu können? Beispiel: "https://oparl.example.org/vocab/message". Hier fehlt ein allgemeiner Beschreibungsteil in der Doku.

[marians]

Ihr Beispiel stammt aus dem Abschnitt Objektlisten / Kompakte und vollständige Form. Wenn eine solche URL an der Stelle Fragen aufwirft, wäre es unter Umständen besser, das JSON-Beispiel dort nicht mit einer URL, sondern mit einem einfachen String zu versehen. Die Entsprechung könnte "Mitteilung" lauten.

Das eigentliche Konzept hinter den URLs in Eigenschaften wie paperType wird im Abschnitt "Vokabulare zur Klassifizierung" erläutert. Ob "classification" im Objekttyp oparl:Organization oder "paperType" in oparl:Paper, die dort genannten Eigenschaften funktionieren alle auf die gleiche Art und Weise: Sie können als Wert entweder einen String oder eine URL haben. (In einigen Fällen sind Arrays gefordert, d. h. die Eigenschaft muss analog als Wert ein Array von Strings oder URLs haben.)

Wenn Sie Sich für URLs entscheiden wollen, dann ist das zu tun: Sie müssen entweder selbst auf einem Webserver Ihrer Wahl die berühmten skos:Concept Objekte ablegen. Oder Sie nutzen Alternativ die URLs von skos:Concept Objekten, die jemand anderes für diesen Zweck bereits auf einem öffentlichen Webserver hinterlegt hat.

Wenn Sie also beispielsweise eine Drucksache mittels URLs klassifizieren wollen, könnten Sie auf einem Server Ihrer Wahl die folgenden Dateien anlegen:

http://beispielserver.de/oparl/vokabeln/mitteilung.jsonld
http://beispielserver.de/oparl/vokabeln/anfrage.jsonld
http://beispielserver.de/oparl/vokabeln/antrag.jsonld
....

Wie der Inhalt dieser Dateien beschaffen sein muss, ist in "Vokabulare zur Klassifizierung" beschrieben.

Diese URLs könnten Sie dann als Wert für die Eigenschaft "paperType" einsetzen.

Für die sich anschließende Frage, warum sie das tun sollten: Das dient dazu, auf verschiedenen Systemen das selbe Vokabular zu benutzten. Wenn in A-Stadt und B-Ort jeweils der paperType "Antrag" ausgegeben wird, sieht das zwar identisch aus, man weiß aber nicht, ob das zufällig ist oder wirklich dasselbe gemeint ist. Verwendet man jedoch in beiden Städten dieselbe URL, kann es sich nicht um einen Zufall handeln.

Perspektivisch könnte OParl auch solche Objekte/Dateien/URLs für Vokabeln zur Verfügung stellen. Aber das ist ein anderes Projekt.

Halten Sie vor diesem Hintergrund die Beschreibung im Abschnitt "Vokabulare zur Klassifizierung" für ausreichend und verständlich, oder besteht da Bedarf für Nachbesserung?

[sterni24]

Das fällt für mich unter das Thema Standardisierung von OParl-Eigenschaften. Wenn jeder Server-Implentierer hier anfängt, eigene Dinge zu entwicklen, wird es unüberschaubar.

Die Aussichten einer Standardisierung haben sie ausreichend erläutert. Ich würde die Möglichkeit der Nutzung dieser externen URLs aus dem OParl 1.0 rausnehmen.

[marians]

Ich rechne ja auch nicht damit, dass alle nun sofort anfangen, ihre eigenen Vokabulare zu hosten. Der Standardfall wird anfangs sicherlich sein, dass der Server einfache Strings ausgibt. Entspechend sollten wir evtl. darauf achten, in den Beispielen wo möglich von URLs zur Klassifizierung abstand zu nehmen und diese nur im Sonderfall einzusetzen.

Aber warum würden Sie die Möglichkeit, mit URLs zur Klassifizierung zu arbeiten, aus OParl 1 rauslassen? Wegen der Verständlichkeit?

Der Vorteile davon, die URLs für die Klassifizierung jetzt zu integrieren, wäre der, dass wir unabhängig von der weiteren Standard-Entwicklung (die ja ein bisschen dauern kann, wie wir sehen) am Vokabular arbeiten können. Wir können also sukzessive URLs/Vokabeln, z.B. für Drucksachen-Typen, bereitstellen, bevor die nächste OParl-Version verabschiedet wird.

[akuckartz]

@sterni24

Ich würde die Möglichkeit der Nutzung dieser externen URLs aus dem OParl 1.0 rausnehmen.

Was ist mit "extern" gemeint? Dass in den URLs andere Domains als die des RIS verwendet werden? Wozu diese Einschränkung? Dann müsste jede Körperschaft ihr eigene Begriffsmenge betreiben. Was wäre damit gewonnen? Die Unübersichtlichkeit würde dadurch nur noch größer, nicht kleiner.

[marians]

Ich verstehe unter "externen URLs" die Verwendung einer URL anstelle eines einfachen Strings.

[sterni24]

Zu Absatz 1: sehe ich auch so, ohne Sonderfälle

Zu Absatz 2: ich würde für die OParl 1.0 saubere Abgrenzungen vornehmen.

Zu Absatz 3: wenn es hier einmal Standardisierungen geben wird, dann würde ich so etwas für eine Version 1.1 oder 1.2 vorsehen. Das kann doch erst nach Freigabe einer solchen Spezifikation in den Server-Implementierungen entsprechend umgesetzt werden. Oder?

[akuckartz]

Das würde zu einer noch viel größeren und noch dazu erzwungenen Unübersichtlichkeit führen.

(Um auf die Parallelentwicklung hinzuweisen: In OpenGovLD werden einfache Strings für solche Zwecke nicht zugelassen, um eine geringe Redundanz zu erzwingen. Das gilt jedenfalls für Server mit höheren Ansprüchen an die Datenqualität.)

[sterni24]

@akuckartz externe URLs sind für mich Pfade, die nicht zu den festgelegten Objekten von OParl zählen. In diesem Zusammenhang meinte ich die "../vocab/.."-URLs.

[akuckartz]

Das kann doch erst nach Freigabe einer solchen Spezifikation in den Server-Implementierungen entsprechend umgesetzt werden. Oder?

Das ist einfach. Eine Menge von skos:Concept kann jederzeit völlig unabhängig von OParl, OpenGovLD oder irgend jemand sonst erstellt und angeboten werden. Also auch z.B. von Städte- und Gemeindetag o.ä. Eine Kopplung an OParl Versionen o.ä. ist damit nicht verbunden - muss es jedenrfalls nicht sein.

[marians]

Das kann doch erst nach Freigabe einer solchen Spezifikation in den Server-Implementierungen entsprechend umgesetzt werden. Oder?

Das sehe ich nicht so. Wir können in der OParl Spezifikation (Version 1.0) den Mechanismus beschreiben, und dann irgendwann - unabhängig vom Lebenszyklus der Spezifikation, ein Vokabular veröffentlichen. Das muss nicht teil einer neuen Spezifikations-Version sein.

Möglicherweise kommt uns aber auch jemand anderes zuvor und macht sich die Mühe - dann müssten wir das von OParl nicht mehr tun. Oder beispielsweise ein Bundesland empfiehlt seinen Kommunen die Verwendung eines einheitlichen maschinenlesbaren Vokabulars, möchte aber damit nicht auf uns oder andere angewiesen sein und entwickelt lieber in einer Arbeitsgruppe ein eigenes.

Wenn eine bestimmte Kommune jetzt schon mustergültig sein will, was Vokabulare betrifft, kann sie sich auch jetzt sofort ihr ganz eigenes entwickeln und dieses einsetzen, sobald ihr OParl Server läuft.

Egal, mit welchem Vokabular irgendwer irgendwann herauskommt, folgendes ist relativ sicher: Es wird nicht jeden glücklich machen. Einzelne Begriffe werden irgendwo nicht passen. Daher ist es gut, wenn man verschiedene Vokabulare kombinieren kann. Wenn Immekepeln unter einem "Dringlichkeitsantrag" unbedingt etwas anderes verstehen will als Bottrop, dann macht Immekeppeln eben dafür eine eigene Vokabel. Das lässt sich ja kombinieren.

Das System ist also ziemlich offen für verschiedenste Szenarien. Wir sollten nur darauf achten, dass es nicht kompliziert dargestellt wird.

[sterni24]

Das würde zu einer noch viel größeren und noch dazu erzwungenen Unübersichtlichkeit führen.

Solange es hier keinen OParl-Standard gibt, gilt das für Ihr System mehr als für OParl 1.0.

[akuckartz]

Ich stimme dem Kommentar von @marians vollständig zu. Genau das ist es worum es hier geht.

Es wird eine Grundlage zu Vereinheitlichungen geschaffen, nicht eine konkrete Vereinheitlichung selbst. Solche Vereinheitlichungen können dann unabhängig und mit eigenem Zeitplan etc. geschaffen werden.

[sterni24]

Was muss denn ein Server-Implementierer tun, damit er diese Vocabs einsetzen kann?

[akuckartz]

@sterni24 Wenn ein solches Vokabular bereits existiert (unter welchen URLs auch immer), dann muss eIn Server-Implementierer nur die URLs der jeweiligen skos:Concept-Objekte verwenden. Das ist bereits alles!

[sterni24]

Wer hat diese Objekte angelegt?

[akuckartz]

@sterni24 Das kommt ganz drauf an. Solche Objekte können z.B. auf sitzungsdienst.net oder stadt-koeln.de oder nrw.de oder govdata.de von den Betreibern dieser Server angeboten werden. Oder z.B, ein Dienstleister oder Verein bietet solche Objekte in 30 Sprachen an (denn SKOS unterstützt von sich aus Mehrsprachigkeit).

Das mag zunächst nach Unübersichtlichkeit aussehen, aber es würde einen immensen Fortschritt bei der Vereinheitlichung bedeuten.

Wenn noch kein geeignetes Vokabular existiert und ein bestehendes RIS mit einer solchen Schnittstelle ausgerüstet werden soll, dann ist der Aufwand gut überschaubar: Statt z.B. einer Zeichenkette "Mitteilung" für die Art einer Drucksache müsste jeweils die URL des entsprechenden skos:Concept-Objekts ausgegeben werden - und dieses Objekt kann auf dem selben Server angeboten werden.

Wichtig vielleicht noch: Ein RIS-System kann bei Bedarf von einem Augenblick zum nächsten oder auch allmählich auf ein anderes Vokabular wechseln. Das wäre in technischer Hinsicht völlig ok.

[sterni24]

Das hört sich alles plausibel an, ist m. E. jedoch sehr praxisfremd. Ich nehme einmal die Eigenschaft oparl:Paper paperType als Beispiel:

Scenario 1: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller kennt die Werte dieser Eigenschaft nicht und legt entsprechend viele Objekte des Typs skos:Concept, die jeder einzelnen Körperschaft zugeordnet wird, an. Bei jedem Datenabgleich muss der RIS-Betreiber die Existenz des skos:Concept-Objekts prüfen und nicht vorhandene Werte speichern.

Scenario 2: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller fängt an, alle Werte dieser Eigenschaft auszulesen und auf RIS-Betreiber-Ebene zu speichern. Hier kommt dann folgendes heraus:

Anfrage
Anfragen
Antrag
Antrag der Fraktion XY
Antraege
Beschlussantrag
Beschlussvorlage
Beschlussvorlagen
Beschlüsse
Bürgerantrag
Bürgeranfrage
Drucksache 
Dringlichkeitsentscheidung
Fraktionsantrag der XY
Mitteilungsvorlage
Sitzungsvorlage
Sitzungsvorlagen
Vorlagen
Tischvorlage

... das ist nur eine kleine Auswahl

Bei jedem Datenabgleich muss der RIS-Betreiber die Existenz seiner skos:Concept-Objekte prüfen und nicht vorhandene Werte speichern.

Scenario 3: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller fängt an, alle Werte dieser Eigenschaft auszulesen und eine einheitliche skos:Concept-Klassifizierung vorzunehmen. Hier kommt dann folgendes heraus:

Anfrage -> Anfrage
Anfragen -> Anfrage
Antrag -> Antrag
Antrag der Fraktion XY -> Antrag
Antraege -> Antrag
Beschlussantrag -> Antrag
Beschlussvorlage -> Beschlussvorlage
Beschlussvorlagen -> Beschlussvorlage
Beschlüsse -> Beschlussvorlage
Bürgerantrag -> Antrag
Bürgeranfrage -> Antrag
Drucksache -> Beschlussvorlage 
Dringlichkeitsentscheidung -> Beschlussvorlage
Fraktionsantrag der XY
Mitteilungsvorlage -> Mitteilungen
Sitzungsvorlage -> Beschlussvorlage
Sitzungsvorlagen -> Beschlussvorlage
Vorlagen -> Beschlussvorlage
Tischvorlage -> Beschlussvorlage

Daraus ergeben sich folgenden skos:Concept-Objekte

Anfrage
Antrag
Beschlussvorlage
Mitteilungen

Der RIS-Hersteller oder RIS-Betreiber muss über eine Tabelle die Klassifizierung vornehmen und stetig auf Vollständigkeit überprüfen. Falls ein skos:Concept-Objekt fehlt, muss dieses zunächst definiert, gespeichert und dann zugeordnet werden.

Scenario 4: Ich verzichte darauf, das Scenario 3 mit mehreren RIS-Betreibern und einer großen Menge von RIS-Betreibern aufzuzeigen. Das wird unüberschaubar.

Scenario 5: Die OParl-Community legt eine einheitliche Klassifizierung für paperType fest. An diese sind alle RIS-Betreiber und RIS-Hersteller gebunden. Die Klassifierzungen der vorhandenen Werte muss zwingend je RIS-Betreiber erfolgen. Ggf. müssen von Zeit zu Zeit weitere skos:Concept-Objekte angelegt und allen RIS-Betreibern zur Verfügung gestellt werden.

Zusammenfassung Aus Client-Sicht sind die Scenarien 1 bis 4 für eine übergreifende Auswertung auf paperType nicht weiter nutzbar. Es leidet nur die Performance.

Aus RIS-Hersteller-Sicht sind für die Scenarien 1 und 2 überschaubare Entwicklungsarbeiten zu leisten. Scenario 3 halte ich dagegen schon für sehr aufwendig.

Aus OParl-Sicht wäre Scenario 5 die einzig sinnvolle Anwendung von skos:Concept-Objekten. Die RIS-Hersteller und RIS-Betreiber haben einen entsprechend hohen Implentierungsaufwand. Ob der Client jemals einen Nutzen daraus zieht, ist fraglich.

Ich würde die Einführung der skos:Concept-Objekte in OParl 1.0 verwerfen und aus der Doku entfernen.

.

[sterni24]

Noch ein Nachsatz:

Perspektivisch könnte OParl auch solche Objekte/Dateien/URLs für Vokabeln zur Verfügung stellen. Aber das ist ein anderes Projekt.

Das System ist also ziemlich offen für verschiedenste Szenarien. Wir sollten nur darauf achten, dass es nicht kompliziert dargestellt wird..

Ich bin für eine klare, verbindliche Spezifikation, ohne irgendwelche Interpretationsspielräume und Funktionalitäten, die ggf. in eine falsche Richtung führen (siehe vorstehende Szenarien).

[akuckartz]

@sterni24 Danke für die Zusammenstellung und das Durchdenken der Szenarien. Ich denke aber, dass es weiterhin Missverständnisse über die Aufwände und Vorgehensweisen gibt. Zunächst zu den einzelnen Szenarien und dann zu dem (fast schon trivialen) minimalen Aufwand der für RIS-Entwickler und -Betreiber geleistet werden muss.

Scenario 1: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller kennt die Werte dieser Eigenschaft nicht und legt entsprechend viele Objekte des Typs skos:Concept, die jeder einzelnen Körperschaft zugeordnet wird, an. Bei jedem Datenabgleich muss der RIS-Betreiber die Existenz des skos:Concept-Objekts prüfen und nicht vorhandene Werte speichern.

Um welchen Datenabgleich geht es? Wenn die RIS-Betreiber sich auf ihre eigenen skos:Concept Objekte beschränken (auf eigenen Servern), dann gibt es keine Notwendigkeit zu einem Datenabgleich mit einem Hersteller. Und wenn sie Objekte des RIS-Herstellers verwenden, dann müssen sie ebenfalls keine Daten abgleichen. Sie können sich schlicht auf die Objekte beschränken, die der Hersteller zum Zeitpunkt der Installation der Software auf einem Server des Herstellers angeboten hat. Das setzt nur voraus, dass der Hersteller die Objekte weiter anbietet und nicht deren Bedeutung verändert. Das jedoch ist eine Sache der Vereinbarung zwischen Betreiber und Hersteller und muss nicht in einer Spezifikation festgelegt werden.

Scenario 2: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller fängt an, alle Werte dieser Eigenschaft auszulesen und auf RIS-Betreiber-Ebene zu speichern. ...

Bei jedem Datenabgleich muss der RIS-Betreiber die Existenz seiner skos:Concept-Objekte prüfen und nicht vorhandene Werte speichern.

EIne solche Vorgehensweise mit Datenabgleich etc. ist schlicht nicht notwendig. Dazu eine mögliche Vorgehensweise ganz am Ende.

Scenario 3: Ein RIS-Hersteller hat eine Menge von RIS-Betreibern, die jeder für sich eine Reihe von paperType definiert haben. Der RIS-Hersteller fängt an, alle Werte dieser Eigenschaft auszulesen und eine einheitliche skos:Concept-Klassifizierung vorzunehmen. Hier kommt dann folgendes heraus: ... Der RIS-Hersteller oder RIS-Betreiber muss über eine Tabelle die Klassifizierung vornehmen und stetig auf Vollständigkeit überprüfen.

Weder Hersteller noch Betreiber müssen dies tun. Eine Vereinheitlichung erfordert tatsächlich Aufwand und die Verwendung von skos:Concept-Objekten ermöglicht diese Vereinheitlchung ohne sie aber (mit den damit verbundenen Aufwänden) zu erzwingen.

Falls ein skos:Concept-Objekt fehlt, muss dieses zunächst definiert, gespeichert und dann zugeordnet werden.

Ein solches Objekt dem RIS-Betreiber zur Verfügung stehen. Er kann es auf seinem System hosten und muss dazu keinerlei externe Abstimmung durchführen.

Scenario 5: Die OParl-Community legt eine einheitliche Klassifizierung für paperType fest. An diese sind alle RIS-Betreiber und RIS-Hersteller gebunden.

Eine solcher Zwang muss nicht sein - ich würde ihn nicht für hilfreich halten! Eine solche einheitliche Klassifizierung sollte ein Angebot sein, kein Zwang.

Die Klassifierzungen der vorhandenen Werte muss zwingend je RIS-Betreiber erfolgen.

Nein, ein solcher Zwang wäre tatsächlich fürchterlich. Eine Neuklassifizierung alter Daten ist nicht erforderlich.

Ggf. müssen von Zeit zu Zeit weitere skos:Concept-Objekte angelegt und allen RIS-Betreibern zur Verfügung gestellt werden.

Diese können dann genutzt werden (und sollen es eventuell auch), müssen es aber nicht.

Zusammenfassung Aus Client-Sicht sind die Scenarien 1 bis 4 für eine übergreifende Auswertung auf paperType nicht weiter nutzbar. Es leidet nur die Performance.

Aus Client-Sicht ist gibt es keine nennenwerten Auswirkungen auf Performance, weder was Bandbreite betrifft noch Rechengeschwindigkeit o.ä.

Ein Client hat dann aber die Möglichkeit z.B. auf einen Server zuzugreifen, der selber als Client auf RIS-Systeme mehrerer Kommunen zugreift und deren Daten weiter aufbereitet. Warum soll ein solcher Server nicht ebenfalls eine einheitliche Schnittstelle verwenden können ohne dadurch in seinen Möglichkeiten beschränkt zu werden?

Aus RIS-Hersteller-Sicht sind für die Scenarien 1 und 2 überschaubare Entwicklungsarbeiten zu leisten. Scenario 3 halte ich dagegen schon für sehr aufwendig.

Wie oben dargestellt wurde kann zwar Aufwand hineingesteckt werden, muss aber nicht. Einen geringen EInstiegsaufwand halte ich dafür auch für wichtig.

Aus OParl-Sicht wäre Scenario 5 die einzig sinnvolle Anwendung von skos:Concept-Objekten. Die RIS-Hersteller und RIS-Betreiber haben einen entsprechend hohen Implentierungsaufwand. Ob der Client jemals einen Nutzen daraus zieht, ist fraglich.

Nun zu der eingangs angekündigten fast trivialen Implementierungsmöglichkeit.

Für die Begriffe "Antrag", "Beschlussvorlage" kann ein RIS-System diese zwei URLs automatisch bilden:

https://example.org/ris/createskosobject?label=Antrag
https://example.org/ris/createskosobject?label=Beschlussvorlage

Der Server kann dann aus den Werten automatisch skos:Concept-Objekte generieren. Mehr muss ein Server nicht tun. Aber er kann mehr tun ohne durch eine Spezifikation unnötig eingeengt zu werden.

Ein einfacher Client, der nur mit einem einzigen Server einer Kommune Verbindung aufnimmt wird relativ wenig Vorteile davon haben (Mehrsprachigkeit ist ein Beispiel, welche auch in einem solchen Szenario relevant sein kann). Auf je mehr Daten verschiedener Körperschaften zugegriffen wird, um so bedeutsamer wird die Möglichkeit zu Vereinheitlichung. Dazu hilft durchaus auch, wenn Kommune A ein eigenes Begriffs-Objekt für Anfragen hat und Kommune B ebenfalls ein eigenes Objekt für Anfragen. Das dann zusammenzuführen kann einem Client überlassen werden (der möglicherweise wesentlich mehr tut als Daten in HTML-Form aufzubereiten).

[sterni24]

Soweit mir bekannt ist, hat SKOS etwas mit Wissensorganisation tu tun. Das Beispiel in Scenario 3 geht in diese Richtung. Wenn der Client sich dieses Wissen letzendlich durch Sichtung aneignen (organisieren) muss, ist das eine fragwürdige Argumentation.

Ich kann es nicht nachvollziehen, dass Wertelisten, die nicht eindeutig sind, in einer solchen Struktur abgelegt werden sollen / können.

Solange es keine OParl-einheiliche Lösung gibt, werden wir in unserem RIS keinen Gebrauch davon machen.

Da es aus meiner Sicht hier nichts mehr zu dikutieren gibt, schließe ich diesen Beitrag.

[marians]

Damit die skos:Concept Idee in der Spezifikation nicht im Weg steht, habe ich in allen Beispielen anstelle der URLs einfache Strings eingefügt. Evtl. werde ich unter "Vokabulare zur Klassifizierung" noch etwas mehr dazu schreiben, damit es wenigstens dort deutlich wird, was mit externen Vokabularen gemeint ist.

[akuckartz]

@sterni24 Da das leicht zu übersehen ist: SKOS sieht auch die Möglichkeit der Festlegung von Reihenfolgen für Begriffe vor. Diese Eigenschaft war bisher auch die Grundlage um z.B. die Reihenfolgen der Anzeige von Ausschüssen festzulegen. Dazu gab es das eine oder andere Issue. Wenn keine skos:Concept-Objekte zur Verfügung stehen, dann fehlt auch die Grundlage, um auf dem Weg solche Reihenfolgen festzulegen.

[sterni24]

Das glaube ich jetzt nicht! Zeigen Sie mir das mal auf! Aber konkret und nicht als ein Verweis auf www.

[akuckartz]

Ich hatte in dem Kommentar https://github.com/OParl/specs/issues/167#issuecomment-44530307 am Ende ein einfaches Beispiel für die Angabe einer solchen Reihenfolge angegeben. Möglicherweise ist das bislang nicht in die Spezifikation eingeflossen.

[sterni24]

Was hat das mit einer Sortierung zu tun?

[akuckartz]

Die Werte der Eigenschaft memberList einer skos:OrderedCollection sind sortiert, das ist so spezifiziert und kann in JSON-LD entsprechend im Kontext schlicht per @list deklariert werden, fertig. Ohne JSON-LD und Kontext muss man stattdessen Text schreiben um so etwas zu spezifizieren - aber das ist eine andere Baustelle.

[sterni24]

Also gilt dies nicht für OParl 1.0.

[akuckartz]

Ja, diese Sortierung wurde gewissermassen zusammen mit JSON-LD entsorgt.