search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

oparl:Organization - Kategorien, Sortierung und zusätzliche Merkmale #119

Closed sterni24 closed 10 years ago

sterni24 commented 10 years ago
  1. Nach der Zusammenlegung von Parteien, Fraktionen und Gremien in dem Objekt oparl:Organization taucht nun folgendes Problem auf. Ein Client möchte alle Objekte des Typs Gremium abrufen, um sie z. B. in einer Auswahlliste bereitzustellen. Wie wird das gehandelt?
  2. In größeren Verwaltungen kommt es vor, dass 25 und mehr Ausschüsse vorhanden sind. Zur Zeit würden diese Gremien in einer unbestimmten Reihenfolge oder vielleicht alphabetisch ausgegeben werden. Hier sollte ein zusätzliches (optionales) Sortiermerkmal eingerichtet werden. Idealerweise wäre das eine Gruppierung und eine Sortierung. Damit ließe sich z. B. der Rat einer Stadt als erstes Gremium abbilden. Siehe hierzu: http://ris.essen.de/gremien.do https://www.ratsinfomanagement.net/gremien
akuckartz commented 10 years ago

@sterni24

Zu 1: Das ist eine berechtigte Frage und mir gefällt das auch noch nicht. Ich kümmere mich für den OParl-Draft um einen Vorschlag.

Zu 2: Ich kann dazu nur aus Linked Data- und Semantic Web-Sicht antworten. Der Client ist für die Sortierung verantwortlich und eine Ausgabemöglichkeit von OParl mit alternativer Reihenfolge ist nicht notwendig oder gewünscht (es sei denn mittels SPARQL, aber das können wir in OParl nicht festschreiben).

