Benutzer:Mabschaaf/WD-Konzept
Prämisse
WikiData kann in deWP (und in anderen gut referenzierten WPs) nur dann erfolgreich werden, wenn
- die Standards an Datensicherheit und -integrität auf Wikidata höher sind als in den lokalen WP-Sprachversionen
- die Bedienung leichter und keinesfalls schwieriger als das aktuelle Eintragen von Daten einschließlich Referenzen in den WP-Quelltext in Wiki-Syntax ist
- die Einbindung von WikiData nicht zu Mehrarbeit oder Störungen (wie gefluteten Beobachtungslisten) auf den lokalen WPs führt.
Grundannahmen
- WikiData wird so umfangreich sein, dass dort alle Prozesse, die den Schutz der Daten erhöhen, vollautomatisiert ablaufen müssen
- Benutzer, die zu WikiData beitragen, gewinnen mit steigender Anzahl inhaltlich akzeptierter Beiträge vollautomatisch mehr Rechte
- Daten gelten als umso wertvoller, je häufiger sie in lokalen Wikipedias eingebunden sind. Sie erhalten mit steigender Anzahl an Einbindungen einen steigenden Schutz-Status.
Erster Schritt: Trennung von Daten (Werten, Aussagen) und Referenzen (Einzelnachweisen)
Aufbau einer Referenz-Datenbank
Jeder Einzelnachweis kann und sollte nach WD überführt werden in eine Einzelnachweisdatenbank. Dazu können Daten aus externen Datenbanken eingepflegt werden (Autoren, Zeitschriftentitel, Publikationsjahr, Band, Seite etc. sind erreichbar, wenn der DOI vorliegt). Grundlage für Einträge in diese Datenbank sind beispielsweise eindeutige Identifier wie ISBN, URN, etc. Auch Webseiten sollen dort mit allen weiteren Informationen (URL, Autor, Publisher, ...) hinterlegt werden.
Ähnlich den aktuellen {{#property:xxx}}
-Nummern könnte jeder Eintrag in dieser Referenzdatenbank mit einer {{#reference:xxx}}
-Nummer versehen werden, die später den daraus bezogenen Daten (Werten, Aussagen) zugeordnet (also verknüpft) wird.
Jedem {{#reference:xxx}}
-Objekt muss dabei auf WD ein Typ (Webseite, Literatur, etc.) zugewiesen werden, mit dessen Hilfe die Darstellung in den lokalen WPs angepasst werden kann. Diese Darstellung erfolgt natürlich nach Sprache des jeweiligen Projekts lokalisiert, mit "Seite", "page" oder "pagina".
Umsetzung
Wie könnte das umgesetzt werden? Einzelnachweise, die schon jetzt in stark strukturierter Form vorliegen (die also mit Vorlage:Literatur, Vorlage:Internetquelle etc. eingebunden sind) können problemlos per Bot nach WD transferiert werden und dort entsprechende Felder einer Datenbank füllen. Doppeleinträge sind dabei zu vermeiden. Die lokalen Einträge können im gleichen Zug oder später per Bot mit dem {{#reference:xxx}}
-Konstrukt ersetzt werden.
- Beispiel: Aus der WP-Aussage
- Ascorbinsäure wird aus D-Glucose hergestellt.[1]
- die im Quelltext so aussieht:
Ascorbinsäure wird aus <small>D</small>-Glucose hergestellt.<ref>{{Literatur | Autor=T. Sonoyama et al. | Titel=Production of 2-Keto-<small>L</small>-Gulonic Acid from <small>D</small>-Glucose by Two-Stage Fermentation | Sammelwerk=[[Applied and Environmental Microbiology|Appl Environ Microbiol]] | Band=43 | Nummer=5 | Jahr= | Seiten=1064–1069 | DOI= | PMID=16346005}} ([http://aem.asm.org/cgi/reprint/43/5/1064.pdf Volltext, PDF]; engl.)</ref>
- wird
Ascorbinsäure wird aus <small>D</small>-Glucose hergestellt.{{#reference:1234567}}
- Das Aussehen des Einzelnachweises unter dem Artikel bleibt unverändert:
- ↑ T. Sonoyama et al.: Production of 2-Keto-L-Gulonic Acid from D-Glucose by Two-Stage Fermentation. In: Appl Environ Microbiol. Band 43, Nr. 5, S. 1064–1069, PMID 16346005. (Volltext, PDF; engl.)
Gewinn für Wikipedia
Der Quelltext eines WP-Artikels wird so deutlich vereinfacht und besser lesbar, gleichzeitig kann der Einzelnachweis auch in anderen Artikeln verwendet werden, die auf den gleichen Sachverhalt eingehen oder die gleiche Quelle verwenden. Die Korrektur oder Ergänzung des Einzelnachweises (hier fehlt beispielsweise der DOI und der PMC-Identifier) wäre zentral möglich und würde in alle Einbindungen übernommen werden.
Schon während der Eingabe eines Einzelnachweises wird im Hintergrund geprüft, ob dieser bereits in der Datenbank vorhanden ist bzw. werden Vorschläge gemacht, die übernommen werden können. Idealerweise ist zukünftig beispielsweise nur noch das Nennen einer ISBN und der Seite nötig, der Rest wird automatisch ergänzt.
Parallel dazu: Edit-Rechte auf WD definieren
Zwingend erforderlich ist, dass auf Wikidata Mechanismen aktiv sind, die die Einträge gegen Vandalismus schützen.
Benutzerrechte
Um die Datensicherheit und -konsistenz auf Wikidata sicherzustellen, muss auch auf WD ein hierarchisches System abgestufter Benutzerrechte geschaffen werden, ähnlich der Editor/Sichter/Admin-Hierarchie auf den lokalen WPs. Ich schlage hierfür aber eine feinere Untergliederung mit 6 Stufen vor. Die Grenzen und Übergänge hierfür müssen sicher ausdiskutiert/abgestimmt werden, hier nur ein grober Vorschlag, der das Prinzip verdeutlichen soll:
User-Level | Bezeichnung | Daten | Referenzen | Verknüpfungen | Edits Bestätigen | Benutzerrechte |
---|---|---|---|---|---|---|
0 | Newbie, IP | Neue Daten eintragen, ungesichtete Daten ändern | Neue Referenzen eintragen, ungesichtete Referenzen ändern | Daten mit Referenzen verknüpfen, ungesichtete Verknüpfungen ändern | wird nach xxx gesichteten Edits automatisch zu Level 1 | |
1 | Junior Editor | gesichtete Daten ändern, wenn diese ungenutzt sind | gesichtete Referenzen ändern, wenn diese ausschließlich mit ungenutzten Daten verknüpft sind | gesichtete Verknüpfungen lösen, wenn die damit verknüpften Daten ungenutzt sind | Level-0-Edits als gesichtet markieren | wird nach yyy gesichteten Edits automatisch zu Level 2 |
2 | Editor | gesichtete Daten ändern, wenn diese nur in einer Wikipedia-Sprachversion genutzt sind | gesichtete Referenzen ändern, wenn diese zwar genutzten Daten verknüpft sind, das aber nur selten | Level-1-Edits als gesichtet markieren | ||
3 | Senior-Editor | gesichtete Daten ändern, auch wenn diese in vielen Wikipedia-Sprachversionen genutzt sind | gesichtete Referenzen ändern, wenn diese häufig mit genutzten Daten verknüpft sind | Verknüpfungen ändern | Level-2-Edits als gesichtet markieren | Benutzerrechte auf Level 2 erhöhen |
4 | Junior-Admin | Daten ändern, ohne weitere Sichtung zu erzwingen | Referenzen ändern, ohne weitere Sichtung zu erzwingen | Verknüpfungen ändern, ohne weitere Sichtung zu erzwingen | Level-3-Edits als gesichtet markieren | Benutzerrechte auf Level 3 erhöhen |
5 | Admin | Benutzerrechte auf Level 4 erhöhen / Benutzerrechte absenken, sperren |
Bot-Rechte
Wie Bot-Rechte vergeben werden und auf welchem User-Level Bots (und deren Edits, die automatisch als gesichtet gelten müssen) stehen, mag die WikiData-Community entscheiden. Um auch hier Datensicherheit zu gewährleisten, wäre beispielsweise vorstellbar, dass jeder Bot-Lauf auf einer zentralen Seite angekündigt sein muss, dort muss er in Abhängigkeit von der Anzahl der geplanten Edits:
- für eine bestimmte Dauer verbleiben und zur Diskussion stehen
- anschließend von einem User des Levels 4 oder 5 formal beauftragt werden
Zweiter Schritt: Referenzieren von Daten auf WikiData
Wenn eine gegen Vandalismus geschützte Referenzen-datenbank vorhanden ist, kann diese auch auf Wikidata selbst genutzt werden, um dort gehostete Aussagen/Werte/Daten mit Einzelnachweisen zu belegen.
Das Herstellen/Ändern von Verknüpfungen zwischen Aussage und Einzelnachweis muss dabei ebenso gegen Vandalismus gesichert werden.
Damit wären die Grundlagen zur Einbindung statischer Daten in die lokalen WPs geschaffen.
Dritter Schritt: Einbinden dynamischer Daten
Dynamische Daten sind Daten, die sich in bestimmten Zeitintervallen ändern und der Aktualisierung bedürfen, beispielsweise Einwohnerzahlen, Wahlergebnisse, statistische Daten.
Die Herausforderung dürfte hier sein, eine valide Aktualisierung eines Datensatzes von zwar aktuelleren Daten, die aber beispielsweise mit einer abweichenden Ermittlungsmethode gewonnen wurden, zu trennen. Es handelt sich also um inhaltliche Entscheidungen. Ob dazu softwareseitig Fumktionen oder zusätzliche technische Hilfestellungen nötig sind, ist noch zu diskutieren.
Kontrollmechanismen
Property/Referenzeinbindung mit Zeitstempel ermöglichen
Wenn in ein WP-Projekt ein Property aus Wikidata in einer bestimmten Version eingebunden werden kann (also basierend auf dem Zeitstempel des Einbindungsedits), kann dieser Eintrag durch Vandalismus in Wikidata in der lokalen WP nicht verändert werden. Diese Zeitstempel-Variante könnte in einer Zwischenphase hilfreich sein, die generelle Akzeptanz von Property-Einbindungen zu erhöhen oder überhaupt herzustellen. Möglicherweise kann diese Funktion später wieder deaktiviert werden, wenn alle Voraussetzungen programmiert sind und angewendet werden, die Vandalismus auf Wikidata (nahezu) unmöglich machen.
Sichten
Nur sehr wenige Benutzer können nach der oben stehenden Tabelle überhaupt Änderungen in WikiData vornehmen, die anschließend nicht nochmals gesichtet werden müssen. Das bedeutet aber, dass die WikiData-Aktiven alleine das Sichten nicht schaffen können. Daher muss das Sichten genauso funktionieren, wie es auch jetzt vonstatten geht: Wird ein Eintrag auf WikiData geändert (egal, ob Wert, Zuordnung oder Referenz), wird diese Änderung in jeder Sprachversion der Wikipedia, für die die Änderung Folgen hat, zum Sichten vorgeschlagen. Sichten kann daher auch jeder Wikipedia-Benutzer, der die nötigen Sichterrechte hat.
- Beispiel: Eine auf deWP im Artikel "Zäune" eingebundene Aussage
- Der Gartenzaun hat fünf Latten.[Ref1]
- wird auf WP zum Sichten vorgeschlagen, wenn jemand "Gartenzaun" zu "Lattenzaun" ändert. Mit WikiData könnte die Einbindung so aussehen:
- Der Gartenzaun hat
{{#property:12345}}
Latten.{{#reference:67890}}
- Der Gartenzaun hat
- Ändert nun jemand auf WikiData den Wert von
{{#property:12345}}
auf "vier" oder im Eintrag{{#reference:67890}}
den Autor, wird der Artikel "Zäune" auf deWP zum Sichten vorgeschlagen. Wird gesichtet, gilt damit automatisch der neue Property-Wert oder die korrigierte Referenz auf Wikidata als gesichtet.
Voraussetzung für dieses Vorgehen wäre, dass jedem WP-Benutzer in Abhängigkeit von beispielsweise seinem Editcount automatisch ein bestimmter WikiData User-Level zugeordnet wird.
Steht auf Wikidata auch noch, dass der Gartenzaun "rot" ist (in {{#property:12346}}
) und wird diese Angabe auf Wikidata in "blau" geändert, wird der Artikel "Zäune" auf deWP dagegen nicht zum Sichten vorgeschlagen, weil die Aussage keine Verwendung findet. Damit bleiben die persönlichen Beobachtungslisten der WP-Benutzer genauso voll oder leer wie jetzt auch.
Transparenz
Es muss einfach möglich werden, herauszufinden, wo überall bestimmte Properties oder Referenzen eingebunden sind. Es werden also Backlink-Funktionen benötigt (ähnlich wie unter jedem Commons-Bild steht, auf welchen Projekten in welchen Artikeln es verwendet wird), die mit einem Mausklick verfügbar macht
- auf welchen Projekten in welchen Artikeln ein bestimmtes Property verwendet wird (bspw. Spezial:Propertysuche)
- welche Properties mit einer bestimmten Referenz verknüpft sind (bspw. Spezial:Referenzsuche)
- auf welchen Projekten in welchen Artikeln bestimmte Referenzen direkt eingebunden sind
Mit steigender Anzahl der Verknüpfungen/Einbindungen erhöht sich automatisch der Schutzstatus eines Properties / einer Referenz, Änderungen können also zunehmend nur von Benutzern mit hohem WikiData User-Level durchgeführt werden.
Roadmap
In welcher Reihenfolge sollten die notwendigen Ergänzungen programmiert und freigeschaltet werden?
- Userlevels mit entsprechenden Rechtezuweisungen
- Möglichkeit, Änderungen an Properties (und Referenzen) direkt aus WP zu sichten (ohne Projektwechsel)
- Suchfunktionen (Spezial:Propertysuche und Spezial:Referenzsuche) und Funktionen, die die Einbindungshäufigkeit ermitteln, damit die Schutzstufe eines Properties, einer Verknüpfung oder Referenz bestimmt werden kann
- Referenzdatenbank programmieren (alle Möglichkeiten aus Kategorie:Vorlage:Datenbanklink, Kategorie:Vorlage:Zitation abdecken) und diese behutsam(!) füllen, immer in Kontakt mit der Community, um Probleme schnell zu erkennen
- Meinungsbild mit dem Ziel, die Einbindung von Referenzen in deWP freizugeben
- Verknüpfung von Daten mit Referenzen ermöglichen (Grundlage für die zukünftig einzigen zulässigen Daten in Wikidata: Saubere Kombination aus Aussage-Verknüpfung-Quelle, alles aus gesichterten Datenquellen. WP ist keine Quelle!)
- Nach einer Übergangsphase: Nicht mit Referenzen verknüpfte Daten rigoros aus Wikidata löschen
- Ggf. softwareseitige Voraussetzungen zur Einbindung dynamischer Daten schaffen
- Meinungsbild mit dem Ziel, die Einbindung von (den dann ausschließlich referenzierten) Properties in deWP freizugeben
Ausblick
Wenn Wikidata das zentrale Referenzen-Repositorium wird, sehe ich zukünftig letztlich die Grenzen zwischen den Projekten Wikidata und Wikipedia verschwimmen. Ob Referenzen zuerst hier lokal oder auf Wikidata direkt eingetragen; mit dem klassischen Editor in den Quelltext geschrieben oder mit VisualEditor in Datenfelder eingegeben werden wird egal sein: Im ersten Fall käme ein Bot vorbei und würde die Daten nach Wikidata schaufeln oder der VE erledigt das sofort. Wikidata könnte sich praktisch immer im Hintergrund halten und von dort seine Dienste anbieten: Auto-Vervollständigen von Einzelnachweisen, für die nur noch ein Identifier oder die Webadresse angegeben werden muss.
Auch ein Expandieren der kryptischen {{#property:12345}}
- oder {{#reference:67890}}
-Syntax im Edit-Modus wäre vorstellbar, so dass direkt hier auf WP geändert/ergänzt werden kann, ohne dazu extra nach Wikidata zu wechseln. So würde der Wikidata-Datenbestand direkt aus WP mitgepflegt, Mehraufwand wäre nicht mehr nötig.
So viel zu meiner Vision...--Mabschaaf 00:01, 7. Jun. 2014 (CEST)