System, Betreiber, Körperschaften, Mandanten

[marians]

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):

• Wer ist für dieses System technisch verantwortlich? (Ansprechpartner bei Fehlern, Rückfragen)
• Welche OParl-Version unterstützt dieses System?
• Unter welchen URLs findet man Objekte wie Körperschaften, Gremien, Drucksachen, Sitzungen, ...
• Unter welcher Lizenz stehen die Daten?

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):

• Name der Körperschaft
• Ggf. Externe Schlüssel wie z.B. Regionalschlüssel und GKD-URL, die zur eindeutigen Identifizierung der Körperschaft beitragen
• Wer ist für diese Körperschaft inhaltlich zuständig? Ansprechpartner im Fall von Nachfragen zu Dokumenten, Meldung von fälschlicherweise veröffentlichten Dokumenten etc.

(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]

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, ...

• Eine Frage des Datenzugriffs.

  •Unter welcher Lizenz stehen die Daten?
  -Das sollten die "Eigentümer der Daten" - die Städte , Landkreise etc. hier diskutieren. Aus unserer Sicht sind die Eigentümer der Daten die jeweiligen Körperschaften. Porgrammhersteller und Rechenzentren erbringen hier nur technische Dienstleistungen. Für die inhaltliche Kontrolle ( es dürfen keine urheberrechtlic h geschützten Werke "in Umlauf" gebracht werden) sind die Verwaltungen zuständig. Es sollte sich grundsätzlich und pauschal um OpenData handeln.

[marians]

@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]

Dies scheint ein Duplicate von #28 zu sein.

[akuckartz]

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

[marians]

@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]

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]

Workshop 22.01.2014 Bielefeld Gruppe B Vorschlag

Verweis auf #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]

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