Wikidata:Forum/Archiv/2018/05

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Abfrage mit Link

Mit dieser Abfrage (tinyurl.com/ya6c5h6b) möchte ich einen Link in der Form geo.hlipp.de/browse.php?ll=?lat,?lon generieren. Bei der Abfrage entsteht kein aktiver Link. Ich vermute, dass es am Format der Werte ?lat und ?lon liegt. Wie vermeide ich Duplikate in der Trefferliste? Viele Grüße --ChristianSW (talk) 16:44, 22 April 2018 (UTC)

@ChristianSW: das Problem war, dass ?lat und ?lon keine Strings waren, das behebt man mit STR(?lat) [1]. Bei den Duplikaten kann ich dir leider nicht weiterhelfen, frag am besten in WD:RAQ auf englisch nach. Viele Grüße Bigbossfarin (talk) 19:08, 23 April 2018 (UTC)
@Bigbossfarin: Danke und viele Grüße! --ChristianSW (talk) 19:46, 23 April 2018 (UTC)
@ChristianSW: … und mit DISTINCT sind es zumindest einige Duplikate weniger. --Marsupium (talk) 20:49, 24 April 2018 (UTC)
@Marsupium: Ja, das habe ich auch bereits ausprobiert. Ich denke, dass ich die ersten Zeilen von WHERE falsch gebildet habe. Mir geht es darum, alle Objekte (eines bestimmten Typs: Mühle, Schule, ...) ausfindig zu machen, die sich in einem Gebiet (Landkreis/Stadt/...) befinden. Also auch Untereinheiten zu "liegt in der Verwaltungseinheit" und "Ort". Viele Grüße --ChristianSW (talk) 04:22, 25 April 2018 (UTC)
Nachtrag: Ich habe funktionierende Abfragen variiert: Sobald ich die Abfrage nach ?lat und ?lon anhänge, treten die ersten Duplikate auf. Zum Basteln komme ich erst frühestens heute Abend wieder. --ChristianSW (talk) 04:54, 25 April 2018 (UTC)
Es klappt nun: tinyurl.com/ydhzl4z8 Einen schönen Mai wünscht --ChristianSW (talk) 15:56, 1 May 2018 (UTC)

Property:P1087

Hier scheint irgendwas falsch gelaufen zu sein, nach meiner Ergänzung eines Constraint ist die Con-Vio-Liste vom Bot jetzt geleert worden. Was ist da falsch? Steak (talk) 12:57, 27 April 2018 (UTC)

User talk:Ivan A. Krestinin#new constraint type no bounds constraint (Q51723761). Ivan muss das implementieren, daher wird das bald wieder laufen; bei einer anderen Eigenschaft hat es heute morgen schonmal kurz geklappt. Ich plane, diese neue Einschränkung an so einige Quantity-Eigenschaften anzubringen, dabei aber jeweils auch die Verletzungen abzuarbeiten. Elo hat ziemlich viele Claims, das sollte jedoch eher ein Bot machen denke ich… —MisterSynergy (talk) 14:19, 27 April 2018 (UTC)
Was genau soll ein Bot machen? Laut der neu erstellten Con-Vio-Liste gibt es diesbezüglich keine Verletzungen. Steak (talk) 14:38, 28 April 2018 (UTC)
Nix, hast Recht. Irgendwie hab ich die Eigenschaft wohl mit einer anderen verwechselt. —MisterSynergy (talk) 14:55, 28 April 2018 (UTC)

@MisterSynergy: Mir scheint, dass der Constraint nicht richtig ausgewertet wird: Property:P1350 hat angeblich keine entsprechenden Verletzungen, es gibt aber welche (z. B. Q1944). Steak (talk) 22:38, 30 April 2018 (UTC)

Mittlerweile sind die weg; ich repariere das gerade systematisch, siehe meine letzten Änderungen.
Tatsächlich muss man bei den covi reports ein bisschen unterscheiden, des es gibt letztlich zwei unabhängige Auswertungen, die sich auf dieselben Constraint-Definitionen stützen (nämlich die in den Eigenschaftsseiten im Abschnitt „Constraints“):
  1. Die botgestützten Listen unter Wikidata:Database reports/Constraint violations sind älter und bekannter, aber letztlich dem Einsatz von User:Ivan A. Krestinin zu verdanken, der dafür ziemlich großen Aufwand treibt. Einige Dinge wertet er nicht aus, wie zum Beispiel Verletzungen in Qualifikatoren oder in Referenzen. Diese Listen werden letztlich communitygestützt gepflegt, und wenn Ivans Bot ausfällt, springt Pasleim manchmal mit dem Deltabot (oder PLbot?) ein.
  2. Das Wikidata-eigene System ist jünger, und umfasst sichtbar vor allem das Gadget, welches Dir die Verletzungen direkt im Objekt anzeigt, und Dinge wie Special:ConstraintReport/Q1944. Dieses System kann mittlerweile auch in Qualifikatoren und Fundstellen Verletzungen analysieren, und tut das darüber hinaus mehr oder weniger live. Richtige Listen bekommt es (bislang) nicht hin.
—MisterSynergy (talk) 05:24, 1 May 2018 (UTC)

QuickStatements und URL mit Gleichheitszeichen

Hallo, rund 800 noch zu erstellende Objekte sollen in described at URL (P973) eine Webadresse bekommen, die sich nur durch die ID im Querystring ?id=123 unterscheidet. QuickStatements transportiert URLs mit = nicht. Maskieren des = mit %3D führt zu defekten Links in Wikidata.

Frage: Wie kann man das Problem lösen - ohne 800 Edits von Hand? Dank und Gruß --Quarz 17:46, 5 May 2018 (UTC)

Das ist mit Botcode einfach möglich, bei Bedarf kannst Du hier oder bei Wikidata:Bot requests fragen. Der Operator bräuchte praktisch nur Paare Qid->URL zum Einfügen. Alternativ wäre vielleicht eine Identifikator-Eigenschaft für die URLs möglich? —MisterSynergy (talk) 18:22, 5 May 2018 (UTC)
Danke! An Identifikator-Eigenschaft hatte ich zunächst gedacht, hatte dann aber Bedenken: Es geht um Stolpersteine (Q314003) in zwei Städten mit guter Dokumentation. In einem Fall sind alle an einer Adresse verlegten Steine auf einer ID vereinigt. Das ist nicht wirklich ein Identifkator für das Einzelobjekt. Allgemein rechnete ich mit der ablehnenden Frage "wollen wir für jede Stadt einen Stolperstein-Identifikator?" Sehe ich das falsch? Dann bitte ich um Unterstützung für die Anträge. --Quarz 18:57, 5 May 2018 (UTC)
Oh, es geht um Stolpersteine. Ja bei der beschriebenen Situation macht das vermutlich nicht so recht Sinn, einen Identifikator zu beantragen. Wobei ich mich schon häufiger gefragt habe, ob es da eigentlich eine gute Datenbank mit Informationen zu allen Stolpersteinen weltweit gibt – das Projekt hat ja durchaus Einfluss und anscheinend auch eine Menge Resourcen. Bei Wikipedia werden dazu sehr aufwändig Inhalte eingepflegt, aber so von außen betrachtet wirkt das manchmal … sehr suboptimal aufbereitet.
Egal, wenn Du Hilfe für die URLs brauchst, schick mir die Liste und ich pflege Dir die ein. Ginge auch per Wikimail. Viele Grüße! —MisterSynergy (talk) 20:12, 5 May 2018 (UTC)
Ganz herzlichen Dank! Auf Dein freundliches Angebot komme ich gerne zurück.
Leider ist das Stolperstein-Projekt dezentral dokumentiert. Je nach Organisationsgrad und Engagement der lokalen Initiativen (die auch die Kosten tragen) variieren die gespeicherten Daten – und deren Zugänglichkeit. Der Zustand der Aufbereitung bei Wikipedia spiegelt das zutreffend (das Wort "schön" wäre hier missverständlich). Als zentrale Dokumentation verfügbar ist nur die Chronik: Wann hat Gunter Demnig wo Stolpersteine verlegt oder Vorträge gehalten. Viele Grüße --Quarz 20:33, 5 May 2018 (UTC)
Verstehe. Dezentrale Organisation hat ja häufig auch so Vorteile, diesbezüglich aber eher nicht.
Ein Skript für Deinen Task wäre startklar, ich hätte bestenfalls 5 Minuten Aufwand mit der Sache. Habt also keine Hemmungen … —MisterSynergy (talk) 20:40, 5 May 2018 (UTC)
Prima! Voraussichtlich bis morgen Abend werden die Objekte importiert sein. Dann bekommst Du Post. Meiner Datenbank iet es egal, welche Feldtrennzeichen und Textbegrenzer sie ausgibt. Bevorzugst Du da etwas? --Quarz 05:57, 6 May 2018 (UTC)
Tabseparierte Textdateien mit einem Datensatz je Zeile sind nett; Tabs kommen nämlich weder in Q-IDs noch in URLs noch sonst irgendwo vor ;-) An sich ist das aber egal, ich forme das sowieso mit einem regulären Ausdruck zu dem passenden Input für das Importskript um.
Kennst Du Dich eigentlich mit Python aus? Dann könnte ich Dir das pywikibot-Skript auch geben und Du führst das mit Deinem Account selbst aus. Mit dem PAWS tool ist die Einstiegshürde dafür extrem niedrig. —MisterSynergy (talk) 06:04, 6 May 2018 (UTC)
Bis jetzt hatte ich noch keinen Anlass, mich mit Python zu befassen. Du machst mich neugierig! Es ist eben eine Sprache mehr in meiner Sammlung. Ja bitte, schick mir das Skript. Ich versuche mich da rein zu denken (wenn nicht für die aktuelle Aktion, dann zumindest für die Zukunft) und verspreche vorsichtig zu sein. Dank und Gruß --Quarz 07:18, 6 May 2018 (UTC)
Bis vor ca. einem Jahr hatte ich auch keinen Anlass, Python zu erlernen. Mit ein paar grundlegenden PHP-Kenntnissen und diesen kurzen Buch war der Einstieg aber recht einfach möglich, und dann sind eben weit komplexere Modifikationen möglich als mit den bekannten Tools. Das Skript ist hier, Du brauchst Dich einfach beim PAWS-Tool mit dem Wikimedia-Account einzuloggen (ähnlich wie bei QuickStatements), kannst dann ein neues „Notebook“ mit jenem Skript anlegen und das ausführen. Auch wenn das letztlich Botcode ist, gilt für die Nutzung von PAWS letztlich dasselbe wie für QuickStatements zum Beispiel: Du darfst das mit Deinem normalen Account nutzen, es ist ein Tool zur Batch-Bearbeitung. Es gibt Wikidata:Pywikibot - Python 3 Tutorial zum Lernen und für Beispielcode, test.wikidata.org zum testen und hier eine manchmal etwas bescheidene, aber letztlich doch nützliche Pywikibot-Doku. —MisterSynergy (talk) 07:54, 6 May 2018 (UTC)
Du hast mich überzeugt, das tu ich mir an. Das Skript sieht nach gut lesbarem OOP aus und Vokabeln kann man lernen. Vielen Dank! --Quarz 08:36, 6 May 2018 (UTC)
Prinzip verstanden, Skript erfolgreich probiert. Ich gehe davon aus, dass das Problem damit gelöst ist. Vielen Dank für die Hilfe zur Selbsthilfe - das ist die Variante, die ich bevorzuge! Viele Grüße --Quarz 15:10, 6 May 2018 (UTC)

