deletedReason

[konstin]

Für OParl 1.1 soll ein neues Feld deletedReason: stringeingeführt werden. Dieses soll bei allen Objekten unterstützt werden.

[sterni24]

Was soll der Inhalt sein?

[konstin]

z.B. "Doppelter Eintrag (s. https://example.com/richtiger-eintrag)", "Urheberrechtsverstoß", "Veröffentlichung geheimer Informationen" oder bei Tagesordnungspunkten einfach "abgesetzt". Es geht dabei darum, dass Transparenz über die Löschung von Inhalten geschaffen wird. Nutzer können damit außerdem erkennen, ob bzw. wo die von ihnen aufgerufe Seite doch noch zu finden ist.

[sterni24]

Informationen, die nicht mehr zu veröffentlichen sind, werden in OParl nicht mehr ausgegeben. Die IDs dieser ehemaligen Informationen werden für OParl als "deleted" vorhalten. Hierzu einige Beispiele:

• Personen, die aus einem Gremium ausscheiden werden, weil es die Verwaltung so wünscht, nicht mehr ausgegeben.
• Versehentlich wird eine Vorlage mit nichtöffentlichem Inhalt durch eine fehlerhafte Zuordnung in OParl ausgegeben. Der Fehler wird (hoffentlich) sofort erkannt und korrigiert.
• Eine Tagesordnung wurde versehentlich zu früh veröffentlicht, zurückgezogen, korrigiert und erneut veröffentlicht.
• Eine Verwaltung verkürzt den Export-Zeitraum (Body.oparlSince).

Bei den von @konstin genannten Löschvermerken handelt es sich m. E. um inhaltliche Löschungen, die in den Dokumenten zu vermerken sind.

• Ein Urheberrechtsverstoß sollte in dem bestehenden Dokument korrigiert und mit einem Hinweis versehen werden.
• Ein abgesetzter Tagesordnungspunkt ist immer noch im System vorhanden oder zumindest im Protokoll erwähnt.
• Der Hinweis "Veröffentlichung geheimer Information" passt zwar gut in die Zeit, ich halte ihn jedoch für äußerst fragwürdig. Das will keine Verwaltung sehen!

Die deleted-Eigenschaft ist dafür vorgesehen, den replizierten Datenbestand zu bereinigen. Das sollten wir auch den Verwaltungen gegenüber so vertreten.

[konstin]

Ich kenne zumindest aus dem Münchner RIS die Praxis, dass bei kaputten oder falschen Dokumenten das alte Dokument gelöscht und ein neues erstellt wird. Auch habe ich einen Fall gesehen, indem zuerst eine Anfrage veröffentlicht wurde, das zugehörige Dokument dann gelöscht wurde und stattdessen ein anderes mit einem Hinweis auf die Geheimhaltung hochgeladen wurde. Über die Frage, ob es sich dabei um eine gute Praxis handelt, lässt sich diskutieren, jedoch ist das dort die übliche Vorgehensweise.

In einem anderem Fall wurde eine Person mit einem Tippfehler im Namen ein zweites mal angelegt und dieser Person wurden sogar einige Dokumente zugeordnet. Dort wäre es meiner Ansicht nach sinnvoll, in einem Löschvermerk auf die Dopplung hinzuweisen,

Sollte es eine solche Praxis nur in München geben, lohnt es sich dafür natürlich nicht, ein neues Attribut hinzufügen.

[akuckartz]

Hat hier jemand Informationen, wie bei anderen Arten offener Daten mit Löschungen umgegangen wird?

[akuckartz]

Für permanent gelöschte Resourcen ist in RFC 7231 der HTTP Status Code 410 ("Gone") vorgesehen (https://tools.ietf.org/html/rfc7231#section-6.5.9). Darin kann auch ein Grund, Zeitpunkt der Löschung u.dgl. mitgeliefert werden werden. Es gibt hier einen gewissen Widerspruch mit https://oparl.org/spezifikation/online-ansicht/#geloeschte-objekte Wie eine mit RFC 7231 konforme Replikation von Löschungen aussehen kann oder soll ist damit aber noch nicht vorgegeben. Ich suche dazu auch selbst nach einer guten Lösung, die universell verwendbar ist.

[eFrane]

Ich kenne zumindest aus dem Münchner RIS die Praxis, dass bei kaputten oder falschen Dokumenten das alte Dokument gelöscht und ein neues erstellt wird.

Heißt das nicht in OParl-Sprech, dass ein oparl:File als deleted: true markiert wird, ein neues erstellt wird und die entsprechende andere Entity referenziert die neue Datei und bekommt einen neuen modified-Zeitstempel?

In einem anderem Fall wurde eine Person mit einem Tippfehler im Namen ein zweites mal angelegt und dieser Person wurden sogar einige Dokumente zugeordnet.

Das ist in der Tat ein Fall, den wir momentan nicht mit den Bordmitteln von OParl tracken können. Für solche Dinge würde ich aber eher ein duplicateOf vorschlagen, was alle Entities haben können.

Was mich an deletedReason stört ist der implizite Zwang eines so benannten Feldes. OParl soll zwar den Prozess der Verwaltung offenlegen, dies aber eben im vorhandenen juristischen und verfahrenstechnischen Rahmen. Und da gibt es nun mal leider (noch) nicht immer die Möglichkeit den Grund für die Löschung eines Datums anzugeben.