oParl:Meeting - Status der Sitzung nicht eindeutig

[sterni24]

In Ergänzung zu #262 ist nicht ersichtlich, in welchem Status (vor der Sitzung / nach der Sitzung) sich Meeting zum Zeitpunkt des Datenabrufs befindet. Man kann zwar durch das Vorhandensein eines Protokolls annehmen, das es sich um den Status 'nach der Sitzung' handelt. Problematisch wird es insofern, dass in oParl:AgendaItem nach der Sitzung andere Einträge enthalten sein können als vor der Sitzung.

Es gibt RIS-Kunden, die ihre Protokolle bereits ein oder zwei Tage nach der Sitzung veröffentlichen, es gibt jedoch auch Fälle, in denen es durchaus 2-3 Monates dauert. Außerdem gibt es Gremien, zu denen nur die Einladung bzw. nur das Protokoll veröffentlicht wird.

Hieraus ergeben sich 2 Fragen:

• muss der Stand *wie eingeladen' nach der Veröffentlichung des Protokolls noch abrufbar sein?
• reicht es aus, diesen Status über eine weitere Eigenschaft z. B. meetingState zu bestimmen?

Hinweis:
Die ursprüngliche Tagesordnung befindet sich in aller Regel im Protokoll.

[akuckartz]

Protokolle/Niederschriften haben bisher in RIS häufig oder überwiegend keine brauchbare maschinenlesbare Struktur (dazu ist die Verwendung von Akoma Ntoso eine Option: OpenGovLD#55).

Siehe auch OpenGovLD#63 und die Diskussion unter #244

[eFrane]

Ein meetingState-Feld wäre meiner Ansicht nach keine ideale Lösung, da es sich wohl oder übel in OParl 1.0 um ein weiteres Feld handeln würde, dessen konkreten Inhalt wir schwer be- und vorschreiben können. Mein Vorschlag wäre daher, ähnlich wie bei File zu verfahren und Meetings Vorgänger und Nachfolger zu erlauben.

Die Namen dieser Eigenschaften könnten dann z.B. original und descendants sein, die resp. einen Link auf das ursprüngliche (Einladung, entsprechende Tagesordnung) und eventuelle weitere (Protokolle) Meetingobjekte angeben. Das in diesem Beispiel verlinkende Meeting würde dann die tatsächliche Tagesordnung enthalten und gewissermaßen den Status "nach einem Meeting aber vor der Veröffentlichung des Protokolls" darstellen.

Diese Art der Modellierung bietet glaube ich zum einen die nötige Flexibilität, um das von @sterni24 beschriebene Problem zu lösen, stellt aber zum anderen sicher, dass keine Eigenschaften eingeführt werden, die dann von unterschiedlichen Nutzern der implementierenden RIS-Systeme inkonsistent genutzt werden.

Fraglich bleibt für mich, ob dies nicht zu viel eventuell unnötige Komplexität mit sich bringt und ob es vielleicht insbesondere für OParl 1.0 praktischer wäre, einfach das Meeting im Verlauf des realen Meetings anzupassen und die entsprechenden AgendaItems und/oder Dateien zu verändern. Dies würde allerdings Datenverluste bedeuten, da, wie @akuckartz schon angemerkt hat, Protokolle schwer bis gar nicht maschinenlesbar sind und sich daher die ursprüngliche Tagesordnung nicht in jedem Fall nachvollziehen lassen würde.

[akuckartz]

einfach das Meeting im Verlauf des realen Meetings anzupassen und die entsprechenden AgendaItems und/oder Dateien zu verändern

Dass das "einfach" wäre bestreite ich unter Hinweis auf die Frage #244 (comment) und die Antwort #244 (comment)

[eFrane]

Das "einfach" bezog sich auf die technische Umsetzung der Fragestellung. Ich habe ja trotzdem bereits auf die möglichen Datenverluste bei einer solchen Verfahrensweise hingewiesen.

Die Darstellung aller möglichen Konstellationen von Besprechungen und TOPs (sh. auch #24, #171, #244, #245, #262 u.A.) wird sich mit OParl 1.0 nicht realisieren lassen, wenn wir an dem Ziel festhalten wollen, möglichst bald einen benutzbaren Konsens zu finden, auf dem spätere Spezifikationsversionen aufbauen können.

Dabei ist auch zu bedenken, dass wir zwar durchaus die ein oder andere Änderung an der Modellierung der Daten in der Spezifikation vornehmen könnten, die Probleme wie das in diesem Issue diskutierte lösen würden, allerdings können wir damit nicht die vorhandenen Datenbestände verändern, aus denen letztendlich die Daten in die API gespeist werden müssen. Diese Restriktion durch alten, schlecht mit Metadaten angereicherten Datenbestand, kann sicher auch in Zukunft nicht ganz ausgeräumt werden. Es wird aber absehbar einfacher, die diversen Modellierungsprobleme, die sich durch ein möglichst minimales aber flexibles Schema ergeben, aufzulösen, wenn wir diese Probleme tatsächlich erfassen können. In Hinblick darauf möchte ich auch auf die bereits vorhandene Möglichkeit herstellerspezifischer Erweiterungen hinweisen.

Allerdings, um auf das hier vorliegende Problem zurück zu kommen, sollten wir bei all dieser angestrebten Einfachheit versuchen Datenverluste von vornherein zu vermeiden. Daher bleibe ich bei meiner vorangegangen Argumentation und plädiere für die Einführung von verlinkten Meetings.

[sterni24]

Wenn wir den Gedanken der verlinkten Meetings weiterverfolgen, würde das zu einer unüberschaubaren Anzahl von AgendaItems führen. Da im AgendaItem-Objekt eine Verlinkung zum Meeting enthalten ist, müssten alle Meeting- und AgendaItem-Objekte gedoppelt werden. Wir würden im Vorfeld der Sitzung eine Meeting-Versionierung aufbauen, die nach der Sitzung m. E. niemand mehr benötigt.

In unserem Verfahren ist es seit so, dass Veränderungen an der Tagesordnung vor der Sitzung in den AgendaItems aktualisiert werden. Die ursprünglichen IDs bleiben erhalten, neue IDs kommen hinzu und vorhandene IDs werden ggf. entfernt. Dazu gibt es eine Reihe von Dokumenten wie Ursprungs- und Ergänzungstagesordnungen. Wenn jemanden nach der Sitzung die Veränderungen interessieren, kann er diese Dokumente einsehen.

Die letzte Stand der Tagesordnung vor der Sitzung wird solange "eingefroren", bis die finale Version aus der stattgefundenen Sitzung veröffentlicht wird.

Ich komme zurück auf die Eigenschaft meetingState, die diesen Zustand konkret beschreiben würde.

[akuckartz]

Ich stimme zu, dass

• kein unnötiges Duplizieren von Daten erforderlich sein darf
• der Inhalt alter Datenbestände formulierbar sein muss

Allerdings sollte es ermöglicht werden, auch Änderungen der Tagesordnung maschinenlesbar auszudrücken.

Die bisherigen Lösungsansätze gefallen mir so noch nicht, da sie diese Anforderungen nicht alle erfüllen.

Prinzipiell kommt auch die Angabe von "Deltas" oder "Patches" (also der Unterschiede) in Frage.

Nur als Anregung, nicht als fertiger Vorschlag gemeint: Es gibt mehrere Standardisierungsbestrebungen zur maschinenlesbaren Formalisierung von Daten-Änderungen. Siehe u.a. https://dvcs.w3.org/hg/ldpwg/raw-file/ldpatch/ldpatch.html und https://tools.ietf.org/html/rfc6902 und http://tools.ietf.org/html/rfc5789

Auch das zu Wikipedia gehörende Wikidata-Projekt treibt einigen Aufwand zur maschinenlesbaren Ausgabe von Daten-Änderungen (und nutzt dabei RDF ;-)

[the-infinity]

Ist schon länger drin unter c143138.

[the-infinity]

Am letzten Sonntag in diesem Zusammenhang besprochene Änderung cancelled auch drin: 5d99649

[sterni24]

Die Eigenschaft meetingState als string kann beliebigen Text aufnehmen und ist somit nicht geeignet, einem Client den Status der Sitzung anzuzeigen. Ein meetingState kann bezogen auf den Termin 3 Eigenschaften annehmen:

• terminiert (geplant)
• eingeladen (vor der Sitzung bis zur Freigabe des Protokolls)
• durchgeführt (nach Freigabe des Protokolls)

Ich schlage vor, daher einen Type integer mit den Werten 0, 1, 2 zu verwenden.

[akuckartz]

eingeladen (vor der Sitzung bis zur Freigabe des Protokolls)

Die Freigabe eines Protokolls erfolgt in der Regel erst einige Zeit nach dem Ende einer Sitzung (häufig sogar erst kurz vor der nächsten Sitzung des Gremiums). Dass eine Sitzung zu Ende ist kann (und sollte) sich jedoch unmittelbar in den Daten wiederspiegeln und nicht erst nach der Freigabe des Protokolls. Entsprechendes gilt für den Beginn der Sitzung.

Gibt es einen Grund, warum die Aufhebung eines Termins nicht schlicht als weiterer Zustand aufgenommen werden kann (statt einer cancelled-Eigenschaft)?

[konstin]

Die Information zum Sitzungsstand und, ob eine Sitzung stattfindet, werden oft unabhängig voneinander gespeichert und verarbeitet. So kann eine Sitzung z.B. ausfallen, nachdem eingeladen wurde, oder schon nach der Planung des Termins.

[sterni24]

Wenn eine Sitzung ausfällt, wird auch eine bereits veröffentlichte TO zurückgezogen.

meetingState könnte so dargestellt werden:

• terminiert (geplant)
• eingeladen (vor der Sitzung bis zur Freigabe des Protokolls)
• durchgeführt (nach Freigabe des Protokolls)
• aufgehoben (nicht durchgeführt)

cancelled ist damit überflüssig. Es kann auch sein, das ein Termin komplett entfernt wird. Somit wird gar nichts dargestellt.

[konstin]

Hierfür gilt das Gleiche wie für #173 (comment), weshalb ich auch diesen Issue schließe.

[akuckartz]

Siehe #173 (comment)