Wie kann ein Client Fraktionen von Gremien unterscheiden? Arten von Gruppierungen

[akuckartz]

Eine Frage von @sterni24. Hierzu sind voraussichtlich weitere Festlegungen bezüglich organizationType erforderlich, da OParl bisher keine konkreten oparl:Concept Objekte dafür anbietet. Eine kleine Minimalmenge ist eventuell erforderlich, damit ein Client zwischen Gremien und Fraktionen unterscheiden kann.

[sterni24]

Mir fallen hierzu spontan folgende organizationType ein:

• Gremien
• Fraktionen
• Parteien
• externe Gremien
• Institutionen

[akuckartz]

Was genau unterscheidet interne von externen Gremien?

[sterni24]

Interne Gremien sind die des RIS-Betreibers (Rat und Ausschüsse), externe Gremien sind die anderer Verwaltungen, die Personen in ein internes Gremium entsenden.

Dies tritt z. B. bei Verbänden, Bezirksregierungen etc. auf. Beispiel:
http://www.regionalrat-detmold.nrw.de/gremien/?__=LfyIfvCWq8SpBQj0MjyGavGau9TuCPj2NgzHauCWr8Um5Ol7MfyIeuDGJ

Interne Gremien haben Meetings, externe mangels Datenerhebung wahrscheinlich keine.

[akuckartz]

Siehe auch #178 (comment)

[sterni24]

Ein neutraler Client findet in einer Objektliste von oparl:Organization folgende Einträge für name und classificationvor (aus Platzgründen geben ich das zeilenweise aus):

"SPD", "Partei"
"Kirchenkreis Frechen", "ev. Einrichtungen"
"Rat der Stadt", "Rat und Ausschüsse"
"CDU", "Partei"
"CDU", "Fraktion"
"FDP/BGW", "Gruppierung"
"Hauptausschuss", "Rat und Ausschüsse"
"Seniorenbeirat", "Beiräte und Kommissionen"
"Die Linke"; "Partei"
"Sparkasse Köln", "Kreditinstitute"
"1. FC Köln", "Kultur und Sport"
usw.

Die Verwendung von classification wurde gemäß Doku so empfohlen.

Der Client möchte mit einer Abfrage nur den Typ "committee" erhalten:
"Rat der Stadt", "Rat und Ausschüsse"
"Hauptausschuss", "Rat und Ausschüsse"
"Seniorenbeirat", "Beiräte und Kommissionen"
(und wenn es geht auch in dieser Sortierung)

Was ist zu tun?

[akuckartz]

@sterni24 Falls eine Erwähnung von SKOS kein größeres Unbehagen auslöst, dann kann ich darstellen wie eine Lösung damit aussehen kann.

[marians]

@sterni24 Das hilft mir schon mal zum Verständnis. Ich ändere den Titel des Issue von "Wie kann eine Objektliste aller Gremien abgerufen werden? / Organisationsarten" in "Wie kann ein Client Fraktionen von Gremien unterscheiden? Arten von Gruppierungen" und öffne das Issue wieder. Und jetzt, wo mir klar ist, worum es hier geht, wird mir auch klar, dass Sie und @akuckartz das unter #177 am 30. Mai schon einmal diskutiert haben. Mit der Änderung in f11a76e wurde dieses Issue noch am selben Tag wieder geschlossen, darin wurde ein neues Attribut organizationType eingeführt.

Um die Frage "Wie kann ein Client Fraktionen von Gremien unterscheiden?" ganz konkret zu beantworten:

Sowohl Fraktionen als auch Gremien (wie z.B. Ausschüsse) sind Objekte des selben Typs, nämlich oparl:Organization. Dieser Objektyp sieht vor, dass man Gruppierungen benennt (name) und kategorisiert (classification).

In meiner pragmatischen Welt könnte man nun zwei verschiedene Gruppierungen so ausgeben:

{
    "name": "SPD",
    "classification": "Fraktion"
}

{
    "name": "Hauptausschuss",
    "classification": "Gremium"
}

Der Betreiber des Servers kann letztlich entscheiden, welche Begriffe mit classification ausgegeben werden.

