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

[sterni24]

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]

@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]

@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]

@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]

@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]

@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]

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

[sterni24]

@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]

@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]

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]

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]

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]

@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]

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]

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