Suche auf Commons

Ist es möglich, alle Commons-Kategorien zu finden, die zu einer Person gehören, aber nicht mit einem Wikidata-Objekt per Property:P373 verbunden sind? Und Zusatzfrage, kann man das auch thematisch einschränken, z.B. alle Schachspielerkategorien ohne Link von Wikidata? Steak (talk) 11:55, 7 May 2018 (UTC)

Hallo Steak,
eine Möglichkeit wäre, die Ergebnisse dieser Wikidata-Query mit dieser Petscan-Abfrage zu vergleichen. Die Ergebnisse findest du in dieser Tabelle. --MB-one (talk) 13:30, 7 May 2018 (UTC)
Versteh ich jetzt nicht so ganz. Beispielsweise gleich der erste Eintrag in der Google-Liste, commons:Category:Mladen_Muse, ist doch sauber von Q96725 verlinkt?! Steak (talk) 14:13, 7 May 2018 (UTC)

AdvancedSearch

From May 8, AdvancedSearch will be available as a beta feature in your wiki. The feature enhances the search page through an advanced parameters form and aims to make existing search options more visible and accessible for everyone. AdvancedSearch is a project by WMDE Technical Wishes. Everyone is invited to test the feature and we hope that it will serve you well in your work!

Birgit Müller (WMDE) 14:53, 7 May 2018 (UTC)

Interwiki-Auseinanderdröselung

Servus!

Wo diskutiert man am besten (gerne in Englisch), wie man Artikel in verschiedenen Wikipedien zwei Wikidata-Einträgen zuordnet? Falls hier, um folgendes Beispiel geht es mir:

Thema ist ein Lied mit russischer Originalversion (Дорогой длинною) und sehr bekannter englischer (Cover-)Version (Those Were the Days). Den diversen Lemmata entnehme ich (es nicht genau wissend), dass es auch andere Sprachversionen der Nummer gibt. Die deutschsprachige Wikipedia scheint die einzige mit zwei getrennten Artikeln zum Original und der englischen Version.

