-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wie kann ein Client Fraktionen von Gremien unterscheiden? Arten von Gruppierungen #173
Comments
Mir fallen hierzu spontan folgende organizationType ein:
|
Was genau unterscheidet interne von externen Gremien? |
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: Interne Gremien haben Meetings, externe mangels Datenerhebung wahrscheinlich keine. |
Siehe auch #178 (comment) |
Ein neutraler Client findet in einer Objektliste von "SPD", "Partei" Die Verwendung von Der Client möchte mit einer Abfrage nur den Typ "committee" erhalten: Was ist zu tun? |
@sterni24 Falls eine Erwähnung von SKOS kein größeres Unbehagen auslöst, dann kann ich darstellen wie eine Lösung damit aussehen kann. |
@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 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 ( 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 Alternativ erlaubt 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? |
Nein, ich habe jedoch nicht mehr die Zeit, hier zu antworten. |
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. |
Diese Frage kam ebenfalls auf: "Wie soll ich ... eine Liste aller zukünftigen Meetings aller Gremien abrufen können?" |
Welche Lösungsvorschläge gibt es aktuell? |
@sterni24 Wollten Sie nicht mal darüber nachdenken, ob es nicht doch zwei verschiedene Objekttypen für Gremien und andere Gruppierungen braucht? |
Eine einfache Zuordnung |
Um die Diskussion hier wieder etwas anzustoßen: In München gibt es die folgenden Typen von Gremien:
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. |
Fraktion und Partei sind nun auch als Gruppen anzusehen und finden sich in den Beispielen wieder, siehe ebf073d .
|
Wir wollen demnächst einen Wert
|
Wir kommen nicht umhin, der |
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. |
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. |
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. |
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! |
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.
|
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. |
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. |
Die Lösung der Frage „Nomenklatur für |
Eine Frage von @sterni24. Hierzu sind voraussichtlich weitere Festlegungen bezüglich
organizationType
erforderlich, da OParl bisher keine konkretenoparl:Concept
Objekte dafür anbietet. Eine kleine Minimalmenge ist eventuell erforderlich, damit ein Client zwischen Gremien und Fraktionen unterscheiden kann.The text was updated successfully, but these errors were encountered: