Eindeutige Kennung für Körperschaften about spec HOT 30 CLOSED

http://de.wikipedia.org/wiki/Amtlicher_Gemeindeschl%C3%BCssel

from spec.

Neue Erkenntnis nach kurzer Recherche: Der Amtliche Gemeindeschlüssel (AGS) kann im Sinne einer ID langfristig nicht eindeutig sein. "Der Amtliche Gemeindeschlüssel (AGS) unterliegt hauptsächlich aufgrund von Gemeindezusammenlegungen und Gemeindereformen ständigen Veränderungen" (s. BIT). Folglich wäre eine andere Lösung zu finden. Gruß aus 11000000!

from spec.

Dass gelegentlich ein AGS wegfällt oder neu entsteht ist bezüglich Eindeutigkeit wohl kein Problem. Und zumindest in Kombination mit einem Datum dürfte ein AGS auch immer eine eindeutige Bedeutung haben.

Ob bei Gemeindezusammenlegungen oder Gemeindereformen die RIS richtig neu konfiguriert werden ist eine andere Frage - die sich aber auch bei jeder anderen Art von Kennung stellen wird.

Eventuell sollten auch die Spezialisten vom Statistischen Bundesamtes um Rat gefragt werden. Einerseits sind die für AGS und Regionalcodes zuständig. Andererseits müssen Statistiker ja auch darauf achten, dass Gemeindezusammenlegungen und Gemeindereformen nicht statische Untersuchungen unmöglich machen.

Eine ähnliche Problematik gibt es übrigens auch bezüglich Ländern und Territorien. Auch die ISO 3166 Ländercodes sind nicht über alle Zeiten konstant. Manchmal verschwindet z.B. ein Land, Beispiel DDR, manchmal ändert sich ein offizieller Name wie zuletzt im Falle Libyens.

from spec.

Mir ist der Mehrwert einer eindeutigen Kennung für Gemeinden nicht klar.

Den Gemeindeschlüssel in irgendeiner Weise über die API auszuweisen halte ich auch nicht für sinnvoll. Was soll das bringen?

from spec.

Es gibt zwei Gründe, warum eine eindeutige Bezeichnung der Gebietskörperschaften sinnvoll ist:

• Einige Systeme sind für mehrere Gebietskörperschaften (Mandanten) im Einsatz. Z.B. Ulmen

Stadt Ulmen: https://sessionnet.krz.de/ulmen/bi/to0040.asp?__ksinr=618
Verbandsgemeinde Ulmen: https://sessionnet.krz.de/ulmen/bi/to0040.asp?__ksinr=626

• Möchte man die Daten aus mehreren Systemen zusammen führen, muss man die Systeme eindeutig benennen.

Die Nummern- bzw. Namensräume der Kennungen aller möglichen Objekte sind nur innerhalb eines Systems eindeutig. Daher braucht man einen System-Schlüssel. Und wenn man den schon braucht, stellt sich die Frage, ob das System ihn nicht direkt selbst liefern kann.

from spec.

Ah jetzt glaube ich zu verstehen.

Ein Dokument im RIS der Stadt Köln hat eine Nummer und du möchtest jetzt eine ID bauen aus dem Gemeindeschlüssel und dieser Dokumentennummer?

Damit du das Dokument identifizieren kannst, selbst wenn es mit Dokumenten aus anderen Städten in einen Topf geworfen wird, gibt es im Web ein simples Mittel: URI!

Jedes Dokument, jedes Gremium, jede Sitzung muss durch einen URI identifiziert werden. Im einfachsten Fall ist das die URL, auf die ich ein HTTP GET mache um das JSON Dokument zu bekommen. Damit habe ich die einzige im Web relevante ID. Wozu also eine Gemeinde ID?

from spec.

Beim AGS würden die Bezirke Berlins nicht berücksichtigt. Das wären immerhin 12 Parlamente an der Zahl (ca. 300.000 Einwohner pro Bezirk)

Ich bin mir gerade nicht ganz sicher, ob z.B. auch Industrie- und Handelskammern als Körperschaften des öffentlichen Rechts (mit Parlamenten) berücksichtigt werden sollten. Stichwort "Open IHK".

from spec.

@jehrhardt Sagen wir es mal ganz platt: Ich möchte eine Datenbank befüllen können, in der das Dokument 123 aus Köln direkt neben dem Dokument 123 aus Bonn liegt. Dafür kann ich mir natürlich einen beliebigen kombinierten Schlüssel bauen aus Dokumenten-ID und einem selbst gebauten Gebietskörperschafts-Schlüssel wie zum Beispiel "Köln" und "Bonn" oder "K" und "B" oder "stadt-koeln.de" und "bonn.de". Aber genau so gut kann ich auch für jedes Dokument eine tatsächlich eindeutige URL nehmen.

Jetzt ist die Frage: Gibt es bescheuerte Fälle, bei denen das zu nicht so prickelnden Ergebnissen führt? Beispielsweise, weil ein Server unter zwei verschiedenen Hostnamen erreichbar ist? Im Prinzip bedeutet das für die API, dass sie selbst die "kanonischen" Objekt-URLs ausgeben sollte.

from spec.

Ok, dann verstehe ich es langsam. Ziel ist es also eine Kommunen spezifische ID auszugeben, damit ein Client sich aus dieser ID und einer Kommunen spezifischen Drucksachennummer eine ID basteln kann?

Halte ich nicht für Ziel führend. Wenn es um die eindeutige Identifizierung einer Drucksache geht, sollte man sich überlegen eine ID für Drucksachen zu definieren, die als Teil der Metadaten einer Drucksache raus gegeben wird.

Ich würde zu diesem Zweck immer eine vorhandene ID verwenden, wenn es denn eine gibt und ansonsten auf UUIDs zurückgreifen. Gibt es also eine Standard ID für Drucksachen in deutschen Parlamenten? Wenn nicht sollte man sich sowas auch nicht konstruieren sondern einfach UUIDs als zusätzliche ID vorschreiben. Das impliziert natürlich, dass Hersteller ihre RIS dahingehend aufbohren müssen.

from spec.

@marians Du hast natürlich Recht, dass URLs nur bedingt als IDs taugen. Neben URLs gibt es aber auch noch eine weitere Variante von URIs nämlich die URN. URN eignen sich vor allem als IDs. Verwendet man z. B. ISBNs bei Büchern, könnte man eine URN so urn:isbn:3442157439 aufbauen. Das isbn hinter urn ist dabei so eine Art Protokoll für das, was danach kommt.

Für Drucksachen könnte eine Variante so aussehen: urn:oparl+gemeindeschluessel:12054000:13/SVV/0175 könnte dann dieses Dokument identifizieren. Man könnte dasselbe Dokument aber auch mit dieser URN urn:oparl+koerperschaften:Brandenburg:Potsdam:13/SVV/0175 identifizieren. Beide Variante sind zwar gültige URNs, aber ihre Protokolle wurden natürlich von niemandem standardisiert, was sie er schwierig macht.

Der Bundestag scheint für seine Protokolle ISSNs zu verwenden, dort könnte eine URN urn:issn:0722-7980 dieses Dokument identifizieren.

Statt den Gemeindeschlüssel rauszugeben, sollten Drucksachen eine URN als ID Attribut haben. Für die URN könnte man dann zwei Protokolle zulassen:

• ISSN: urn:issn:0722-7980
• UUID: urn:uuid:8c69bccd-a1c9-438e-a002-3788895201ca

Jeder Anbieter hat dann die Möglichkeit sich für eine der beiden Varianten zu entscheiden. Evt. findet man noch einen geeigneten Standard, dann kann man die Liste der Protokolle erweitern. Auf jeden Fall sollte man mit dem zusammenbasteln von IDs vorsichtig sein!

from spec.

@jehrhardt schrieb: "Jedes Dokument, jedes Gremium, jede Sitzung muss durch einen URI identifiziert werden". Das finde ich grundsätzlich richtig. Es sollte dann aber auch für jede Gemeinde gelten.

Wenn man Daten aus vielen Gemeinden auswerten möchte, dann ist es sinnvoll dafür eine eindeutige Kennung zu haben. AGS halte ich dafür als Grundlage für geeignet.

Eine Frage ist dann aber noch, woher man diese Kennung bzw. URI bekommt. Ich sehe diese sich nicht gegenseitig ausschließenden Möglichkeiten:

1. Das RIS kann danach über eine API gefragt werden.
2. Automatische oder manuelle Verwendung von https://www.destatis.de/DE/ZahlenFakten/LaenderRegionen/Regionales/Gemeindeverzeichnis/Gemeindeverzeichnis.html

Gleiches gilt für den Namen der Gemeinde.

Was spricht denn gegen Alternative 1 ? Das sollte zumindest technisch kein Problem sein. Oder übersehe ich etwas?

Nicht klar ist mir, was üblicherweise tatsächlich bei einer Verschmelzung oder Aufspaltung von Gemeinden mit den entsprechenden RIS passiert. Deshalb halte ich die Möglichkeit einer Art Verifikation durch Alternative 2 für sinnvoll.