Man könnte nun hergehen und sagen, wir machen ein Item zum Original und eins zum Cover. Problem: Wohin mit den Artikeln, wo das Lemma weder zur einen, noch zur anderen Vertextung der Melodie passt? Außerdem: De facto sind beide vorhandenen Datensätze dem russischen Lied gewidmet (in Q1246097 ist nur der deutschsprachige Artikel zum russischen Lied, Q614175 behandelt laut Kurzbeschreibung ein russisches Lied. Die Statements sind dafür Kraut und Rüben (Ursprungsland = russisches Original, Veröffentlichungsdatum = englisches Cover). Und die einsortierten Artikel gehen das Thema sehr unterschiedlich an, sodass eine klare Linie schwierig zu finden ist.

Was tun? → «« Man77 »» 17:58, 7 May 2018 (UTC)

Blöde Situation, kommt aber manchmal vor. Als Wikipedianer kann (und soll) man frei von Zwängen ein Thema eingrenzen, aber beim 1:1-Mapping für Interwikilinks wird es dann manchmal schwierig. Es gibt für solche Fälle Wikidata:Interwiki conflicts, oder alternativ Wikidata:Project chat. Ich würde vorschlagen, ein Item je Coverversion anzustreben sofern das möglich ist, und dann die Objekte mit different from (P1889) miteinander zu verlinken, damit nicht jemand daherkommt und versehentlich die entmischten Objekte wieder zusammenmischt. —MisterSynergy (talk) 20:35, 7 May 2018 (UTC)

cs Rozhodnutí

Wer kann mir das Datenobjekt dieses Artikels sagen cs: Rozhodnutí--Oursana (talk) 13:58, 8 May 2018 (UTC)

Special:ItemByTitle sagt Q13427241. --Pasleim (talk) 14:26, 8 May 2018 (UTC)

Inverse Eigenschaft für "gewidmet"

Bei den Stolpersteinen gibt es vielfach den Bezug zur Person über commemorates (P547). Im Personendatensatz steht bestenfalls ein Bild einer Gedenktafel. Damit ist noch keine Verknüpfung zu weiteren Informationen zum Stolperstein gegeben. Meine Suche nach einer inverse property (P1696) für "gewidmet" blieb erfolglos. Gibt es das nicht - ggf. aus welchem Grund? --Quarz 13:10, 10 May 2018 (UTC)

Mir ist keine solche inverse Eigenschaft bekannt, aber Gründe dafür auch nicht. Grundsätzlich reicht es, wenn unidirektional eine Verbindung hergestellt wird, zumindest sofern man die Daten mit dem Query Service oder ähnlichem abfragt. Wenn Du jedoch explizit in dem Item über die Person eine Aussage zu dem Stolperstein machen möchtest, dann müsste ggf. eine neue Eigenschaft her. Einander inverse Eigenschaftspaare sind in vielen Fällen nicht unproblematisch und letztlich tragen sie viel redundante Information. —MisterSynergy (talk) 19:53, 10 May 2018 (UTC)
Danke für die Auskunft. Meine Frage war nicht auf Stolpersteine begrenzt, es gibt doch verschiedenartige Gedenkobjekte. Und es gibt (ohne Beispiele aufzählen zu wollen) sicher viele andere Fälle, bei denen einseitige Verknüpfungen logisch gesehen halber Kram sind.
Wenn man aus einer Welt kommt, in der Datenbanken auf miteinander verknüpften Tabellen basieren, fehlt einem hier die Möglichkeit, ohne Klimmzüge von beiden Seiten auf die jeweils andere verknüpfte Information zuzugreifen. Wer "mal eben" die Daten einer handvoll von Personen-Objekten auslesen möchte, kommt möglicherweise nicht einmal auf die Idee, dass er mit einer Abfrage mehr Informationen erhalten kann, als ihm auf der Seite angezeigt (zumindest ihre Existenz) werden. Ob er dann als Nutzer erhalten bleibt?
Wenn bei Wikidata eine Verknüpfung nicht wechselseitig notiert werden soll, nehme ich das mit Bedauern zur Kenntnis. --Quarz 11:12, 11 May 2018 (UTC)
Ich bin nicht die entscheidende Instanz bezüglich der Existenz einer solchen Eigenschaft. Per Wikidata:Property proposal kannst Du eine Eigenschaft vorschlagen, und basierend auf Deiner Arbeit würde ich Dich auch unterstützen. Obs was wird, entscheidet dann die Community. —MisterSynergy (talk) 12:10, 11 May 2018 (UTC)
Schon klar, dass Du das nicht zu entscheiden hast. :-) Aber Du steckst tief genug in der Wikidata-Denke, um die generelle Haltung der Community einzuschätzen. Danke! --Quarz 14:39, 11 May 2018 (UTC)
Aus eigener Sicht in dem Bereich eher nicht, aus der Eigenschaftserstellung halte ich mich weitgehend raus. Durchdachte Vorschläge mit konkretem Einsatzbereich haben in der Regel gute Chancen, oder es schlägt jemand eine Alternative vor. Ich würds probieren. —MisterSynergy (talk) 14:49, 11 May 2018 (UTC)

Mehrere Statements auf einmal entfernen

Ich möchte bei Antonio Palma (Q13527942) alle Statements des Propertys "Elo-Zahl" entfernen (beziehen sich auf einen anderen Antonio Palma). Das scheint allerdings nicht möglich zu sein, und alle einzeln zu entfernen ist sehr mühsam. Steak (talk) 08:06, 11 May 2018 (UTC)

Ist erledigt, mit diesem Pywikibot/Python-Skript in PAWS: 
import pywikibot

wikidata_site = pywikibot.Site('wikidata', 'wikidata')
repo = wikidata_site.data_repository()

Qitem = pywikibot.ItemPage(repo, 'Q13527942')
Qitem.get()
Qitem.removeClaims(Qitem.claims['P1087'])
Grüße, MisterSynergy (talk) 08:31, 11 May 2018 (UTC)
Danke! Steak (talk) 12:38, 11 May 2018 (UTC)

Handelsregister et al.

