oparl:Organization benötigt Eigenschaft "meeting"

[marians]

Wir haben bisher keine Möglichkeit vorgesehen, ausgehend von einer Gruppierung (oparl:Organization) die Sitzungen (oparl:Meeting) der Gruppierung zu sehen. Das sollten wir als ZWINGEND einfügen.

[akuckartz]

Meine Meinung dazu ist neutral. Die Information ist redundant aber ich sehe wie das verwendet werden kann.

In die OWL-Ontologie nehme ich dann bezüglich der beiden Eigenschaften organization bzw. meeting schlicht dies auf:

oparl:organization owl:inverseOf oparl:meeting .

[akuckartz]

ZWINGEND ist problematisch da OParl keinen Ausschuss zwingen kann Sitzungen abzuhalten. Allerdings kann die inverse Beziehung zwischen den beiden Eigenschaften erzwungen werden.

[sterni24]

@akuckartz Ich denke, die Eigenschaft "meeting" hat in oparl:Organization genau so wenig zu suchen, wie die Eigenschaften "post" und "member". Nach dem vorliegenden Konzept von OParl muss jede Struktur einzeln ausgelesen werden.

Die Vorgehensweise eines Clients wäre dann wie folgt:

1. Auslesen aller Gremien (oparl:Organization + organizationType = committee) nach einer vorgegebenen Struktur (Gruppierung / Sortierung)
2. Auswahl eines Gremiums
3. nachlesen oparl:Membership
4. nachlesen oparl:Person

Das ist nicht sehr performant. Ist z. B. eine Methode vorgesehen ist, die zu einem Gremien eine komplette Datenstruktur mit oparl:Memberships, oparl:Person und / oder oparl:Meetings ausgibt?

PS: Unter oparl:Organization steht in dem Beispiel noch eine Eigenschaft "classification". Sollen das die Gruppierungen sein? Eine Erläuterung fehlt in den Eigenschaften.

[akuckartz]

@sterni24 Zunächst nur eine Antwort zu der wohl wichtigsten Frage: Nein, es ist keine Methode vorgesehen, die zu einem Gremium eine solche komplette Datenstruktur ausgibt.

Ich bin tendentiell für die Verwendung einer Query-Language die so etwas ermöglicht. Mit SPARQL geht das. Aber wir können SPARQL auf Server-Seite nicht voraussetzen. Deshalb ist die Ergänzung einer Query-Language in OParl eine größere Baustelle - also nichts für Version 1.0. Siehe dazu auch #12 und #165.

[sterni24]

@akuckartz Ist mein Gedanke 'die Eigenschaft "meeting" hat in oparl:Organization genau so wenig zu suchen, wie die Eigenschaften "post" und "member".' korrekt? Soll ich dazu eigene Issues schreiben?

[akuckartz]

@sterni24 Warum meeting keine Eigenschaft in oparl:Organization sein soll verstehe ich bisher nicht. Eigene Issues für post und member wären gut.

[sterni24]

@akuckartz Wenn ich das richtig verstehe, werden hier alle IDs von oparlMeeting für jeweils ein Item aus oparl:Organization bereitgestellt. Dies können, je nach Umfang der Historie, eine erhebliche Anzahl von Terminen sein.

Zu welchem Zweck soll dies in oparl:Organization bereitgestellt werden?

[akuckartz]

@sterni24 Dass eine hohe Anzahl vorkommen kann hatte ich tatsächlich nicht im Blick (da das weniger eine Frage der Modellierung als der Serialisierung ist). Über die Konsequenzen muss ich etwas grübeln - auch in Zusammenhang mit einer eventuellen Modellierung von Wahlperioden.

[marians]

Ich sehe das Problem nicht. Listen werden entweder direkt im Objekt ausgegeben oder über eine eigene Listen-URL (vgl. Abschnitt 4.7.3 im aktuellen Dokument). Der Server entscheidet, welche der beiden Varianten gewählt wird. Handelt es sich um viele Sitzungen, soll der Server diese über eine eigene URL anbieten, die dann Paginierung erlaubt.

Die Eigenschaft meeting einer oparl:Organization wäre also in der Praxis typischerweise das gleiche wie die Eigenschaft meeting einer oparl:Body.

[marians]

@sterni24 Um noch auf Ihre Frage "Zu welchem Zweck soll dies in oparl:Organization bereitgestellt werden?" einzugehen: Es erscheint mir recht wahrscheinlich, dass es Anwendungsfälle gibt, in denen man nur die Sitzungen eines bestimmten Gremiums auslesen möchte. Würde man hierfür alle Sitzungen auslesen und dann Client-seitig filtern müssen, wäre der Aufwand deutlich größer.

[sterni24]

@marians @akuckartz Heißt das im Umkehrschluss, dass ich clientseitig keine Methode aufrufen kann, die mir eine Objektliste von oparl:Meetings eines bestimmten Gremiums über einen vorgegebenen Zeitraum in einer nach Datum aufsteigenden Reihenfolge zurückgibt?

Wenn nein, würde das bedeuten, dass ich mir als Client zunächst die Objektliste aller Gremien ausgeben lasse. Hieraus wird dann gezielt ein Gremium abgerufen. Alle Objekte der Eigenschaft "member" müssen dann wiederum einzeln nachgelesen und verarbeitet (gefiltert und ggf. sortiert) werden, um z. B. die zukünftigen Termine eines Gremiums auszugeben. Ist das so korrekt?

[marians]

@sterni24 Bisher ist nur die Liste aller Sitzungen, die über die meeting Eigenschaft des oparl:Body Objekts aufgerufen werden kann, vorgesehen. Diese kann auf einen bestimmten Datumsbereich eingeschränkt werden.

Deswegen bin ich auch der Meinung, dass wir die Eigenschaft meeting am Objekttyp oparl:Organization dafür brauchen.

[sterni24]

@marians Ich kann mir leider immer noch nicht vorstellen, wie das in der Praxis funktionieren soll. Ich bitte um Beantwortung meiner Frage aus dem 2. Absatz.

Beim Durcharbeiten der Spezifikation von oparl:Body und oparl:Organization tritt in diesem Zusammenhang folgende Frage auf: wie kann ich eine Objektliste aller Gremien abrufen?

[akuckartz]

@marians Stimmt, Paging-Aspekte sollten nicht hier in diesem Issue behandelt werden.

@sterni24 Ich sehe weiterhin keinen Grund, der aus Modellierungssicht gegen die meeting-Eigenschaft spricht.

