Person > Body: Kann dieselbe Person in mehreren Körperschaften auftauchen? #243
Comments
|
bei uns nicht |
|
Das mag selten vorkommen, es ist aber nicht ausgeschlossen. Es gibt ja Gebietskörperschaften die sich flächenmäßig überlappen. Dann kann eine Person z.B. Mitglied eines Landtages sein und gleichzeitig in einem Ausschuss eines Gemeinderats als sachverständiger Bürger agieren. Solche Situationen fallen bisher deshalb nicht auf, weil die beteiligten Gebietskörperschaften regelmäßig separate Systeme verwenden - selbst wenn die Software vom selben Hersteller stammt. |
|
Es ist die Regel, dass Mandatsträger aus Städten und Gemeinden im Kreistag des zugehörigen Kreises vertreten sind. Ich sehe hier allerdings keine Möglichkeit, diese Personendaten auf Client-Ebene zusammenzuführen, es sei denn, dass z. B. eine eindeutige ID (z. B. SV-Nummer) unter |
|
Dann ist die Antwort auf die Eingangs-Frage offenbar ein eindeutiges JA. Entsprechend sollte auch die Spezifikation das Auftauchen in mehreren Körperschaften ermöglichen. Die Vorteile überwiegen jedenfalls die geringen Nachteile eventuell etwas größeren Aufwands auf Clientseite. |
|
Die Frage ist eindeutig mit NEIN zu beantworten. Ein oparl:Person-Objekt existiert in genau einer Körperschaft. Siehe meine vorstehenden Ausführungen. |
|
Die Frage war: "Kann dieselbe Person in mehreren Körperschaften auftauchen?". Diese plausible Aussage beantwortet die Frage: "Es ist die Regel, dass Mandatsträger aus Städten und Gemeinden im Kreistag des zugehörigen Kreises vertreten sind." Ob solche Situationen mit gegenwärtiger RIS-Software abgebildet werden können oder werden ist irrelvant, da es hier nur um die Kardinalität in einer Spezifikation geht und deshalb die Realität vorgehen muss und nicht die gegenwärtige RIS-Praxis. |
|
@akuckartz Können Sie mir bitte ein kurzes Beispiel geben, wie das abgebildet werden soll, sowohl in der einen Körperschaft als auch in der anderen? Wie sieht die die Handhabung durch den Client aus? Welchen Nutzen zieht der Client daraus? |
|
@sterni24 Der Server muss (bzw. die Server müssen) dazu in beiden Körperschaften das selbe Personenobjekt (URL) verwenden. Der Client bekommt dadurch die Möglichkeit zu der einen Person auch die Informationen der jeweils anderen Körperschaft anzubieten. Ein Benutzer kann damit über die Person zwischen den beiden Körperschaften hin und her wechseln. |
Der Server muss (bzw. die Server müssen) dazu in beiden Körperschaften das selbe Personenobjekt (URL) verwenden Wie soll das funktionieren? Hierzu meine Anmerkungen von oben:Ich sehe hier allerdings keine Möglichkeit, diese Personendaten auf Client-Ebene zusammenzuführen, es sei denn, dass z. B. eine eindeutige ID (z. B. SV-Nummer) unter oparl:Person ausgegeben wird. Aber diese Merkmale wird es auch bei den RIS-Betreibern nicht geben. Wenn Sie die Zusammenführung serverseitig vorhaben, würde mich Ihr Lösungsansatz interessieren. |
|
@sterni24 Ja, das kann bzw. sollte auf dem Server geschehen. Wenn man von einem Server ausgeht der von beiden Körperschaften verwendet wird, dann muss für beide Körperschaften eine Person nur einmal unter einer URL ausgegeben werden. Ein technisches Problem sehe ich dabei nicht. Selbstverständlich sollten sich die beiden Körperschaften vorher auf ein solches Vorgehen einigen. |
|
@marians Sofern die anderen RIS-Hersteller dazu keine andere Meinung haben, bitte ich darum, diesen Weg nicht weiter zu verfolgen. Zwischen Person und Körperschaft gibt es eine 1:1 Beziehung. Die von @akuckartz erwähnte Realität (eine Person in 2 oder mehr Körperschaften) ist, dass sich solche Daten weder programmtechnisch abgleichen noch mittels Absprachen zwischen Körperschaften zusammenführen lassen. Letzteres geht doch erheblich an der Praxis (Realität) vorbei. Das Gleiche gilt entsprechend für #245. |
|
Es ist nicht die Aufgabe von Spezifikationen gegenwärtig möglicherweise bestehende Restriktionen von Server-Implementierungen zu verewigen. OpenGovLD wird hier deshalb flexibel sein. Kein Anbieter oder Betreiber von Server-Software wird dadurch gezwungen eine Person in mehreren Körperschaften als identische Objekte zu behandeln. Bezüglich #245 hatte ich bereits auf #55 verwiesen. Auch dies wird in OpenGovLD entsprechend berücksichtigt. |
|
Zwischen Person und Körperschaft existiert in der Praxis eine 1:1 Beziehung. Spezialfälle wie eine Samtgemeinde ( Verband und eigene Mitgliedsgemeinden - Person jedoch nur einmalig) sollten zum jetzigen Zeitpunkt ebenfalls nicht weiter verfolgt werden. |
|
@BThie Es geht hier nur um die Festlegung der erlaubten Kardinalität. Es wurden mehrere Beispiele genannt, wo solche Fälle in der Realität vorkommen. Ich sehe deshalb keinen Grund (jedenfall keinen guten) die Kardinalität auf 1 zu beschränken. Wenn Betreiber von Servern dort nur 1 Wert ausgeben wollen, dann verstossen diese nicht gegen die Spezifikation. Wenn aber ein Server mehrere Werte hat (z.B. mehrere Körperschaften für eine Person) und diese aufgrund einer technisch nicht begründeten Beschränkung einer Spezifikation nicht ausgeben kann, dann ist das ein Problem. |
|
Es gibt 2 Gründe warum es jetzt für OParl 1.0 eine 1:1 Beziehung geben sollte: |
|
In der Bremischen Bürgerschaft (Land Bremen) ist dies in gewisser Weise sogar die gesetzliche Regel. Deren Mitglieder für die Stadtgemeinde Bremen vertreten gleichzeitig diese (Stadtbürgerschaft). Das wird dort über separate Hauptausschüsse etc. abgebildet (ja, dort gibt es zwei Hauptausschüsse). Die Mitglieder für Bremerhaven haben dagegen eine eigene Stadtverordnetenversammlung. |
|
@akuckartz Was wollen Sie uns damit sagen? |
|
@sterni24 Es sollten nun ausreichend Argumente für 1:n zusammengetragen sein. Die in #243 (comment) angeführten Aspekte halte ich für irrelevant, da 1:n keinen Server-Hersteller oder -Betreiber zu einer Vereinheitlichung von Personen zwingt, und 1:1 vorbildliches Verhalten nur unter Verstoß gegen die Spezifikation ermöglicht. |
|
@marians Aufgrund der zusammengetragenen Argumente ist eine 1:1 Beziehung der einzig pragmatische Ansatz.. Irgendwann kommen wir in diesem Modellierungswahn noch zu der Erkenntnis, die Objekte von |
|
Ich kann mich inzwischen leider nicht mehr des Eindrucks erwehren, dass möglicherweise ein Motiv hinter der Opposition gegen die hier im Raum stehenden 1:n Beziehungen in dem Bestreben besteht solchen Kommunen die stärker zusammenarbeiten wollen Steinchen in den Weg zu legen. |
|
Zu Ihrem Lösungsansatz Gehen Sie davon aus, dass vor den meisten RIS-Systemen noch eine Verwaltungssoftware steckt, die das entsprechend umsetzen müsste. Daran wird sich keiner beteiligen. Wir sollten die Debatte an dieser Stelle beenden und @marians entscheiden lassen. |
Das wird die Zukunft zeigen. In technischer Hinsicht ist das jedenfalls eine Aufgabe die aggregierende Portale übernehmen können. Solche Aufgabenstellungen mit Lösungen sind im Bereich Linked Data schon lange etabliert (ein Stichwort: "Interlinking") und dafür gibt es auch geeignete Werkzeuge die das unterstützen können. |
|
Vielen Dank für die ausführliche Beteiligung. Für OParl 1.0 halte ich es keineswegs für irrelevant, wie aktuelle RISe bestimmte Informationen abbilden. Deswegen habe ich auch gefragt. Dass es theoretisch sein kann, dass dieselbe Person in mehreren Körperschaften existieren kann, kann ich mir vorstellen. Mich interessiert aber auch die gängige Praxis. Als Ergebnis ziehe ich hier heraus: Für Version 1 sollte es genügen, dem Objekttyp |
|
Dann wird OParl 1.0 für Kommunen oder Server die solche Daten zusammengeführt ausliefern wollen nicht geeignet sein. OpenGovLD wird (das dürfte nicht überraschen) keine solche Einschränkung enthalten. |
|
Es wird keine Kommunen geben, die dies tun wollen. Die von @akuckartz erwähnte Realität (eine Person in 2 oder mehr Körperschaften) ist, dass sich solche Daten weder programmtechnisch abgleichen noch mittels Absprachen zwischen Körperschaften zusammenführen lassen. Letzteres geht doch erheblich an der Praxis (Realität) vorbei. Das hieße ja auch, dass die Objekte |
Korrekt! |
|
Da die Datensynchronisation zwischen verschiedenen RIS-Instanzen nicht absehbar ist, werden alle Objekte zunächst zu einem Body zugeordnet werden. Somit Verschieben des Themas auf eine zukünftige Version. |
|
@the-infinity Die Begründung ist nicht nachvollziehbar. |
|
Soweit ich das erkennen kann, ist im veröffentlichten Standard keine explizite Einschränkung vorhanden, die verhindert, dass eine Person in mehreren Bodies auftaucht. |
|
Meine Meinung dazu hatte ich ja schon vor vier Jahren in mehreren Kommentaren in diesem Issue geäußert. Heute würde ich #243 (comment) wohl eher noch schärfer formulieren.
Dann ist die Hälfte der Daten redundant.
Das halte ich nicht für ein überzeugendes Argument und auch nicht für notwendig, um solche tatsächlichen oder vermeintlichen Lücken in einer Spezifikation zu füllen. |
|
Spannend. Wir haben bislang immer den Fokus auf einzelnen Kommunen gelegt, da wir bislang immer zurückgespiegelt bekommen haben, dass derartige Verknüpfungen in sehr weiter ferne Liegen. Eine kleine Ausnahme hierfür ist Rückreferenzen sind ja durchaus überall vorgesehen, und ich zumindest sehe das ganz ähnlich wie @Medo42, dass Rückreferenzen immer da sein sollten - sei es, um Daten zu validieren, sei es, um partielle Updates zu machen, und auch ich würde gerne überraschende Workarounds unterbinden, alleine, um die Cliententwicklung leichter zu machen - je leichter der Client zu entwickeln ist, desto breiter kann OParl eingesetzt werden. Ich für meinen Teil würde auch nichts gegen eine zukünftige Erweiterung um das Attribut |
Zumindest hier im Issue sind nur entsprechende Kommentare von RIS-Herstellern zu finden, nicht jedoch von Kommunen.
Prima :-) |
Das kann ich nachvollziehen, aber meine Motivation ist die folgende: Wenn ich z.B. ein Organization-Objekt abrufe, dann enthält es eine Liste von Memberships. Wenn Beziehungen nicht an beiden Seiten angegeben werden müssen, könnte sich ein RIS-Anbieter aber entscheiden, Memberships nur von den Person-Objekten aus zu verknüpfen, und in den Memberships dann auf die Organization zu verweisen. Die Membership-Liste in der Organization könnte er weglassen. Die Daten wären dann immer noch vollständig, denn jede Beziehung zwischen Organization und Membership sowie zwischen Membership und Person wird einmal erwähnt und kann gefunden werden. Es wäre auch weniger redundand. Aber als Client-Anbieter, der alle Memberships einer Organization herausfinden will, müsste ich dann erst alle Person-Objekte abfragen und durch ihre Memberships iterieren, um eine Liste aller Memberships meiner Organization zu ermitteln. Das ist zwar im Prinzip machbar, aber vermutlich doch mehr Arbeit. Abgesehen davon habe ich (bis auf die oben erwähnte Ausnahme) noch nicht bemerkt, dass ein RIS-Hersteller eine Verknüpfung tatsächlich nur auf einer Seite ausgeben würde. |
Wie einfach oder schwierig das ist hängt vom konzeptionellen Aufbau der verwendeten API ab. Ich nehme das als Anregung für einen Use Case. |
|
Ein weiterer Datenpunkt für diese Diskussion: Ich implementiere gerade ein inkrementelles Update über den in OParl 1.1 definierten Mechanismus. Wenn man den Mechanismus so nutzt, dass man alle Objekte über ihre eigene Objektliste abfragt und dis Ausgabe eingebetteter Objekte unterdrückt (so ist das meinem Verständnis nach angedacht), dann sind die Verbindungen zwischen den Objekten nur über die "Rückreferenzen" abgebildet (also in Gegenrichtung der Einbettung). Hier ist man also darauf angewiesen, dass der RIS-Hersteller diese Rückreferenzen angibt, wenn das Objekt nicht als eingebettetes Objekt ausgegeben wird. |
Bisher gibt es in oparl:Person noch keinen Verweis auf die Körperschaft(en), in der die Person definiert ist. anders ausgedrückt: Die inverse Beziehung von "member" in oparl:Body fehlt. Damit ist die "Browseability" in diese Richtung nicht gewährleistet.
Existiert ein oparl:Person Objekt in genau einer Körperschaft, oder in beliebig vielen? Was sagen die RIS-Hersteller hierzu? @bschalitz @BThie @sterni24
The text was updated successfully, but these errors were encountered: