CRE205 Wikidata

Veröffentlicht am von

Eine ontologische Datenbank revolutioniert die Erfassung und Verarbeitung der Wikipedia

Episode image forCRE205 Wikidata

Die Wikipedia hat es geschafft, binnen eines Jahrzehnts nahezu alle Enzyklopädien abzulösen und zum universellen Nachschlagewerk der Menschheit zu werden. Doch stößt das bisherige System der Erfassung von Informationen in Fließtext an seine Grenzen, wenn es um die einfache Wiederverwertbarkeit und maschinelle Abfragen geht. Das jüngste Projekt der Wikimedia Foundation will hier Abhilfe schaffen: Wikidata tritt an, die Erfassung formal beschreibbarer Metadaten auf eine neue Grundlage zu stellen und verbindet dabei erstmals auch alle Sprachvarianten der Wikipedia.

Jens Ohlig hat Wikidata mit entwickelt und im Gespräch mit Tim Pritlove erläutert er, wie es zu diesem Projekt kam, welche Notwendigkeiten und Motivationen das Design beeinflusst haben, wie Wikidata technisch aufgebaut ist und welche Probleme damit künftig gelöst werden sollen.

avatar
Tim Pritlove
Twitter Icon @timpritlove@mastodon.social Icon Website Icon Spenden via PayPal Icon
avatar
Jens Ohlig
GitHub Icon Website Icon Twitter Icon
Shownotes

55 Gedanken zu „CRE205 Wikidata“

  5. Zur Wikipedia API:
    Meiner Meinung nach lässt die Mediawiki API auch sehr zu wünschen übrig. Ich will nach einem Begriff suchen und zu jedem dafür gefundenen Artikel die N größten/besten Bilder von der Wikipedia Seite anzeigen. Dafür benötige ich min. 3 Requests: Suche -> liefert Artikelnamen, Anfrage der Artikelinfo -> liefert Bilderliste, Anfrage der Bilderinfos.

    Weil ich die Infos von mehreren Artikeln auf einmal anfragen kann sind das tatsächlich nur 3 Requests. Aber was gebe ich als die Anzahl der Bilder die ich zurück bekommen will an? Ich will N *pro Artikel*, aber wenn ich ein Limit von N angebe gibt mir die API *alle* vom 1. Artikel, dann die vom 2. etc. bis N ausgeschöpft ist. Ich kann nicht „pro Artikel“ sagen.

    Und wie bekomme ich die representativsten Bilder? Hmm, da nehm ich einfach die größten? Falsch gedacht. Die Größe ist nicht die, wie groß das Bild im Artikel angezeigt wird, sondern wie groß die Bilddatei im Original ist. Bei SVGs ist das immer gigantisch. Und ja, alle (SVG!) Icons für Wikipedia Metadaten werden zurückgegeben, nicht nur die direkt eingebetteten Bilder. D.h. ich muss mir selbst eine Blacklist dieser Icons zusammensuchen. Gibt ja eh nicht so viele, würde man denken. Wieder falsch gedacht, denn oft wird auf einem Unterportal für genau das Selbe ein anderes Icon verwendet als auf der restlichen Wikipedia. Eventuell könnte ich die Kategorie-Hierarchie bis zu „Icons“ hinaufwandern, aber was ist wenn in einem Artikel das Icon tatsächlich direkt sinn macht? Wie das Icon einer Anwendung?

    Alternativ könnte ich den Wiki-Source parsen, aber hab echt keine Lust einen Parser dafür in JavaScript zu schreiben (ja, wir verwenden die JSON-P API).

    Und ab und zu (selten) gibt es auch einfach so einen API Error, der beim nächsten mal Probieren wieder weg ist. Aber dieses Problem haben ja viele kostenlose APIs.

    Versteht mich nicht falsch, es ist schon echt geil, dass es da eine kostenlose API für diese Sachen gibt, nur könnte die API schon noch um vieles besser sein.

    Antworten ↓

  6. Tolle Folge; das Projekt find ich ja super interessant!
    Eine Frage hätte ich zum Datenmodell – sind die Claims uni- oder bidirektional? Wenn ich bspw. eintragen wollte, dass “LP4” ein Album der Band “Ratatat” ist, müsste ich dann auch bei der Band “Ratatat” eintragen, dass diese das Album “LP4” herausgebracht hat? Was wäre denn an der Stelle die “reine Lehre”, wenn es denn eine gibt?

    Antworten ↓

    • Das sind ja genau genommen zwei verschiedene Aussagen, auch wenn man sie mit menschlicher Logik auseinander ableiten kann. Das kann aber Wikidata nicht wissen.

      Das eine Property ist „album“, das andere ist „author“. Dass diese beiden komplementär sind, ist in den Properties selbst nicht abgebildet (zumindest ist das IMHO derzeit so).

      Ansonsten gilt aber „ein Mensch ist ein Lebewesen, aber nicht jedes Lebewesen ist ein Mensch“ und von daher ist es schon sinnvoll, dass man über jedes Objekt separate Aussagen macht.

      Antworten ↓

      • Es ist wahr, dass es in Wikidata keinerlei Prüfung auf Validität von Aussagen gibt. Man kann einem Stein ein Geschlecht geben und sein eigener Großvater sein.
        Es werden ausschließlich Datentypen geprüft und wenn man einen falschen verwendet (bspw. eine URL für das Property „image“ [erwartet wird der Name des Bildes auf commons]) bekommt man eine mehr oder weniger hilfreiche Fehlermeldung: „An error occurred while trying to perform save and because of this, your changes could not be completed.“ http://lbenedix.monoceres.uberspace.de/screenshots/1phz4xepls_2013-12-10_21.08.44.png

        Die „reine Lehre“ ist, dass man eine Ontologie baut und mit einem sogenannten Reasoner automagisch Aussagen erzeugen kann, die nicht explizit getroffen werden. Wenn Alice die Mutter von Bob ist, muss man nicht unbedingt auch die Aussage treffen, dass Bob das Kind von Alice ist…

        Nun noch ein wenig Kritik an Tims Beispiel: Lebewesen würde man als eine Klasse modellieren, Mensch als eine Unterklasse davon und Tim als eine Instanz von Mensch.

        Antworten ↓

        • Um das mit der Validität von Aussagen mal etwas weiter auszuführen: teilweise ist es auch nicht bzw. nur sehr schwer möglich, zu überprüfen, ob eine Aussage „richtig“ ist: dass ein Stein kein Geschlecht haben kann, kriegt man vielleicht noch hin, bei allen derzeit über 1000 Properties herauszufinden, welche Kombinationen Sinn ergeben oder nicht, ist aber sicher keine Aufgabe, die man mal eben nachmittags bei einer Tasse Kaffee erledigt.

          Andererseits gibt es aber auch Aussagen, wie die im Podcast angesprochenen VIAF- und MusicBrainz-IDs (und weitere IDs von Normdateien), die in Wikidata selbst einfach Zeichenfolgen sind, denen man nicht ansieht, ob sie gültig sind oder eben nicht. Um das festzustellen, müsste eine externe Datenquelle befragt werden und dann weiß man immer noch nicht, ob der Datensatz in der externen Datenquelle dem in Wikidata entspricht: so gibt es beispielsweise sowohl einen Komponisten „John Williams“ (kennt man von Star Wars), als auch einen Gitarrenspieler mit dem gleichen Namen.

          Man kann das ganze also nach Belieben komplex gestalten, irgendwann muss man aber auch mal darauf vertrauen, dass die Nutzer sich nicht wie die Axt im Walde benehmen :-)

          Antworten ↓

          • Zu prüfen, ob Aussagen „richtig“ sind, ist tatsächlich schwer bis unmöglich. Aber Validität sollte schon drin sein.

            Man kann in Wikidata folgendes tun:

            Alice „Geschlecht ist“ weiblich
            Alice „ist Bruder von“ Bob

            Das ist eine Aussage, die nicht mal valide ist.

            Viel sinnvoller wäre es ein Property „sibling“ zu haben und die Konkretisierung über das Geschlecht des entprechenden Items zu erledigen. Solch ein Property gibt es aber nicht: https://www.wikidata.org/wiki/Wikidata:List_of_properties/Person#Relationshipdict

            In wikidata gibt es ausschließlich direkte Relationen, keine Form von Transitivität.

            Antworten ↓

  10. Bin ja überrascht das bei der Wikipedia so viel noch manuell passiert, wie Listen, diese Infoboxen, etc. Ich dachte so etwas wie WikiData wäre längst Teil von Wikipedia. Insofern, ja, sehr wichtiges und interessantes Projekt!

    Antworten ↓

  12. Ich bin hin und her gerissen. Einerseits ist es toll nochmal etwas über wikidata zuhören, andererseits ist die Form mehr als anstrengend. Jolig sagt das er über RDF nicht auf dem neuesten Stand ist und trotzdem führt er verschiedene Gründe dagegen an? Sollte man nicht vermeiden über Dinge aussagen zu treffen deren Aktualität oder Richtigkeit man nicht einschätzen kann ? ;) nach einer Stunde kommt ihr dann endlich dazu wie ‚wikidata‘ aussieht. Wäre hier ein screencast nicht nützlich gewesen? Damit alle anderen sehen worüber ihr redet? Am liebsten wurde ich ein gegeninterview geben…

    Antworten ↓

    • Weiß nicht genau, was ein „Gegeninterview“ sein soll, aber ein Screencast findet hier nicht seinen Platz, da CRE eben kein Screencast-Format ist. Warum das jetzt mehr von den Konzepten vermittelt hätte ist mir allerdings auch nicht ganz klar.

      Antworten ↓

  13. Es geht nicht im speziellen um einen Screencast sondern darum zum Audio noch eine weitere Dimension hinzuzufügen. Wenn andere Leute nachvollziehen können was ihr geklickt habt und wie das wikidata Benutzerinterface dort ausgesehen hat, machen die Erklärungen gleich doppelt soviel Sinn.
    Das mit dem finden der Wahrheit(über wikidata oder sonstwo) wird übrigens schwierig, denn man könnte ja der Meinung sein das Wahrheit lediglich ein sozialer Konsens ist und es nur Fakten gibt.

    Antworten ↓

  14. Ach so eine App zum bar Code scannen ist z.B. Codecheck bzw codecheck.info
    Wenn wir alle Wikimedia Projekte als ‚freie‘ Informationsprojekte betrachten fände ich ein EAN Verzeichnis gar nicht so verkehrt. Gerade auch in Bezug auf Inhaltsstoffe Verträglichkeit etc.

    Antworten ↓

  16. Mir ist nicht ganz klar, wieso das Projekt Wikidata sich nicht auf DBPedia gestützt hat. Wenn ich das richtig sehe ist der Vorteil von Wikidata gegenüber DBPedia, dass es in Wikipedia integriert ist. Von den Daten die da so drin sind hab ich bisher keinen Vorteil gesehen (aber auch nicht zu lange gesucht) und technisch gibt es für DBPedia schon Dinge die Wikidata noch nicht kann, SPARQL-Anfragen sind dafür wohl das prominenteste Beispiel. Warum wird da das Rad neu erfunden?

    Antworten ↓

  17. Hallo Tim.

    Ich wollte meinen Dank für den neuen PodCast aussprechen und auch dass es wieder einer ist aus der Richtung der Technik. Vielen Dank dafür.
    Schöne Feiertage und viel Spass auf dem Kongress.

    Grüße aus Freiberg, Frank.

    Antworten ↓

  18. Für mich als Wikipediagelegenheitseditierer war dieser Podcast sehr, sehr spannend.
    Vielen Dank dafür!
    Eine Art Screencast oä. hätte mir diese abstrakten Dinge doch ein bisschen klarer machen können.

    Antworten ↓

  19. In Bezug auf geographische Daten wie Grenzen, die gibts in OpenStreetMap, hier z.B. links von Wikidata zu OSM-Relationen (Grenzen): https://www.wikidata.org/wiki/Special:WhatLinksHere/Property:P402

    z.B. im Eintrag Japan findet man die „OpenStreetMap Relation ID“ 382313 in wikidata hinterlegt, und die führt in OSM zur Grenze: https://www.openstreetmap.org/relation/382313

    Andersrum wird auch schon vereinzelt an der Verlinkung gearbeitet, hier ist die Doku zum aktuellen Stand:
    http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata
    und hier die Anzahl und Varianten der tatsächlich verwendeten tags („jetzt“ 379 Verwendungen): http://taginfo.openstreetmap.org/search?q=wikidata

    Antworten ↓

  20. Nachdem mit dem Podcasts zu TeX/LaTeX und WoW jetzt auch hier die Programmiersprache Lua zur Sprache kam und schon länger keine Programmiersprach im Fokus bei CRE stand: wäre das nicht eine, die es wert wäre, näher beleuchtet zu werden?

    Antworten ↓

  21. … fand den Podcast nicht so spannend.
    Beim Thema Wikipedia, bekomme ich eh‘ Blutdruck,
    aus den in der Sendung genannten Gründen.
    … als dann klar wurde, dass nur die Spiegel-Leser
    die waren Wikipedia-Autoren sind hatte ich fast schon genug gehört
    und spontan das Interesse an der Sendung verloren.
    Jens konnte mich auch mit seinen Erzählungen nicht begeistern.
    … ich bin wohl zu weit weg von der Technik und
    dem logischen Unterbau.
    P.S. habe sogar wieder gespendet fürs Online-Lexikon,
    mit der Hoffnung, dass es besser wird,
    für die „freien“ Autoren.

    Antworten ↓

  23. Mehr CRE mehr CRE mehr CRE mehr CRE.
    Das kann doch echt nicht wahr sein. Es werden in Wochen oder 14-Tagesabständen NSFW oder FS-Podcasts rausgehauen, aber das Ding, welches alles überhaupt erst ans laufen gebracht hat wird totgeschwiegen.
    Ich weiß das Interessen sich ändern, Podlove ist bestimmt ein fettes Teil. Mich als bloßen Konsument interessiert das aber leider nicht so sehr, daher werde ich wohl immer seltener hier vorbeischauen und meine Flattermilliarden anderen in den Rachen werfen :-(
    So, und jetzt möge der Shitstorm beginnen :-)

    Antworten ↓

    • Man sagt zwar das Totgesagte länger leben, aber bei CRE habe ich die Hoffnung auch verloren. Hört lieber den Omega Tau Podcast. Da werden noch interessante Themen behandelt…NSFW und auch FS sind halt reine Labercasts und haben zusätzlich an Qualität verloren. Ich komme deshalb nur noch selten vorbei, um dann festzustellen, dass sich nix getan hat. Wer an intelligenten Gesprächen interessiert ist, dem bietet Holgi mit seinen Wrint-Podcasts mittlerweile mehr viel mehr Qualität, wobei die Wrintheit mit Alex Tobor nochmal heraus ragt…

      Antworten ↓

    • Jetzt haltet doch mal die Füße still! Schon mal was von einer kreativen Pause gehört?

      @Tim: Vielen Dank für deine tollen Podcasts! Immer wieder ein Genuss. Freu mich schon auf die nächste Folge, und selbst wenn es noch ein Jahr dauern würde…

      Antworten ↓

      • … auch ich würde mich über mehr Content freuen. Das waren tolle Zeiten, als man alle zwei bis drei Monate mit einem CRE rechnen konnte!

        Antworten ↓

  25. Hallo von ein Norweger in Kanada! Ich habe letzten Zeit die Podcasts vom Chaos-Radio und CRE gefunden, und sie sind einfach super-toll! Ich gehe gerne Waldwandern, und dann sind diese lange Podcasts super. Hier war diese Winter sehr sehr kalt (oft -20), und mein iPhone Batterie kann das gar nicht leisten, aber glücklicherweise habe ich gefunden, dass mein iPad gut läuft. Dann stecke ich sie in mein Rucksack und laufe gerne zwei-drei Stunden, und lerne über Wikidata, Snowden, Stadtplanung, die Geschichte der Pornografie, und alles weiteres.

    Sehr sehr vielen Dank für alle deine Arbeit an diese Sendung – es ist wirklich schön dass man heutzutage auch „intelligente Unterhaltung“ erhalten kann!

    Antworten ↓

      • Der Nachwelt zur Freude: Eine Kurzsuche ergibt, dass das Intro wohl von Kevin Kelly stammt, die genaue Herkunft der hier verwendeten Version bleibt jedoch unklar, da die Rede augenscheinlich mehrfach gehalten wurde mit jeweils eigener wortlicher Abwandlung. Schade, dass der Podcaster hier keine Pflege betreibt.

        Antworten ↓

  29. Hi Tim

    sagtest Du nicht Du hast noch ne Sendung auf Halde liegen?
    Da ich Deine cast sehr schätze wäre es toll wenn es weiter ginge hier.
    Danke!

    Christian

    PS: Nur kein Stress!

    Antworten ↓

  30. Sehr geehrte Damen und Herren von der Metaebene,

    wie kann es sein, dass dieses altgediente Produkt Ihrer Firma derart vernachlässigt wird? Nur weil einige Ihrer Mitarbeiter nun an dem neuen profitablen Projekt Fokus Europa arbeiten und Ihre Inovationsabteilung an Podlove schraubt, kann es doch nicht sein das alte Projekte derart vernachlässigt werden. Bei einer so großen Firma kann man ein Mindestmaß an Output erwarten. Schließlich bekommen sie ja nicht umsonst monatlich Rundfunkgebühren vom Steuerzahler!11!!! Bitte lenken sie Ihren Konzern dementsprechend, um Ihre anspruchsvolle und vor allem zahlende Kundschaft nicht zu verkraulen.

    Mit vorzüglicher Hochachtung
    Dr. Mett Wurstfett

    Antworten ↓

    • Ich als altgedienter Rundfunkonsument kann dem nur uneingeschränkt vollständig und hundertprozentig zustimmen. Aber so ist es halt bei diesen gesichtlosen Podcastmolochen – am Ende leidet halt immer der kleine Mann! So siehts doch aus!

      Antworten ↓

    • Dem kann ich nur beipflichten! Die Anderen Formate sind auch sehr interessant, beispielsweise Logbuch:Netzpolitik oder Raumzeit, aber trotzdem würde ich mich sehr über eine neue Folge zu einem ganz losgelösten Thema freuen, wie sie üblicherweise hier auf CRE zu hören sind.
      Jedenfalls vielen Dank für die Bisherigen Folgen. Ich habe irrsinnig viel dabei gelernt! Auch wenn jemand über mir bezüglich der Rundfunkgebühren gewitzelt hat. Meiner Meinung nach sollte Tim wirklich, mehr als jeder andere, Teil am GEZ-Kuchen haben. Aber das bleibt wohl leider Wunschdenken…

      Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.