oparl / spec Goto Github PK

Aktuell sieht der Entwurf eine direkte (optionale) Beziehung zwischen einer Drucksache und einem Gremium vor.

Es ist zu prüfen, ob das in dieser Form sinnvoll ist.

Inhaltlich ist es für suchende Nutzer durchaus interessant, zu sehen, dass ein Dokument im Hauptausschuss oder in einer bestimmten Bezirksvertretung behandelt wurde.

In der Praxis werden Drucksachen häufig zur Beratung in mehreren Sitzungen verschiedener Gremien mit Tagesordnungspunkten verknüpft. Daher müsste es eigentlich beliebig viele Beziehungen zu Gremien geben, wenn überhaupt. Alternativ könnte auch die Beziehung über den Tagesordnungspunkt und die jeweilige Sitzung zum Gremium führen.

Die Zugehörigkeit von Drucksachen zu Gremien (in der Praxis auch "Beratungsfolge" genannt) wird von einigen Systemen wie z.B. dem Kölner RIS klassifiziert.

Beispiel:
http://ratsinformation.stadt-koeln.de/vo0050.asp?__kvonr=32312

Die Unterscheidung ist beim Kölner RIS (ohne Anspruch auf Vollständigkeit):

• Vorberatung (Fachausschuss)
• Anhörung (BV)
• Entscheidung

Es ist zu recherchieren

• welche weiteren Zuständigkeiten hier vorkommen können
• inwiefern dies in anderen System berücksichtigt wird

Um Videoaufzeichnungen von Ratssitzungen mit der Tagesordnung taggen zu können, wäre die Erfassung des Zeitpunktes interessant:

• Tagesordnungspunkt Zeit/Anfang
• Tagesordnungspunkt Zeit/Ende

Als Vorbereitung für späteres LOD:

• Verschlagwortung der Tagesordnungsthemen nach LeiKa, SKOR oder Dbpedia.

Das "Nummer"-Feld scheint in München nur in Kombination mit dem "Öffentlich"-Feld eindeutig zu sein: es gibt pro Sitzung einen öffentlichen und einen nicht-öffentlichen Teil - in jedem wird mit Nummer 1 zu zählen angefangt.

Beispiel: http://www.ris-muenchen.de/RII2/RII/ris_sitzung_detail.jsp?risid=2799385

#24

Bisher sind den Objekten - Gremium/Sitzung -, zwingend genau eine Gebietskörperschaft zugeordnet.

Es gewinnen, durch die zunehmenden politischen Bemühungen sich in den Kommunen übergreifend abzustimmen, Fälle an Bedeutung, bei denen Gremien und Sitzungen zwei Gebietskörperschaften zugeordnet sein können, z. B. den gemeinsamen Ausschuss Bonn / Ahrweiler bzw. gemeinsame Sitzungen verschiedener Gebietskörperschaften, insbesondere zu Verkehrs- und Liegenschaftsthemen.

Interessant festzuhalten wäre der Behandlungsgegenstand einer Drucksache sofern sie sich auf einen konkreten Ort/Bezugspunkt bezieht, bspw. im Sinne von einer Abfrage "zeige alle Drucksachen mit Bezug zu "meiner" Straße", zu "meiner" Schule, zu "meinem" Ortsteil, ..."

Hierfür gibt es bereits -sicherlich nicht nur in Berlin- feststehende:

• Straßennummern
• Bezirksnummern
• Einschulungsgebietsnummern
• Prognoseraumnummern
• ...

Dazu ein Beispiel aus dem (auch mit Webservice-Schnittstelle ausgestattetem) Regionalen Bezugssystem Berlin (RBS):
http://fbinter.stadt-berlin.de/rbs/rbs-slct-str.jsp?beznr=04&otnr=0401&strnr=&strname=Einsteinufer&hausnr=5&go=&mapLabel=&targetUrl=

siehe: http://www.stadtentwicklung.berlin.de/geoinformation/geodateninfrastruktur/de/geodienste/rbs_adressauskunft.shtml

.. könnte das Ganze aber auch etwas überfrachten ..

Zur eindeutigen Kennzeichnung von Gebietskörperschaften bieten sich möglicherweise Amtliche Gemeindeschlüssel (AGS) an.

Es ist zu prüfen, ob diese auch für Landkreise funktionieren.

Für RISe, die keine Gebietskörperschaft abdecken, sollte der AGS als Kennung nicht gelten müssen. Hier wäre zu klären, ob es ein alternatives System für die Kennzeichnung geben kann und ob dies überhaupt Teil des Standards sein soll.

Update 26. April: Inzwischen wurde "Gebietskörperschaft" zu "Körperschaft" umbenannt. Die Frage, ob man die Körperschaft, die sozusagen als "Betreiber" des Systems auch über die API kommuniziert werden könnte, eindeutig identifizieren kann, ist weiterhin offen. Da es sich um verschiedene Arten von Körperschaften handeln kann, ist ein einheitliches System nicht in Sicht. Für Gebietskörperschaften bieten sich Regionalschlüssel an, für andere Körperschaften existieren andere Systematiken wie z.B. GKD. Es zeichnet sich ab, dass hier mehrere Systeme zum Einsatz kommen könnten.

Beim Protokoll könnte bei der Erfassung des Abstimmmungsergebisses der Zeitpunkt einfach mitgelocked werden. So wäre zusammen mit dem Objekt Sitzungsverlauf, eine personenbezogene Erfassung der Abstimmungsergebnisse möglich:

• Zeitpunkt des Votums

Sollte es Räte geben, die neben DAGEGEN, ENTHALTUNG (DAFÜR wird in der Regel nicht erfasst) bei einem Votum auch ABWESEND erfassen, wäre mit der Anwesenheitsliste die Erfassung eines personenbezogenen Abstimmungsergebnisses ebenfalls möglich:

• Votum mit : DAGEGEN, ENHALTUNG, ABWESEND

Hier gibt es in München bei den Bezirksausschüssen noch "Initiativen", in Abgrenzung zu "Anträgen". Sie sind im RIS völlig separat aufgeführt, http://www.ris-muenchen.de/RII2/BA-RII/ba_initiativen.jsp?Men=j im Vergleich zu http://www.ris-muenchen.de/RII2/BA-RII/ba_antraege.jsp?Men=j&nav=1&selTyp=BA-Antrag

Eventuell wäre noch "Wortprotokoll" ein weiterer Typ.

Die property names der JSON-Beispiele im examples-Verzeichnis müssen zwischen Anführungszeichen stehen. Das ergibt sich unmittelbar aus der JSON-Spezifikation http://www.json.org/

Siehe
http://stackoverflow.com/questions/2067974/in-json-why-is-each-name-quoted

Moin!

Nur als Hinweis, was ALLRIS alles so ausspuckt, hier das Beispiel für unseren OB:

    <element>
        <kplfdnr>57</kplfdnr>
        <kppartei>CDU</kppartei>
        <kpgdat>2441079</kpgdat>
        <kpsdat>0</kpsdat>
        <aktiv>1</aktiv>
        <antext1>Oberb&#252;rgermeister</antext1>
        <antext3>Sehr geehrter Herr Oberb&#252;rgerm</antext3>
        <adname>Philipp</adname>
        <advname>Marcel</advname>
        <adtit/>
        <adename/>
        <adstr>Hasslerstra&#223;e</adstr>
        <adhnr>22-24</adhnr>
        <adplz>52066</adplz>
        <adort>Aachen</adort>
        <adoteil/>
        <ademail>oberb&#252;[email protected]</ademail>
        <ademail2/>
        <adwww1>www.aachen.de</adwww1>
        <adwww2/>
        <adtel>0241-4327200</adtel>
        <adtel2/>
        <adtel3>432-7200</adtel3>
        <adtel4/>
        <adtel5/>
        <adtel6>176171</adtel6>
        <adfax>0241-4328008</adfax>
        <adfax2/>
        <link_kp>kp020.asp?KPLFDNR=57options=8</link_kp>
    </element>

Die Frage ist wahrscheinlich, ob man alle möglichen Felder (wie 6 Telefonnummern) optional aufnimmt oder man sich beschränkt. Generell wäre ich aber schon dafür, alle Informationen des Systems auch herauszugeben. Dazu müsste man aber wahrscheinlich schauen, was andere Systeme noch für Felder haben (vielleicht gibt ja auch eines noch pro Telefonnummer ne Beschreibung an).

kppartei muss übrigens dabei keine Partei sein, sondern kann auch Verein, Polizeipräsidium etc. sein.

Eher eine Frage als ein Issue:

Ist JSON-LD in irgend einer Weise berücksichtigt ?

Offensichtlich gibt es in der Praxis gemeinsame Sitzungen von verschiedenen Gremien. Wenn dies richtig unterstützt werden soll, müssen Sitzungen entsprechende 1:n Beziehungen zu Gremien haben.

In welchem RIS gibt es dazu in der Praxis schon ein Beispiel? (Bitte idealerweise mit Link)

Dieser Fall ist anscheinend bisher in der Spezifikation nicht berücksichtigt.

Das Beispiel person.json kann eine Grundlage geben. Die id's dort in den Listen verweisen auf Gremien. Eventuell umbenennen.

Das Thema wurde beim Workshop gestern (17.4.) schon andiskutiert. Wenn Hersteller Ihre API um Eigenschaften, URL-Parameter etc. erweitern wollen, die nicht im Standard definiert sind, kann es bei zufälliger Benennung zu Überschneidungen bei zukünftigen Weiterentwicklungen des Standards kommen.

Angenommen, der Standard definiert eine Klasse "Person" mit nur einer Eigenschaft "name":

{
    name: "Hans Wurst"
}

Hersteller A möchte zusätzlich das Geburtsdatum der Person mit ausgeben können und nennt die Eigenschaft "date".

{
    name: "Hans Wurst",
    date: "1970-01-01"
}

Nun wird der Standard erweitert und die Klasse "Person" soll ein eine weitere Eigenschaft für das Beitrittsdatum der Person mit dem Namen "date" bekommen. Hierdurch kommt es zu einem Namenskonflikt. Hersteller A muss seine Implementierung anpassen, sonst liefert die Eigenschaft "date" nicht den erwarteten Wert.

Eine mögliche Lösung hierfür sind hersteller-spezifische Namenspräfixe. Nehmen wir an, der Hersteller A hat das Namenspräfix herstellera gewählt, dann wäre, in Anlehnung an MIME Types und HTTP Header folgende Nomenklatur möglich:

{
    name: "Hans Wurst",
    x-herstellera-date: "1970-01-01"
}

Gleiches gilt für URL-Parameter. Beispiel:

/api/people?x-herstellera-date=1970-01-01

Für herstellerspezifische Methoden könnte dieses Prinzip ebenfalls eingesetzt werden. Beispiel:

/api/x-herstellera-supermethode?foo=bar

Dies lässt als Herausforderung übrig, dass die Vergabe der Namenspräfixe zumindest zentral dokumentiert werden sollte. Das können wir leisten.

In vorangegangenen Beiträgen ist bereits auf den Zusammenhang von OParl und LOD hingewiesen worden. Die Nutzung des GovData-Metadaten-Standards könnte diese Überlegungen für eine spätere OParl-Version vorbereiten.

Geoportal.de und DeStat.de werden bereits auf Basis von Metadaten-Standards verlinkt. Bei einer Verwendung von Metadaten-Standards für RIS könnten ebenfalls interessante Potenziale durch Verlinkung entstehen.
Der GovData-Metadaten-Standard könnte zumindest auszugsweisen genutzt werden und die 14 GovData-Kategorien könnten durch eine zusätzliche Verschlagwortung auf Basis von Standard-Schlagwortkatalogen für RIS eine Ergänzung erfahren ( LeiKa, Bremer-Katalog, SKOR, Dbpdia, RAMON).

Unter Leitung von Mehr Demokratie-NRW evaluiert abgeordnetenwatch.de im Rahmen des LOD2-EU-Projektes die Möglichkeiten von LOD für RIS. Die Ergebnisse könnten sicher zu einer Konkretisierung der LOD-Überlegungen für eine spätere OParl-Version beitragen.
Eine Kategorisierung und Verschlagwortung an der Quelle durch das GovData-Metadaten-Schema dürfte auch unabhängig von LOD große Vorteile bieten, um die Vergleichbarkeit und Suche der RIS optimieren zu können.

• Attribute aus GovData-Metadaten-Schema auszugsweise verwenden:
  http://htmlpreview.github.com/?https://github.com/fraunhoferfokus/ogd-metadata/blob/master/OGPD_JSON_Schema.html
• Attribut - Schlagworte - ergänzen (Basis: Standard-Schlagwortkataloge).

Beispiele sind immer sehr gut und anschaulich. Ich würde mich aber dafür aussprechen zusätzlich ein JSON-Schema für die Schema-Validierung von Anfragen zu entwickeln.

Diese können dann auch für die Zertifizierung verwendet werden. Dieses Issue soll eigentlich nur JSON-Schema ins Spiel bringen und abfragen, ob es grundsätzliche Einwände gegen dieses Vorgehen gibt.

Ein issue zum Tracking der Erstellung von OWL 2 Ontologien, die dem Datenmodell entsprechen. Alternativ kommt eventuell auch RDF Schema (RDFS) in Frage. (RDFS ist in OWL 2 enthalten)

Hat aktuell keine hohe Priorität.

Die aktuelle Beschreibung sieht vor, dass "Sitzung" nur auf drei verschiedene Drucksachen verweisen kann (Einladung, Ergebnisprotokoll, Wortprotokoll). In der Praxis kann jedoch die Sitzung beliebige weitere Anhänge haben. Die Beschreibung und Abbildung müssen entsprechend erweitert werden.

Hilfreich wäre noch das Attribut, Gremientypen, da Kommunen gleiche rechtliche Funktionen unterschiedlich bezeichnen und es hilfreich wäre, den verschiedenen Gremiennamen einheitliche rechtliche Entsprechungen zuordnen zu können, vgl.:

http://www2.bonn.de/bo_ris/ris_sql/hbr_gremien_start.asp?e_caller=hbr_gremien_result

• Rat
• Hauptausschuss
• Ausschuss

Ergänzungen

• Unterausschuss
• Beirat
• Projektbeirat
• Kommission
• AG
• Verwaltungsrat
• usw.