Mit dem "2. Absatz" ist offenbar die "Vorgehensweise eines Clients" (#167 (comment)) gemeint. Diese Vorgehensweise sieht grob korrekt aus. Zwei Anmerkungen dazu:

• "organizationType = committee" und zur Frage "wie kann ich eine Objektliste aller Gremien abrufen?": Mit "committee" ist ein Link auf ein durch das RIS angegebenes skos:Concept-Objekt außerhalb des Namensraums von OParl gemeint. Hier müssen wir wohl weitere minimale Festlegungen treffen: Wie kann ein Client Fraktionen von Gremien unterscheiden? Arten von Gruppierungen #173
• "nach einer vorgegebenen Struktur (Gruppierung / Sortierung)": Gruppierungen und Sortierungen ergeben sich aus der bisher als organizationType bezeichneten Eigenschaft und weiteren Angaben. Eine Reihenfolge aus einem Gesamtbeispiel (legt schlicht fest, dass der Hauptausschuss vor Finanzausschuss kommt):

{
    "@id": "beispielris:conceptScheme/commitees",
    "@type": "skos:OrderedCollection",
    "note": "Kann u.a. für die Reihenfolge der Anzeige verwendet werden. Hauptausschuss ist wichtiger als Finanzausschuss",
    "memberList": [
        "beispielris:vocab/main",
        "beispielris:vocab/finance"
    ]
}

[sterni24]

@akuckartz Zum letzen Beitrag von @marians:
Was nützt mir eine Liste von meetings eines Gremiums, wenn ich diese nicht nach Datum einschränken kann. Das sind bei einigen RIS-Systemen durchweg mehrere Legislaturperioden! Hier müsste jeder einzelne Eintrag der Liste nachgelesen werden. Das ist nicht sehr performant.

M. E. wird eine Methode benötigt, die eine Objektliste des Typs oparl:Meetings (für ein bestimmtes Gremium, über einen bestimmten Zeitraum, in einer nach Terminen aufsteigenden Reihenfolge) ausgibt.

[akuckartz]

@sterni24 Ich verstehe die Problematik. Sie spricht aus meiner Sicht für eine allgemeinere Abfragesprache, da wir sonst Stückwerk bekommen, bei denen für spezielle Abfragen spezielle Lösungen vorgesehen sind.

[sterni24]

@akuckartz Ich denke auch mit einfachen Mitteln kommt man hier weiter. Für weitere Diskussionen habe ich #174 angelegt.

[akuckartz]

Ich habe die Eigenschaft als EMPFOHLEN aufgenommen. ZWINGEND geht nicht, da es eventuell gar keine Sitzung gibt.

Die Problematik der Übertragung nicht benötigter Daten sollten wir aus der Modellierung weitgehend heraushalten. Ein Aspekt der Schwierigkeit ist, dass wir nicht wissen sondern allenfalls vermuten können, welche Daten der Client tatsächlich benötigt. Wir müssen dieses Problem auf andere Weise angehen, jedoch nicht mehr für Version 1.0.

[sterni24]

Warum wird an dieser Eigenschaft "meeting" festgehalten?

"meeting" wird aus dem selben Grund nicht benötigt, wie "member" in oparl:Organization nicht benötigt wird. Ein Client sollte hier eher in die Lage versetzt werden, meetings für eine organization gezielt nachzulesen. Siehe auch Beiträge weiter oben.

EMPFOHLEN macht hier auch keinen Sinn. Wie soll ein Client das interpretieren, wenn keine Meetings übergeben wurden. Sind wirklich keine vorhanden? Oder hat der Server keine bereitgestellt, weil der Betreiber die Ausgabe nicht für sinnvoll hält? - Der Client muss in jedem Fall nachlesen!!!

[akuckartz]

Für @sterni24 und wegen #203 wieder geöffnet.

[akuckartz]

@SternI Das Problem des letzten Absatzes kann durch eine zwingende Anforderung oparl:organization owl:inverseOf oparl:meeting . (hier schlicht in OWL formuliert) erledigt werden. Insowiet gibt es einen Zwang. Eventuell muss das in der Beschreibung verdeutlicht werden.

Das hilft beim ersten Problem aber nichts, sondern verschärft es eher.

[sterni24]

Durch die in Specs unter 4.7.3 beschriebene Möglichkeit, eine Objektliste (in diesem Fall meeting als URL

    "meeting": "https://oparl.beispielris.de/meeting_of_organization/1"

auszugeben, bin ich dafür, dass diese Eigenschaft erhalten bleibt.

Es ist sehr hilfreich, über diesen Weg eine Liste der Termine eines Gremiums abzufragen. Ggf. kann man die o. a. URL noch mit einem startdate ergänzen.

[marians]

@sterni24 Vielen Dank für den Kommentar!

[marians]

Im aktuellen Entwurf ist die Eigenschaft "meeting" im Objekttyp "oparl:Organization" als ZWINGEND enthalten. ZWINGEND gilt hier natürlich nur, sofern auch tatsächlich Sitzungen vorhanden sind (an anderer Stelle bereits diskutiert). Das Issue wird entsprechend geschlossen.