Definition von oparl:Body

[konstin]

Die momentane Definition von oparl:Body ist sehr offen:

Der Objekttyp oparl:Body dient dazu, eine Körperschaft und damit ein Parlament zu reprä-
sentieren, zu dem der Server Informationen bereithält. Eine Körperschaft kann beispielsweise
eine Gemeinde, ein Landkreis oder ein kommunaler Zweckverband sein.

Mit dieser Definition ist nicht ersichtlich, ob z.B. auch Bezirksausschüsse gemeint sind oder nur die Stadt, die die Bezirksauschüsse enthält. Es wäre deshalb sinnvoll, diese Definition noch zu präzesieren.

[akuckartz]

Zum Begriff "Bezirksausschuss": https://de.wikipedia.org/wiki/Bezirksausschuss

[akuckartz]

Letztendlich geht es hier anscheinend um die Frage, ob bzw. wie hierarchische Beziehungen zwischen Gebietskörperschaften modelliert werden. Als Beispiele sind Landkreis und Gemeinde explizit angegeben. Zwischen diesen kann eine hierarchische Beziehung bestehen (muss aber nicht: kreisfreie Städte). Eine ähnliche Beziehung besteht zwischen den Gebietskörperschaften Stadt und Bezirksausschuss,

[konstin]

In diesem Fall fände ich es aber sinnvoll, die Definition in diesem Sinne zu konkretisieren.

[akuckartz]

Die korrekte Feststellung, ob etwas eine (Gebiets-)Körperschaft ist oder nicht, ist anscheinend nicht ganz trivial, da man das dem Begriff nicht unmittelbar ansehen kann und jedes Bundesland eine eigene Gemeindeordnung hat. Siehe https://de.wikipedia.org/wiki/Gebietsk%C3%B6rperschaft_%28Deutschland%29

[eFrane]

Warum müssen wir das eigentlich einschränken? Wenn eine Einrichtung meint, OParl für sich anwenden zu können, dann sollte sie das auch tun können. („Technik“ sollte immer eher ermöglichen anstatt einzuschränken.) Und ich sehe einfach keinen Grund, warum man mit der Körperschaftsdefinition beschränken sollte, wer das nutzen darf und wer nicht.

Allerdings wäre ganz sicher eine eindeutigere Aufschlüsselung von dem, was OParl als Körperschaft bezeichnet, nicht schädlich.

[akuckartz]

„Technik“ sollte immer eher ermöglichen anstatt einzuschränken.

👍

[konstin]

Ich hätte eigentlich erwartet, dass es das Ziel eines Standards ist, Dinge möglichst genau zu definieren, sodass nicht jeder RIS-Betreiber seine Definition nutzt. Das Problem könnte man aber meiner Ansicht nach dadurch lösen, dass man eine Definition nach den Eigenschaften einer Körperschaft, die für oparl:body relevant sind, nutzt. Diese sollten insbesondere die Abgrenzung zu oparl:organization erklären.

[akuckartz]

Ich hätte eigentlich erwartet, dass es das Ziel eines Standards ist, Dinge möglichst genau zu definieren, sodass nicht jeder RIS-Betreiber seine Definition nutzt.

👍

