Die Welt begrenzen

Dies ist der erste in einer kurzen Serie von Blogeinträgen, in denen ich einige Design-Entscheidungen für Wikidata erkläre. Dies sind …

  • Denny Vrandecic
  • 22. Februar 2013

Dies ist der erste in einer kurzen Serie von Blogeinträgen, in denen ich einige Design-Entscheidungen für Wikidata erkläre. Dies sind persönliche Meinungen, aber sie haben einen großen Einfluss auf Features oder Non-Features von Wikidata. Diese sollen hier erklärt werden.

By Tomascastelazo (Own work)
CC-BY-SA-3.0,
via Wikimedia Commons

Eines der Features – andere Menschen nennen es Bug – ist, dass man jedes Objekt als Wert einer Eigenschaft festlegen kann. Viele davon ergeben keinen Sinn: Wenn man einen Artikel zu Paris hat und dann sagt, dass das zugehörige Land Ziegenkäse ist, ergibt nicht wirklich Sinn. Wäre es nicht toll, wenn Wikidata wüsste, welche Werte für ein Land sinnvoll sind und dir erlauben würde, nur diese auszuwählen anstatt alle möglichen anderen Werte zuzulassen? Wäre es nicht toll, wenn die Community entscheidet, dass eine Eigenschaft wie das vielgenutzte P107 auf die sechs Werte eingeschränkt wird, für die die Community sich entschieden hat?

Ich stimme dem absolut nicht zu.

Ein weiteres Feature – andere nennen es Bug – von Wikidata ist, dass du jede Eigenschaft für jedes Objekt verwenden kannst. Wenn du die Hauptstadt von Julius Caesar angeben willst, kannst du das tun. Wäre es nicht toll, wenn Wikidata wüsste, welche Eigenschaften für ein bestimmtes Objekt sinnvoll sind und dich dann nicht nur auf diese beschränkt, sondern sogar auflistet, welche Eigenschaften noch keine Werte haben? Wäre es nicht toll, wenn die Community Vorlagen mit allen Eigenschaften anlegen könnte, die für eine Person, für eine Stadt oder für ein Land angegeben werden müssen – und nichts anderes erlaubt wäre?

Ich stimme dem absolut nicht zu.

Ich bin der Meinung, dass schlauere Vorschläge großartig wären. Einige davon könnten relativ trivial zu implementieren sein: Zähle die Häufigkeit der Werte für eine bestimmte Eigenschaft und mache basierend darauf Vorschläge. Und was ist mit Vorschlägen für Eigenschaften? Es wird viel in diesem Bereich geforscht, im Prinzip so etwas wie „Objekte mit diesen Eigenschaften haben auch jene Eigenschaften“. Du hast das vielleicht schon auf einigen Shoppingseiten gesehen.

Ich bin absolut für bessere Vorschläge. Ich bin jedoch gegen harte Einschränkungen. Es gibt hier viel zu viel Raum für Drama und Edit-wars. Hat jedes Land eine Hauptstadt? Was ist überhaupt ein Land? Was sollen die möglichen Werte für die Eigenschaft Geschlecht sein? Was sind die richtigen Eigenschaften für Presidenten?

Nicht alles, was das System nutzt, um die Nutzeroberfläche und Hauptfunktionalität zu bauen – Bezeichnungen und Beschreibungen zum Beispiel, oder die Links zu Wikipedia-Seiten – kann Belege haben. Es gibt Dinge, die das System einfach „glaubt“. Wenn du aber die Aussage hinzufügst, dass Kosovo ein Land ist, dann kannst du  einen Beleg hinzufügen. Andere könnten behaupten, dass Kosovo ein Teil von Serbien ist. Du kannst auch dafür einen Beleg angeben. Aber sobald du willst, dass die Nutzeroberfläsche diese Information verwendet – zum Beispiel, wenn eine Eigenschaft auf Länder beschränkt ist, – muss das System entscheiden, ob Kosovo ein unabhängiges Land ist oder nicht. Das lässt keinen Raum für die Art von Wissensvielfalt, für die Wikidata gebaut ist.

Ich sehe die Gefahr, dass ein Teil von Wikidata im Bau einer Ontologie stecken bleiben könnte. Ich glaube, dass diese Übungen fundamental nicht lösbar sein können, und daher sollte es nicht Wikidatas Aufgabe sein, diese zu lösen. Wikidata sollte meiner Meinung nach auf einer weniger abstrakten Ebene arbeiten: Lasst uns die Autoren von Aerosmiths “I Don’t Want to Miss a Thing” angeben und nicht diskutieren, ob Urheberschaft auf ein Lied angewandt werden kann oder nicht. Lasst uns den Stammbaum der britischen Monarchen erstellen und nicht diskutieren, ob offizielle Posten nur von Personen begleitet werden können. Bist du sicher, dass kein Esel je römischer Senator war? Kannst du entscheiden, ob ein Drink einen Erfinder haben sollte?

Für Menschen und Bots bietet Wikidata einen einzigartigen Ort für Kollaboration. Noch viel mehr als Wikipedia, die schon ein erstaunliches Beispiel für eine solche Umgebung ist. In Wikipedia haben wir Bots, die nach veralteten Belegen auf Webseiten suchen, nach korrekter Interpunktion und so weiter. In Wikidata können wir Bots schreiben, die schauen, ob ein Lehrer tatsächlich vor dem Tod seiner Schüler lebte. Ob alle römischen Senatoren vor dem 6. Jahrhundert gelebt haben. Ob die Summe aller Bewohner der Städte eines Landes kleiner ist als die Anzahl der Bewohner des ganzen Landes. Und die Bots, die dies prüfen, müssen einen Weg finden, ihre Ergebnisse an Menschen zu melden, die dann prüfen können, ob sie echte Inkonsistenzen entdeckt haben – entweder in der realen Welt oder in Wikidata – oder nicht.

Die Welt ist komplex. Wikidatas Ziel ist es, strukturiertes Wissen über diese komplexe Welt zu sammeln. Die Wurzeln von Wikidata, wie der Name schon sagt, sind Wikis – und Wikis bedeuten Freiheit. Basierend auf diesem Erbe ist es weder das Ziel von Wikidata Einschränkungen für bestimmte Typen von Eigenschaften zu implementieren, noch Einschränkungen für mögliche Eigenschaften von Objekten festzulegen.

(Ich habe die langweiligen technischen Details übersprungen, warum es schwierig zu implementieren wäre und welche möglichen Probleme durch die Implementierung dieser Features auftreten könnten. Es gibt ernstzunehmende Probleme dabei, aber ich wollte bei den konzeptionellen Gründen bleiben.)

  1. […] (Die deutsche Version dieses Artikels ist hier.) […]

    Pingback by Wikimedia Blog » Blog Archive » Restricting the World on 22. Februar 2013 at 15:17

  2. Wikitext ist frei gewachsen und unreparabel inkonsistent. Wieso wird das Wikidata nicht passieren?

    Kommentar by Torsten on 22. Februar 2013 at 15:36

  3. Weil Wikidata strukturierte Daten verwendet und es viel einfacher ist Änderungen auch in großem Maße zu automatisieren.

    Kommentar by Lydia Pintscher on 22. Februar 2013 at 15:50

  4. Wenn es um Listen geht, muss sich aber dann doch eine Ontologie etabliert haben, richtig? Damit die 100 größten Städte aufgelistet werden, muss jede davon als „Stadt“ markiert sein.

    Ich bin auf die Entwicklung, das Skalieren und die Konfliktlösungsmechanismen gespannt.

    Kommentar by Torsten on 22. Februar 2013 at 16:44

  5. Vielleicht ist Wikidata in dem Sinne vergleichbar mit OpenStreetMap? Es gibt in OSM keine festen Zuweisungen, was an Werten erlaubt ist. Jeder kann alles taggen, es gibt Fehler und Inkonsistenzen, in der Summe entsteht jedoch eine freie Weltkarten, die ohne Probleme nutzbar ist.

    Findige Programmierer entwickeln Spezialkarten, um Fehler und Inkonsistenzen zu finden, die dann von den Mappern korrigiert werden.

    Kommentar by Raymond on 22. Februar 2013 at 19:05

  6. Um das Beispiel mit den „main type of items“ (P107) aufzugreifen. Hier sind nur sechs Werte sinnvoll, aber es ist nicht möglich, eine entsprechende Einstellung vorzunehmen. Fröhliches Suchen in 5 Mill. items ist die Folge und ein ständiges Hinterherräumen. Einen grundlegenden Mangel der Datenbank lasse ich mir nicht als Freiheit verkaufen.

    Kommentar by Steffen on 22. Februar 2013 at 20:32

  7. zu Steffens Kommentar: Es wäre zumindest sinnvoll, wenn Admins lokal ein Dropdown Menü mit den meistbenötigten/sinnvollsten Werten erstellen können. Ein davon abweichender Wert dürfte trotzdem gespeichert werden. Funktioniert in den (mit bekannten) OSM-Editoren auch recht gut.

    Kommentar by Raymond on 22. Februar 2013 at 20:37

  8. Für P107 kann man bots einsetzen, die Fehlerlisten produzieren. Im Grunde kann man das auch bei anderen properties machen. Denkbar wäre ein lernender bot, der die Plausibilität ermittelt und Listen anlegt, wo Benutzer nachschauen könnten. Ansonsten soll ja eine Verknüpfung von Wikidata mit der Beobachtungsliste auf Wikipedia kommen. Das heißt, Falscheingaben dürften etwa so häufig werden, wie damals bevor das Sichten eingeführt wurde. Ein weiterer Punkt ist, dass wir möglicherweise etwas mit dem Missbrauchsfilter machen werden müssen. Der Alptraum wäre ein Vandal-bot.

    Ansonsten stimme ich dem Artikel voll zu. Jedem Property mögliche Eingaben mitzuteilen wäre eine nicht zu bewältigende Daueraufgabe, die auch zu komplex wäre.

    Zu Phase 3: Ausgehend von Wikidata:Phase_III bin ich auf den Artikel Technical_proposal in meta gestoßen. Dort steht, dass eine einfache „query language“ entstehen soll. Nun, ich hatte als Sprache an Prolog, Lisp oder Erlang gedacht. Damit könnte man ein beliebig komplexes System bauen, dass mit den Daten von Wikidata arbeitet. Man könnte so etwas als Prototyp offline mal machen. Die Ausgabe einfacher Listen ist da eine einfache Aufgabe. Interessanter wird es schon, wenn man damit einen lernenden bot baut oder einen, der Umgangssprache versteht. Vorbild wäre hier das IBM-Programm Watson, dass bei der Quizsendung Jeopardy mitspielte und gewann. Laut WP bestand der Computer aus 90 Servern. Das heißt, das wird es nur mit etwas ähnlichem wie bei SETI@home geben können.

    Kommentar by Goldzahn on 23. Februar 2013 at 08:55

  9. Es geht nicht darum, jedem Property zwangsweise feste Eingaben mitzuteilen, sondern um die Möglichkeit eine sinnvolle Auswahl zu treffen. Genauso unbefriedigend ist ein weiteres „Feature“, auf das ich in auf den Diskussionsseiten gestoßen bin. Wer sich die Arbeit macht, Shakespeare seine wichtigsten Dramen zuzuordnen, kann später trotzdem unter „Hamlet“ die Autorenangabe „Goethe“ finden. Auch Ehepartner können einseitig verheiratet sind. A mit B, B aber lieber mit C. Andere Datenbanken (z.B. Freebase) beherrschen solche Grundfunktionen, wie die gegenseitige Verlinkung von Aussagen. Ich habe das Gefühl, das Wikidata an den Interessen der Autoren vorbeientwickelt wird.

    Kommentar by Steffen on 23. Februar 2013 at 15:56

  10. @Steffen Ich habe mir Freebase angesehen (http://www.freebase.com/docs/data). Da steht: „Freebase contains at this time of writing more than 10 million topics, more than 3000 types, and more than 30,000 properties.“ Ich habe mir auch durchgelesen wie man Infos auslesen kann – schon beeindruckend. Lustig ist allerdings, dass sie trotzdem ähnliche Probleme wie wir haben. Ich habe versucht die Seite zu Berlin zu finden. Es gab massig Seiten mit diesem Namen, genau wie bei uns. Genommen habe ich dann etwas anderes, weil ich es nicht gefunden habe, und von dort ging es dann (http://www.freebase.com/view/en/berlin) Ich denke man kann hier gut den Unterschied zu Wikidata sehen. Freebase ist Wikidata plus die Verlinkungen in der Wikipedia. Und die Daten dort sind mehr oder weniger bedeutungslos. Hier ist Wikidata besser, weil es auf die Anwendung Wikipedia ausgerichtet ist. Vielleicht ändert sich das bei Freebase, nachdem Google es gekauft hat. Oder vielleicht beerdigen sie Freebase auch demnächst, ähnlich wie Google Knol.

    Ich glaube, dass wir die von dir angesprochenen Mängel nachträglich noch beheben werden, aber sonst das einfachere und damit bessere System haben. Übrigens, da hat aktuell jemand ein Javascript-Programm geschrieben, mit dem man die Eingabe für z.B. P107 beschränken kann. (User:Tpt/validator.js) Vielleicht wird so etwas mal zur Standardeinstellung?

    Kommentar by Goldzahn on 24. Februar 2013 at 06:44

  11. […] Ontologie, also die möglichen Beziehungen zwischen den verschiedenen Wikidata-Objekten, ist nach Willen der Entwickler offen. So kann die Community flexibel entscheiden, welche Angaben zu einem Objekt in der Datenbank […]

    Pingback by Wikipedia-Datenfundus Wikidata geht in die zweite Runde | virtualfiles.net on 29. März 2013 at 05:26

The comments are closed.