Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitgliedschaft / Person in zwei oder mehr disjunkten Zeiträumen in selbem Gremium #23

Closed
akuckartz opened this issue Apr 22, 2013 · 10 comments

Comments

@akuckartz
Copy link
Contributor

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.

@sterni24
Copy link
Contributor

Ich schlage vor, zunächst keine historischen Daten abzugreifen.

Aiuch hier fehlt m. E. eine Entität Mitgliedschaften mit z. B. folgenden Merkmalen:

  • Sortierung
  • Funktionsbezeichnung
  • 1. pers. Vertreter
  • 2. pers. Vertreter
  • Gültigkeit von / bis:

und folgenden Beziehungen:

Gremium -> Mitgliedschaft -> Person
Mitgliedschaft -> Organisation

@akuckartz
Copy link
Contributor Author

Ja, so etwas schwebte mir vor. Dann können aber auch relativ einfach historische Mitgliedschaften abgebildet werden.

Inwieweit solche Daten in aktuellen RIS verwaltet werden ist mir nicht bekannt. Hat jemand dazu Infos / Beispiele ?

Gegebenenfalls kann das in OParl 1.0 als optional deklariert werden.

@BThie
Copy link

BThie commented May 3, 2013

Wir schlagen ebenfalls vor in Version 1 keine historischen Daten abzufragen. sondern sich auf die aktuelle Periode zu konzentrieren. Für kommunale Verwaltungen ist ein definierter Zeitraum eine Wahlperiode, für die Legislative die Legislaturperiode. Die Ausgabe von beliebigen Wahlperioden als auch die Suche in diesen ist grundsätzlich möglich. Vertreter und die Konstellationen ( persönlich definierte Vertreter, Vertreterpool) halten wir in Version 1 für entbehrlich.

@marians
Copy link
Contributor

marians commented May 4, 2013

@sterni24 Im Fall eines relationalen Datenbank-Schemas würden wir wohl eine Entität brauchen, um die Mitgliedschaft einer Person in einem Gremium abzubilden. Allerdings ist es nicht das Ziel, für die Standard-Spezifikation ein solches Schema zu beschreiben. Stettdessen könnten wir beispielsweise entscheiden, dass die Mitgliedschaften einer Person in Gremien als Teil des Objekttyps Person ausgegeben werden - weil eine "Mtigliedschaft" ohne eines der beiden "Bezugsobjekte" nicht existieren kann. Ähnlich kann es ggf. auch mit den Tagesordnungspunkten (als Teil der "Sitzung") gemacht werden.

@BThie
Copy link

BThie commented May 8, 2013

@marians , @sterni24 Technisch sollte beides möglich sein, wir würden uns hier dem Vorschlag
"Ausgabe als Teil des Objekttyps Person" anschließen.

@akuckartz
Copy link
Contributor Author

Wer tief einsteigen möchte, der kann hier Tipps bekommen wie Mitgliedschaften, Rollen etc. abgebildet werden können:

EDIT: inzwischen W3C Recommendation

The Organization Ontology,
W3C Recommendation 16 January 2014,
http://www.w3.org/TR/vocab-org/

Dort sind sowohl "Membership" als eigene Klasse als auch die Verwendung von Properties "hasMember" bzw. "memberOf" als Alternativen vorgesehen. Geht damit also einfach bis ziemlich komplex in verschiedenen Schattierungen.

Mir ist es ziemlich egal, ob die Daten in eigenen Mitgliedschaftsobjekten enthalten sind oder direkt an den Personen hängen. (Denn das wird sich wenn es sauber als JSON-LD ausgegeben letztendlich in die gleichen RDF-Tripel konvertieren lassen ;-)

@akuckartz
Copy link
Contributor Author

Von mehreren Seiten werden Mitgliedschafts-Rollen in OParl 1.0 gewünscht. Dann ist die Aufnahme von Zeiträumen/Wahlperioden aber nur noch ein kleiner Schritt.

@akuckartz
Copy link
Contributor Author

Siehe auch #7

@akuckartz
Copy link
Contributor Author

Siehe auch popolo-project/popolo-spec#25

@akuckartz
Copy link
Contributor Author

Ein eigenes Sortierkriterium für oparl:Membershipist aktuell nicht vorgesehen, da dafür die Eigenschaften der Eigenschaften verwendet werden können und vermutlich ausreichen. Gegebenenfalls neues Issue dazu erzeugen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants