Direkte Beziehung zwischen Drucksache und Gremium möglicherweise nicht sinnvoll about spec HOT 12 CLOSED

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

from spec.

Also geht die Diskussion doch schon Richtung Linked Data. Siehe auch #10 bzgl. JSON-LD.

from spec.

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.

from spec.

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. :)

from spec.

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

from spec.

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.

from spec.

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.

from spec.

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.

from spec.

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

from spec.

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.

from spec.

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?

from spec.

Dieses Issue scheint vollständig bearbeitet zu sein.

Deshalb geschlossen.

from spec.