from spec.

@akuckartz Ich wäre auch dafür, dass die API selbst darüber Auskunft gibt, welche Gebietskörperschaften sie abbildet. Wenn Gemeinden umorganisiert werden, ist dies wohl in der Praxis auch mit Arbeit am RIS verbunden. Dann müssten ggf. im RIS neue Gemeindeschlüssel hinterlegt werden. Wäre IMHO kein Problem. Wenn wir tatsächlich Gemeindeschlüssel wollen.

from spec.

Ein Weg der Zuordnung einer Drucksache zu einer Gemeinde lässt sich am besten über einen Link auf eine Ressource, die die Gemeinde repräsentiert, lösen. Beispiel:

{
  "_links": {
    "koerperschaft": { "href": "http://www.potsdam.de }
  }
}

Natürlich impliziert das, dass es mindestens eine URL im Web gibt, die so etwas liefert und dazu noch in einem standardisierten Format. Es gibt eigentlich zwei Möglichkeiten:

• Wir schaffen innerhalb der OParl Spezifikation eine Ressource zur Beschreibung der Körperschaft (man sollte es vielleicht nicht auf Gemeinden beschränken). Dazu müsste man auch das darin enthaltene Format spezifizieren.
• Es gibt bereits ein standardisiertes Format dafür und es gibt einen Dienst, der dieses Format liefert. Man kann also einfach diese externe URL als Link angeben.

Die erste Möglichkeit hat den Nachteil, dass wir den Fokus verlieren. Unsere Domäne ist die Standardisierung von RIS APIs und ein RIS ist nicht der Ort an dem Informationen über die Gemeinde verwaltet werden, sondern der Ort an dem Drucksachen und Sitzungen verwaltet werden.

Die zweite Möglichkeit scheitert daran, dass es derzeit keine Option gibt. Das Statistische Bundesamt stellt zwar diese Onlineabfrage bereit, scheint aber keine verlinkbaren URLs zu benutzen. Eine API scheint es auch nicht zu geben.

Für Version 1

Ich würde vorschlagen, dass wir den Gemeindeschlüssel rauslassen und uns damit abfinden, dass es derzeit keine geeignete Möglichkeit gibt, eine verlässliche maschinenlesbare Beschreibung von Körperschaften zu bekommen. Wenn wir mit der ersten Version fertig sind, können wir daraus ein neues Projekt machen und eine weitere Spec schreiben.

Wir sollten aber zumindest in einer Art Root Objekt den Namen und einen optionalen Link auf die Homepage der Körperschaft hinterlegen.

from spec.

Ein Vorteil von mehr Zeit zur Klärung der Frage ist, dass dann eine Chance besteht das Statistische Bundesamt zu beteiligen.

from spec.

@akuckartz +1

from spec.

Ich habe die Hoffnung, dass das dann einfacher wird als vermutet. Denn dies ist für die Liste der AGS bereits festgelegt (gerade erst auf https://www.xrepository.deutschland-online.de gesehen) und wird auch bereits für andere Zwecke in XÖV verwendet:
"urn🇩🇪bund:destatis:bevoelkerungsstatistik:schluessel:ags"

:-)

Die Deutschland-Flagge fügt github automatisch hinzu ...

from spec.

@mionysos Alle Berliner Bezirke haben einen eigenen AGS.

11000000 Berlin, Stadt
11001001 Mitte
11002002 Friedrichshain-Kreuzberg
11003003 Pankow
11004004 Charlottenburg-Wilmersdorf
11005005 Spandau
11006006 Steglitz-Zehlendorf
11007007 Tempelhof-Schöneberg
11008008 Neukölln
11009009 Treptow-Köpenick
11010010 Marzahn-Hellersdorf
11011011 Lichtenberg
11012012 Reinickendorf

from spec.

Prinzipiell wird Sitzungsdienst auch von anderen tagenden Körperschaften eingesetzt z.B. Kirchengemeinden, Universitäten, Banken... sollten die berücksichtigt werden.

from spec.

@bschalitz Meiner Meinung kann "Gebietskörperschaft" durch "Körperschaft" ersetzt werden. Der Aufbau der Kennungen für Gebietskörperschaften muss ohnehin definiert werden. Das kann man machen, ohne gleichzeitig technisch andere Arten von Körperschaften auszuschliessen - und der Zusatz-Aufwand ist sehr gering.

from spec.

Es gibt die GKD = Gemeinsame Körperschaftsdatei: https://de.wikipedia.org/wiki/Gemeinsame_K%C3%B6rperschaftsdatei
bzw. die GKD ist nun in die GND übergegangen: https://de.wikipedia.org/wiki/Gemeinsame_Normdatei

Beispiele:
Köln: http://d-nb.info/gnd/2015732-0
Köln-Ehrenfeld: http://d-nb.info/gnd/4806120-7

Die GNDs werden in Wikipedia-Artikel ganz am Ende angezeigt. Im Moment ist Wikidata in Aufbau, so dass Wikidata bald als Quelle für GNDs dienen kann:

Köln: https://www.wikidata.org/wiki/Q365
Museum Wallraf in Köln: https://www.wikidata.org/wiki/Q700959

from spec.

Der Gemeindeschlüssel greift aber nicht mehr wenn es sich um andere Gremien als Kommunen handelt. Schließlich gibt es auch beim VRR einen Sitzungsdienst (http://zvis.vrr.de/bi/infobi.asp) für das ein potentielles Interesse besteht. Wie kann man das dann abbilden?

from spec.

Auch hier würde die GND helfen:

Für den VRR gibt es:
http://d-nb.info/gnd/2075900-9
bzw
http://d-nb.info/gnd/4010601-9
Wie man sieht, gibt es aktuell noch Duplikate. Die sind nach der Zusammenführung mehrer Datenbankbestände entstanden. Die Deutsche Nationalbibliothek arbeitet an einer Bereinigung.

from spec.

@elmarburke (Mit Linked Data ist das - fast - kein Problem ;-)

Ob für Oparl GND oder AGS als Grundlage geeigneter ist halte ich nach kurzer Überlegung noch nicht für klar. GND basiert offenbar nicht auf AGS. Tendentiell sind die Betreuer von AGS (das statistische Bundesamt) näher an der Struktur der Körperschaften als die Betreuer von GND (Bibliotheken im deutschprachigen Raum).

Eine Lösung kann möglicherweise so aussehen:

1. Kennung besteht nur aus AGS falls kein IRI/URN/URI verwendet wird. (EDIT: In JSON-LD wäre der Wert für Neukölln dann "_:11008008" im Körperschaftsdokument)
2. Verwendung von GND als IRI/URN/URI. Für Köln also "https://www.wikidata.org/wiki/Q365" oder "http://d-nb.info/gnd/2015732-0". Eine Festlegung auf wikidata oder d-nb.info durch OParl muss nicht zwingend erfolgen. (owl:sameAs kann bei Linked Data helfen :-)

from spec.

Info: "Gebietskörperschaft" ist jetzt im Entwurf zu "Körperschaft" umbenannt.

from spec.

Im aktuellen Entwurf findet sich nun ein Extrakt aus den Vorschlägen hier wieder. Bitte schaut Euch das mal an und kommentiert, ob man das nach Eurer Meinung so machen kann. Der AGS ist dabei übrigens dem "Regionalschlüssel" gewichen, hat aber letztlich die selbe Bedeutung.

from spec.

Musste den Abschnitt zur Körperschaft noch einmal aktualisieren. Da sich andere Objekte im System auf eine Körperschaft beziehen können müssen, braucht es auch eine interne ID für die Körperschaft. Die gibt es nun.

from spec.

Regionalschlüssel ist auf jeden Fall besser als AGS (wird auch vom statistischen Bundesamt empfohlen).

EDIT: Teil gelöscht, der möglicherweise nicht ganz richtig war. Greife ich eventuell später wieder auf. Eilt nicht.

Eine Kleinigkeit: "url" würde ich durch "body_url" o.ä. ersetzen.

from spec.

In der Annahme, dass es hierzu keinen Diskussionsbedarf gibt, schließe ich dieses Issue. Bitte vor dem 17. Mai wieder öffnen, falls sich doch noch diskussionswürdige Punkte ergeben.

from spec.

Auf dem Workshop haben wir beschlossen, dass es möglich sein soll, den AGS zusätzlich zum Regionalschlüssel anzugeben. Der AGS wird noch verwendet und wird erst in Zukunft vom Regionalschlüssel abgelöst.

from spec.

Das Body-Objekt hat jetzt die Eigenschaften "amtlicherGemeindeschlüssel" und "regionalschlüssel". Wir haben uns gegen die Abkürzungen "AGS" und "RS" entschieden, damit sofort klar ist, was gemeint ist. Die Abkürzung "RS" für "Regionalschlüssel" ist auch noch nicht wirklich verbreitet.

from spec.