Alternativ erlaubt classification auch schon in der aktuellen Fassung die Angabe einer URL eines skos:Concept Objekts. Auch dieses Objekt kann der Betreiber selbst bereitstellen und bestimmen, welche Begrifflichkeit es abbildet.

So könnte beispielsweise ein skos:Concept für Fraktion und eins für Gremium angeboten werden.

skos:Concept bietet zusätzlich die Möglichkeit, dass man eine Systematik aus Konzepten erstellt. Beispielsweise könnten Sie ein skos:Concept Hauptausschuss anlegen und sagen, dass Hauptausschuss eine bestimmte Form des Gremiums ist. Dazu dient die skos:broader Beziehung. Damit sind Sie nicht auf eine oder zwei Ebenen beschränkt, sondern können die Hierarchie so tief gestalten, wie Sie es benötigen.

Ist das eine adäquate Lösung für Ihre Anforderung?

[sterni24]

Nein, ich habe jedoch nicht mehr die Zeit, hier zu antworten.

[akuckartz]

Die Fragen "Wie kann ein Client Fraktionen von Gremien unterscheiden?" und "Wie kann eine Objektliste aller Gremien abgerufen werden?" sind nicht identisch. Die Beantwortung der ersten Frage ist wichtig, beantwortet aber die zweite nicht automatisch. Wie ein Client an alle Gruppierungen kommt ist dann zwar klar - und der Client kann daraus die Gremien herausfischen -, aber nicht, wie oder ob man den Server auch nur nach Gremien fragen kann.

[akuckartz]

Diese Frage kam ebenfalls auf: "Wie soll ich ... eine Liste aller zukünftigen Meetings aller Gremien abrufen können?"
#177 (comment)

[sterni24]

Welche Lösungsvorschläge gibt es aktuell?

[marians]

@sterni24 Wollten Sie nicht mal darüber nachdenken, ob es nicht doch zwei verschiedene Objekttypen für Gremien und andere Gruppierungen braucht?

[sterni24]

Eine einfache Zuordnung isCommittee TRUE/FALSE reicht nicht aus. Wir benötigen einen festdefinierten Objekttyp. Siehe oben.

[konstin]

Um die Diskussion hier wieder etwas anzustoßen: In München gibt es die folgenden Typen von Gremien:

• Ausschüsse
• Referate
• Fraktionen

Es dürfte ausreichend sein, in der Spezifikation eine Nomenklatur für einen Satz von Standardtypen festzulegen, sodass clients die verschiedenen Gruppierungen automatisch zuordnen können.

[the-infinity]

Fraktion und Partei sind nun auch als Gruppen anzusehen und finden sich in den Beispielen wieder, siehe ebf073d .
Die korrekte Sortierung könnte über eine feste Sortierung der Classification-Liste vom Body (dies hatten wir im Workshop besprochen). Dies würde sich aber mit dem Update-Mechanismus beißen und bietet eine Menge Probleme bei der Aufwärtskompatibilität, wenn wir mit Sortierungen anfangen wollen.
As Alternative könne man einen Zusatzwert organisationClassification abgedeckt werden, welches Attribut von Body ist und einfach die Strings in korrekter Reihenfolge angibt / den Classifications IDs zuordnet. Also gewissermaßen so:

organisationClassification : [
  {
    'id': '1',
    'name': 'Rat',
    'position': 1,
  },
  {
    'id': '2',
    'name': 'Fraktion',
    'position': 2
  }
]

[konstin]

Wir wollen demnächst einen Wert classificationName einführen, mit dem Gremien unterschieden werden können. Dafür sollen in OParl 1.0 keine Werte zwingend festgelegt werden, die folgenden Werte werden aber zur Verwendung emfohlen und an Beispielen erklärt:

• "Fraktion"
• "Gremium" (schließt Ausschüsse mit ein)
• "Plenum" bzw. "Oberste Instanz" bzw. "Rat". Für diesen Eintrag suchen wir noch nach einem passendem Begriff.

[sterni24]

Wir kommen nicht umhin, der classification feste Werte zuzuordnen, siehe diesen Beitrag ganz oben. Der eine nennt es "Parlament" und "Gremien", der nächste "Rat" und "Ausschüsse".

[the-infinity]

Deswegen soll es die empfohlenen Werte geben, so dass Gremium wirklich Gremium und nicht Ausschuss ist. Es wird jedoch die Option geben müssen, weitere Werte anzugeben, da es eine Menge weiterer Gruppen in einem Rat gibt, die in RIS auch gespeichert werden. Von externen Gruppen wie Vereinen oder kommunalen Unternehmen über Parteien bis hin zu regionalen Sonderfällen gibt es da eine gewisse Vielfalt.

[sterni24]

Eine Empfehlung ist nur eine Empfehlung. Da ich davon ausgehe, dass die OParl-Daten zu über 90% aus der Kommunalpolitik (Kreise, Städte und Gemeinden) stammen, plädiere ich trotzdem dafür, die Begriffe in diesem Bereich festzuschreiben. Es handelt sich dabei um alle Kommunen, denen ein AGS zugeordnet ist.

[konstin]

Diese Begriffe sollen auch festschrieben werden, jedoch zunächst nur als Empfehlungen. Mit OParl 1.0 soll eine möglichst einfache, vor allem aber mit möglichst allen Systeme kompatible Spezifikation geschaffen werden. Mit den Erfahrungen der ersten Version kann dann entschieden werden, welche Begrifglichkeiten man zwingend verlangen kann, ohne die 10% abweichenden Systeme auszuschließen.

[sterni24]

Wir drehen uns hier leider im Kreis. OParl ist für mich eine Schnittstelle, die zunächst einmal für RIS-Systeme spezifiziert werden soll. Falls andere Systeme diese Schnittstelle nutzen, können diese sich derselben Typisierung bedienen oder als Eigenschaftswert "Sonstige" einsetzen (s.o.). Zur Selektion werden m. E. eindeutige Merkmale benötigt!

[akuckartz]

Zwei Hinweise von mir, da ich dieses Issue ursprünglich eröffnet hatte und auch für OpenGovLD (bzw. Oparl-LD) eine Lösung für den Umgang mit diesen Begriffen benötigt wird.

• Eine solche Begriffsmenge kann separat spezifiziert werden. Dann muss nicht z.B. bei einer schlichten Erweiterung um einen Begriff gleich eine neue Version der anderen Spezifikation entstehen.
• Es ist möglich, (Ober-)begriffe festzulegen und gleichzeitig genügend ausdrucksstark für alle Gremieninformationssysteme zu bleiben. Ohne einen (kleinen) Thesaurus wird das allerdings schwierig.

[konstin]

Wir haben das noch mal diskutiert und sind zu dem Ergebnis gekommen, dass wir es in OParl 1.0 bei Empfehlungen belassen. Der Grund hierfür ist, dass es im Moment noch zu wenig Daten gibt, um Begriffe festlegen zu können, die eindeutig sind, für möglichst jedes RIS funktionieren und gleichzeitig einfach zu implementieren sind. In zukünftigen Version ist es aber durchaus möglich, Begriffe festzulegen. Begriffsvorschläge dafür sollten aber seperat diskutiert werden, weshalb ich diesen Issue schließe.

Sollte es jedoch tatsächlich unbedingt nötig sein, eindeutige Begriffe auszugeben, z.B. um mit einem bestimmten client kommunizieren zu können, so kann das mit Hilfe von herstellerspezifischen Erweiterung umgesetzt werden.

[akuckartz]

Wenn ein Issue ohne Lösung geschlossen wird (statt z.B. den Milestone zu verschieben), dann impliziert das regelmäßig, dass auch in der Zukunft keine Lösung beabsichtigt ist.

[konstin]

Die Lösung der Frage „Nomenklatur für Organization in OParl“ lautet „Keine Nomenklatur“, weshalb ich das Issue geschlossen habe. Und da die Diskussion über feste Begriffe in einer späteren Version auf Grund von bisher fehlenden Daten sowieso erst in einiger Zeit Sinn ergibt, hatte ich keinen neuen Issues eröffnet. Aber damit das auch formal weiterhin zur Lösung aussteht, hier zwei neue Issues: #335 und #336