spec
spec copied to clipboard
OParl
Person > Body: Kann dieselbe Person in mehreren Körperschaften auftauchen?
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
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 oparl:Person ausgegeben wird. Aber diese Merkmale wird es auch bei den RIS-Betreibern nicht geben.
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.
@akuckartz
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: -Kommentar von @Sterni24 vom 16.Juli 2014, -der Umstand, dass wir wieder Wochen hinter einem abgestimmten Zeitplan sind und endlich mal eine abgestimmte Spezifikation benötigen um programmieren zu können
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.
@sterni24 Es sollten nun ausreichend Argumente für 1:n zusammengetragen sein. Die in https://github.com/OParl/specs/issues/243#issuecomment-49263207 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 oparl:Person unter skos:OparlPerson abzubilden, weil jede Person einzigartig ist.
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 <blockquoteWenn 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.habe ich schon alles gesagt.
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.
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.
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 oparl:Person eine Eigenschaft body zu geben, die auf genau eine Körperschaft zeigt.
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 oparl:Membership aus 2 oder mehr Körperschaften unter einer Person zusammengeführt werden müßten. Diese wiederum greifen auf die Objekte von oparl:Organization zurück. Eine interessante Vorstellung!
Das hieße ja auch, dass die Objekte oparl:Membership aus 2 oder mehr Körperschaften unter einer Person zusammengeführt werden müßten. Diese wiederum greifen auf die Objekte von oparl:Organization zurück.
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.
Soweit ich das erkennen kann, ist im veröffentlichten Standard keine explizite Einschränkung vorhanden, die verhindert, dass eine Person in mehreren Bodies auftaucht. Die Eigenschaft "body" kann zwar nur ein einzelnes Objekt enthalten, ist aber streng genommen nur "empfohlen" da sie nicht explizit als zwingend beschrieben ist. Ein RIS-Hersteller, mit dem wir zusammenarbeiten, nutzt nun diese Lücke und definiert die Verknüpfung zwischen Personen und Bodies nur auf der Body-Seite, so dass die gleichen Personen in mehreren Bodies auftauchen können. Da der aktuelle Standard ein solches Vorgehen anscheinend nicht verbietet, haben wir unseren Client entsprechend angepasst. Die n:m-Beziehung zwischen Body und Person macht uns bei der Indizierung und Darstellung der Daten bisher keine Probleme. Aus meiner Sicht würde daher nichts dagegen sprechen, die Verknüpfung einer Person mit mehreren Bodies in einer zukünftigen Version des Standards explizit zu erlauben. Wenn man sich gegen diese Möglichkeit entscheidet, sollte das aber auch eindeutig im Standard festgelegt werden. In jedem Fall sollte für Beziehungen zwischen Objekten generell verlangt werden, dass sie immer auf beiden Seiten der Beziehung angegeben sind (außer bei eingebetteten Objekten, wo die andere Seite implizit bekannt ist), um überraschende "Workarounds" wie den beschriebenen zu verhindern.
Meine Meinung dazu hatte ich ja schon vor vier Jahren in mehreren Kommentaren in diesem Issue geäußert. Heute würde ich https://github.com/OParl/spec/issues/243#issuecomment-50123026 wohl eher noch schärfer formulieren.
In jedem Fall sollte für Beziehungen zwischen Objekten generell verlangt werden, dass sie immer auf beiden Seiten der Beziehung angegeben sind
Dann ist die Hälfte der Daten redundant.
um überraschende "Workarounds" wie den beschriebenen zu verhindern.
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.