Direkte Beziehung zwischen Drucksache und Gremium möglicherweise nicht sinnvoll

[marians]

Aktuell sieht der Entwurf eine direkte (optionale) Beziehung zwischen einer Drucksache und einem Gremium vor.

Es ist zu prüfen, ob das in dieser Form sinnvoll ist.

Inhaltlich ist es für suchende Nutzer durchaus interessant, zu sehen, dass ein Dokument im Hauptausschuss oder in einer bestimmten Bezirksvertretung behandelt wurde.

In der Praxis werden Drucksachen häufig zur Beratung in mehreren Sitzungen verschiedener Gremien mit Tagesordnungspunkten verknüpft. Daher müsste es eigentlich beliebig viele Beziehungen zu Gremien geben, wenn überhaupt. Alternativ könnte auch die Beziehung über den Tagesordnungspunkt und die jeweilige Sitzung zum Gremium führen.

[jehrhardt]

Das Problem lässt sich mit Hyperlinks recht elegant lösen (z. B. gemäß einem IETF Draft. Ein Bespiel:

{
  "name": "Antrag auf ...",
  "_links": {
    "self": {  "href": "http://..." },
    "gremium": [
      { "href": "http://..." },
      { "href": "http://..." }
    ]
  }
}

Die Attribute des obigen _links Objekts entsprechen dem rel Attribut des HTML <link> Elements. Sie geben die Beziehung der Verlinkten Ressource an. Grundsätzlich spricht nichts dagegen, mehrere Ressourcen mit der selben Relation zu verlinken. Im obigen Beispiel hätte die Drucksache eine Beziehung zu zwei Gremien

[akuckartz]

Also geht die Diskussion doch schon Richtung Linked Data. Siehe auch https://github.com/OParl/specs/issues/10 bzgl. JSON-LD.

[jehrhardt]

Linked Data geht ja noch einen Schritt weiter Richtung Verknüpfung mit externen Daten, wenn ich das richtig sehe.

Das man in einer API für das Web Beziehungen über Links abbildet liegt in der Natur des Webs. Das ist ein gelöstes Problem und taucht im HTML der RIS ja auch schon auf. Diese minimalen Beziehungen existieren also schon und sollten sich auch in der API wiederspiegeln.

[marians]

Das Issue habe ich eigentlich angelegt, um die Frage zu stellen, ob die Beziehung zwischen Gremium und Drucksache so überhaupt benötigt wird. Also eher auf der fachlich/inhaltlichen Ebene. :)

[jehrhardt]

@marians Eigentlich wollte ich auch genau die inhaltliche Frage beantworten.

Wenn diese Beziehung vorkommen kann und das sogar mehrfach, dann sollte sie auch da sein.

[akuckartz]

Es Ist auch eine Frage, ob wir hier Redundanz haben möchten und wie einheitlich das Datenmodell sein soll. Was sich automatisch ergibt (Zuordnung zu einem bestimmten Gremium aufgrund von Zuordnung zu einem bestimmten Tagesordnungspunkt) sollte nicht explizit gemacht werden müssen.

[bschalitz]

Eine Vorlage kann in verschiedenen Gremien beraten werden. Prinzipiell hat die Beratungsfolge noch weitere Eigenschaften wir die Zuständigkeit. Desweiteren spiegelt sich darin sowas wie ein Soll, wenn die Vorlage erst am Ende nach den erfolgten Vorberatungen noch im Rat der Stadt entschieden werden muss. Es aber noch keine geplante/veröffentliche Sitzung im Rat der Stadt gibt.

Also nicht nur Redundanz wenn man sich nicht nur nachträglich (nach allen Beratungen) den Stand anschaut.

[sterni24]

Daraus ergibt sich eine neue Entität: Beratung (auch als Beratungsfolge in Drucksachen bekannt)

Hier einige Beispiele der Beziehungen:

• Gremium -> Sitzung -> Ort
• Driucksache -> Beratungsfolge -> Sitzung
• Sitzung -> Tagesordnung -> Beratungsfolge (bei Drucksachen)
• Sitzung -> Tagesordnung (bei Überschriften)

Zu beachten ist, dass eine Drucksache zu einem geplanten Termin nicht zwingend auf einer Tagesordnung stehen muss.

Für die Tagesordnung wird ein Sortiermerkmal (1-n) benötigt. Die TOP-Nummer ist ein reines Textfeld und kann Redundanzen aufweisen: Auch als Lösung für #16 zu verwenden.

[marians]

@bschalitz Wozu würde eine Sortiernummer des Tagesordnungspunkts benötigt? Wenn es nur darum geht, die Liste aller TOPs einer Sitzung in der richtigen Reihenfolge anzuzeigen, geht es evtl. auch ohne. Wenn TOPs grundsätzlich als sortierte Liste (alle TOPs der Sitzung) abgerufen werden können, kann die Reihenfolge dieser Ausgabe gelten, ohne dass man ein zusätzliches Feld für eine Sortiernummer benötigt.

Oder gibt es weitere Gründe, warum man beispielsweise eine rein numerische Sortiernummer haben sollte?

EDIT: Die Frage hätte ich eigentlich an @sterni24 richten wollen, nicht an @bschalitz.

[bschalitz]

Wenn ich nun schon angesprochen war, kann ich ja auch antowrten.

@marians Also im Prinzip hast du Recht, die Reihenfolge der Tops zu einer Sitzung könnte als Sort-Index genutzt werden. Die Sortiernummer ist in allen RIS da und würde keinen Aufwand auf dieser Seite bedeuten. Die Frage ist, was passiert, bei Nichtöffentlichen Tops einer an sich öffentlichen Sitzung. Hier gibt es für ALLRIS unterschiedliche Einstellungen wie diese angezeigt werden. Gar nicht, mit Platzhalten (nichtöffentlicher TOP) oder darf der Name oder ein öffentlicher Teil davon angezeigt werden. Hier könnte man die Sortiernummer verwenden und den beimessen, wenn Lücken, gibt es nichtöffentliche TOP's.

Ansonsten stimme ich Ihnen zu, man braucht sie eher nicht.

[jensklessmann]

Workshop:

• siehe Punkt 9 (Datenmodell: Direkte Beziehung zwischen Drucksache und Gremium möglicherweise nicht sinnvoll), direkte Beziehung gestrichen
• Ein TOP hat eine Drucksache (1-0 oder 1-1)
• Beratungsfolge muss eine Drucksache haben
• Wie tief sollen die Verknüpfungen in der JSON-Ausgabe aufbereitet werden?

[akuckartz]

Dieses Issue scheint vollständig bearbeitet zu sein.

Deshalb geschlossen.