Zu den Gruppierungen ("Ausschüsse", "Bezirksvertretungen" etc.) überlege ich mir etwas. Ich gehe davon aus, dass dies mittels SKOS Concept Scheme (Simple Knowledge Organization System, http://www.w3.org/2004/02/skos/) relativ einfach zu modellieren ist - und wir dazu auch keine Festlegungen treffen müssen, was es denn alles für Gruppierungen gibt.

sterni24 commented 10 years ago

@akuckartz Zu 2: Wie soll ein Client sortieren, wenn ihm dazu die Eigenschaften fehlen? Zu 3: Die Gruppierungen sind bei uns in einer Zuordnungstabelle abgelegt. Z. B. 01 Rat // 01=Gruppierung, Rat=Bezeichnung 11 Beschließende Gremien 12 Beratende Gremien ... 99 Sonstige Gremien

akuckartz commented 10 years ago

@sterni24 Die Menge der OParl-Daten insgesamt enthält ja alles, was für die in Frage kommenden Sortierungen benötigt wird. Sich die dazu benötigten Daten zu holen ist Aufgabe des Client.

sterni24 commented 10 years ago

@akuckartz Das kann ich aus dem jetzigen Datenmodell nicht ableiten. Oder habe ich hier etwas überlesen?

Wie soll ich in einer Gremiendarstellung nach Fraktionen und Funktionen sortieren, wenn nicht einmal die Fraktion / Funktion selbst als Eigenschaft zugeordnet ist?

sterni24 commented 10 years ago

@akuckartz @marians Ich schlage vor, die entsprechenden Eigenschaften in die Objekte aufzunehmen. Ob diese dann auch gefüllt werden, hängt vom jeweiligen RIS ab.

akuckartz commented 10 years ago

@sterni24 Wenn Fraktionszugehörigkeit und Funktion aktuell noch nicht modelliert sind, dann fehlt das aus meiner Sicht. Sehe ich als meine Baustelle.

sterni24 commented 10 years ago

@akuckartz @marians Ich bin gern bereit, das Oparl-Datenmodell hinsichtlich der Objekte und Eigenschaften ganzheitlich durchzuarbeiten. Allerdings sind die voliegenden und zukünftigen issues m. E. nicht das richtige Medium. Es gibt schon viele Anregungen in offenen aber auch schon geschlossnenen issues, die nicht eingearbeitet werden.

akuckartz commented 10 years ago

@sterni24 Prima! Danke für das Angebot! @marians

Mein Vorschlag ist, das Durcharbeiten ab Anfang nächsten Monats anzugehen. Bis dahin wird sich noch vieles im Dokument und der Menge der offenen issues ändern.

Wenn Anregungen in geschlossenen Issues ohne entsprechende Entscheidung nicht eingearbeitet wurden, dann ist das ein tatsächlich ein Problem. Alle offenen issues die für 1.0 vorgesehen sind, sollen für den Draft eingearbeitet werden. Bevor ich ein issue schliesse gehe ich die enthaltenen Kommentare grundsätzlich alle noch einmal durch, um sinnvolle Anregungen oder noch offene Punkte zu identifizieren.

sterni24 commented 10 years ago

Laut @marians ist am 30.04. Redaktionsschluss.

@akuckartz

Es gibt noch einige wichtige Punkte, die aus fachlicher Sicht vor Offenlegung der Dokumemntation eingearbeitet werden sollten. Ich werden Sie demzufolge noch weiter "anfüttern" und hoffe, das dies entsprechend einfließt.

akuckartz commented 10 years ago

Die Gruppierungen ("Ausschüsse", "Bezirksvertretungen", etc.) können mittels skos:Collection oder skos:OrderedCollection modelliert werden: http://www.w3.org/TR/2009/REC-skos-reference-20090818/#collections

marians commented 10 years ago

Ich verstehe einen Teil der obigen Kommentare so, dass durch die Sortierung eine bestimmte Bedeutung von Listenelementen kommuniziert werden soll, z. B. die Gruppierung "Stadtrat" an erster Stelle. Falls das so beabsichtigt ist, spreche ich mich dagegen aus.

Die Gruppierungen einer Körperschaft oder die Mitglieder einer Gruppierung (und andere vergleichbare Listenelemente) sollten meiner Meinung nach

  1. entweder nicht sortiert, also in zufälliger Reihenfolge ausgegeben werden oder, gleichbedeutend, nach einem vom Server bestimmten, "unsichtbaren" Kriterium sortiert sein.
  2. oder grundsätzlich nach einem für den Client sichtbaren Kriterium sortiert sein, beispielsweise nach @id des jeweiligen Listeneintrags.

Eine Sortierung nach einem unbekannten Kriterium wie "Wichtigkeit" oder ähnliches ist aus Sicht des Clients gleichbedeutend mit Option 1.

akuckartz commented 10 years ago

@marians Ich vermute, dass wir hier in der Sache übereinstimmen: Unsichtbare bzw. schlicht implizite Sortier-Kriterien soll es nicht geben.

Es gibt Unterschiede der Wichtigkeit von Gremien. Ein Hauptausschuss ist z.B. in NRW nach der Gemeindeordnung einer von drei Pflichtausschüssen. Und eine sinnvolle Reihenfolge anderer Gremien würde möglicherweise einen "Ausschuss für Kindertagesstätten" sinngemäßt unter "K" einsortieren, statt unter "A". Gleichzeitig haben wir aber in OParl 1.0 keine abgestimmte Liste von Gremien, Ausschüssen etc. und können deshalb keine Reihenfolge vorgeben.

Eine saubere Lösung besteht daher in durch den jeweiligen RIS-Betreiber selbst festlegbaren und für den Client sichtbaren Reihenfolgen der Gremien-Begriffe. Beispiele dazu kommen noch. Ob eine solche Reihenfolge durch einen Client beachtet wird ist dann dessen Angelegenheit.

marians commented 10 years ago

Das Issue ist seit langem unberührt. Aktuell sehe ich hier keinen konkreten Vorschlag, der in die Spezifikation einfließen könnte. Was ist hierzu der Stand?

Ich entferne das Issue vom Milestone 1.0. Sollte sich etwas ergeben, das für 1.0 relevant ist, bitte wieder zuweisen. Aber bitte nur dann.

sterni24 commented 10 years ago

Kann hier gerschlossen werden, weil das Thema in #173 bzw. #178 weiter behandelt wird.