Der Standard sollte beim Dokumentenabruf neben dem Streamen (Antwort des Servers

• 200 OK) auch
  auch
• 307 Moved Temporarily :
  "Der angeforderte URL wurde verschoben, aber nur temporär. Der Location-Header enthält die neue Position, über die zukünftige Gültigkeit dieses Redirects wird aber nichts ausgesagt. Der Client sollte auch zukünftig den Original-URL besuchen."

vorgesehen. Damit ergibt sich serverseits die Möglichkeit, neben einem Streamen des binären Inhalts optional auch ein Redirect auf einen (Zufalls-) URL auszuführen.

Nicht nur OParl-APIs von RIS-Server sollten getestet und zertifiziert werden können, sondern auch OParl-Clients. Dafür wäre ein Beispiel-Server hilfreich, der (eventuell manuell erzeugte) statische JSON-Dokumente ausliefert.

Wie werden neue Informationen bekannt gemacht? Atom Feeds?

Beispiele:

• Feed für Änderung der Zusammensetzung eines Gremiums
• Feed für neue Tagesordnungen eines Gremiums

Ich habe einen Entwurf des Datenmodells erstellt:
http://www.sitzungsdienst.net/downloads/oparl/OParl-ORM.pdf bzw.
http://www.sitzungsdienst.net/downloads/oparl/OParl-ORM.zip
(Im ZIP ist eine XML-Datei enthalten, die auf www.draw.io geöffnet und editiert werden kann.)

Es sind anschaulich die Relationen zwischen den einzelnen Entitäten aufgezeigt.
Die Entitäten und Felder ergeben sich aus der Doku von Herrn Steinbach, ergänzt um welche, die wir aus Erfahrung für erforderlich halten und bei denen uns die anderen RIS-Hersteller sicherlich zustimmen.

Erläuterungen zu einigen Eigenschaften:
Beratung.Aktion: Werte sind z. B.

• Vorberatung
• Kenntnisnahme
• Beschlussfassung
• 1. Lesung

Dokument.Kategorie: Art des Dokuments (Drucksache, Einladung, Protokoll, Beschluss, Anlage)

Wir haben bei uns im Haus diskutiert, wie Gremien, Mitgliedschaften, Personen, Fraktionen sinnvoll abgebildet werden können. Der Teil würde im Datenmodell einen wesentlich größeren Teil einnehmen, als die aktuelle Version umfasst. Daher ist unser Vorschlag, sich im ersten Schritt und vielleicht sogar in der ersten Version der Schnittstelle auf Termine und Dokumente zu konzentrieren. Um die Gremienzusammensetzung zu sehen, kann man eine URL zu Ursprungs-RIS angeben (siehe Gremium.URL).

Wie kann ich den "Datenmodell"-Label an diese Issue heften?

http://parlmnt.com/#/api ist eine API für Daten des britischen Parlaments. Möglicherweise enthält sie die eine oder andere gute Idee.

Ich schlage vor, in die OParl-Spezifikation einen unverbindlichen Hinweis auf dieses für die Europäische Kommission erstellte Dokument aufzunehmen:

Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC,
2012-12-17,
https://joinup.ec.europa.eu/sites/default/files/D7.1.3%20-%20Study%20on%20persistent%20URIs.pdf

Leider ist eine grundsätzliche Haftungsbeschränkung auf den Ursprung einer rechtsverletzenden Nutzungskette aus Datenschutz- und Lizenzrechtsverletzungen, auch wenn die Quelle z. B. durch ein Häckchen die Unbedenklichkeit aus ihrer Sicht erklärt, nach denen mir vorliegenden Erkenntnissen nicht möglich.

Auf der anderen Seite verfügt die Verwaltung über die qualifizierteste Möglichkeit zur Bewertung ihrer eigenen Daten, da ihnen die vertraglichen Vereinbarungen ihrer Gutachten und auch der Erfassungsvorgänge personenbezogener Daten in den Drucksachen bekannt sein sollten.

Man sollte Drucksachen grundsätzlich als intern verwendbare Daten kennzeichnen und die Verwaltung auffordern, diese zu prüfen und gegebenenfalls freizugeben.
Es wird sonst z. B. fast so viele rechtliche Bewertungen der verwendbaren Kölner Drucksachen geben, wie es Nutzer der OParl Schnittstelle geben wird.
Viele Kategorien an Drucksachen sind beim Kenntnisstand der Verwaltungen sehr einfach freizugeben. Es fehlt in der Regel nur der Wille. Erst wenn man selbst betroffen ist, handelt die Verwaltung auch, s. Köln OpenStreetMap oder in Bonn sind vielleicht 10% der Drucksachen kritisch, um eine entsprechende Lösung für die anderen 90% bemüht man sich seit über 6 Monaten nicht.

Hier sollte vielleicht ein entsprechendes Benchmarking auf der OParl - Webseite den notwendigen öffentlichen Druck erzeugen, die Drucksachen auch wirklich zu prüfen und freizugeben.
Die regionalen Medien dürften diesen Vorgang schon aus eigenem Zugangsinteresse entsprechend in der Öffentlichkeit begleiten.
OParl Anwender die Drucksachen ohne FREIGABE öffentlich verwenden, nutzen dies mit entsprechend erhöhtem Risiko.

• Status: INTERNE VERWENDUNG oder FREIGABE

Bei den Terminen sollte eine Möglichkeit bestehen, den Ort genauer anzugeben. Entweder durch ein einfaches Textfeld, oder durch eine Beziehung zu einem "Ort"-Objekt.

Beispiele, wo das in München vorkommt:
http://www.ris-muenchen.de/RII2/RII/ris_sitzung_detail.jsp?risid=2799821
http://www.ris-muenchen.de/RII2/BA-RII/ba_sitzungen_details.jsp?Id=2817299

Für Gremienmitgliedern können bisher keine unterschiedlichen Funktionen bzw. kein unterschiedlicher Status in Abhängigkeit von ihrer Gremien- bzw. Sitzungszugehörigkeit definiert werden:
Ein Ratsmitglied kann z. B. auch in einem weiteren Ausschuss den Status eines Sachkundigen-Bürgers innehaben bzw. ein Ratsmitglied kann gleichzeitig auch Bezirksverordneter sein.

• Status (Person)
• Buergermeister
• Bezirksbuergermeister
• Stadtverordneter
• Bezirksverordneter
• Sachkundige Buergerin /Buerger
• Einzelstadtverordnete (Mitglieder des Rates die keiner Fraktion/Organisation angehören -> die Zuordbarkeit einer fiktiven Organisation ermöglichen)
• Funktion (Gremium):
• Vorsitzende/er des Gremiums
• 1. Stellvertreter/in des Gremiums
• 2. Stellvertreter/in des Gremiums
• Schriftführerin
• Stellvertretende Schriftführerin
• Ordenliches Mitglied des Gremiums
• Stellvertretendes Mitglied des Gremiums
• Funktion (Sitzung)
  • Vorsitzende/er des Gremiums
  • Schriftführerin
  • Ordentliches Mitglied des Gremiums (EDIT: wird NICHT umgesetzt)

Ich schlage vor, neben dem Datenmodell ein neues Label Objekttypen anzulegen, in dem je Eintrag ein Objekttyp (Gremium, Sitzung, Drucksache usw.) definiert wird und es uns (den RIS-Anbietern) ermöglicht, auf einfache Art und Weise die Datendeklarationen abzustimmen und ggf. fortzuschreiben. Einzelne Datenfelder könnten mit einem Firmenkürzel versehen werden.

Objekttyp: Beratung
Beziehungen: Sitzung, Drucksache
Eigenschaften:

• Eigenschaft1
• ...
• Eigenschaft6
• Eigenschaft7 (ALR)
• Eigenschaft8 (SOM)
• Eigenschaft9 (SST)

@marians: ließe sich das kurzfristig einrichten?

Falls das noch nicht erwähnt ist: Insbesondere Bei Antworten auf Anfragen wäre es wichtig, einen formellen Verweis zur ursprünglichen Anfrage-Drucksache zu haben.

Das Prinzip lässt sich aber noch auf andere Beziehungen erweitern.

Die Fertigstellung der ersten OParl-Version wird sich wohl kaum noch bis Ende Juni 2013 realisieren lassen.

Ich halte es daher für sinnvoll einen aktualisierten Zeitplan aufzustellen.

Wenn es keinen besonderen Zeitdruck gibt, dann sollten wir die saubere Unterstützung/Verwendung von JSON-LD als ein Ziel für die erste Version aufnehmen. Den zusätzlichen Aufwand dafür halte ich, wie bereits an anderer Stelle ausgeführt, für gering (eventuell ist er sogar negativ ;-).

Sofern der Standard nicht schon vorschreibt, unter welchen Lizenzen die Daten veröffentlicht sein müssen, wäre es vielleicht sinnvoll, gerade bei den Drucksachen die Möglichkeit vorzusehen, Angaben über die Lizenz des Dokuments mitzuliefern. Also insb. ob eine kommerzielle Weiterverwendung oder eine Veränderung der Daten zulässig ist.

Also z.B. ein ENUM-Feld mit den Möglichkeiten "CC-BY", "CC-BY-SA", "CC-ND", ..., "other", oder aber ein freies Textfeld mit ein paar Konventionen zur Benennung von Standardlizenzen wie den CC-Lizenzen.

Für die meisten Objekttypen wird ein Datum bzw. Datum/Uhrzeit der letzten Änderung hilfreich sein. Dieses muss noch in die Eigenschaften-Beschreibung eingefügt werden.

