[Talk-de] Objekte gegen Änderungen schützen

[Frederik Ramm]

Hallo,

Markus wrote:
>> Grundsätzlich halte ich es für gar nicht wünschenswert, 
>> dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit 
>> in die Datenbank einbauen. 
> 
> Warum?

Weil dies eine Macht bei jenen konzentrieren wuerde, die entscheiden, 
was gesperrt wird und was nicht und wer etwas bearbeiten darf. Solche 
Machtkonzentration fuehrt fast immer zu einem oder mehreren der 
folgenden negativen Effekte:

* einige Leute fuehlen sich besonders wichtig, es bilden sich 
Machtstrukturen, Entscheidergremien, Abstimmungen, Anfechtungen von 
Abstimmungen, Rauswuerfe von Gremienmitgliedern, Anfechtugen von 
Rauswuerfen und all das
* einige Leute sind Flaschenhaelse, an denen immer alles haengenbleibt, 
und wenn sie mal in Urlaub oder im "Real Life" ueberarbeitet sind, geht 
nix mehr
* es entstehen komplizierte Authentifikations-/Legitimationsverfahren 
und ein Ruf nach Sicherheit (wenn Du mit Deinem Account ploetzlich 
spezielle Bearbeitungsrechte hast, wird Dein Account auch ploetzlich 
besonders schuetzenswert - man darf dann nur noch Authentifizierung 
ueber HTTPS machen und solche Scherze); all das bindet Zeit und Arbeitskraft

Wenn man hingegen am Ausgang kontrolliert, dann kann jeder Empfaenger 
selbst definieren, welche Art von Qualitaet er will, wem er trauen will 
und wem nicht und so weiter; an den zentralen Bottlenecks der Datenbank 
faellt dadurch keine zusaetzliche Last an, es muessen keine Listen 
privilegierter Benutzer gefuehrt werden, Editoren muessen nicht 
angepasst werden...

>> Ich könnte mir aber gut vorstellen, dass man Objekte dadurch "schützt", 
>> dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht.
> 
> Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis 
> gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also 
> bereits am Eingang zu erzeugen. (Im Gegensatz zu "Qualität am Ausgang zu 
> überprüfen" und Ausschuss ggf. wegzuschmeissen).

Diese Lektionen lassen sich m.E. auf OSM keinesfalls uebertragen, 
zumindest nicht pauschal. Bei OSM gibt es keine zentrale, allen 
gemeinsame Definition von Qualitaet; was der eine wegwirft, ist fuer den 
andren wertvoll (bsp. ein 1000m daneben liegender Leuchtturm - wenn ich 
nur analysieren will, wie die Leuchtturmdichte pro Quadratkilometer in 
verschiedenen Kuestengebieten ist, dann ist mir das wurscht).

> Das entspricht der von mir vorgeschlagenen "sorgfältigen 
> Eingangsprüfung", und deckt möglichst alle Qualitätsforderungen ab, 
> natürlich auch böswillige Datenänderungen.

Eine Eingangspruefung wird es auf absehbare Zeit nicht geben. Dazu 
fehlen sowohl die technischen Mechanismen als auch der Wille.

> Jede/r kann Änderungen einbringen.
> Aber vor der Speicherung in die DB wird diese geprüft.

Das wuerde eine Warteschlange von "noch nicht genehmigten Aenderungen" 
erfordern, zusammen mit einem Interface und einer privilegierten 
Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach 
denen sich diese privilegierte Personengruppe konstituiert. Sowas sehen 
wir fruehestens 2011 und auch dann nur gegen meinen Widerstand ;-)

>> "Seezeichen-Qualitätskontrollgruppe" mit gemeinsamem OSM-Account
>> alle Seezeichen prüfen und mit unserem Accountnamen "abstempeln". 
>> und wenn jemand genau unsere abgesegnete Seezeichenkarte 
>> will, wird er beim Download halt alles rauswerfen, was nicht von unserem 
>> Account kommt. 
> 
> Ja, das wäre eine Alternative zu "read-only".
> Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung 
> stehen (nicht gestempelte können nicht in der gestempelten Vorversion 
> geladen werden).

Sag das nicht, sowas waere recht leicht ueber ein modifiziertes OSMXAPI 
machbar (es uebernimmt einfach nur gestempelte).

> In der Eingangskontrolle wären solche Instrumente sehr effizient.

Es wird keine Eingangskontrolle geben. Das widerspricht den 
Grundprinzipien von OSM. - Eine Eingangskontrolle gibt es bei Google Map 
Maker, soviel ich weiss.

> Das klingt interessant!
> Und vielleicht sind "gefilterter mirror" ja dasselbe wie "read-only" für 
> einen keinen Bereich von sicherheitsrelevanten Daten....

In die Richtung koennte es gehen. Der Vorteil ist das 
"basisdemokratische Element" - jeder oder jede Gruppe entscheidet 
selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand 
sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung 
vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte 
Daten, steht diese Option nicht mehr offen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"