Beide Positionen stehen nicht in absolutem Widerspruch zueinander! Spezifikationen sollten präzise sein, dabei aber nicht unnötig einschränken. Unbegründete Einschränkungen sind in der Regel auch unnötig. Manchmal ist das eine feine Gratwanderung. (Grundsätzlichere Ausführungen gibt es in http://www.w3.org/TR/qaframe-spec/)

Diese sollten insbesondere die Abgrenzung zu oparl:organization erklären.

Da ich parallel eine allgemeinere Spezifikation entwickle: Die Beziehung zwischen "Organization" und "Body" halte ich für überdenkenswert.

[lu-j]

Oha, den Text müssen wir auf jeden Fall überarbeiten!

Aus technischer Sicht ist das Body-Objekt das übergeordnete Objekt. Alle Objekte (außer dem System-Objekt) gehören zu genau einem Body. In der Regel gibt ein RIS nur ein Body-Objekt aus. Falls sich mehrere Kommunen ein System teilen, wird ein Body-Objekt pro Kommune ausgegeben, ich denke das wird aber mit den meisten RISen nicht möglich sein und jede Kommune braucht eine getrennte Installation.

Ein Server, der Daten aus mehreren RISen spiegelt, gibt also mehrere Body-Objekt aus, in der Regel ein Body-Objekt pro gespiegeltes RIS.

Ein Body Objekt soll eine Gemeinde, eine Stadt, ein Landkreis oder ein Bezirk in den Stadtstaaten Berlin oder Hamburg (in Bremen gibt es auf Bezirksebene nur Beiräte) repräsentieren. Ich verwende der Einfachheit halber meistens nur den Begriff Kommune.

Eine andere Möglichkeit wäre, dass ein Body die politische Vertretung der Kommune repräsentiert. Ich denke das war ursprünglich mal angedacht, daher ist in dem Text auch von einem Parlament die Rede. Wir sollten den Begriff Parlament sowieso vermeiden, auf Kommunalebene gibt es nur Räte oder Kreistage, die werden nur umgangssprachlich manchmal als Parlament bezeichnet. Parlamente sind Teil der Legislative, Räte und Kreistage hingegen Teil der Exekutive (es werden nur Verordnungen erlassen, aber keine Gesetze). Ich weiß, der Name OParl ist nicht ideal :) Die politische Vertretung einer Kommune nennt man oft Gemeinderat (bzw. Stadtrat), der Gemeinderat besteht aus dem Rat und den Ausschüssen. Manchmal nennt man den Gemeinderat auch nur Rat, es ist also nicht immer klar ob man mit dem Wort "Rat" den Gemeinderat allgemein oder tatsächlich nur den Rat meint. Daher ist es besser, wenn ein Body eine Kommune repräsentiert, dann ist klar was gemeint ist und es gibt keine Verwechslungsgefahr mit den Organization-Objekten.

Hier mein Textvorschlag für die Beschreibung der Body-Objekte:

Der Objekttyp oparl:Body dient dazu, eine Körperschaft zu repräsentieren. Eine Körperschaft ist in den meisten Fällen eine Gemeinde, eine Stadt oder ein Landkreis.

In der Regel sind auf einem OParl-Server Daten von genau einer Körperschaft gespeichert und es wird daher auch nur ein Body-Objekt ausgegeben. Sind auf dem Server jedoch Daten von mehreren Körperschaften gespeichert, MUSS für jede Körperschaft ein eigenes Body-Objekt ausgegeben werden.

In den meisten RISen scheint man jedoch keine Informationen zu der Kommune speichern zu können. Man kann stattdessen das Logo und den Text auf der Startseite anpassen um die Besucher zu informieren, um welche Kommune es sich handelt. Ich denke es ist sinnvoll, wenn mindestens der Name der Kommune über die OParl Schnittstelle ausgegeben werden muss, das will ich aber in einem eigenen Issue behandeln und auch mit den RIS-Herstellern besprechen.

[akuckartz]

Der Objekttyp oparl:Body dient dazu, eine Körperschaft zu repräsentieren.

Falls ich nichts übersehe, dann ist das der einzige Text-Teil der normativ notwendig ist. Noch kürzer formuliert: Body gleich Körperschaft.

Sind auf dem Server jedoch Daten von mehreren Körperschaften gespeichert, MUSS für jede Körperschaft ein eigenes Body-Objekt ausgegeben werden.

Daraus folgt, dass es für jeden Bezirksausschuss in Münschen ein Body-Objekt geben muss. Ist das gemeint?

[the-infinity]

Um mal ein etwas ungewöhnliches Beispiel zu nehmen: der Verkehrsverbund VRR nutzt auch SessionNet, und das ist eines meiner nächsten Ziele für Politik Bei Uns. Es gibt da schlicht noch keine klaren Strukturen, wo RIS eigentlich überall eingesetzt werden, so dass es sehr schwierig sein wird, logische Verknüpfungen zwischen Body und Organization aufzubauen - zumindest in OParl 1.0.
Text von @lu-j in a21a7a4 eingebaut. Der Rest ist ein eigenes Issue und für Version > 1.0, oder?