Ins company register (Q1394657) muss ja jeder merchant (Q215536), gleich der Rechtsform, eingetragen werden. Daneben führen die Registration court (Q2138576) ja jeweils auch noch ein register of cooperatives (Q1502498), partnership register (Q1718964) und register of associations (Q2515188) tweilweise auch noch ein ship register (Q319949). Wären das nicht jeweils interessante Datenpunkte für Wikidata?

Wie sollte man das am besten Modellieren? z.B.: thyssenkrupp AG (Q137910) wird beim Local Court Duisburg (Q480642) unter HR Abteilung B Nr. 9092 und beim Local Court Essen (Q480664) HR Abteilung B Nr. 15364 geführt. --Bcoh (talk) 14:25, 13 May 2018 (UTC)

Da stimmt was nicht

Bei der Wikipedia-Suche wird:

Tevele Schiff Rabin (1800–1791) ♂; German rabbi

angezeigt. In Wikidata wird als Geburtszeitraum 18. Jahrhundert angegeben, das fängt allerdings 1700 an. Hier sieht es für die User aus, als wäre er von der Geburt verstorben. Das könnte wohl ein grundlegendes Problem bei Wikidata oder WIkipedia-Suche sein. Zabia (talk) 09:47, 14 May 2018 (UTC)

Das ist ein Darstellungproblem in dem Wikipedia-Gadget, welches die Präzision des Datum (hier: „Jahrhundert“) nicht zu interpretieren vermag. Das Problem tritt an verschiedenen Stellen auf, ich kann gerade leider nicht sagen, wo der Code dazu ist. Das 18. Jahrhundert ging übrigens von 1701 bis 1800. —MisterSynergy (talk) 10:03, 14 May 2018 (UTC)
Die Beschreibung kommt vom Gadget en:MediaWiki:Wdsearch.js. --Pasleim (talk) 11:20, 14 May 2018 (UTC)

Tätigkeit = Hobby ?

Kann man occupation (P106) auch für Tätigkeiten verwenden, die von einer Person vermutlich nur hobbymäßig ausgeübt wurde? Wenn z. B. ein Eintrag bei Chessgames.com player ID (P1665) besteht, könnte man dann immer occupation (P106) = Schachspieler angeben, unabhängig vom tatsächlichen Beruf einer Person? Steak (talk) 18:40, 17 May 2018 (UTC)

Ja, das ist okay, sofern diese Tätigkeit nachweisbar ist. Bei einem Eintrag in einer Datenbank mit Wikidata-Eigenschaft gehe ich davon aus, dass das der Fall ist. —MisterSynergy (talk) 15:02, 21 May 2018 (UTC)
Okay. Steak (talk) 07:21, 22 May 2018 (UTC)

Franz Michael Vierthaler (Q2696190) und Vierthaler, Franz Michael (ADB) (Q27600229)

Hallo,

wer kennt sich damit aus und kann mir Auskunft geben?

  • Diese beiden Lemmata betreffen ein und dieselbe Person. Warum haben sie dann unterschiedliche Datensätze oder wie man auch immer diese Q-Nummern nennt?
  • Kann man diese beiden Lemmata nicht unter das Lemma des Franz Michael Vierthaler zusammenziehen?
  • Warum erscheint in der Betreff-Zeile das jeweilige Lemma rot (Seite existiert nicht)? (Ich lass es mal trotzdem so)
  • Kann es sein, dass in Wikidata ganz anders verlinkt und bearbeitet wird, als in anderen Wikimedia Schwesterprojekten?

Auf eine Antwort freut sich Peter-K (talk) 19:09, 18 May 2018 (UTC)

Hallo Peter, mit {{Q|2696190}} erhälst du den Link auf die Person Franz Michael Vierthaler (Q2696190). Vierthaler, Franz Michael (Q27600229) ist, wie in der Beschreibung des Objekts steht, ein "Artikel in der Allgemeinen Deutschen Biographie". Gruß --Kolja21 (talk) 03:36, 19 May 2018 (UTC)

Lexikographische Daten sind jetzt auf Wikidata verfügbar

Hallo!

Nach mehreren Jahren Diskussion und einem Jahr Entwicklung und Diskussion mit den Communities hat das Entwicklerteam von Wikimedia Deutschland nun die erste Version für die Unterstützung von lexikograpischen Daten auf Wikidata veröffentlicht.

Seit dem Start von Wikidata im Jahr 2012 konzentrierte sich die mehrsprachige Wissensdatenbank hauptsächlich auf Konzepte: Q-Items beziehen sich auf ein Ding oder eine Idee, nicht auf das Wort, das es beschreibt. Ab sofort speichert Wikidata eine neue Art von Datenobjekten: Wörter, Redewendungen und Sätze, in vielen Sprachen, multilingual beschrieben. Diese Informationen werden in neuen Entitätentypen gespeichert, die als Lexem, Form und Bedeutung bezeichnet werden.

Lexikographische Daten in Wikidata haben das Ziel, Wörter und Sätze strukturiert und maschinenlesbar in mehreren Sprachen zu beschreiben, an einem Ort gespeichert und unter CC-0 nachnutzbar. In naher Zukunft werden diese Daten für Wiktionaries und andere Projekte verfügbar sein, so wie es von vielen gewünscht wird.

Im Moment sind wir bei den ersten Schritten dieses Projekts: Die neue Datenstruktur wurde auf Wikidata veröffentlicht, und wir suchen nach Leuten, die sie ausprobieren und uns Feedback geben, was funktioniert und was nicht. Die Teilnahme an diesem Projekt ist die Gelegenheit, eine Stimme zu haben, um sicherzustellen, dass Bedürfnisse und Wünsche sehr früh im Prozess berücksichtigt werden, und um Wikidata mit Wörtern in der eigenen Sprache zu füllen!

Das neue System wird den Editoren erlauben, alle Wörter in allen Sprachen genau beschreiben zu können. Die Daten werden wiederverwendbar sein, genau wie der gesamte Inhalt der Wikidata. Die geschieht durch mehrere Tools und Abfragen, die von der Gemeinschaft geschafft werden, um mit Wörtern zu arbeiten. Lexikographische Daten können innerhalb und außerhalb der Wikimedia-Projekte wiederverwendet werden und sollen Wiktionary unterstützen.

Die erste Version

Um Wörter und Phrasen modellieren zu können, wurde ein neuer Namensraum und mehrere neue Datentypen erstellt. Wenn du neu in diesem Projekt bist, kannst du mehr in der Dokumentation darüber erfahren. Sie erklärt kurz das Datenmodell und das Interface. Obwohl die technische Struktur festgelegt ist, steht es den Benutzern weiterhin frei, Daten nach Belieben zu modellieren und zu organisieren. Dies geschieht durch offene Diskussionen und Community-Abläufe in Wikidata. Erste Diskussionen über neu zu erstellende Eigenschaften haben bereits begonnen: Wenn du in die frühe Phase des Projekts mit einbezogen werden möchtest, kannst du ab sofort teilnehmen!

Beachte, dass die nun erschienene Version am Anfang der Entwicklung steht und in Zukunft verbessert und weiter ausgebaut wird. Manche Funktionen können noch fehlen und manche Fehler können noch auftreten. Hier eine Liste der Funktionen, die in dieser ersten Version verfügbar sind:

  • Lexeme, Formen, Aussagen, Qualifikatoren, Referenzen hinzufügen, bearbeiten und löschen
  • Links zwischen verschiedenen Datentypen (Datenobjekt zu Lexem, Form zu Datenobjekt, usw.)
  • Auswahlvorschläge beim Hinzufügen einer Eigenschaft oder eines Werts

Die folgenden Funktionen sind nicht in der ersten Version enthalten, aber für die Zukunft geplant:

  • Lexeme und Formen über Spezial:Suche finden
  • RDF-Unterstützung (das heißt: die Fähigkeit auf query.wikidata.org Abfragen durchzuführen)
  • Unterstützung von Bedeutungen
  • Zusammenfügen von Lexemen
  • Einbeziehen von Daten aus anderen Wikimedia-Projekten wie Wiktionary

Wie kann man es ausprobieren?

Die oben beschriebenen Funktionen werden ab sofort auf wikidata.org bereitgestellt. Hier einige Vorschläge, wie du lexikographische Daten in Wikidata ausprobieren kannst:

  • Wem das Datenmodell nicht vertraut ist, sollte zunächst die die Dokumentationsseite dazu ansehen. Wer mit Wikidata überhaupt noch nicht vertraut bist, dem empfehle ich diese Seite als Ausgangspunkt.
  • Man kann sich auch ansehen, welche Lexemes bereits existieren (Suchfunktionen werden in der Zukunft verbessert).
  • Wer selbst ein Wort erstellen möchte, ruft die Seite Special:NewLexeme auf.
  • Wenn benötigte Eigenschaften fehlen, dann können sie auf dieser Seite vorgeschlagen werden (bei Unklarheiten zum Prozess einfach eine Nachricht auf der Diskussionsseite hinterlassen und jemand wird dann helfen).
  • Die Hauptdiskussionsseite ist Wikidata talk:Lexicographical data. Hier kann man um Hilfe bitten, Möglichkeiten zur Organisation der Daten vorschlagen, aber auch Feedback geben: Wer auf einen Fehler oder ein Problem stößt, sollte es uns nach Möglichkeit wissen lassen! Wir suchen vor allem nach den für die Community wichtigsten Funktionen, an denen wir als nächstes arbeiten können.
  • Melde Fehler und Probleme, die auftreten: Entweder auf der Diskussionsseite oder in Phabricator, wenn du dich damit auskennst (erstelle eine Aufgabe, füge das Tag Lexicographical data und Lea_Lacroix_(WMDE) als Teilnehmerin hinzu)

Über Massenimporte und Tools

