search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

System, Betreiber, Körperschaften, Mandanten #58

Closed marians closed 10 years ago

marians commented 11 years ago

Die "Körperschaft" steht im Datenmodell für die Organisation oder die Gebietskörperschaft, der ein Parlament und Ausschüsse angehören. Beispiel: Landkreis X, Gemeinde Y, Zweckverband Z.

In den meisten Fällen existiert ein RIS exklusiv für eine einzige Körperschaft. Sprich: Eine Instanz eines Ratsinformationssystems beinhaltet ausschließlich Inhalte zu einer einzigen Körperschaft. Unter der (öffentlichen) URL für dieses RIS (z.b. http://ratsinformation.stadt-koeln.de/infobi.asp) sind nur die Inhalte dieser Körperschaft abrufbar.

In einzelnen Fällen jedoch teilen sich mehrere Körperschaften ein RIS.

In Issue #55 ist dies für Bonn/Ahrweiler beschrieben. Das System wird von Bonn betrieben, ein Gremium darin gehört aber gleichzeitig zu Bonn und Ahrweiler.

Ein weiterer komplexer Fall ist das System für Ulmen (https://sessionnet.krz.de/ulmen/bi/ , Somacos SessionNet). Technischer Betreiber ist, zumindest nach der Domain zu urteilen, das KRZ Minden-Ravensberg/Lippe. Das System wird von 22 "Mandanten" genutzt. Diese sind, im Sinne der aktuellen OParl Bezeichnungen, Körperschaften wie z.B. die "Stadt Ulmen" oder "Zweckverband Kindergarten Kliding".

Innerhalb eines einzigen technischen Systems können also von einander unabhängige Körperschaften abgebildet sein, denen jedoch bestimmte Objekte gemeinsam zugeordnet sein können.

Für OParl ergibt sich zum einen die Anforderung, dass jedes (technische) System über sich selbst Auskunft geben können soll. Die Annahme ist, dass ein bestimmter API-Endpunkt genau ein System repräsentiert. Diese Selbstauskunft soll voraussichtlich Informationen wie die folgenden beinhalten (ohne Anspruch auf Vollständigkeit):

Jedes System kann nun beliebig viele Körperschaften beherbergen. Zu diesen Körperschaften wiederum sind ebenfalls Informationen zu hinterlegen (wie bereits in Teilen im Entwurf zu sehen):

(Zur Frage, wo die Lizenzinformation am besten aufgehoben ist, bitte auch #25 beachten.)

Lässt sich dadurch die Realität vernünftig abbilden? Kommentare erwünscht.

BThie commented 11 years ago

Die angesprochene Teilung eines RIS ist in der Überschrift Körperschaft, Mandanten, technischer Betreiber gut wiedergegeben. Es stellt nichts anderes als eine Verbandsgemeinde mit Ihren Mitgliedsgemeinden und ihren Beteilgungen dar, die technisch bei einem Dienstleister betrieben werden. Das ist heute gängige Praxis und in anderen Bundesländern in den Konstrukten Verwaltungsamt, Verwaltungsgemeinschaft, Samtgemeinde im Kontext zum Betrieb in einem Rechenzentrum auch ganz normal. Zu den Fragen:

•Wer ist für dieses System technisch verantwortlich? (Ansprechpartner bei Fehlern, Rückfragen) -Für das Ratsinformationssystem ist die jeweilige Körperschaft verwantwortlich. Im Innenverhältnis regelt es die Körperschaft mit ihrem technischen Dienstleister, Hersteller usw.

•Welche OParl-Version unterstützt dieses System? -Gibt es denn schon OParl-Versionen ? Nein, aber wir sollten jetzt zu einer Spezifikation der Version 1.0 kommen und alles weitere dann in der Fortentwicklung der Schnittstelle klären.

•Unter welchen URLs findet man Objekte wie Körperschaften, Gremien, Drucksachen, Sitzungen, ...

marians commented 11 years ago

@BThie Ich habe die Befürchtung, dass meine Ausführungen nicht so verstanden wurden, wie ich es beabsichtigt hatte.

Die genannten Fragen an den jeweiligen Entitäten/Objekten waren nicht als Anregung zur Diskussion hier gedacht, sondern sind Fragen, die über die API an der entsprechenden Stelle beantwortet werden sollen.

Beispiel: "Welche OParl-Version unterstützt dieses System?" - Dies soll heißen, dass die API darüber Auskunft gibt, welche OParl-Version diese API unterstützt. Dass es zukünftig mehr als eine Version der OParl Spezifikation geben wird, halte ich für eine sinnvolle Annahme.

Es läuft (immer noch) auf die Frage hinaus, welches "Objekt" über die API welche Information beinhalten soll. Zur Veranschaulichung ein Auszug aus der möglichen System-Selbstauskunft:

{
    "oparl_version": "1.0",
    "metadata_license": {...},
    "contact": ...
    ...
}
akuckartz commented 11 years ago

Dies scheint ein Duplicate von #28 zu sein.

akuckartz commented 11 years ago

Ich habe Bedenken bezüglich der Angabe bzw. Aussagekraft von OParl-Versionsnummern. Ich finde die Möglichkeit inkrementeller Verbesserungen angebotener Daten wichtig.

marians commented 11 years ago

@akuckartz Das solltest Du näher erklären. Idealerweise in einem eigenen Issue, damit hier der Fokus des Themas nicht zu stark ausgeweitet wird. Danke!

BThie commented 11 years ago

Die Frage wurde jetzt verstanden- Danke. Das gewählte Beispiel hinsichtlich der Selbstauskunft des OParl-Servers erscheint sinnvoll. Kann aus unserer Sicht unterstützt/ implementiert werden. Allerdings muss der Eigentümer der Daten ( Körperschaft) hier die Informationen zur Lizenz und Kontakt liefern, anfangs werden diese Angaben u.U. leer sein. Weitere Antwort zu Frage Versionsstände/ inkrementelle Verbesserungen im Issue #60

BThie commented 10 years ago

Workshop 22.01.2014 Bielefeld Gruppe B Vorschlag

Verweis auf https://github.com/OParl/specs/issues/28

-Kontaktinformationen OParl: E-Mail der Verwaltung ( gedacht für inhaltlich Verantwortlichen , technische Fragen werden intern weitergeleitet) -OParl Version: -globale Lizenzinformation: -Product URL : verweist auf URL mit Name und Version der RIS-Software -Vendor URL : verweist auf URL mit Herstellerangabe

marians commented 10 years ago

Inhalte sind in https://github.com/OParl/specs/blob/master/dokument/master/chapter_8030.md eingeflossen. Das Issue wird geschlossen.