[konstin]

Der neue Text ist zwar schon deutlich besser, aber meiner Meinung nach immer noch zu vage. Ich würde vorschlagen, Body als Gebietskörperschaft zu definieren. Damit muss man nur noch wissen, ob von einem Gremium o.Ä. ein Gebiet verwaltet, um zu bestimmen, ob es sich um Body oder Organization handelt.

Mein Textvorschlag:

Der Objekttyp oparl:Body dient dazu, eine Gebietskörperschaft zu repräsentieren. Eine Gebietskörperschaft ist in den meisten Fällen eine Gemeinde, eine Stadt, ein Landkreis oder ein Bezirksausschuss.

In der Regel sind auf einem OParl-Server Daten von genau einer Gebietskörperschaft gespeichert und es wird daher auch nur ein Body-Objekt ausgegeben. Sind auf dem Server jedoch Daten von mehreren Gebietskörperschaft gespeichert, MUSS für jede Gebietskörperschaft ein eigenes Body-Objekt ausgegeben werden.

[the-infinity]

Ist der Verkehrsverbund eine Gebietskörperschaft? Ich denke nein. Er bedient die Aufträge einer Gebietskörperschaft (der des RVR, um genau zu sein), aber in all den Dokumenten steht nichts darüber, dass er selbst eine ist.
Das Problem ist letztlich, dass die Trennung zwischen Body und Organization willkürlich ist. Das wird ganz besonders dann deutlich, wenn eine Gebietskörperschaft eine Rolle in einem anderen RIS hat. Im einen RIS taucht das Treffen dann nämlich der Body des einen RIS als Organization im anderen RIS auf. Die Entscheidung, wo ein RIS wie eingesetzt wird, ist ja keine wirklich logische Entscheidung, sondern mehr eine arbeitstechnisch-strukturelle.
Was natürlich eine Lösungsidee wäre, wäre, einen optionalen Link von einer Organization zu einem fremden Body. Das wird kein RIS-Hersteller ausgeben, könnte aber für unsere Drittsysteme spannend sein, als nachträglich manuell eingefügte Info.

[konstin]

Eingetlich bin ich davon ausgegangen, dass Oparl sich hauptsächlich an die Informationssysteme der mehr oder weniger direkt gewählten Parlamente wie die von Städten und Gemeinden richtet, weshalb ich Verkehrsverbünde nicht berücksichtigt habe. Wenn man diese mit einschließen will, dann ist die momentane Version passender.

Eine Unterscheidung zwischen Bodyund Organisation ist aber dennoch sinnvoll, weil es sehr häufig eine Unterteilung zwischen einem "Parlament", das bindende Entscheidungen treffen kann, sowie den darin Fraktionen und den verschiedenen Ausschüssen, die nur für ein bestimmtes Thema bzw. einen bestimmten Themenbereich verantwortlich sind. In diesem Sinne könnte es sogar sinnvoll sein, Organization in Typ für Ausschüsse und einen für Fraktion aufzuteilen, was aber eher in #173 behandelt werden sollte.

Da die momentane Definition Body für Version 1.0 ausreichen sollte, schließe ich dieses issue.

[the-infinity]

Es hat ja auch den primären Fokus parlamentarische Systeme in Städten und Gemeinden, da hast du schon recht. Das Problem ist nur leider das, was ich oben versucht habe zu erläutern mit der Willkür zwischen Body und Organization. Das dahinter liegende Problem ist, dass wir zur Zeit einfach noch zu wenig über die parlamentarischen Systeme in Deutschland wissen, um da eine sinnvolle Aufteilung vorschlagen zu können. Das wäre dann der Job für OParl > 1.0: herausfinden, was es eigentlich für Organisationstypen gibt und logische Relationen zwischen den Organizations / Persons / etc herstellen können.