Wir bitten darum vorerst keine Massenimporte egal aus welcher Quelle durchzuführen und zu planen. Dafür gibt es mehrere Gründe: Zu Beginn, wie oben erwähnt, ist dies die erste Version und wir müssen überblicken können, wie unser System auf manuelle Bearbeitungen reagiert, bevor diese automatisiert werden. Das System könnte noch nicht bereit sein für riesige Importe. Des Weiteren gibt es einen rechtlicher Grund. Lexikographische Daten in Wikidata werden unter der CC0-Lizenz veröffentlicht und jeder Nutzer trägt die eigene Verantwortung, dass die hinzugefügten Daten kompatibel mit dieser Lizenz sind. Für weitere Informationen, kannst du den Hinweis des WMF-Rechtsteam anschauen. Zuletzt möchten wir dich ermutigen dich mit der Community abzusprechen, bevor ein Import von einem Wiktionary in Betracht gezogen wird. Die Benutzer der Wiktionary haben in den letzen zwei Jahrzehnten viel Arbeit aufgewendet um Definitionen zu erstellen und wir sollten respektvoll mit dieser Arbeit umgehen. Dazu sollte man mit der Community diskutieren, um gemeinsame Lösungen zu finden, um mit lexikographischen Daten zu arbeiten und die Verwendung dieser zusammen genießen zu können.

Wir empfehlen dir auch, ein wenig zu warten, bevor du Tools oder Skripte für lexikographische Daten erstellst. Das Interface und seine API wird sich wahrscheinlich in den nächsten Monaten weiterentwickeln, und das System ist möglicherweise nicht stabil genug, um solche Tools zu unterstützen. Wir werden dich informieren, sobald Skripte und Tools möglich sind.

Weitere Schritte

Nach dieser ersten Veröffentlichung werden Verbesserungen regelmäßig vorgenommen (jede Woche). Wenn du schon versucht hast, dich mit den neuen Daten vertraut zu machen, kannst du uns gerne ein Feedback geben. Wir suchen vor allem nach den wichtigsten Funktionen, an denen wir als nächstes arbeiten sollen.

  • Was hast du beim Bearbeiten lexikographischer Daten bisher versucht? Was ist schiefgelaufen oder war unerwartet?
  • Welche Bugs oder Probleme hast du während des Bearbeitens festgestellt?
  • Was sind deiner Meinung nach die wichtigsten Funktionen? An welcher Stelle sollten wir als nächstes arbeiten?

Wenn du daran interessiert bist, den Diskussionen und weiteren Ankündigungen über lexikographische Daten zu folgen, möchte ich dich ermutigen, dir regelmäßig Neuigkeiten auf der Diskussionsseite anzuschauen. Dort wird diskutiert, wie Daten organisiert und strukturiert werden sollen, welche neuen Funktionen hinzugefügt werden sollen, außerdem finden sich dort Ideen für Tools und Abfragen und viele weitere Dinge.

Zusätzliche Anmerkung: Mit dieser neu eingeführten Art von Daten auf Wikidata, erwarten wir, dass einige neue Editoren Interesse daran haben, Lexeme zu bearbeiten, Eigenschaften vorzuschlagen oder Fragen zu stellen. Einige kennen sich daher vielleicht noch nicht mit unseren Community-Abläufen und unserer Organisation von Inhalten aus und benötigen Hilfe und Unterstützung. Ich hoffe, dass wir alle freundlich und geduldig sein können, sowohl mit anderen Benutzern, als auch mit der Software, die am Anfang vielleicht nicht so funktioniert, wie wir es wollen :)

Danke an die Leute, die das Modell und das Interface vor der Veröffentlichung getestet haben, und danke auch an die Leute, die Unterstützung und Neugierde für lexikographische Daten in Wikidata zeigen!

In jedem Fall sollte nicht gezögert werden, mich zu kontaktieren, wenn es Fragen oder Probleme gibt, ich werde mich dann sehr gerne darum kümmern.

Vielen Dank und alles Gute, Wikidata Diskussion:Lexikographische Daten an oder kontaktiere mich. Lea Lacroix (WMDE) (Diskussion) 14:22, 23. Mai 2018 (MESZ)

Teile des Beitrags übersetzt von Bigbossfarin (talk) 12:27, 24 May 2018 (UTC)

Wikipedia ←→ Wikisource

Gibt es eigentlich keine Möglichkeit, die Objekte Q54145977 und Q21234161 sinnvoll zu verknüpfen, obwohl es sich um ein- und dieselbe Person handelt? --Färber (talk) 07:48, 25 May 2018 (UTC)

Ich habe die mal gegenseitig mit den Eigenschaften described by source (P1343) und main subject (P921) verlinkt. —MisterSynergy (talk) 08:03, 25 May 2018 (UTC)

Constraint für Ränge?

Es scheint kein Constraint zu geben, das Ränge einschränkt, oder hab ich das nur nicht gefunden? Steak (talk) 14:05, 26 May 2018 (UTC)