An verschiedenen Stellen wird ein Tages-Datum mit bzw. ohne Uhrzeit angegeben. Das Format sollte spezifiziert werden. Beispiel:

"last_modified": "2012-08-16T14:05:27+02:00"

Sitzung start: Datum und ggf. Uhrzeit des Anfangszeitpunkts der Sitzung. Beispiel:

"start": "2013-01-04T08:00:00+01:00",

Drucksache (date) : Datum der Veröffentlichung. Beispiel:

"date": "2013-01-04"

Das letzte Beispiel entspricht offenbar dem in ISO 8601 (gleich EN 28601) spezifizierten erweiterten Format für ein Datum ohne Zeitangabe mit Mittelstrich als Trennzeichen.

Noch besser ist ein Verweis auf RFC 3339 (http://www.ietf.org/rfc/rfc3339.txt), dieser Standard bezieht sich auf ISO 8601.

An verschiedenen Stellen ist die Ausgabe von mail-Adressen vorgesehen.

Sollen in OParl Vorkehrungen gegen den automatischen Abruf durch Spammer getroffen werden oder sollen nur Hinweise auf die Problematik aufgenommen werden?

Hier soll das Für und Wieder von und die Alternativen zu URL-Parametern bei Methodenaufrufen diskutiert werden.

Eine Möglichkeit, um beispielsweise von einer Methode http://einris.de/api/sessions die öffentlichen Sitzungen abzurufen, wäre:

http://einris.de/api/sessions?public=1

Was spricht dagegen? Welche bessere Möglichkeit gibt es?

(Die Diskussion wurde schon in #13 begonnen und nun in ein eigenes Issue ausgelagert.)

Von @lanthaler wurde in #10 diese Fragestellung zusammengefasst (hier leicht gekürzt):

HTTP arbeitet mir URLs. Wenn es nicht eine SOAP-ähnliche API werden soll, führt meiner Meinung nach wirklich kein Weg an URLs vorbei. Der einzige andere Weg den ich sehe ist wie gesagt ein SOAP-ähnliches Interface, d.h., alle IDs werden per POST an eine URL geschickt das dann die jeweiligen Daten zurückgibt. Ich hoffe wirklich sehr dass das nicht so beabsichtigt ist.

Meine Fragen sind also:

1. Können wir davon ausgehen, dass auf die JSON-Dokumente durch jeweils eine URL per http GET zugegriffen werden kann ?
2. Spricht etwas dagegen, dass diese URLs auch in anderen OParl JSON-Dokumenten als Referenzen verwendet werden und dies auch in OParl 1.0 festgelegt wird ? (Also eine URL statt z.B. "0003/2013" für eine Drucksache)

Die Fragen richten sich an alle, besonders aber an die RIS-Hersteller.

Einhellige Zustimmung würde einiges vereinfachen.

Wir müssen klären, ob das Thema Suche im Standard Version 1.0 enthalten sein soll oder nicht. Mein Vorschlag ist, es nicht in den Standard aufzunehmen, trotz der damit verbundenen Konsequenzen.

Es geht auch ohne. Die Methoden zum Abruf der verschiedenen Objekte sollten natürlich bestimmte Kriterien zur Einschränkung (Filterung) der Rückgabe bieten. Beispiele: Sitzungen mit Termin innerhalb eines bestimmten Datumsbereichs, Drucksachen vom Typ "Antrag".

Suche wäre beispielsweise: Drucksachen, die den Begriff "radfahrer" enthalten.

Die sinnvolle Beantwortung einer solchen Suchanfrage erfordert auf Seite des Systems die Indexierung der Inhalte, idealerweise die Grundformreduktion (radfahrerin/radfahrers/radfahrern/... => "radfahrer"), dafür üblicherweise die Pflege von Stoppwortlisten und darüber hinaus möglicherweise die Pflege von Synonymen. Bei der Rückgabe stellt sich die Frage, wie diese sortiert sein soll (Relevanz-Sortierung? Nach welchen Kriterien?).

Alle diese Aspekte machen Suche zu einem Thema, das viel Spielraum für Interpretation lässt. Nach meiner Vorstellung sollte der API-Standard nicht zu solchen Interpretationen einladen, die fast zwangsläufig zu unterschiedlichen Ergebnissen führen. Die API sollte sich hier viel mehr neutral verhalten.

Keine Suche in den Standard zu integrieren bedeutet natürlich, dass man das Thema komplett an die Nutzer der API auslagert bzw. die Clients auslagert. Um eine Suche bieten zu können, müssen also API-Nutzer zunächst Inhalte ausgelesen und indexiert haben. Leichtgewichtige mobile Anwendungen oder beispielsweise rein JavaScript-basierte Anwendungen, die direkt auf die API zugreifen, würden es dadurch schwer haben, Nutzern eine Suche bieten zu können.

Hier ein paar Anmerkungen, die sich auf das Münchner Ratsinformationssystem http://ris-muenchen.de/ beziehen

Termin:

Hier sollte zumindest noch der Ort der Sitzung mit hinein.
Zum Feld "Nummer": Das "Nummer"-Feld scheint in München nur in Kombination mit dem "Öffentlich"-Feld eindeutig zu sein: es gibt pro Sitzung einen öffentlichen und einen nicht-öffentlichen Teil - in jedem wird mit Nummer 1 zu zählen angefangt. Beispiel: http://www.ris-muenchen.de/RII2/RII/ris_sitzung_detail.jsp?risid=2799385 . (Bei Nicht-Öffentlichen TOPs ist aber der Name des TOPs trotzdem öffentlich einsehbar)

Drucksache:

• Typ: Hier gibt es in München bei den Bezirksausschüssen noch "Initiativen", in Abgrenzung zu "Anträgen". Sie sind im RIS völlig separat aufgeführt, http://www.ris-muenchen.de/RII2/BA-RII/ba_initiativen.jsp?Men=j im Vergleich zu http://www.ris-muenchen.de/RII2/BA-RII/ba_antraege.jsp?Men=j&nav=1&selTyp=BA-Antrag
• Typ: Wortprotokolle werden in der Dokumentation des bisherigen Datenmodells weiter oben als Drucksache erwähnt, finden sich aber im Abschnitt Drucksache nicht mehr (explizit) wieder.

Ort:

• Hier schlage ich vor, von vorne herein gewisse "Zuverlässigkeitsgrade" der Ortsangaben zu unterscheiden. Also "Amtlich zugeordnet" (wenn die Eingabe durch eine Bedienstete der Stadt erfolgte), "Automatisch erkannt" (bei automatischen Algorithmen), "Von unbekannten Dritten" (Benutzer-Tagging), "Von der Antragsstellerin".

Gremium:

http://www.ris-muenchen.de/RII2/RII/ris_gremien_trefferliste.jsp?nav=1
Gremien werden durch eine (interne) numerische ID, ein eindeutiges Kürzel und einen Namen gekennzeichnet. Jeder einzelne Wert ist für sich genommen auch eindeutig.

Ergänzen könnte man das Objekt - Gremium -, noch durch ein Attribut - Gremienthemen - .

Man findet bundesweit kaum einheitliche inhaltliche Bezeichnungen für die verschiedenen kommunalen Gremien unterhalb des Rates oder Hauptausschusses.
Die verschiedenen Politikfelder werden sehr unterschiedlichen Ausschüssen zugeordnet, die sich nicht aus dem Namen der Gremien erschliessen müssen, z. B. Agenda 21 kann Teil des Bürger- aber auch Umweltausschusses sein.

Eine einheitliche bundesweite Kategorisierung der Gremien wäre für die Analyse der Politikprozesse sehr wichtig. Dies setzt aber die Möglichkeit der Verschlagwortung voraus, z. B. mit Katalogen aus LeiKa, SKOR, Dbpedia oder durch das harvesting der Ausschussbezeichnungen der Workshop-RIS-Anbieter.

Die Limitierung des Umfangs der API sollten durch den Datenschutz (betrifft Objekt: Person, Tagesordnung, Drucksache) und das Urheberrecht (betrifft: Objekt: Drucksache) definiert sein.

Das Objekt - Person - könnte folgende datenschutzrechtliche Überlegungen berühren:

• Welche personenbezogenen Daten können weder als Pflicht- noch als optionale Attribute Verwendung finden?
• Welche Unterschiede bei der Nutzung gibt es auf den verschieden politischen Ebenen?

Die Veröffentlichung der Adresse und Tel. des Büros eines Landtagsabgeordneten ist nicht gleich zu setzen mit den privaten Adressangaben eines Nicht-Berufspolitikers auf der kommunalen Ebene, auch wenn beide Adressen im PIS bzw. RIS aufgeführt sind.

Für die API sollte man sehr vorsichtig mit dem Thema Datenschutz umgehen, da der API-Erfolg entscheidend von der Zustimmung der Räte abhängt, die definierte Schnittstelle auch mit Daten bedienen zu wollen. Eine öffentliche Diskussion über die mangelnde datenschutzrechtliche Zuverlässigkeit der Schnittstelle dürfte ihren Erfolg sehr in Frage stellen. Eine datenschutzrechtliche Zertifizierung wäre hier sicher hilfreich.

Da die Daten zwar öffentlich über das RIS zur Verfügung stehen, aber eine Verwendung durch Dritte sich daraus nicht automatisch ableiten lässt, würde bei den datenschutzrechtlich und urheberrechtlich relevanten Objekten auch eine Beschreibung, nur zur - internen Verwendung - benötig. Diese könnten für interne Apps-Schnittstellen genutzt werden, für statistische Auswertungen oder auch nach Klärung der Rechtslage freigeschaltet werden.

Abgeordnetenwatch hat bezüglich des datenschutzrechtlichen Rahmens zur Veröffentlichung von personenbezogenen Daten für die Landesebene NRW ein Gutachten erstellen lassen:
http://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument?Id=MMI15/49
Zurzeit befindet sich ein weiteres Gutachten für die kommunale Ebene in Arbeit, das aber wahrscheinlich nicht bis zum 30.6. zur Verfügung stehen wird.

(#48 Original lässt sich nicht wieder öffnen)

• Zeitpunkt des Votums mitloggen

marians:

Personenbezogene Nachvollziehbarkeit der Stimmabgabe ist in jedem Fall erwünscht, wenn die entsprechende Information erfasst wird und beispielsweise auch im Protokoll nachvollziehbar wäre. Da wir bei jedem Tagesordnungspunkt die Abwesenheit von Personen abbilden können und außerdem bei der Abstimmung bei Bedarf individuelle Stimmabgaben erfasst werden können, sollte dies ausreichen.

Bitte wieder öffnen, wenn ich mich irre.
Closed

marians closed the issue 5 hours ago

Eine Rückmeldung von QuinScape zeigt, dass die Abgrenzung des Entwurfs noch nicht klar genug ist. Es geht dabei aktuell nur um eine Lese-API auf öffentliche Inhalte. Das sollte deutlich herausgestellt werden.

Neben der in #11 behandelten Körperschaft gibt es eventuell auch andere Daten die (auch) als Meta-Information des Datensatzs auf standardisierte Weise zugänglich gemacht werden sollte. Das können z.B. der Name und Version der Software sein, auf der das RIS läuft oder auch ein Ansprechpartner für die OParl-Schnittstelle. Eventuell auch Angaben zur OParl-Version oder Unterstützung von optionalen OParl-Features.

Unabhängig von den datenschutzrechtlichen Überlegungen, #43 wären folgend weitere Attribute für das Objekt - Person - hilfreich:

• Tel., Fax und E-Mail würden 2x benötigt: Wie für Provox dargestellt, ist es auf kommunaler Ebene häufig üblich, sowohl private als auch geschäftliche Daten anzugeben.
• Twitter- und/oder Facebook-Accounts: sind bei +/- 10% der Gremienmitglieder vorhanden und könnten mit erfasst werden.
• Familienstand: wird häufig auch erfasst.
• Ausgeübter Beruf: Angabe wäre bei Nicht-Berufsparlamentariern auf kommunaler Ebene wegen möglicher Interessenkonflikte noch von politischer Bedeutung
• Sonstige Tätigkeiten: Angaben über Verbandstätigkeiten, usw. wären auf allen politischen Ebenen wegen möglicher Interessenkonflikte, ebenfalls von Bedeutung.

Die meisten Systeme führen Angaben über Tätigkeiten von Personen (im Sinne von z.B. § 17 Korruptionsbekämpfungsgesetz NRW).

Diese Angaben sind bisher nicht vom Datenmodell abgedeckt.

In einigen Räten wird der Zeitpunkt der Anwesenheit im Ratssaal und in einigen Räten sogar der Anwesenheitsverlauf im Ratssaal während der Sitzung erfasst.

Da, außer bei namentlichen Abstimmungen, eine personenbezogene Erfassung der Abstimmungsergebnisse, obwohl nicht geheim, mit dem Hinweis auf den administrativen Aufwand in den Räten bisher nicht erfolgt, käme der zeitlichen Erfassung eine hohe Bedeutung zu, um die Abstimmungsergebnisse personenbezogen zuordnen zu können.
Der Wähler hat erfahrungsgemäß ein Interesse an dem Abstimmungsverhalten seiner Politikvertreter, insbesondere in Bundesländern mit kumulierendem und panaschierendem Wahlrecht auf kommunaler Ebene.
Diese sehr eingeübte Praxis der Gremienmitglieder, sich durch das Fernbleiben im Ratssaal einem Abstimmungskonflikt gegenüber der eigenen Fraktion zu entziehen, bedürfte dringend einer Transparenz gegenüber dem Wähler.

Durch die Ergänzung des Objektes Sitzung durch ein Objekt Sitzungsverlauf, könnte eine entsprechende Transparenz bei den diese Daten bereits erfassenden Kommunen (z. B. Köln) erfolgen.
Auch für eine angemessenere Abrechnung der Sitzungsgelder dürfte dieses Objekt hilfreich sein.

Einer Stärkung des parlamentarischen Systems käme die Aufbereitung dieser Daten sicherlich zugute.

Nicht jeder kennt die unterschiedlichen Organisationseinheiten in den verschieden kommunalen Verwaltung bzw. die Abkürzungen regionaler Parteien in anderen Kommunen.