cdn.media.ccc.de/.../wikidatacon2019-9-eng-Data_quality_panel_hd.mp4

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.