Nee, da gibt es nichts. Welches Problem möchtest Du hier mit Einschränkungen lösen? Im Einzelfall wird das vermutlich mit einem {{Complex constraint}} lösbar sein. —MisterSynergy (talk) 18:10, 26 May 2018 (UTC)
Es gibt einige Elo-Zahlen (vom Mai 2017) mit preferred-Constraint, was aber sinnlos ist, da das jeden Monat geändert werden müsste. Steak (talk) 18:18, 26 May 2018 (UTC)
Ich glaube, Du suchst in etwa diese Abfrage. Wenn das als covi-report ausgewertet werden soll, dann müsste das (so ähnlich) mit dem genannten Template eingesetzt werden. Soll ich das mal machen? —MisterSynergy (talk) 18:30, 26 May 2018 (UTC)
Nützlicher zur Wartung ist vielleicht diese Version: 
SELECT ?item (GROUP_CONCAT(?elo; separator=', ') AS ?elos) (GROUP_CONCAT(?strtime; separator=', ') AS ?months) (COUNT(*) AS ?cnt) WHERE { 
  ?item p:P1087 ?statement .
  ?statement ps:P1087 ?elo; wikibase:rank wikibase:PreferredRank .
  OPTIONAL { ?statement pq:P585 ?time . BIND(SUBSTR(STR(?time), 1, 7) AS ?strtime) }
} GROUP BY ?item HAVING (?cnt != 1)
Try it!
—MisterSynergy (talk) 18:38, 26 May 2018 (UTC)
Deine Queries finden nur 8 Seiten, ich hab jetzt schon eine andere Version, die 10000 Treffer hat, als Complex-Constraint eingebaut. Feel free da noch Verbesserungen vorzunehmen. Steak (talk) 18:43, 26 May 2018 (UTC)
Ah, jetzt gesehen. Ich glaube, Deine Abfrage findet nicht das, was Du als Problem identifiziert hast. Du möchtest ja sicherstellen, dass nicht mehr als eine Elo-Zahl mit bevorzugtem Rang je Objekt vorhanden ist. Von solchen Fällen gibt es nämlich nur jene acht aus meiner Abfrage. —MisterSynergy (talk) 18:49, 26 May 2018 (UTC)
Nein, ich möchte sicherstellen, dass gar keine Elo-Zahlen einen preferred Rank haben. Steak (talk) 18:55, 26 May 2018 (UTC)
Achso. Typischerweise wird ja so der aktuelle Wert gegenüber älteren hervorgehoben. Wenn irgendwo ausdiskutiert wurde, dass das bei der Eigenschaft zukünftig ohne Ränge gemacht werden soll, dann könnte man mit einem Bot alle auf normalen Rang ändern. —MisterSynergy (talk) 20:07, 26 May 2018 (UTC)
Mein Verständnis von Ranks ist, dass man damit gute Daten von schlechten unterscheiden kann. Wenn man aber per Modulaufruf den aktuellen Monat übergeben kann, braucht es nicht auch noch eine zusätzliche Hervorhebung per Rank. Die Diskussion unter Property_talk:P1087#Preferred_value:_Highest_or_most_recent? hat damals nicht wirklich ein Ergebnis geliefert. Von mir aus kann ein Bot loslaufen. Steak (talk) 20:20, 26 May 2018 (UTC)
Sehe gerade auch, dass zumindest in 9301 Fällen der bevorzugte Rang nicht auf der Aussage mit dem jüngsten Zeitstempel sitzt. Bei denen kann man wohl tatsächlich erstmal den normalen Rang einstellen. Wer dann einen bevorzugten Rang braucht, kann ein weiteres Mal alle Objekte bearbeiten. Code hätte ich jedenfalls fertig, ein Durchlauf würde ca. drei Stunden dauern. —MisterSynergy (talk) 20:27, 26 May 2018 (UTC)
Jo, wie gesagt, die meisten sind von Mai 2017. Hau rein :) Steak (talk) 20:31, 26 May 2018 (UTC)
Kannst Du bitte bei Kateryna Dolzhykova (Q13742178) einmal prüfen, welcher Wert für Mai 2017 stimmt? Da sind zwei verschiedene angegeben. —MisterSynergy (talk) 20:33, 26 May 2018 (UTC)
Erledigt. Steak (talk) 20:43, 26 May 2018 (UTC)

novalue nicht als Fehler anzeigen

Wie verhindert man am sinnvollsten, dass novalue in Constraint Violation Reports als Fehler angezeigt wird (Beispiel)? --Leyo 09:07, 31 May 2018 (UTC)

Das müsste reichen. Dauert jetzt aber ein bis zwei Tage, bis das im covi-Report berücksichtigt wird. —MisterSynergy (talk) 10:00, 31 May 2018 (UTC)
Danke! Dann ergänze ich auch bei anderen Eigenschaften eine Pipe. --Leyo 13:32, 31 May 2018 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Forum/Archiv/2018/05&oldid=696547581"