Angaben im Datenmodell überarbeiten: ZWINGEND nur für Systemeigenschaften, OPTIONAL nur für wirkliche optionale Eigenschaften, für alle anderen Eigenschaften grundsätzlich EMPFHOLEN

[lu-j]

Auf dem Workshop haben wir beschlossen:

• Es soll grundsätzlich empfohlen sein, alle vorhandenen öffentlichen Daten aus der Datenbank auszugeben, sofern keine Datenschutzbestimmungen dagegen sprechen. Damit entfällt die ständige Angabe von "EMPFOHLEN" bei den Eigenschaften.
• Aktuell sind manche wichtige Eigenschaften mit "OPTIONAL" deklariert, weil sie nicht für jedes Objekt angegeben werden können. Beispiel: endDate bei Organization, die Eigenschaft kann natürlich nur angegeben werden, wenn die Gruppierung nicht mehr existiert, trotzdem ist die Eigenschaft wichtig, daher ist die Deklaration mit "OPTIONAL" irreführend. "OPTIONAL" sollen nur zusätzliche Eigenschaften sein, die man ohne großen Informationsverlust weglassen kann, zum Beispiel wenn der Implementierungsaufwand zu hoch ist. Ein Beispiel dafür ist sha1Checksum bei File.

Dazu passend, ein weiterer Änderungsvorschlag von mir, bei dem ich mir nicht mehr sicher bin, ob wir ihn nicht auch schon auf dem Workshop beschlossen haben:

• ZWINGEND sollen nur Systemeigenschaften sein, also Metainformationen, die direkt vom RIS ausgegeben werden, zum Beispiel "id" oder "type". Aktuell sind aber auch Daten, wie zum Beispiel der Name einer Sitzung oder das Veröffentlichungsdatum einer Drucksache eine Pflichtangabe. Es sollen aber auch bestehende Datensätze mit OParl ausgegeben werden, daher kann man nicht davon ausgehen, dass für eine bestimmte Eigenschaft immer ein Wert vorhanden ist. Es gibt RISe, die die Daten der letzten fünfzehn Jahre gespeichert haben, oft wurde ein Teil der Daten aus einem anderen, simpleren RIS importiert. Eine weitere Frage wäre, was passieren soll, wenn ein Wert für eine zwingende Eigenschaft fehlt. Wenn eine Sitzung keinen Namen hat, dann dürfte dieses Objekt nicht ausgegeben werden. Damit dürften dann aber auch alle Objekte nicht ausgegeben werden, die von dieser Sitzung abhängen, also die zugehörigen AgendaItem, Consultation und File-Objekte und auch alle Verweise von anderen Objekten zu dieser Sitzung dürften ebenfalls nicht ausgegeben werden. Das wäre aufwendig zu implementieren und im worse-case würden viele Objekte nicht ausgegeben werden. Aktuell sind fast alle Eigenschaften EMPFOHLEN oder OPTIONAL, daher muss ein Client sowieso damit rechnen, dass nicht immer ein Wert vorhanden ist.

Wie immer freuen wir uns über konstruktives Feedback und Vorschläge.

[akuckartz]

Es sollen aber auch bestehende Datensätze mit OParl ausgegeben werden, daher kann man nicht davon ausgehen, dass für eine bestimmte Eigenschaft immer ein Wert vorhanden ist.

Ich stimme vollkommen zu, dass die Verhinderung der Ausgabe von "unvollständigen" Daten häufig kontraproduktiv ist - das gilt insbesondere für historische Daten. Wichtiger ist, dass vorhandene Daten ausgegeben werden können. Insofern ist also eine Minimal-Kardinalität >=1 häufig problematisch.

Umgekehrt kann aber auch eine Maximal-Kardinalität 1 ebenso kontraproduktiv sein, wie z.B. bei #243 und #245. Auch dadurch wird die Möglichkeit der Ausgabe von vorhandenen Daten eingeschränkt, nämlich für die Zukunft.

Randbemerkung: Wenn ein RIS-System eine maschinenlesbare Spezifkation zur Verfügung stellt, dann können darin auch genauere Angaben zu den vorhandenen Daten/Eigenschaften gemacht werden.

[the-infinity]

Habe das mal explizit hineingeschrieben: f065de4 .
Nun noch TODO: da könnten noch 2, 3 OPTIONAL aus den Tabellen weg. Kannst du das machen, @eFrane ?

[konstin]

Könnte man OPTIONAL nicht auch gleich ganz entfernen? Schließlich sollten möglichst alle der in der Spezifikation definierten Informationen auch ausgegeben werden und alle Eigenschaften, die nicht vorhanden oder zu schwierig zu Implementieren sind, kann man mit einem impliziten EMPFOHLEN immernoch weglassen.

[the-infinity]

Der angedachte Unterschied ist folgender:

• EMPFOHLEN: Daten sollen ausgegeben werden, sofern sie vorhanden sind.
• OPTIONAL: Es ist hübsch, wenn diese Daten da sind, muss aber nicht.
  Hintergrund ist, dass wir ein Bewertungssystem für die OParl-Ausgabe entwickeln wollen. Wenn Daten aus dem Bereich EMPFOHLEN auf der Weboberfläche erscheinen, nicht jedoch aber in OParl, dann gibt es Punktabzug. Bei optionalen Daten dagegen ist es wirklich optional.

[eFrane]

@the-infinity Mir ist leider nicht ganz klar, auf welche OPTIONAL du dich beziehst.

[the-infinity]

@eFrane Beispiel: sha1Checksum bei File. Du hast aber Recht, dass da zur Zeit einige Sachen noch bei OPTIONAL drin sind, die eigentlich ausgegeben werden sollen, wenn sie vorhanden sind.

[the-infinity]

... wobei, wenn ich mir das so durchschaue, hast du schon Recht, eigentlich kann man alles mit der Regel "gib aus wenn vorhanden" erschlagen, auch wenn dann die Priorisierung etwas verloren geht, dafür ist es aber einfacher vom Aufbau her. Oder siehst du da ein entscheidendes Problem, @lu-j?

[konstin]

Sinnvoll wäre es auch, alle Eigenschaften die ziemlich sicher vorhanden und für die sinnvolle Nutzung der Informationen nötig sind, mit zwingend zu kennzeichnen, z.B. body:system, body:shortname, body:oparlSince, person:name, meeting:name, etc.

[the-infinity]

Wurde bereits in Issue #71 gelöst.