Hallo allerseits zum Datenqualitätspanel.
Datenqualität ist wichtig, weil immer mehr Menschen da draußen
sich darauf verlassen, dass unsere Daten in einem guten Zustand sind.
Daher werden wir über die Datenqualität sprechen
und es werden vier Sprecher kurze Einführungen geben
zu Themen im Zusammenhang mit der Datenqualität
und im Anschluss folgen Fragen und Antworten.
Und der Erste ist Lucas.
Vielen Dank.
Hallo, ich bin Lucas und beginne mit einer Übersicht
der Datenqualitätstools, die wir bereits auf Wikidata haben
und auch von einigen Dingen, die bald verfügbar sind.
Und ich habe das alles in allgemeine Themen gruppiert
wie Fehler sichtbarer machen, Probleme angehbar machen,
den Daten mehr Aufmerksamkeit widmen, damit die Leute die Probleme bemerken,
einige der häufigen Fehlerquellen beheben,
die Qualität der vorhandenen Daten sichern
und auch Datenpflege durch Menschen.
Und die, welche derzeit verfügbar sind, beginnen mit Eigenschaftsbeschränkungen.
Ihr habt dies wahrscheinlich bereits auf Wikidata gesehen,
manchmal habt ihr diese Symbole,
die die interne Konsistenz der Daten überprüfen.
Wenn zum Beispiel ein Ereignis dem anderen folgt,
dann sollte das andere Ereignis auch von diesem gefolgt werden,
was auf dem WikidataCon-Item anscheinend fehlte.
Keine Ahnung, dieses Feature ist erst ein paar Tage alt.
Wenn dies für euch zu einschränkend oder zu einfach ist, gibt es auch
den Query Service, mit dem ihr beliebige Kontrollen erstellen könnt,
was natürlich bei vielen Dingen nützlich ist,
aber ihr könnt diesen auch zum Auffinden von Fehlern verwenden.
Also wenn ihr das Auftreten eines Fehlers bemerkt habt,
dann könnt ihr nachschauen, ob es noch andere Orte gibt,
wo Leute andere, ähnliche Fehler gemacht haben
und dies mit dem Query Service finden.
Ihr könnt auch beide kombinieren
und nach Verstößen gegen Constraints im Query Service suchen,
zum Beispiel nur die Verstöße in einigen Bereichen
oder einem WikiProject, das für euch relevant ist.
Leider sind die Resultate derzeit nicht vollständig.
Es gibt eine Revisionswertung.
Das ist... ich denke, das kam von den letzten Änderungen.
Ihr könnt es auch auf eure Beobachtungsliste setzen,
eine automatische Bewertung vornehmen lassen,
ob diese Änderung wohl in gutem Glauben geschehen ist oder nicht
und schädlich oder nicht schädlich ist.
Ich denke, das sind die beiden Bereiche.
Also könnt ihr, wenn ihr wollt,
euch auf nur die schädlichen, aber sinnvollen Änderungen konzentrieren.
Wenn ihr euch besonders freundlich und einladend fühlt,
könnt ihr den Editoren sagen:
"Vielen Dank für euren Beitrag, so hättet ihr es machen sollen,
aber trotzdem danke."
Und wenn euch nicht danach ist,
könnt ihr die nicht sinnvollen Änderungen durchgehen
und die Vandalen wieder zurücknehmen.
Ähnliches gilt auch bei der Bewertung von Entitäten.
Anstatt also eine Änderung zu bewerten, was sie geändert hat,
bewertet ihr die gesamte Revision
und ich glaube, das ist das gleiche Qualitätsmaß,
welches Lydia zu Beginn der Konferenz erwähnt hat.
Hier oben gibt es ein Benutzer-Skript,
welches euch eine Wertung von 1 bis 5 vorgibt.
Ich glaube, das bezieht sich auf die Qualität des aktuellen Eintrags.
Das Primary-Sources-Tool ist für jede Datenbank gedacht,
die ihr importieren möchtet,
die aberqualitativ nicht so gut ist, um sie direkt zu Wikidata hinzuzufügen,
also fügt ihr es zu dem Primary-Source-Tool hinzu
und dann können die Leute entscheiden,
ob sie diese einzelnen Aussagen hinzufügen sollten oder nicht.
Das Anzeigen von Koordinaten als Karten
ist vorwiegend eine praktische Funktion,
aber auch für die Qualitätskontrolle nützlich.
Wenn ihr beispielsweise seht,
dies soll Büro von Wikimedia Deutschland sein,
aber die Koordinaten liegen irgendwo im Indischen Ozean,
dann wisst ihr, dass da etwas nicht stimmt
und ihr könnt es viel einfacher sehen als nur mit den Koordinaten.
Dies ist ein Gadget mit dem Namen relativer Vollständigkeitsindikator,
das euch dieses kleine Symbol hier zeigt,
das euch sagt, für wie vollständig es diesen Punkt hält
und auch welche Eigenschaften am ehesten fehlen.
Das ist wirklich nützlich, wenn ihr eine Sache bearbeitet
und ihr euch in einem Bereich befindet, mit dem ihr nicht sehr vertraut seid
und ihr nicht wisst, welche Eigenschaften richtig sind.
Dann ist dies ein sehr nützliches Gadget.
Und wir haben Shape-Ausdrücke.
Ich denke, Andrea oder Jose werden mehr darüber erzählen,
aber das ist im Grunde eine sehr leistungsfähige Methode
zum Vergleichen der Daten, die ihr habt, gegen das Schema,
also welche Aussage sollten bestimmte Entitäten haben,
mit welchen anderen Entitäten sollten diese verbunden sein
und wie sollten diese aussehen?
Und so könnt ihr Probleme auf diese Weise finden.
Ich denke... Nein, da ist noch mehr.
Das Integraality- oder Property-Dashboard
gibt euch einen schnellen Überblick der Daten, die ihr bereits habt.
Dies ist zum Beispiel aus dem WikiProject Red Pandas
und ihr könnt sehen, dass wir ein Geschlecht
für fast alle der roten Pandas haben,
das Geburtsdatum variiert sehr im Bezug zum Zoo, aus dem sie stammen
und wir haben fast keine toten Pandas, was wunderbar ist,
weil sie so süß sind.
Das ist also auch nützlich.
Nun kommen wir zu den Themen, die aktuell anstehen.
Wikidata Bridge oder auch bekannt als Client-Editing,
also die Bearbeitung von Wikidata mittels Wikipedia-Infoboxen.
Einerseits wird auf die Daten mehr Augenmerk gelegt,
weil mehr Leute die Daten dort sehen können.
Dies wird hoffentlich vermehrt den Gebrauch von Wikidata
in den Wikipedias anregen und das bedeutet,
dass mehr Leute davon Kenntnis bekommen können,
wenn manche Daten veraltet sind und aktualisiert werden müssen,
als wenn dies nur auf Wikidata sichtbar wäre.
Es gibt auch kaputte Referenzen.
Die Idee hier ist, dass wenn ihr den Wert einer Anweisung bearbeitet,
ihr auch die Referenzen aktualisieren solltet,
außer es handelt sich nur um einen Tippfehler oder Ähnliches.
Und diese kaputten Referenzen weisen die Bearbeiter
und auch andere Bearbeiter, die das sehen können, darauf hin,
ob und welche anderen Änderungen vorgenommen wurden,
den Wert der Anweisung und die nicht aktualisierte Referenz.
Ihr könnt das dann korrigieren und entscheiden, ob es das war...
oder noch mehr ansteht oder das tatsächlich so in Ordnung ist
und ihr die Referenzen nicht aktualisieren müsst.
Das bezieht sich auf signierte Anweisungen,
die von einem Anliegen stammen, soweit ich weiß,
dass einige Datenanbieter das zum Beispiel so handhaben...
es gibt eine Anweisung, auf die von der UNESCO verwiesen wird oder so
und dann zerstört plötzlich jemand die Anweisung
und sie sind dann besorgt, dass es dann so aussieht,
als ob der falsche veränderte Wert immer noch von der Organisation
wie der UNESCO stamme,
also können sie mit signierten Anweisungen
solche Referenzen kryptografisch signieren.
Das verhindert zwar keine Änderungen daran,
aber zumindest, wenn jemand die Anweisung verfälscht
oder sie in irgendeiner Weise verändert, dann ist die Signatur nicht mehr gültig,
dann wisst ihr, dies entspricht nicht dem, was von der Organisation stammt.
Vielleicht war es eine konforme Änderung und diese sollte neu signiert werden,
aber vielleicht muss diese wieder rückgängig gemacht werden.
Nun etwas, das auch sehr aufregend sein wird, denke ich,
Citoid ist dieses erstaunliche System, das sie auf Wikipedia haben.
Damit könnt ihr eine URL, einen Bezeichner oder eine ISBN
oder Wikidata ID oder im Grunde alles in den Visual Editor einfügen
und es spuckt eine Referenz aus, die schön formatiert ist,
und dazu alle Daten, die ihr braucht, und der Gebrauch davon ist toll.
Und im Vergleich dazu auf Wikidata, wenn ich einen Verweis hinzufügen möchte,
muss ich normalerweise eine Referenz-URL, einen Titel,
einen String des Autorennamen, Veröffentlichungsort,
Veröffentlichungsdatum, Abfragedatum,
zumindest diese angeben und das ist ärgerlich.
Die Integration von Citoid in Wikibase wird hier hoffentlich Abhilfe bringen.
Und ich denke, das war alles, was ich hatte, ja.
Also gebe ich jetzt ab zu Cristina.
Hi, ich bin Cristina.
Ich bin wissenschaftliche Mitarbeiterin der Universität Zürich
und ich bin auch aktives Mitglied der Schweizer Community.
Als Claudia Müller-Birn und ich dies auf der WikidataCon einreichten,
war es unser Anliegen, unsere Diskussion fortzusetzen,
die wir Anfang des Jahres begonnen hatten
mit einem Workshop für Datenqualität und einigen Sessions in Wikimania.
Also das Ziel dieses Vortrags ist es, einige Ideen von uns
und der Community anzusprechen, die wir aufgegriffen haben,
und die Diskussion fortzusetzen.
Wir möchten also weiterhin viel mit euch interagieren.
Also was wir für sehr wichtig halten,
ist, dass wir kontinuierlich jede Art von Benutzer in der Community fragen,
was sie wirklich brauchen,
welche Probleme sie mit der Datenqualität haben,
nicht nur Bearbeiter, sondern auch die Leute, die programmieren
oder einfach Daten verwenden, und auch Forscher,
die den gesamten Bearbeitungsverlauf verwenden,
um zu analysieren, was vor sich geht.
Wir haben also eine Überprüfung von rund 80 Tools durchgeführt,
die in Wikidata vorhanden sind, und wir haben sie ausgerichtet
an verschiedenen Dimensionen der Datenqualität.
Und was wir eigentlich bemerkten,
viele davon waren für das Monitoring der Vollständigkeit gedacht,
doch einige von ihnen ermöglichen auch Verknüpfungen.
Es besteht jedoch ein großer Bedarf an Tools, die sich mit Vielfalt befassen.
Das ist eines der Merkmale, die tatsächlich in Wikidata möglich sind.
Insbesondere dieses Gestaltungsprinzip von Wikidata,
wo wir Vielfalt haben können,
also unterschiedliche Anweisungen mit unterschiedlichen Werten,
die aus verschiedenen Quellen kommen.
Da es sich um sekundäre Quellen handelt, haben wir nicht wirklich Werkzeuge,
die uns zeigen, wie viele kumulierte Aussagen es gib
und wie viele davon wir verbessern können und wie
und wir wissen auch nicht wirklich,
was die Gründe für die Vielfalt sind, die auftreten können.
Also was wir besprochen haben auf diesen Community-Treffen,
waren die Herausforderungen, die noch Aufmerksamkeit erfordern.
Sehr toll zum Beispiel sind all diese Crowdsourcing-Communities,
weil verschiedene Leute verschiedene Bereiche
der Daten oder der Diagramme angehen
und wir haben auch unterschiedliche Hintergrundkenntnisse.
Tatsächlich ist es jedoch sehr schwierig, alles in etwas Konsistentes auszurichten,
weil unterschiedliche Menschen
unterschiedliche Eigenschaften auf unterschiedliche Weise nutzen
und sie erwarten auch Unterschiedliches von Entitätsbeschreibungen.
Die Leute meinten auch, dass sie mehr Werkzeuge brauchen,
die einen besseren Überblick ermöglichen über den globalen Status der Dinge.
Also welche Einheiten in Bezug auf Vollständigkeit fehlen,
aber auch so etwas wie, woran die Leute gerade die meiste Zeit arbeiten,
und sie erwähnen auch oft eine engere Zusammenarbeit
nicht inur m Hinblick auf Sprachen, sondern die WikiProjects
und die verschiedenen Wikimedia-Plattformen.
Und wir haben alle transkribierten Kommentare veröffentlicht
von all diesen Diskussionen in diesen Links hier in den Etherpads
und auch auf der Wiki-Seite von Wikimania.
Einige der Lösungen, die tatsächlich aufgetaucht sind,
gingen in die Richtung, mehr Best Practices auszutauschen,
die in verschiedenen WikiProjects entwickelt werden.
Aber die Leute wollen auch Tools,
die dabei helfen, die Arbeit in Teams zu organisieren,
oder zumindest verstehen helfen, wer woran arbeitet,
und sie erwähnten auch, dass sie sich mehr Anwendungsbeispiele wünschen
und mehr Vorlagen, mit denen sie Dinge besser erstellen können.
Und im Hinblick auf den Kontakt,
den wir mit offenen staatlichen Datenorganisationen haben,
und insbesondere stehe ich in Kontakt mit dem Kanton und der Stadt Zürich,
sind diese sehr daran interessiert, mit Wikidata zu arbeiten
weil sie wollen, dass ihre Daten für alle an dem Ort zugänglich sind,
an dem Menschen Daten abrufen oder darauf zugreifen.
Für sie wäre es wirklich interessant
eine Art von Qualitätsindikatoren zu haben
sowohl im Wiki, was bereits verwirklicht wird,
als auch in SPARQL-Ergebnissen,
um zu wissen, ob sie diesen Community-basierten Daten
vertrauen können oder nicht.
Weiterhin wollen sie auch wissen,
welche Teile der eigenen Datensätze für Wikidata nützlich sind.
Und sie hätten gerne ein Tool,
mit dem sie dies automatisch beurteilen können.
Sie benötigen auch eine Methode oder ein Werkzeug,
das ihnen bei der Entscheidung hilft, ob sie ihre Daten importieren
oder verknüpfen sollen, denn in einigen Fällen
haben sie auch ihre eigenen verknüpften offenen Datensätze.
Sie wissen also nicht, ob sie die Daten nur aufnehmen sollen
oder weiterhin Links von den Datensätzen zu Wikidata erstellen sollen
und umgekehrt.
Und sie möchten auch wissen,
auf welche Websites in Wikidata verwiesen wird.
Und wenn sie eine solche Abfrage im Query Service ausführen,
bekommen sie oft Zeitüberschreitungen.
Vielleicht sollten wir wirklich mehr Werkzeuge schaffen,
die ihnen helfen, diese Antworten auf ihre Fragen zu bekommen.
Und davon abgesehen,
uns als Wiki-Forschern fehlen manchmal auch bei den Zusammenfassungen
der Änderungen einige Informationen.
Ich erinnere mich daran, als wir daran arbeiteten,
das unterschiedliche Verhalten der Bearbeiter zu verstehen
im Hinblick auf Tools oder Bots, anonyme Benutzer und so weiter,
fehlte uns zum Beispiel wirklich eine Standardmethode zum Nachverfolgen,
ob Tools verwendet wurden.
Und es gibt einige Tools, die das bereits tun
wie PetScan und viele andere,
aber vielleicht sollten wir in der Community
öfter darüber diskutieren, wie Sie diese
mit einer feinkörnigen Datenherkunft aufnehmen können.
Weiterhin sind wir der Meinung, dass wir
konkretere Datenqualitätsdimensionen berücksichtigen müssen,
die sich auf verbundene Daten beziehen, aber nicht alle Arten von Daten.
Deshalb haben wir einige Maßnahmen erarbeitet,
um auf den Informationsgewinn tatsächlich zuzugreifen,
der durch die Links aktiviert wird, und was wir damit meinen, ist,
dass wenn wir Wikidata mit anderen Datensätzen verknüpfen,
sollten wir auch daran denken,
wie viel die Entitäten tatsächlich durch die Klassifizierung gewinnen,
auch in der Beschreibung, aber auch in den Vokabeln, die sie verwenden.
Also nur um ein sehr einfaches Beispiel zu geben, was ich damit meine, ist,
was wir uns in diesem Fall vorstellen können, wäre, Wikidata
oder das externe Rechenzentrum, das mit Wikidata verknüpft ist,
dort haben wir die Entität einer Person, die Natasha Noy heißt,
wir haben die Zugehörigkeit und andere Dinge
und dann sagen wir: OK, wir verlinken zu einem externen Ort
und diese Entität hat den gleichen Namen, tatsächlich haben wir den gleichen Wert.
Was also besser wäre, ist, dass wir auf etwas verlinken,
das einen anderen Namen hat.
Das ist immer noch gültig, weil es zwei Möglichkeiten gibt,
den Namen dieser Person zu schreiben
und auch andere Informationen, die wir nicht in Wikidata haben
oder auch nicht in einem anderen Datensatz haben.
Aber was noch besser ist, ist,
dass wir tatsächlich im Zieldatensatz suchen,
da sie dort auch neue Möglichkeiten
zur Klassifizierung der Informationen haben.
Das ist also nicht nur eine Person, sondern in dem anderen Datensatz
steht auch, ob es sei eine Frau oder etwas anderes,
mit dem sie sich einordnen lässt.
Und wenn in dem anderen Datensatz, viele andere Vokabeln verwendet werden,
hilft das auch bei der gesamten Informationsbeschaffung.
Damit möchte ich auch sagen, dass wir denken,
dass wir gebündelte Abfragen besser präsentieren können,
denn wenn wir uns das Abfrageprotokoll von Malyshev et al. ansehen,
sehen wir, dass wir aus den organischen Abfragen
nur sehr wenige gebündelte Suchergebnisse haben.
Und tatsächlich ist Bündelung einer der Hauptvorteile von Verbindungsdaten.
Also vielleicht brauchen die Community oder die Leute, die Wikidata benutzen,
auch mehr Beispiele dazu.
Und wenn wir uns die Liste der verwendeten Endpunkte ansehen,
ist dies keine vollständige Liste und wir haben noch viele mehr.
Natürlich wurden diese Daten aus Abfragen bis März 2018 analysiert,
aber wir sollten uns jedoch die Liste der gebündelten Endpunkte ansehen,
die wir haben und sehen, ob wir sie wirklich benutzen oder nicht.
Also zwei Fragen, die ich für das Publikum habe,
die wir nachher als Grundlage für eine Diskussion verwenden können:
Welche Datenqualitätsprobleme sollten eurer Meinung nach behoben werden
aufgrund eurer Bedürfnisse?
Aber ebenso, wo braucht ihr mehr Automatisierung,
die euch beim Bearbeiten oder dem Kontrollieren hilft.
Das ist alles, vielen Dank.
(Jose Emilio Labra) Okay, worüber ich sprechen werde,
sind einige Tools, die wir im Zusammenhang mit Shape Expressions entwickelt haben.
Also darüber möchte ich etwas erzählen.
Ich bin Jose Emilio Labra,
aber all diese Tools wurden von verschiedenen Leuten gemacht,
hauptsächlich im Zusammenhang mit W3C ShEx,
der Shape Expressions Community Group.
ShEx Community Group.
Also das erste Tool, das ich erwähnen möchte, ist RDFShape,
dies ist ein allgemeines Werkzeug,
weil Shape Expressions nicht nur für Wikidata sind.
Shape Expressions ist eine Sprache zur allgemeinen Validierung von RDF.
Dieses Tool wurde hauptsächlich von mir entwickelt
und es ist ein Werkzeug, um RDF im Allgemeinen zu validieren.
Wenn ihr also mehr über RDF erfahren wollt oder RDF validieren möchtet
oder SPARQL-Endpunkte nicht nur in Wikidata,
ist meine Empfehlung, dass ihr dieses Tool verwenden könnt.
Auch zum Unterrichten.
Ich bin Lehrer an der Universität
und ich benutze es in meinem Semantic-Web-Kurs,
um RDF zu unterrichten.
Wenn ihr also RDF lernen möchtet, halte ich es für ein nützliches Werkzeug.
Dies ist beispielsweise eine Visualisierung
eines RDF-Diagramms mit dem Tool.
Aber bevor ich letzten Monat hierher gekommen bin,
habe ich einen Fork von rdfshape speziell für Wikidata erstellt,
weil ich dachte...
Es heißt WikiShape und ich habe es gestern als Geschenk für Wikidata präsentiert.
Was ich also genommen habe, ist...
Ich habe alles entfernt, was nicht mit Wikidata zu tun hatte
und um einige Dinge zu hartcodieren, zum Beispiel den Wikidata-SPARQL-Endpunkt.
Doch jetzt hat mich jemand gefragt, ob ich das auch für Wikibase machen könnte.
Und es ist auch für Wikibase sehr einfach zu machen.
Also dieses Tool, WikiShape, ist ziemlich neu.
Ich denke, es funktioniert, die meisten Funktionen,
aber es gibt einige Funktionen, die möglicherweise nicht funktionieren,
und wenn ihr es versuchen wollt oder es verbessern wollt,
sagt es mir bitte.
Das sind also [unverständlich] Aufnahmen,
aber ich denke, ich kann es auch so versuchen,
Also lasst es uns versuchen.
Mal sehen, ob es funktioniert.
Zuerst muss ich da rausgehen...
Hier.
Okay, ja. Das ist also das Werkzeug hier.
Dinge, die ihr mit dem Tool zum Beispiel machen könnt,
sind, ihr könnt Schemas, Entitätsschemas überprüfen.
Ihr wisst, dass es einen neuen Namespace gibt,
der E-irgendwas heißt.
Wenn ihr also hier zum Beispiel anfangt zu schreiben "Mensch"...
Während ihr schreibt, könnt ihr mittels der Autovervollständigung prüfen.
Dies ist zum Beispiel die Shape Expression für Mensch
und das sind die Shape Expressions hier.
Und wie ihr sehen könnt, hat dieser Editor Syntax-Hervorhebung,
das ist... naja, vielleicht ist der Bildschirm zu klein.
Ich kann versuchen, es größer zu machen.
Vielleicht seht ihr es jetzt besser.
Also... und das ist der Editor mit Syntax-Hervorhebung und er hat auch...
dieser Editor stammt aus demselben Quellcode
wie der Wikidata-Abfragedienst.
Also zum Beispiel, wenn man mit der Maus hier schwebt,
zeigt es die Beschriftungen der verschiedenen Eigenschaften.
Also ich finde, das ist sehr hilfreich, weil jetzt...
die Entitätsschemata in Wikidata
sind nur eine Idee in einfachem Text.
Aber ich denke, dieser Editor ist viel besser, weil er Autocomplete hat
und er hat auch...
Ich meine zum Beispiel, wenn ihr eine Einschränkung hinzufügen wolltet,
sagt ihr "wdt:",
und fangt an zu schreiben "author"
und klickt dann mit *Strg + Leertaste*
und es schlägt euch die verschiedenen Einträge vor.
Das ist also ähnlich wie beim Wikidata-Abfragedienst,
aber speziell für Shape Expressions,
weil ich das Gefühl habe, Shape Expressions zu kreieren
ist nicht schwieriger als das Schreiben von SPARQL-Abfragen.
Manche Leute denken, dass es auf dem gleichen Niveau ist.
Ich denke, es ist wahrscheinlich einfacher.
Denn die Shape Expressions waren, als wir es entworfen haben,
haben wir es getan, um die Arbeit zu vereinfachen.
Okay, das ist eines der ersten Dinge, die ihr in diesen Editor habt
für Shape Expressions.
Und dann habt ihr zum Beispiel auch die Möglichkeit, zu visualisieren.
Wenn man eine Shape Expression habt verwendet man zum Beispiel...
Ich denke, "written" ist eine schöne Shape Expression,
weil sie einige Beziehungen zwischen verschiedenen Dingen hat.
Und das ist die UML-Visualisierung von schriftlichen Arbeiten.
In UML sind die verschiedenen Eigenschaften leicht zu erkennen.
Wenn ihr dies macht - mir wurde das klar, als ich das mit mehreren Leuten versuchte,
finden diese einige Fehler in ihren Shape Expressions,
denn es ist leicht zu erkennen,
welche Eigenschaften fehlen oder was auch immer.
Dann hier eine andere Möglichkeit ist,
dass ihr auch validieren könnt, ich habe es hier, die Validierung.
Ich glaube, ich hatte es in einem Label, vielleicht habe ich es geschlossen.
Okay, aber ihr könnt beispielsweise hier *Validate entities* klicken,
zum Beispiel...
"q42" mit "e42", das ist Urheber.
Mit "human" können wir es machen, glaube ich.
Und dann ist es...
es dauert eine Weile, weil dabei die SPARQL-Abfragen ausgeführt werden
und jetzt, zum Beispiel, scheitert es am Netzwerk, aber...
Also ihr könnt es versuchen.
Gut, lasst uns mit der Präsentation der anderen Tools fortfahren.
Mein Rat ist also, wenn ihr es versuchen möchtet
und Feedback wollt, lasst es mich wissen.
Also, um mit der Präsentation fortzufahren...
Das ist also WikiShape.
Dann, das habe ich schon erwähnt,
gibt es den Shape Expressions Editor,
das ist ein eigenständiges Projekt in GitHub.
Ihr könnt es in eurem eigenen Projekt verwenden.
Wenn ihr ein Tool für Shape Expression benötigt,
könnt ihr es einfach in jedes andere Projekt einbetten.
Das ist auf GitHub und ihr könnt es benutzen.
Der gleiche Autor, einer meiner Schüler,
hat auch einen Editor für Shape Expressions erstellt,
ebenfalls inspiriert vom Wikidata-Abfragedienst,
wo ihr in dieser Spalte
diesen vorwiegend visuellen Editor für SPARQL-Abfragen habt,
wo ihr diese Dinge bewerkstelligen könnt.
Das ist also eine Bildschirmaufnahme.
Ihr könnt sehen, dass dies die Shape Expressions im Text sind.
Dies ist jedoch eine formularbasierte Shape Expression,
bei der es wahrscheinlich etwas länger dauern würde.
Hier könnt ihr die verschiedenen Zeilen in die verschiedenen Felder einfügen.
Oay, dann gibt es ShExEr.
Wir haben...
das wird von einem Doktoranden an der Universität von Oviedo gemacht
und er ist hier, damit er ShExEr präsentieren kann.
(Danny) Hallo, ich bin Danny Fernández,
Ich bin Doktorand an der Universität von Oviedo und arbeite mit Labra.
Da uns die Zeit davon läuft, lasst uns dies schnell machen.
Wir starten also keine Demo, sondern zeigen nur einige Screenshots.
Okay, also die übliche Art, mit Shape Expressions zu arbeiten
oder einer beliebigen Formsprache, ist,
dass Sie einen Domain-Experten haben,
der als Erstes definiert, wie der Graph aussehen soll
einige Strukturen definiert
und dann verwendet man diese Strukturen,
um die tatsächlichen Daten dagegen zu validieren.
Dieses Tool und auch diejenigen, die von Labra vorgestellt wurden,
sind Allzweckwerkzeuge für jede RDF-Quelle.
Es ist so konzipiert, dass es umgekehrt funktioniert.
Man hat bereits einige Daten,
Man wählt aus, welche Notizen die Form erhalten soll
und dann extrahiert oder schließt man die Form automatisch.
Also, auch wenn dies ein Allzweckwerkzeug ist,
was wir für diese WikidataCon gemacht haben,
ist diese schicke Schaltfläche.
Wenn man darauf klickt, was im Wesentlichen passiert, ist,
es gibt so viele Konfigurationsparameter
und es konfiguriert es für die Arbeit mit dem Wikidata-Endpunkt
und ich bin fast fertig, sorry.
Sobald man diesen Knopf drückt, erhält man im Wesentlichen Folgendes.
Nachdem man ausgewählt hat, welche Art von Notizen,
was für Instanzen unserer Klasse, was auch immer man will,
erhält man ein automatisches Schema.
Alle Einschränkungen sind danach sortiert,
wie viele Modi tatsächlich damit übereinstimmen.
Man kann so die selteneren filtern und so weiter.
Also wir haben da unten ein Poster über dieses Thema
und ich werde unten und oben sein
und überall den ganzen Tag.
Wer also weiteres Interesse an diesem Tool hat,
kann mich einfach während dieses Events ansprechen.
Und jetzt werde ich Labra das Mikro zurückgeben, danke.
(Jose) Also lasst uns mit den anderen Tools fortfahren.
Ein anderes Werkzeug ist der ShapeDesigner.
Andra, möchtest du jetzt den ShapeDesigner machen
oder vielleicht später im Workshop?
Es gibt einen Workshop...
Heute Nachmittag gibt es einen Workshop speziell für Shape Expressions und...
Die Idee ist, dass wir dort mehr in die Praxis gehen können,
und wenn ihr etwas ShEx üben möchtet, könnt ihr es dort tun.
Dieses Tool ist ShEx... und hier ist Eric,
also kannst du es präsentieren.
(Eric) Also einfach super schnell.
Das, was ich sagen möchte, ist,
dass ihr wahrscheinlich bereits die ShEx-Schnittstelle gesehen habt,
die auf Wikidata zugeschnitten ist.
Das ist effektiv vereinfacht und speziell auf Wikidata zugeschnitten
da die Generische mehr Funktionen hat,
sich aber herausstellte - ich dachte, ich sollte es erwähnen -
weil eine dieser Funktionen besonders nützlich
zum Debuggen von Wikidata-Schemas ist.
Das heißt, wenn ihr hingeht und den Slurp-Modus wählt,
was es tut, ist, es sagt, während ich validiere,
möchte ich alle Tripel herausziehen und das bedeutet,
wenn ich ein paar Ausfälle bekomme,
kann ich durchgehen und anfangen, diese Fehler zu betrachten und zu sagen:
Okay, was sind die Dreiergruppen, die hier drin sind -
Entschuldigung, die Dreiergruppen sind da unten,
dies ist nur ein Protokoll dessen, was passiert ist -
und dann könnt ihr einfach da sitzen und in Echtzeit damit experimentieren,
als würde man mit etwas spielen und es verändert sich.
Es ist also eine schnellere Variante, um all diese Dinge zu erledigen.
Dies ist ein ShExC-Formular.
Dies ist etwas, was Joachim vorgeschlagen hatte,
das nützlich sein könnte, um Wikidata-Dokumente zu füllen
basierend auf einer Shape Expression für dieses Dokument.
Dies ist nicht auf Wikidata zugeschnitten.
Dies soll jedoch nur heißen, dass ihr ein Schema haben könnt
und einige Anmerkungen, um genau zu sagen,
wie ich das Schema gerendert haben möchte,
und dann baut es einfach ein Formular auf.
Wenn ihr Daten habt, kann es das Formular ausfüllen.
PyShEx [unverständlich].
(Jose) Ich denke, das ist das Letzte.
Ja, das letzte ist PyShEx.
PyShEx ist eine Python-Implementierung von Shape Expressions.
Ihr könnt das auch mit Jupyter Notebooks ausprobieren,
wenn ihr so etwas wollt.
Oay, das ist alles dazu.
(Andra) Ich werde also über ein bestimmtes Projekt sprechen,
an dem ich beteiligt bin, GenWiki genannt,
und wo wir uns auch mit Qualitätsfragen beschäftigen.
Aber bevor wir auf die Qualität eingehen,
vielleicht eine kurze Einführung darüber, was GenWiki ist,
und wir haben gerade einen Vordruck einer Arbeit veröffentlicht,
die wir kürzlich geschrieben haben, welche die Details des Projekts erklärt.
Ich sehe Leute fotografieren, aber im Grunde genommen,
was Gene Wiki macht, es versucht, biomedizinische Daten,
öffentliche Daten in Wikidata hinein zu bekommen
und wir folgen einem bestimmten Muster, um diese Daten in Wikidata zu bekommen.
Also, wenn wir ein neues Repository oder einen neuen Datensatz haben,
der berechtigt ist, in Wikidata aufgenommen zu werden,
ist der erste Schritt das Engagement der Gemeinschaft.
Für eine Wikidata-Community ist dies nicht erforderlich,
aber für eine lokale Forschungsgemeinschaft,
und wir treffen uns persönlich oder online oder auf irgend einer Plattform
und versuchen, ein Datenmodell zu entwickeln,
das ihre Daten mit dem Wikidata-Modell verbindet.
Also hier habe ich ein Bild von einem Workshop,
der letztes Jahr hier stattgefunden hat.
Wir haben dort versucht, einen bestimmten Datensatz anzuschauen
und Sie sehen eine Menge Diskussionen,
dann die Ausrichtung an schema.org und andere vorhandenen Ontologien.
Und dann, am Ende des ersten Schritts,
haben wir eine Whiteboard-Zeichnung des Schemas,
das wir in Wikidata implementieren wollen.
Was Sie dort sehen können, ziemlich offensichtlich,
es ist im Hintergrund.
Wir können heute sogar einige Schemata in diesem Panel erstellen.
Sobald wir das Schema eingerichtet haben,
versuchen wir als Nächstes, das Schema maschinenlesbar zu machen,
weil man umsetzbare Modelle braucht,
um die Daten zu überbrücken, die man einbringt
aus jeder biomedizinischen Datenbank nach Wikidata.
Und hier wenden wir Shape Expressions an.
Und das verwenden wir,
weil man mit Shape Expressions testen kann,
ob der Datensatz tatsächlich... nein, man kann zuerst sehen,
ob bereits vorhandene Daten in Wikidata dem gleichen Datenmodell folgen,
das im vorherigen Prozess erreicht wurde.
Dann können wir mit den Shape Expressions überprüfen:
Okay, die Daten, die zu diesem Thema in Wikidata sind,
müssen bereinigt werden oder wir müssen unser Modell
an das Wikidata-Modell anpassen oder umgekehrt.
Sobald das erledigt ist und wir anfangen, Bots zu schreiben,
und die Bots sähen regelmäßig die Informationen,
die in den primären Quellen ist, nach Wikidata.
Und wenn die Bots fertig sind,
schreiben wir diese Bots mit einer Plattform namens...
mit einer Python-Bibliothek namens Wikidata Integrator.
Diese kam aus unserem Projekt.
Und sobald wir unsere Bots haben, benutzen wir eine Plattform namens Jenkins
für die kontinuierliche integration.
Und mit Jenkins
aktualisieren wir ständig die primären Quellen mit Wikidata.
Und dies ist ein Diagramm für die Arbeit, die ich zuvor erwähnt habe.
Das ist unsere aktuelle Landschaft.
Also jede orangefarbene Kiste da drauf ist eine primäre Ressource für Medikamente,
Proteine, Gene, Krankheiten, chemische Verbindungen mit Wechselwirkung,
und dieses Modell ist zu klein, um es jetzt zu lesen.
Aber das ist die Datenbank, die Quellen,
die wir in Wikidata verwalten
und überbrücken zu den Primärquellen.
Hier ist so ein Workflow.
Einer unserer Partner ist die Disease Ontology.
Die Disease Ontology ist eine CC0 Ontologie
und die CC0 Ontologie hat einen eigenen Kurationszyklus
und sie aktualisieren nur kontinuierlich die Disease Ontology,
um den Krankheitsbereich
oder die Interpretation von Krankheiten zu reflektieren.
Und es gibt den Wikidata-Kurationszyklus ebenso für Krankheiten,
wo die Wikidata-Community ständig überwacht,
was auf Wikidata los ist.
Und dann haben wir zwei Rollen,
wir nennen sie umgangssprachlich den Gatekeeper-Kurator,
und das waren ich und ein Kollege vor fünf Jahren,
wo wir nur an unseren Computern saßen und Wikipedia und Wikidata überwachten
und wenn es ein Problem gab, wurde es der primären Community gemeldet,
die primäre Ressourcen, sie betrachteten die Implementierung und beschlossen:
Okay, vertrauen wir dem Input aus Wikidata?
Ja - dann wird erwägt, geht es in den Kreislauf,
und die nächste Iteration ist Teil der Disease Ontology
und wird in Wikidata zurückgespeist.
Wir machen dasselbe für WikiPathways.
WikiPathways ist ein von MediaWiki inspiriertes Pfad-Repository.
Dieselbe Geschichte, es gibt bereits verschiedene Pfad-Ressourcen
auf Wikidata.
Möglicherweise gibt es Konflikte zwischen diesen Pfadressourcen
und diese Konflikte werden zurückgemeldet
von den Gatekeeper-Kuratoren zu dieser Community,
und man pflegt die einzelnen Kurationszyklen.
Aber wenn Sie sich an den vorherigen Zyklus erinnern,
hier erwähnte ich nur zwei Zyklen, zwei Ressourcen.
Das müssen wir für jede einzelne Ressource tun, die wir haben,
und wir müssen alles, was vor sich geht, verwalten,
denn wenn ich Kuration sage,
meine ich wirklich, auf die Wikipedia-Top-Seiten zu gehen,
auf die Wikidata-Top-Seiten zu gehen und das auszuprobieren.
Das skaliert nicht mit den beiden Gatekeeper-Kuratoren, die wir hatten.
Also, als ich 2016 an einer Konferenz teilgenommen habe,
wo Eric einen Vortrag über Shape Expressions hielt,
sprang ich auf den Zug und sagte: Okay,
mit Hilfe von Shape Expressions können wir feststellen,
welche Unterschiede in Wikidata bestehen
und so können die Gatekeeper
effizienter berichten in dem Log.
Dieses Jahr war ich von der Schemaentität begeistert,
denn jetzt können wir diese Entitätsschemata
auf Wikidata speichern,
auf Wikidata selbst, während es zuvor auf GitHub war.
Und dies integriert mit der Wikidata-Oberfläche,
man hat also Dinge wie Dokumentendiskussionen,
man hat aber auch Revisionen.
Ihr könnt also die Top-Seiten und die Revisionen in Wikidata nutzen,
um darüber zu diskutieren,
was in Wikidata ist und was in den primären Ressourcen.
Also das, was Eric gerade vorgestellt hat, ist schon ein ziemlicher Vorteil.
Also hier haben wir eine Shape Expression für das menschliche Gen erfunden
und dann ließen wir es durch ShEx laufen und wie Sie sehen können,
wir haben gerade erst eines.
Es gibt ein Problem, das überwacht werden muss,
es gibt ein Element, das nicht in dieses Schema passt,
und dann können Sie bereits Schemaentitäten erstellen
und Kurationsberichte basierend auf...
und das an die verschiedenen Kurationsberichte senden.
Aber die ShEx.js ist eine integrierte Schnittstelle
und hier noch mal eine Folie zurück, mache ich nur zehn,
aber wir haben Zehntausende und das skaliert wieder nicht.
Der Wikidata Integrator unterstützt jetzt auch ShEx
und dann können wir einfach Item-Loops verwenden,
wo wir ja-nein, ja-nein, wahr-falsch, wahr-falsch sagen.
Also nochmal,
eine Steigerung der Effizienz beim Arbeiten mit den Berichten.
Aber jetzt, in letzter Zeit, baut das auf dem Wikidata Query Service auf
und wir haben das etwas gedrosselt,
also nochmal, das skaliert nicht.
Es ist also immer noch ein fortlaufender Prozess,
wie man mit Modellen auf Wikidata umgeht.
Und ShEx ist also nicht nur furchteinflössend,
aber auch das Ausmaß ist einfach zu groß, um damit umzugehen.
Also habe ich angefangen zu arbeiten, dies ist mein erster Proof of Concept
oder meine erste Übung,
wo ich ein Werkzeug namens yED verwendet habe
und ich fing an, diese Shape Expressions zu zeichnen und weil...
und dann dieses Schema neu zu generieren
in dieses Schema in das JSON-Format der Shape-Ausdrücke,
damit sich das einem Publikum öffnet,
das von den Shape Expressions-Sprachen eingeschüchtert wird.
Tatsächlich gibt es jedoch ein Problem mit diesen visuellen Beschreibungen,
denn dies ist auch ein Schema,
das tatsächlich von jemandem in yEd gezeichnet wurde.
Und hier ist ein anderes, das schön ist.
Ich hätte das gerne an meiner Wand,
aber es ist immer noch nicht interoperabel.
Ich möchte meinen Vortrag beenden...
und es war das erste Mal,
dass ich diese Folie gestohlen, gebraucht habe.
Es ist eine Ehre, ihn im Publikum zu haben
und ich mag das wirklich:
"Die Leute denken, RDF ist eine Qual, weil es kompliziert ist.
Die Wahrheit ist noch schlimmer, es ist so einfach,
weil Sie mit realen Datenproblemen arbeiten müssen,
die schrecklich kompliziert sind.
Während Sie RDF vermeiden können,
ist es schwieriger, komplizierte Daten
und komplizierte Computerprobleme zu vermeiden."
Hier geht es um RDF, aber ich denke, das gilt auch für das Modellieren.
Mein Diskussionspunkt ist also, ob wir wirklich...
Wie bringen wir das Modellieren voran?
Sollen wir über ShEx oder visuelle Modelle sprechen oder...
Wie machen wir weiter?
Vielen Dank für Ihre Zeit.
(Lydia) Vielen Dank.
Würdest du nach vorne kommen,
damit wir mit den Fragen aus dem Publikum anfangen können?
Gibt es Fragen?
Ja.
Und ich denke, wegen der Kamera müssen wir...
(Lydia) Ja.
(Zuschauer1) Also eine Frage an Cristina, denke ich.
Also du hast im Wortlaut den Begriff "Informationsgewinn" erwähnt
bei der Verknüpfung mit anderen Systemen.
Es gibt das informationstheoretische Maß Informationsgewinn,
welches Statistik und Wahrscheinlichkeit verwendet.
Hast du das... ich meine, hast du genau dieses Maß gemeint,
den Informationsgewinn aus der Wahrscheinlichkeitstheorie,
aus der Informationstheorie,
oder verwendest du einfach dieses Konzept,
um den Informationsgewinn irgendwie zu messen?
Nein, also wir haben Maßnahmen definiert und umgesetzt,
die die Shannon-Entropie verwenden,
auf dies bezieht sich das.
Ich wollte nicht auf die Details der konkreten Formeln eingehen...
(Zuschauer1) Nein, klar, das war meine Frage.
- (Cristina) Aber ja. - (Zuschauer1) Danke.
(Zuschauer2) Ich habe eher einen Kommentar als eine Frage.
(Lydia) Los geht es.
(Zuschauer2) Es gab also viel Fokus auf der Item-Ebene
bezüglich der Qualität und Vollständigkeit.
Eines der Dinge, die mich beschäftigen, ist,
dass wir nicht dasselbe auf Hierarchien anwenden
und ich glaube, das wird uns ein Problem bereiten
dass unsere Hierarchie oft nicht gut ist.
Wir denken, dass dies ein echtes Problem wird
beim Durchsuchen von Commons und anderen Dingen.
Eine der Fähigkeiten, die wir realisieren können, ist,
extern zu importieren --
Die Art und Weise, wie externe Thesauren ihre Hierarchien strukturieren
mit der P4900 Qualifikation für Oberbegriffe.
Aber was ich für sehr hilfreich halte, wären viel bessere Werkzeuge dafür.
Damit kann man die Hierarchie eines externen Thesaurus importieren
und das auf unsere Wikidata-Items abbilden.
Sobald es mit diesen P4900-Qualifizierern zusammen funktioniert,
kann man über SPARQL ziemlich gute Abfragen durchführen,
um zu sehen, wo unsere Hierarchie von dieser externen Hierarchie abweicht.
Zum Beispiel, Paula Morma, User PKM, wie ihr vielleicht wisst,
hat viel über Mode ausgearbeitet.
Das nutzen wir also, um die Hierarchie
des Europeana Fashion Thesaurus zu übernehmen
und die Getty AAT Mode-Thesaurus-Hierarchie,
um dann zu sehen, wo die Lücken
in unseren höhergestuften Items waren,
was ein echtes Problem für uns ist, weil das oft Dinge sind,
die nur als Seiten zur Disambiguierung auf Wikipedia existieren,
Es fehlen also viele übergeordnete Elemente in unseren Hierarchien
und das ist etwas, das wir in Bezug auf Qualität und Vollständigkeit
ansprechen müssen.
Aber was wirklich helfen würde,
wäre ein besseres Werkzeug als der Dschungel der Pull-Skripte,
die ich geschrieben habe.
Wenn jemand das in ein PAWS-Notizbuch in Python schreiben könnte,
um einen externen Thesaurus verwenden zu können,
dessen Hierarchie zu verwenden,
die als verknüpfte Daten verfügbar sein können oder nicht,
um diese dann in Schnellanweisungen umzusetzen und P4900-Werte einzugeben.
Und später dann,
wenn unsere Darstellung vervollständigt wird,
diese P4900s zu aktualisieren, denn sobald unsere Darstellung veraltet,
dichter wird,
müssen die Werte dieser Qualifikationsmerkmale geändert werden,
um darzustellen, dass wir mehr aus ihrer Hierarchie
in unserem System implementiert haben.
Wenn jemand das tun könnte, wäre das sehr hilfreich, denke ich,
und wir müssen uns auch andere Ansätze ansehen,
um die Qualität und Vollständigkeit auf Hierarchieebene zu verbessern,
nicht nur auf der Artikelebene.
(Andra) Kann ich das ergänzen?
Ja, und das machen wir tatsächlich
und meine Empfehlung ist, die Shape Expression zu betrachten,
die Finn gemacht hat mit den lexikalischen Daten,
in denen er Shape Expressions erstellt
und dann auf Autorenausdrücken aufbaut,
so dass wir also dieses Konzept der verknüpften Formausdrücke
in Wikidata haben.
Insbesondere der Anwendungsfall, wenn ich richtig verstehe,
entspricht genau dem, was wir in Gene Wiki machen.
Man hat also die Disease Ontology, die in Wikidata importiert ist,
dann kommen die Krankheitsdaten und wir wenden die Shape Expressions an,
um zu sehen, ob das zu diesem Thesaurus passt.
Und es gibt andere Thesauren
oder andere Ontologien für kontrolliertes Vokabular,
das noch in Wikidata rein muss
und genau deshalb sind Shape Expressions so interessant,
weil sie für die Disease Ontology möglich sind,
man kann Shape Expressions für MeSH haben.
Man kann sagen, ich möchte die Qualität überprüfen,
weil man auch in Wikidata den Kontext bei einem kontrollierten Vokabular hat,
dass man sagt, die Qualität entspricht dem,
aber die Community stimmt euch nicht zu.
Das Werkzeug ist also in der Tat vorhanden,
aber jetzt müssen diese Modelle erstellt und angewendet werden
auf die verschiedenen Anwendungsfälle.
(Zuschauer2) Die Shape Expressions sind nützlich,
sobald ihr die externe Ontologie in Wikidata abgebildet habt,
aber mein Problem ist, dass dieser Zeitpunkt erst kommt.
Momentan legt es nur offen, wie viel von der externen Ontologie
noch nicht in Wikidata enthalten ist
und wo die Lücken sind
und dies ist, wo ich denke, dass viel robustere Werkzeuge,
mit denen ihr erkennen könnt, was aus externen Ontologien fehlt,
sehr hilfreich wären.
Das größte Problem dort
sind nicht so sehr die Werkzeuge, sondern mehr die Lizenzierung.
Also das Einspielen der Ontologien in Wikidata ist ein Kinderspiel,
aber die meisten Ontologien haben, wie kann ich das höflich sagen,
restriktive Lizenzierung, daher sind diese nicht mit Wikidata kompatibel.
(Zuschauer2) Es gibt eine große Anzahl von Thesauren im öffentlichen Sektor
in kulturellen Bereichen.
- (Andra) Dann müssen wir reden. - (Zuschauer2) Kein Problem.
(Andra) Darüber müssen wir reden.
(Zuschauer3) Der Kommentar, den ich machen möchte,
ist eigentlich eine Antwort auf James.
Also die Sache ist die, dass Hierarchien Graphen machen
und wenn du ...
Ich möchte im Grunde genommen über ein bekanntes Problem
in Hierarchien sprechen, das sind zirkuläre Hierarchien,
die auf sich selbst zurück führen, wenn es ein Problem gibt,
das sollte man nicht in Hierarchien haben.
Witzigerweise passiert dies häufig in Wikipedia-Kategorien,
wir haben viele Kreise in Kategorien.
Aber die gute Nachricht ist, dass dies...
Technisch gesehen ist es ein PMP-vollständiges Problem.
Also ihr könnt dies nicht einfach finden,
wenn ihr ein Diagramm davon baut.
Aber es gibt viele Methoden, die entwickelt wurden,
um Probleme in diesen Hierarchiediagrammen zu finden.
Es gibt einen Artikel
namens *Breaking Cycles in Noisy Hierarchies*
und der wurde verwendet,
um die Kategorisierung der englischen Wikipedia zu erleichtern.
Ihr könnt dies einfach nehmen und diese Hierarchien
in Wikidata anwenden,
und dann könnt ihr Dinge finden, die problematisch sind
und diejenigen einfach entfernen, die Probleme verursachen,
und die eigentlichen Probleme finden.
Das ist also nur eine Idee, nur, damit ihr...
(Zuschauer2) Das ist schön und gut,
aber ich denke, ihr unterschätzt die Anzahl
der schlechten Beziehungen in den Subklassen, die wir haben.
Das ist, wie eine Stadt in einem völlig falschen Land zu haben
und es gibt Werkzeuge in der Geographie, um so etwas zu identifizieren,
und wir brauchen viel bessere Werkzeuge in Hierarchien,
um zu identifizieren, wo das Äquivalent des Items für das Land
vollständig fehlt oder tatsächlich in einer Subklasse eingeordnet ist,
die eine völlig andere Bedeutung hat.
(Lydia) Ja, ich denke, du sprichst etwas an,
das ich und mein Team immer wieder von Leuten hören,
die unsere Daten auch ziemlich häufig wiederverwenden, ja.
Einzelne Datenpunkte könnten großartig sein,
aber wenn ihr euch die Ontologie und so weiter ansehen müsst,
dann wird es sehr...
Und ich denke, eines der großen Probleme, warum dies passiert, ist,
dass vieles, was auf Wikidata editiert wird, auf der Grundlage
eines einzelnen Artikels basiert, ja.
Ihr bearbeitet dieses Element,
ohne zu bemerken, dass die Konsequenzen von globaler Natur sind
im Bezug auf dem Rest des Diagramms zum Beispiel.
Und wenn jemand eine Idee hat, wie man dies sichtbarer machen kann,
die Folgen einer einzelnen lokalen Bearbeitung,
ich denke, das wäre es wert, das herauszufinden,
den Leuten besser zu zeigen, was die Folge ihrer Überarbeitung ist,
die sie in gutem Glauben vornahmen,
was das ist.
Whoa! OK, fangen wir an mit, ja, du, dann du, dann du, dann du.
(Zuschauer4) Nun, nach dieser Diskussion
will ich nur meine Zustimmung geben zu dem, was James sagte.
Also das Gefährlichste scheint im Wesentlichen die Hierarchie zu sein,
nicht die Hierarchie, sondern allgemein die Semantik der Beziehungen
der Subklassen aus Wikidata.
Ich habe vor kurzem Sprachen studiert nur für die Zwecke dieser Konferenz
und zum Beispiel finden Sie viele Fälle,
wo eine Sprache sowohl Teil als auch Subklasse derselben Sache ist, okay.
Man könnte auch sagen, dass wir eine flexible Ontologie haben.
Wikidata gibt manchmal die Freiheit, dies auszudrücken,
zum Beispiel, weil diese Ontologie der Sprachen
auch politisch kompliziert ist, oder?
Es ist sogar gut, in der Lage zu sein,
ein gewisses Maß an Unsicherheit auszudrücken.
Aber stellen Sie sich vor, wer daraus maschinell lesen möchte.
Das ist also wirklich problematisch.
Andererseits glaube ich nicht,
dass Ontologie jemals von irgendwoher importiert wurde,
das ist etwas, was ursprünglich von uns kommt.
Wikipedia hat seit den Anfängen seinen Nutzen daraus gezogen, meine ich.
Also frage ich mich, diese Sache mit den Shape Expressions-Ding ist toll.
Das Validieren und Reparieren von Wikidata-Ontologien
durch externe Ressourcen, schöne Idee.
Werden wir letztendlich dort enden, dass wir externen Ontologien
in Wikidata widerspiegeln?
Und ebenso, was sollen wir mit dem Kern unserer Ontologie machen,
der nie von externen Ressourcen verwendet wird,
wie können wir das beheben?
Und ich denke wirklich, dass das ein Problem für sich sein wird.
Darauf müssen wir uns unabhängig von der Idee konzentrieren,
Ontologien mit etwas Externem zu validieren.
(Zuschauer5) Okay, die Constraints und Shapes sind sehr beeindruckend,
was man damit machen kann,
aber das Hauptanliegen ist nicht wirklich klar hervorgetreten.
Das liegt daran, dass wir jetzt genauer definieren können,
was wir von den Daten erwarten.
Vorher muss jeder seine eigenen Tools und Skripte schreiben
und so ist es sichtbarer und wir können darüber diskutieren.
Aber weil es nicht darum geht, was falsch oder richtig ist,
sondern um eine Erwartung
und ihr werdet unterschiedliche Erwartungen
und Diskussionen darüber haben,
wie wir Dinge in Wikidata modellieren wollen,
und das...
Der aktuelle Stand ist nur ein Schritt in die richtige Richtung,
denn jetzt braucht man sehr viel technisches Know-how,
um da reinzukommen
und wir brauchen bessere Möglichkeiten, um diese Constraints zu visualisieren,
vielleicht um es in natürliche Sprache umzuwandeln,
damit es die Leute besser verstehen können,
aber es geht weniger darum, was falsch oder richtig ist.
(Lydia) Ja.
(Zuschauer6) Zu den Qualitätsproblemen möchte ich einfach hinzufügen,
viele der Probleme, auf die ich gestoßen bin,
waren Meinungsunterschiede zwischen *Instanz von* und *Subklasse*.
Ich würde behaupten, Fehler in diesen Situationen
und zu versuchen, diese zu finden, ist sehr zeitaufwändig.
Ich bin auf so etwas gestoßen wie:
"Oh, wenn ich sehr eindrucksvolle Items finde,
die in etwa...
und dann verwendet man alle Subklasseninstanzen,
um alle abgeleiteten Anweisungen davon zu finden."
Dies ist eine sehr nützliche Methode, um nach diesen Fehlern zu suchen.
Aber ich war neugierig, ob Shape Expressions,
ob es ...
ob dies als Werkzeug zur Lösung
dieser Probleme verwendet werden kann, aber ja...
(Zuschauer7) Wenn es einen strukturellen Footprint hat...
Wenn es einen strukturellen Footprint hat,
der irgendwie fälschbar ist,
ihr seht das und könnt sagen, das ist falsch,
ja, dann kannst du das machen.
Aber wenn es nur darum geht, es auf reale Objekte abzubilden,
dann wirst du einfach viel, viel Hirnschmalz brauchen.
(Zuschauer8) Hallo, Pablo Mendes von Apple Siri Knowledge.
Wir sind hier, um herauszufinden,
wie wir dem Projekt und der Community helfen können,
aber Cristina machte den Fehler, zu fragen, was wir wollen.
Also eine Sache, dich ich gerne sehen würde:
Es geht viel um Überprüfbarkeit,
was eines der Grundprinzipien des Projekts in der Gemeinschaft ist,
und Vertrauenswürdigkeit.
Nicht jede Aussage ist gleich, einige von ihnen sind heftig umstritten,
einige von ihnen sind leicht zu lösen,
wie das Geburtsdatum einer Person zu überprüfen.
Wie ihr heute in der Keynote gesehen habt,
ist Geschlechterproblematik komplizierter.
Könnt ihr ein bisschen darüber diskutieren,
was ihr aus diesem Bereich der Datenqualität wisst,
über Vertrauenswürdigkeit und Überprüfbarkeit?
Wenn es nicht viel ist, würde ich gerne viel mehr sehen.
(Lydia) Ja.
Dazu haben wir offenbar nicht viel zu sagen.
(Andra) Ich denke, wir können viel tun,
aber ich hatte gestern ein Gespräch mit dir.
Mein Lieblingsbeispiel, das ich gestern gelernt habe und bereits veraltet ist,
ist, wenn Sie zu Q2 gehen, was die Erde ist,
da gibt eine Behauptung, die besagt, die Erde sei flach.
Und ich liebe dieses Beispiel,
weil es da draußen eine Community gibt,
die das behauptet und sie haben nachprüfbare Ressourcen.
Also ich denke, es ist ein echter Fall,
der nicht abgelehnt werden sondern in Wikidata sein sollte.
Und ich denke, dass Shape Expressions dort wirklich hilfreich sein können,
weil man sagen kann: Okay,
ich bin wirklich an diesem Anwendungsfall interessiert,
oder dies ist ein Anwendungsfall, mit dem ihr nicht einverstanden seid.
Es kann aber auch einen Anwendungsfall geben,
bei dem ihr sagt, okay, das interessiert mich.
Es gibt dieses Beispiel, wo ihr sagt, ich habe Glukose.
Und Glukose, wenn man Biologe ist,
interessiert man sich nicht für die chemischen Restriktionen
des Glukosemoleküls,
Glukose ist immer gleich.
Aber wenn man Chemiker ist, zuckt man zusammen, wenn man das hört,
man hast etwa 200...
Dann kann man viele Shape Expressions nehmen,
okay, ich komme mit... aus der Sicht eines Chemikers,
ich wende das an.
Und dann sagst du, ich gehe von einem biologischen Anwendungsfall aus,
ich wende diese Shape Expression an.
Und wenn ihr dann kollaborieren möchtet,
ja, nun, dann solltet ihr mit Eric über ShEx-Maps sprechen.
Und so... aber diese Reise beginnt gerade erst.
Aber ich persönlich glaube, dass dies in diesem Bereich sehr entscheidend ist.
(Lydia) Okay. Da drüben.
(Zuschauerin1) Ich hatte einige Ideen
zu einigen Punkten in den Diskussionen.
Also werde ich versuchen, diese nicht zu vergessen...
Ich hatte drei Ideen, also...
Basierend auf dem, was James vor einer Weile gesagt hat,
haben wir von Anfang an ein sehr, sehr großes Problem bei Wikidata
bei der oberen Ontologie.
Darüber haben wir vor zwei Jahren bei WikidataCon gesprochen
und wir haben darüber bei Wikimania gesprochen.
Bei jedem Wikidata-Treffen
sprechen wir darüber,
weil es ein sehr großes Problem direkt vor unseren Augen ist.
Was eine Entität ist, was Arbeit ist,
was ein Genre ist, Kunst,
wirklich die wichtigsten Konzepte.
Und das ist tatsächlich ein sehr schwacher Punkt
im Bezug auf die globale Ontologie,
weil die Leute versuchen, regelmäßig aufzuräumen
und alles komplett kaputt gemacht haben.
Ich denke, einige von euch erinnern sich vielleicht an den Typ,
der in gutem Glauben absolut alle Städte auf der Welt durcheinander brachte.
Das waren keine geografischen Objekte mehr,
daher gibt es überall Verstöße gegen Constraints.
Und es passierte in gutem Glauben,
weil er eigentlich einen Fehler in einem Artikel korrigierte,
aber alles brach zusammen.
Und ich bin nicht sicher, wie wir das lösen können,
da es eigentlich keine externe Einrichtung gibt,
die wir verwenden könnten,
weil alle daran arbeiten...
Nun, wenn ich Datenbank für Kunst am Laufen habe,
werde ich nur das verwendete Label für Kunst nehmen,
ich kümmere mich nicht um das philosophische Konzept dessen,
was eine Entität ist,
und das ist eigentlich...
Ich kenne keine Datenbank, die auf diesem Niveau arbeitet,
aber das ist der schwächste Punkt von Wikidata.
Und wahrscheinlich, wenn wir über Datenqualität sprechen,
ist das eigentlich ein großer Teil davon, also...
Und ich denke, es ist dasselbe, was wir gesagt haben...
Oh, tut mir leid, ich wechsle das Thema
Aber wir haben in verschiedenen Meetings über Qualitäten gesprochen,
dass einige von uns eigentlich gute Modellierung machen,
ShEx und solche Dinge tun.
Die Leute sehen es nicht auf Wikidata, sie sehen ShEx nicht,
Sie sehen das WikiProjekt nicht auf der Diskussionsseite und manchmal
sehen sie nicht einmal die Diskussionsseiten von Eigenschaften,
die ausdrücklich angeben, a), diese Eigenschaft wird dafür verwendet.
Letzte Woche zum Beispiel habe ich Constraints einer Eigenschaft hinzugefügt.
Das Constraint wurde ausdrücklich beschrieben
in der Diskussion bei der Einführung der Eigenschaft.
Ich hatte gerade den technischen Teil zum Hinzufügen der Constraint erstellt
und jemanden meinte:
"Was! Du hast alle meine Bearbeitungen zerstört!"
Und die letzten zwei Jahre nutzte er die Eigenschaft auf die falsche Art.
Und die Eigenschaft war eigentlich sehr klar,
aber es gab keine Warnungen oder so etwas.
Und so ist es auch beim Pink Pony, dass wir bei Wikimania gesagt haben,
WikiProject sichtbarer zu machen oder ShEx sichtbarer zu machen,
aber, und das hat Cristina gesagt,
wir haben ein Problem mit der Sichtbarkeit
der vorhandenen Lösungen.
Und in dieser Session haben wir alle darüber geredet,
wie man mehr mit ShEx arbeitet
oder die Arbeit der Leute erleichtert, die alles korrigieren.
Aber wir korrigieren seit dem ersten Tag von Wikidata
und global verlieren wir und wir verlieren, weil, na ja,
wenn ich weiß, dass Namen kompliziert sind,
aber ich die einzige bin, die die Korrekturen macht,
der Typ, der den lateinischen Namen hinzugefügt hat
für alle chinesischen Forscher,
dafür brauche ich Monate um das zu korrigieren.
und ich kann es nicht alleine tun,
und er hat einen großen Batch gemacht.
Also brauchen wir wirklich...
Wir haben mehr ein Sichtbarkeitsproblem als ein Werkzeugproblem, denke ich,
weil wir viele Werkzeuge haben.
(Lydia) Richtig, aber leider habe ich ein Zeichen bekommen,
wir müssen das also abschließen.
Vielen Dank für eure Kommentare.
Ich hoffe, ihr werdet die Diskussion über den Tag fortführen
und vielen Dank für euren Beitrag.