Wikidata:Forum/Archiv/2016/12

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.

Wikimedia-Liste

Hallo zusammen, ich weiß nicht, ob ich hier richtig bin, aber ich bin über die Kurzbeschreibung "Wikimedia-Liste" gestolpert, die anscheinend massenhaft bei allen Listen aus der Wikipedia eingetragen ist. Was ist der Sinn hinter dieser a) sehr nichtssagenden und b) aus meiner Sicht irreführenden (warum Wikimedia und nicht Wikipedia?) Beschreibung? Gerade vor dem Hintergrund dass diese Kurzbeschreibungen auf der Mobilversion eingeblendet werden sollen (unter dem Lemma, das ohnehin schon "Liste von...", "Liste der..." heißt), halte ich solche kryptische Bezeichnungen nicht für sehr leserfreundlich. Soll man solche Beschreibungen manuell in jedem Einzelfall auf etwas halbwegs Sprechendes ändern ([1], [2])? Kann man das maschinell machen? Sollte man eine nichtssagende Kurzbeschreibung wie diese nicht besser einfach wieder löschen? Gruß --Magiers (talk) 08:58, 7 December 2016 (UTC)

Hallo @Magiers! Ein bisschen Erklärung zum Komplex:
  • Alle Seiten aus den Wikimedia-Projekten bekommen ein Wikidata-Objekt, das gilt auch für Listenartikel. Wenn eine Liste in mehreren Projekten existiert, dann kommen alle Sitelinks in dasselbe Objekt. Das müssen nicht alles Wikipedia-Sitelinks sein, sondern all die anderen kleineren Projekte können auch Listen haben und deshalb ist „Wikimedia“ hier der kleinste gemeinsame Nenner – es gibt nämlich nur diese eine Beschreibung je Sprache.
  • Das Präfix „Wikimedia-“ wird mutmaßlich deshalb genutzt, weil diese Wikidata-Objekte keinerlei Existenz oder Entsprechung außerhalb des Wikimedia-Universums haben und deshalb Listen sind, die innerhalb unseres Wikimedia-Projektes (genauer: dem Communityteil davon) definiert wurden und im Grunde nur dort existieren. Diese Wikidata-Objekte zu Wiki*-Projekten haben einen gewissen Metacharakter, aber weil hier nun einmal die Interwikis verwaltet werden, kommen wir als Wikidata-Projekt nicht um diese Objekte umher und müssen die geeignet mit Daten ausstatten.
  • Ob „Liste von Werken“ als Beschreibung besser ist, wenn die Bezeichnung schon so beginnt, das sei mal dahingestellt. Ich würde die Wikidata-Beschreibungen nicht anfassen, weil die eh weitgehend botgestützt gewartet werden und im Grunde standardisiert sind, so wie auch „Wikimedia-Begriffsklärungsseite“ (Beispiel Berlin (Q262009)) und andere. Für die Anzeige in den Apps könnte man ggf. darum bitten, das Präfix „Wikimedia-“ zu entfernen, falls die Beschreibung von einem dieser Metaitems kommt. Das wäre IMHO die beste Lösung.
Viele Grüße, MisterSynergy (talk) 10:08, 7 December 2016 (UTC)
Hallo MisterSynergy, danke für Deine Antwort. Erwartungsgemäß verstehe ich nicht alles. "Wikimedia-" zu entfernen ware aber sicher ein Schritt in die richtige Richtung. Nur "Liste" als Beschreibung ist allerdings immer noch nichtssagend und für den Zweck, den Wikidata-Kurzbeschreibungen in Projekten wie der Wikipedia haben sollen (nämlich eine Kurzdefinition des Artikels in der Suchfunktion und demnächst in der Anzeige unterhalb des Lemmas) nicht angemessen. Deswegen hielte ich es für besser, solche Pseudo-Beschreibungen besser ganz zu entfernen. Dass man als Nicht-Bot die Kurzbeschreibungen nicht anfassen soll, kann ich mir allerdings nicht vorstellen. Wie soll man sonst dafür sorgen, dass sie konsistent zum Artikelinhalt/zur Einleitung ist? Sie wird ja in der WP-Anwendung verwendet, also muss ein WP-Autor auch Einfluss darauf nehmen können. Gruß --Magiers (talk) 11:44, 7 December 2016 (UTC)
Wieder stichpunktartig:
  • Ja, ein komplettes Ausblenden zumindest in der Artikelansicht und Suche wäre sicher auch eine Möglichkeit bei Listen-Objekten, nicht aber bei beispielsweise Begriffsklärungsseiten. Der eigentliche Zweck der Beschreibung ist ja die Unterscheidung von Entitäten, die identische Bezeichnungen haben. Bei Wikipedia macht man das mit den Klammerqualifikatoren, die so ihre eigenen Schwierigkeiten mit sich bringen. Listenartikel und einige andere (aber nicht alle) Metaobjekte bei Wikidata brauchen eigentlich keine weitere Beschreibung mehr, weil die Bezeichnung selbst in diesen Fällen bereits hinreichend eindeutig (und beschreibend) ist.
  • Warum ich die fraglichen Beschreibungen nicht anfassen würde: Help:Description (und dessen deutsche Übersetzung) als relevante Regelung geben implizit diese Standardbeschreibung vor, und es gibt tatsächlich Bots die das basierend auf dem Claim instance of (P31) Wikimedia list article (Q13406463) auch so setzen bzw. korrigieren. Deshalb würde ich mir den Aufwand sparen und an anderer Stelle ansetzen.
  • Nämlich hier: die Beschreibungen sind wie gesagt primär zur Unterscheidung bei gleicher Bezeichnung gedacht, und in dieser Funktion tatsächlich in den allermeisten Fällen in der Suchfunktion und der Artikelansicht bspw. mobiler Apps äußerst hilfreich, in meinen Augen mehr als die Klammerqualifikatoren von Wikipedia. Aber eben nicht in ausnahmlos allen Fällen, und da würde ich nun ansetzen und softwareseitig Ausnahmen vorschlagen. Ob und wie das möglich ist und wie eine solche Liste von Ausnahmen verwaltet werden könnte, ist mir spontan nicht klar, aber das kann man ausarbeiten.
  • Eher grundsätzlich: die Idee, die Wikidata-Beschreibung anstelle der Wikipedia-Klammerqualifikatoren zur Unterscheidung zu nutzen, kommt mutmaßlich nicht von der Wikidata-Community. Ich schätze, die Frontend- und App-Entwickler haben sich das ausgedacht, weil sie diese Lösung für geeigneter halten. Wie so häufig tun Verbesserungen an einigen Stellen aber auch weh, und darauf sollte man angemessen reagieren.
Viele Grüße! —MisterSynergy (talk) 12:25, 7 December 2016 (UTC)
@Magiers: Ein kurzer Einschub, weil gerade was passendes an mir vorbeiscrollte: @DBrant (WMF) hat vor gut einem Monat in Wikidata:Requests for comment/Editing descriptions from Wikipedia Android app eine Communitymeinung zum Ändern von Beschreibungen in den Apps eingeholt. Er erwähnte ganz ausdrücklich als Option:
“Should we hide descriptions entirely for certain types of articles, such as lists?”
bei der Problembeschreibung. Zwar wurde auf die Idee im RfC dann nicht weiter eingegangen; ich denke aber schon, dass für solche Schritte eine grundsätzliche Bereitschaft seitens des Entwicklerteams vorhanden wäre, und ein passender Ansprechpartner wäre damit auch bekannt… Viele Grüße, MisterSynergy (talk) 07:19, 8 December 2016 (UTC)

@Magiers: ich versuchs Mal mit 4 Beispielen:

  • A) Liste von Bergen und Erhebungen in Soundso – als Überblick gedacht, reines Wikipediakonstrukt (per Definition eigentlich nie vollständig) > Wikimedia-Liste
  • B) Liste der Naturschutzgebiete in Soundso – basiert zwar auf amtlichen Infos, aber diese werden nicht unbedingt als Liste i.e.S. geführt (zB wenn Infos aus verschiedenen Verordnungen zusammengesucht wurden) > Wikimedia-Liste
  • C) Liste der Baudenkmäler in Soundso – basiert auf oder entspricht (in den meisten dt. Bundesländern) einer echten Denkmalliste, aber die Wikipediaform weicht oft von der amtlichen Liste ab (zB. weil in mehrere Listen nach Stadtbezirken oder nach Bau- und Bodendenkmälern aufgeteilt oder um diverse Infos erweitert) > Wikimedia-Liste
  • D) Rote Liste gefährdeter Tiere, Pflanzen und Pilze Deutschlands – in Wikipedia ein Artikel über die Liste, aber selbst keine Liste > echte Beschreibung in Wikidata (zB. "Publikation des Bundesamts für Naturschutz")

Außerdem gibts für die Listen-Items, wo "Wikimedia-Liste" reingehört, kaum sinnvolle Beschreibungen, denn die Titel sind ja schon selbstbeschreibend. D.h. fürs Item "Naturschutzgebiet" ist eine ergänzende Beschreibung wie "Gebietsschutzkategorie in Deutschland" sinnvoll, aber was sollte man bei "Liste der Naturschutzgebiete in Soundso" noch ergänzend beschreiben? Zweck der Einheitsbeschreibung "Wikimedia-Liste" ist also eine schnelle Unterscheidung zu anderen Listen-"Artikeln" zu bieten. Außerdem ist das natürlich sehr nützlich wenn man Items wie Q422705 aufruft, wo noch kein deutscher Titel existiert. Auch wenn mir grade kein reales Beispiel einfällt, es gibt bestimmt Fälle, wo die von MisterSynergy treffend erklärte Abgrenzung zu andren Items wichtig ist. Stell dir vor, du hast einerseits eine der üblichen Baudenkmallisten (Wikimedia-Liste) und andrerseits einen Artikel "Kulturdenkmalliste der Amtshauptmannschaft Soundso (1885)", in dem Infos über die Invetarisation und ihre Geschichte stehen (und das Originalwerk vielleicht auf Wikisource). Bei letzterem würde dann vielleicht drinstehen "historische Denkmalliste in Sachsen, Teil von…".
Für einheitliche Beschreibungen ist Gadget-autoEdit.js sehr nützlich, sonst kümmern sich auch Bots drum. Holger1959 (talk) 00:43, 8 December 2016 (UTC)

Danke für Eure Antworten. So ganz will mir noch nicht einleuchten, warum Listen etwas Spezielles sind. Auch viele WP-Artikel haben keinen "realen Artikelgegenstand", sondern sind Konstrukte unseres Projektes (allgemein Artikelauslagerungen wie "Geschichte von...", Kombinationsthemen "xxx und yyy" - dort gibt es auch nicht viel mehr zu beschreiben als das Lemma). Diskografien habe ich gesehen, haben eigene Beschreibungen. "Liste der Lieder von" oder "Liste der Werke von" nicht. Ich glaube ja, dass das einfach ziemlich willkürlich entstanden ist und ein Bot nur "Liste von" abgegrast hat. Wenn es einen echten Bedarf gibt, Listen zu unterscheiden, könnte man dazu ja eine eigene Eigenschaft entwickeln und müsste das nicht über die Kurzbeschreibung machen (die m.E. ja prädestiniert für einen gewissen Wildwuchs ist, weil nicht eindeutig definiert). Aber mein hauptsächlicher Punkt ist wirklich das künftige Einblenden in der Mobilversion, und wenn dort ein Ausblenden der Listenbeschreibung schon mal angedacht war, ist es immerhin schon mal jemand aufgefallen, dass "Wikimedia-Liste" dem Leser nichts sagt und ihn höchstens verwirren wird. Gruß --Magiers (talk) 08:35, 8 December 2016 (UTC)
Tatsächlich wird solch eine schematische Beschreibung nicht nur bei Listen angewendet, sondern auch bei anderen Objekten mit Metacharakter. Beispiel: history of Berlin (Q679741) wird mit „Wikimedia-Geschichts-Artikel“ beschrieben. Das wird meines Wissens für alle Objekte so gemacht, die einen Claim instance of (P31) mit einem Wert haben, der eine Unterklasse von Wikimedia page outside the main knowledge tree (Q17379835) und/oder Wikimedia article page (Q15138389) und/oder MediaWiki main namespace page (Q15633587) und/oder ähnliches ist. Es ist korrekt, dass dies bisher nicht konsequent überall durchgesetzt ist, und auch die Beschreibungen deshalb bisweilen inkonsistent sind. Die Objekte existieren aber vor allem deshalb, weil hier die Interwikis koordiniert werden müssen, und eher nicht weil wir Daten über diese Entitäten strukturieren wollen. —MisterSynergy (talk) 11:02, 8 December 2016 (UTC)
  • "Wikimedia-Liste" ist völliger Unsinn, auch die Argumentation, das seien Listen, die es nur in Wikipedia gibt und nicht außerhalb. Gerade das ist völlig absurd. Auch außerhalb von Wikipedia werden jede Menge Listen geführt, seien ex Denkmallisten, Listen der Milliarden-Dollar-Wetterkatastrophen whatsoever. Wir haben "Wikimedia-Begriffsklärung", weil das ein Wikipedia internes Konstrukt ist und nur der Verwaltung der Enzyklopädie bzw. dem Navigieren zum gesuchten Artikel dient. Wo immer ich "Wikimedia-Liste" sehe, werfe ich es raus und ersetzte es durch "geographische Liste", "Denkmalliste" oder sonst etwas passendes. --Matthiasb (talk) 21:44, 9 December 2016 (UTC)
So sehe ich's ja auch. Aber als manueller Benutzer steht man in Wikidata ja offensichtlich auf verlorenem Posten. Gibt es nicht einen Bot, der eine solche inhalts- statt metafunktionorientierter Befüllung mittels fester Kriterien (geographische Listen und Denkmallisten sollten sich ja erkennen lassen, ebenso die von mir angesprochenen Werklisten) vornehmen kann? --Magiers (talk) 09:11, 11 December 2016 (UTC)
Mir ist da nichts bekannt. Letztlich müssten alle Bots diese Ausnahmen erkennen und akzeptieren, was in für unwahrscheinlich halte. Diese Art der Vereinheitlichung ist ein Standardisierungsprozess für Objekte des Typs Wikimedia page outside the main knowledge tree (Q17379835) (dessen deutschsprachige Bezeichnung/Beschreibung ich gerade angepasst habe). —MisterSynergy (talk) 10:10, 11 December 2016 (UTC)

Logos

Ich habe in dewiki in der Vorlage de:Vorlage:Infobox Unternehmen Wikidata als Grundlage für den Bezug von Dateien aus Commons herangezogen. Dabei kommen berechtige Fragen, wie man auf Logos lokaler Töchter oder alternative Logs (zum Beispiel andere Sprachversion) zugreifen kann.

Grundsätzlich sind da zwei unterschiedliche Ansätze denkbar:

  1. Es handelt sich um ein eigenständiges Tochterunternehmen mit eigen Logo: in diesem Fall wäre ein neues Wikidata-Item anzulegen, auf das man dann verlinken kann.
  2. Es gibt mehrere Logos die gleichwertig verwendbar sind. (z.B. in der Schweiz hat ein Unternehmen gleichzeitig ein französisches und deutsches Logo.) In diesem Fall müsste man über eine Eigenschaft von Logo auf das gewünschte von mehreren Logos zugreifen.) Ein passendes Property unterhalb von Logo finde ich allerdings noch nicht.Boshomi (talk) 17:33, 9 December 2016 (UTC)
Für relevante eigenständige Tochterunternehmen würde ich ebenfalls ein separates Objekt machen, und das dann passend zur Mutter verlinken. Ggf. hilft Wikidata:WikiProject Companies weiter, wie das am besten geht. Bei dem anderen Fall verschiedener Logos ist mir gerade nicht klar, wie man das scharf abgrenzen will. Nach Staat, Region, Sprache, Zeitraum, etc… Da wäre wohl erstmal zu klären, wie man bei Wikipedia bisher das Logo ausgewählt hat welches da in der Infobox angezeigt wird. Mutmaßlich ist das eine Einzelfallentscheidung je nach Firma, und das ist natürlich eher schwierig hier abzubilden. Eine Möglichkeit wäre ansonsten, mehrere Logos einzutragen und dann irgendwie geeignet einen generischen Qualifier wie applies to part (P518) oder of (P642) an die logo image (P154)-Aussage zu ergänzen. Wikipediaseitig würde man dann die Aussage mit Qualifier nutzen falls vorhanden, und sonst die allgemeine ohne Qualifier. Die Logo-Eigenschaft hat keine Single-Value-Einschränkung, daher muss man eh davon ausgehen dass sie mehrere Werte zurückgibt und beim Einbau in die Infobox ausdrücklich davon nur einen auswählen. Einschränkungen hinsichtlich der Qualifier an der Logo-Eigenschaft gibt es nicht. Ich würde das Vorgehen in jedem Fall aber auf Property talk:P154 ansprechen und ankündigen. —MisterSynergy (talk) 20:47, 9 December 2016 (UTC)
Für Fall 1 muss man wohl einen Parameter "Unternehmen" in die Vorlage einfügen. Es kommt öfter vor, dass 2 oder 3 Infoboxen in einem Artikel vorhanden sind. Dort muss man dann über den Parameter Unternehmen auf ein entsprechende Objekt verknüpfen. Mit der Relevanz wird es schwierig. die Tocherunternehmen sind häufig nicht eigenständig relevant, aber für den lokalen Gebrauch wichtig für den Artikel. Kann man sich da mit Weiterleitungen abhelfen, die dann ein wikidata-Objekt begründen?
Für den Fall 2 fehlen mir noch die konkreten Beispiele, und mir fehlt vor allem die Zahl der betroffen Fälle um abschätzen zu können welcher Grad der Verkomplizierung sich noch lohnt.
@MisterSynergy: Ich bitte dich die Diskussionsseite der Vorlage Infobox Unternehmen unter beobachtung zu halten. Ich habe vermutlich in den nächsten Tagen nur wenig, und dann meist nur abends Zeit, mich um Anfragen und Bitten um Hilfen zu kümmern. Vielleicht wird durch die Anfragen dann auch klarer welche Wege einzuschlagen sind.Boshomi (talk) 22:04, 9 December 2016 (UTC)
Hmm, ich wollte mich da wikipediaseitig raushalten, diese Diskussionen tun mir da nicht gut. Aber ich schaue mir das mal an, vielleicht geht das ja auch vorwiegend beobachtend…
Ich würde Euch in der Sache allerdings empfehlen, zunächst nur einen Datenabgleich und Wartungskategorisierung vorzunehmen, und in jedem Fall immer lokale Werte anzuzeigen, sofern die vorhanden sind (und diese auch nicht zu entfernen). Wikidata-Content wäre dann nur sichtbar, wenn kein lokaler Wert gesetzt ist. Da habt Ihr jetzt zwar schon eine Weile in die andere Richtung gearbeitet, aber die dewiki-Community ist frustrierenderweise nicht im Ansatz bereit für Wikidata und will lieber weiter mit grotesk stumpfen Steinzeitwerkzeugen am fortschreitend verranzenden Artikelbestand rumwerkeln. Jedes Experiment wird gleich mit zahlreichen absurden Wortmeldungen totgelabert. Nunja. Wünsche erstmal eine gute Nacht! —MisterSynergy (talk) 22:18, 9 December 2016 (UTC)

2 Fragen

  1. Wie kriege ich das Ergebnis von diesem Query als Wikitabelle exportiert?
  2. Wie kann man die Abfrage für den Listeriabot aufbereiten, also konvergieren von SPARQL zu WDQuery?

Queryzo (talk) 17:01, 11 December 2016 (UTC)

Ein direkter Export vom Abfragedienst zu Wikiquelltext ist mir nicht bekannt. Listeriabot macht aber sowas, womit wir direkt beim nächsten Punkt wären: Listeria kann seit längerem mit SPARQL abfragen, eigentlich sogar besser als mit WDQ. Die Doku-Seiten von Listeria in diversen Projekten sind aber meist veraltet, ich würde an Deiner Stelle mal bei en:Template:Wikidata list schauen, was meines Wissens die aktuelle Version ist. —MisterSynergy (talk) 17:17, 11 December 2016 (UTC)
Nachtrag: ich würde für den ListeriaBot diese SPARQL-Abfrage nutzen: SELECT DISTINCT ?item WHERE { ?item wdt:P570 ?death; wdt:P106/wdt:P279* wd:Q2500638; wdt:P27 wd:Q183; wdt:P31 wd:Q5 . FILTER(YEAR(?death)=1946) . }. Ihr braucht das nur für die Auswahl der Objekte, des Rest holt sich Listeria irgendwie selbst her auf Basis der Parameterwerte in dem Kopf-Template. —MisterSynergy (talk) 17:36, 11 December 2016 (UTC)
Na denn man Tau: Test. @Sebastian Wallroth: zu Info, mal sehen, ob das klappt. Queryzo (talk) 18:38, 11 December 2016 (UTC)
So klappt das nicht. Darf ich da mal dran? —MisterSynergy (talk) 18:42, 11 December 2016 (UTC)
Nur zu! --Sebastian Wallroth (talk) 19:29, 11 December 2016 (UTC)
@Sebastian Wallroth, Queryzo: Büddeschön! Da fehlte das schließende Template, und das SPARQL war auch noch nicht ganz geeignet – da muss bei Listeria in jedem Fall ?item zurückgegeben werden. Bei Fragen: fragen! Viele Grüße, —MisterSynergy (talk) 19:34, 11 December 2016 (UTC)
@MisterSynergy: fantastisch! Kannst Du bitte noch einen Link zum Wikidata-Objekt reinzaubern? Die Einträge ohne deutschsprachigen Artikel haben sonst gar keinen Link. Danke im voraus! --Sebastian Wallroth (talk) 20:01, 11 December 2016 (UTC)
Ein Link zum Resonator ist einfach möglich, alles andere müsste ich erst kompliziert rausfummeln. Der Resonator stellt aber wesentliche Informationen aus dem entsprechenden Wikidata-Objekt „in schön“ dar, und man bekommt einen Überblick über die Person. Beispiel aus Eurer Liste: Adriaan van Maanen (Q2013915). —MisterSynergy (talk) 20:15, 11 December 2016 (UTC)

Property:P205

Der Name "Anrainerstaat" passt nicht, denn es werden damit auch Gewässer versehen, die vollständig auf einem Staatsgebiet liegen. de:Anrainerstaat grenzt allerdings lediglich an. Z. B. ist Deutschland ein Anrainerstaat des Bodensees, aber nicht des Chiemsees, weil der ja vollständig in Deutschland liegt. Man müsste sich also einen anderen Name überlegen. Steak (talk) 12:33, 14 December 2016 (UTC)

New way to edit wikitext

Summary: There's a new opt-in Beta Feature of a wikitext mode for the visual editor. Please go try it out.


We in the Wikimedia Foundation's Editing department are responsible for making editing better for all our editors, new and experienced alike. We've been slowly improving the visual editor based on feedback, user tests, and feature requests. However, that doesn't work for all our user needs: whether you need to edit a wikitext talk page, create a template, or fix some broken reference syntax, sometimes you need to use wikitext, and many experienced editors prefer it.

Consequently, we've planned a "wikitext mode" for the visual editor for a long time. It provides as much of the visual editor's features as possible, for those times that you need or want wikitext. It has the same user interface as the visual editor, including the same toolbar across the top with the same buttons. It provides access to the citoid service for formatting citations, integrated search options for inserting images, and the ability to add new templates in a simple dialog. Like in the visual editor, if you paste in formatted text copied from another page, then formatting (such as bolding) will automatically be converted into wikitext.

All wikis now have access to this mode as a Beta Feature. When enabled, it replaces your existing wikitext editor everywhere. If you don't like it, you can reverse this at any time by turning off the Beta Feature in your preferences. We don't want to surprise anyone, so it's strictly an opt-in-only Beta Feature. It won't switch on automatically for anyone, even if you have previously checked the box to "Automatically enable most beta features".

The new wikitext edit mode is based on the visual editor, so it requires JavaScript (as does the current wikitext editor). It doesn't work with gadgets that have only been designed for the older one (and vice versa), so some users will miss gadgets they find important. We're happy to work with gadget authors to help them update their code to work with both editors. We're not planning to get rid of the current main wikitext editor on desktop in the foreseeable future. We're also not going to remove the existing ability to edit plain wikitext without JavaScript. Finally, though it should go without saying, if you prefer to continue using the current wikitext editor, then you may so do.

This is an early version, and we'd love to know what you think so we can make it better. Please leave feedback about the new mode on the feedback page. You may write comments in any language. Thank you.

James Forrester (Product Manager, Editing department, Wikimedia Foundation) --19:32, 14 December 2016 (UTC)

Koordinaten importieren?

Gibt es jemand/ein Skript, der/das regelmäßig die Koordinaten importiert? Z.B. für diese Liste? Queryzo (talk) 22:52, 15 December 2016 (UTC)

SUDOC

Es gibt einige SUDOC-Statements (P269), die auf Weiterleitungsseiten (z. B. [3]) oder ungültige Seiten (z. B. [4]) verweisen. Man sollte die betroffenen Links suchen und dann die Statements entfernen oder korrigieren. Steak (talk) 09:55, 9 December 2016 (UTC)

Property talk:P269; ca. 328.000 Aussagen mit der Eigenschaft haben wir zurzeit. Die zugehörige Wartungsseite Wikidata:Database reports/Constraint violations/P269 sieht aus als bräuchte sie mal etwas Aufmerksamkeit, das geht zunächst vor allem manuell. Beide von Dir angesprochenen Fälle sind dort aufgelistet und würden beim Abarbeiten erledigt werden, wobei mutmaßlich auch in den Wikipedia-Artikeln diese „falschen“ IDs irgendwo auftauchen. Mit etwas Glück ist eine imported from Wikimedia project (P143)-Quelle dabei, dann findet man das einfach.
Wenn nach dem runterarbeiten immernoch Fehler aufzufinden sind, müsste man mal alle URLs crawlen und schauen, welchen HTTP Statuscode man zurückbekommt. Das würde ich aber angesichts der Anzahl erstmal hinten anstellen. Viele Grüße, MisterSynergy (talk) 20:28, 9 December 2016 (UTC)
Die Constaint-Violations-Wartungsliste enthält aber auch Einträge, wo Dubletten in der SUDOC-Datenbank bestehen und hier kein Handlungsbedarf ist. Die Links auf Weiterleitungen oder Fehlerseiten rauszusuchen ist da sehr mühsam. Deshalb wäre ein Crawlen der URLs als erster Schritt sinnvoller. Steak (talk) 11:03, 10 December 2016 (UTC)
Vielleicht könnte man erstmal die URLs aus der der Wartungsliste crawlen, das wären nur rund 2000 (glaub ich) und durchaus machbar. Hast Du einen Crawler? —MisterSynergy (talk) 11:31, 10 December 2016 (UTC)
Nein. Steak (talk) 11:35, 10 December 2016 (UTC)
Okay, dann versuche ich mich mal am Crawlen auf Basis der covi-Seite, hoffentlich noch dieses Wochenende. —MisterSynergy (talk) 11:55, 10 December 2016 (UTC)

Der Crawler ist fertig, der Lauf noch nicht. Leider gibt die Website keinen sinnvollen Weiterleitungs-HTTP-Code zurück, so dass ich da morgen nochmal händisch nachschauen muss. Meh! —MisterSynergy (talk) 22:28, 10 December 2016 (UTC)

Bin mit einer ersten Runde durch, User:MisterSynergy/P269 worklist markiert schonmal die ungültigen Seiten farbig. Das sind eigentlich relativ wenige, die schonmal korrigiert werden können. Weiterleitungen konnte ich in diesem ersten Durchlauf nicht identifizieren, weil der SUDOC-Server dafür nicht richtig konfiguriert ist. Ich plane dafür einen zweiten Durchlauf, der aber mutmaßlich nicht heute laufen wird. —MisterSynergy (talk) 08:37, 11 December 2016 (UTC)
Die ungültigen Statements habe ich alle missbilligt gesetzt, und dazu den Qualifier reason for deprecated rank (P2241) withdrawn identifier value (Q21441764) gesetzt. Die sollten auf der covi-Seite bald nicht mehr auftauchen, und auch sonsten aus Abfragen etc. verschwinden. Zu den Weiterleitungen gibt es noch keinen Fortschritt. —MisterSynergy (talk) 11:02, 11 December 2016 (UTC)
Ich denke man sollte die ungültigen Statements einfach entfernen. Welchen Sinn hat es, sie herabzustufen? Übrigens war dein Crawler nicht ganz zuverlässig, denn eine kurze Stichprobe hat noch Q24074271 gefunden. Steak (talk) 12:19, 11 December 2016 (UTC)
Die Links des Typs 103084398 (Weiterleitung) konnte ich bisher nicht identifizieren, weil sie als solche für die Crawler bisher nicht erkennbar sind. Dagegen sind die ungültigen, wie das eingangs genannte 130821748 (toter Link) alle erledigt, das waren aber auch nur ca. 20. Den Weg mit der Missbilligung habe ich gewählt, weil es meist tatsächlich externe Belege für den toten Link aus Daten-Importen gibt (BNF, VIAF, etc.). Wenn ich das jetzt entferne, wird das möglicherweise sehr bald wieder erneut importiert. Missbilligung ist tatsächlich das richtige Mittel, diese zwar in der Außenwelt vorhandenen, aber unbrauchbaren Daten zu handhaben. —MisterSynergy (talk) 12:34, 11 December 2016 (UTC)
Mag sein, aber das Argument zieht nicht, wenn null Fundstellen oder Fundstelle: "Wikipedia" angegeben ist, denn Wikipedia ist für uns nicht "Außenwelt". In diesen Fällen hab ich den Identifier deshalb entfernt. Steak (talk) 19:54, 11 December 2016 (UTC)
Dann ist das okay, ich würde in der genannten Fundstellen-Wikipedia den Wert dann aber auch aktualisieren. —MisterSynergy (talk) 19:56, 11 December 2016 (UTC)

@Steak: die Weiterleitungen sind nun grün markiert. —MisterSynergy (talk) 15:07, 11 December 2016 (UTC)

Danke. Kannst du jetzt alle Links crawlen (nicht nur die auf der Covi-Seite)? Bei den restlichen gibts bestimmt auch etliche defekte. Steak (talk) 19:56, 11 December 2016 (UTC)
Lass uns mal bitte erst die covi-Seite runterwarten. 328.000 URLs crawle ich nicht mal ebenso, das will äußerst gut durchdacht sein. Mit einer URL je 10 Sekunden – schneller würd ich das nicht machen wollen – bräuchte man rund einen Monat Zeit dafür. Bei dem ersten Satz konnte ich lernen, musste aber auch schon zweimal jeweils fast 2000 URLs crawlen. Was genau wäre das Ziel eines kompletten Durchlaufes? Ich würde das, wenn überhaupt, nur mit HEAD-requests machen wollen, dann wird nur der HTTP-Header übertragen und nicht die komplette Seite und ich erspare meiner langsamen Internetverbindung und dem SUDOC-Server die Übertragung einer ganzen Menge Daten. Dann könnte ich aber nur defekte Links wie die dunkelblauen in der Wartungsliste finden, keine Weiterleitungen wie die hellgrünen (weil die ihren Server bei den Weiterleitungen ungeeignet konfiguriert haben). Ehrlich, die Menge an Links macht das zu einem ziemlich ambitionierten Vorhaben. —MisterSynergy (talk) 20:07, 11 December 2016 (UTC)

@MisterSynergy: Deine Liste hab ich jetzt abgearbeitet. Jetzt müsste man sich halt irgendwie an das Crawlen aller Links machen. Oder man machts diesbezüglich nichts, soll mir auch recht sein. Gibt ja genug zu tun hier. Steak (talk) 09:43, 21 December 2016 (UTC)

Danke, ich habe das gesehen. Ich warte nun ein bis zwei Tage und werde dann die aktualisierte covi-Seite nochmal crawlen, falls etwas liegen geblieben oder neu hinzugekommen ist. Ansonsten baue ich mir gerade einen etwas besseren Crawler, der vielleicht irgendwann mal auf dem Toolserver (und nicht zu Hause auf dem Notebook) laufen soll. Dann wäre das vielleicht möglich, zumindest um die toten Links zu finden. Allerdings: ETA unbekannt. Du kannst wirklich erstmal eine andere Baustelle suchen
Viele Grüße, —MisterSynergy (talk) 09:59, 21 December 2016 (UTC)

@Steak: ich habe nochmal alle single value constraint violations abgegrast und drei weitere, mutmaßlich neue Fälle gefunden. Ansonsten ist wohl erstmal wenig zu tun. Vielleicht kann ich das in Zukunft nochmal im großen Stil abgrasen, das ist aber jetzt noch nicht seriös abschätzbar. Wir können das hier erstmal als erledigt betrachten. Viele Grüße, MisterSynergy (talk) 15:27, 24 December 2016 (UTC)

Danke. Kannst du das gleiche Crawlen auch für NUKAT (Wikidata:Database reports/Constraint violations/P1207) machen? Da sind mir auch einige tote Links bei den Single-Value-Violations aufgefallen, und es gibt da auch ziemlich viele Format-Violations. Steak (talk) 09:52, 26 December 2016 (UTC)
Ja ich schaue mir NUKAT in den nächsten Tagen an. Wie gut das geht, kann ich jetzt noch nicht abschätzen. --MisterSynergy (talk) 11:55, 26 December 2016 (UTC)

Generierte Artikel als Quelle für WD

Beispiel: Aus dem GeoNames-Eintrag wird automatisch ein Artikel sv:Augstenberg (bergstopp i Österrike, Vorarlberg) generiert, dieser bekommt automatisch einen WD-Eintrag Ogstaberg (Q21878686) und die eizelnen Properties dort werden mit der Fundstelle schwedischsprachige Wikipedia belegt. Vogis kennt an dieser Stellen weder einen Berg noch einen Flurnamen Augstenberg (Flurnamen bei den Inhalten aktivieren). D.h. es ist fraglich, ob das Feature überhaupt existiert, seine Existenz lässt sich aber inzwischen durch die generierten Artikel belegen. In anderen Fällen, wo es eine Entsprechung in der Karte gibt, werden regelmäßig zusätzliche WD-Einträge angelegt, die dann manuell gemischt werden müssen.

Meine Fragen und Bitten und Forderungen:

  • per Bot generierte Artikel können nie und nimmer als Fundstelle in der WD herhalten.
    • das ist mE technisch zu unterbinden und wo schon geschehen, rückgängig zu machen
  • Wenn schon, dann sind die der Generierung zugrundeliegenden Basisdaten (in diesem Fall GeoNames) als Quelle für einen Aussage herzunehmen, aber nicht die daraus abgeleiteten.
  • Aus per Bot generierten Artikel sollten überhaupt keine WD Einträge generiert werden.

Wir erzeugen damit einen nur schwer nachvollziehbaren selbst-referenziellen, widerspruchsfreien Wahrheitengenerierungsapparat, aber keine Aussagen über die reale Welt. Dazu kommt, dass die Community nicht beliebig skaliert. lg --Herzi Pinki (talk) 13:35, 22 December 2016 (UTC)

Hallo Herzi Pinki! Den „schwer nachvollziehbaren selbst-referenziellen, widerspruchsfreien Wahrheitengenerierungsapparat“ sollten wir tatsächlich vermeiden, so sehr und so gut wir das können. Nur: liegt das Problem bei Wikidata? Solange jemand mit Bot derart viel Mist im Wikimedia-Universum abladen kann, sind die Daten leider sowieso in der Welt. Wikidata muss nun einmal Interwikis organisieren und dazu gehört die Regelung, dass alle ANR-Seiten ein Objekt bekommen oder mit einem existierenden Objekt verbunden werden. Davon kann man Bot-generierte Artikel nicht ausschließen, denn die Boteigenschaft ist häufig gar nicht so einfach festzustellen.
Wenn diese Schrottdaten in einer Deiner Abfragen auftauchen, versuche sie zu filtern. Dass als Fundstelle die schwedische oder ceb…ische Wikipedia (oder meinethalben auch Geonames) genannt werden, sind dabei durchaus von Vorteil – sowas kann man mit den modernen Abfragetool ausschließen. Alternativ, und das sehe ich als optimale Lösung an, kann man den oder die falschen Artikel löschen lassen, dann verschwindet auch das Wikidata-Item mit der Zeit (sofern es nicht mehr als Eigenschaftswert woanders genutzt wird). Bei der „Arbeitsleistung“ des betreffenden Bots kann das aber leider eine ziemliche Monsteraktion sein… —MisterSynergy (talk) 13:51, 22 December 2016 (UTC)
Ok, wenn das Problem nicht bei WD liegt, dann heißt das, es gibt keine Qualitätsanforderungen in WD, die auch durchgesetzt werden. Womit aber wieder das Problem bei WD liegt, nur umfassender. Es kann doch nicht allen Ernstes die Fantasie herrschen, das sich die Schwarmintelligenz langfristig schon gegen die Bots durchsetzen wird. Und WD als Provider einer Plattform schaut erste Reihe fußfrei zu. Es hat auch keinen Sinn, wenn ich da einen einzelnen Botbetreiber anspreche. Es ist eine Frage der Policies und ihrer Enforcements. lg --Herzi Pinki (talk) 14:39, 22 December 2016 (UTC)
Bitte nicht imported from Wikimedia project (P143) mit stated in (P248) verwechseln, ersteres wird nur verwendet, um zu zeigen, dass die Information aus der schwedischen Wikipedia gezogen wurde. Daher sehe ich da kein Problem. Queryzo (talk) 14:48, 22 December 2016 (UTC)
Es ist im Wesentlichen ein Bot für derlei verantwortlich, aber man fängt ihn seit Jahren nicht ein. Zeig uns bitte gerne, wie Du hier effektiv mit Verboten ansetzen möchtest, ohne zulässige Daten als Kollateralschaden gleichzeitig mit auszusperren. Botartikel sind weit verbreitet (abgesehen von dewiki) und meist nicht von schlechtester Qualität. Die Forderung wirkt ein bisschen analog zur aktuellen Debatte, sogenannte „Fake News“ mit einem bürokratischen Zensurapparat einzufangen. Das Problem kriegt man mit solchen Ansätzen nicht aus der Welt, aber man holt sich zahlreiche neue Schwierigkeiten ins Haus.
Wir sammeln hier letztlich Daten, die extern nachweisbar sind, und nicht Daten, die „richtig“ sind. Wenn die Daten schlecht sind, sind sie entsprechend auszuzeichnen und dann stören sie auch nicht weiter (das ist im genannten Fall noch nicht passiert). Vieles davon geht automatisch, leider nicht alles. Uns ist allen klar, dass wir noch viel zu tun haben, und mehr Mitarbeiter wären wie bei Wikipedia hilfreich um Altlasten und Problemfälle abzuräumen – haben wir aber nicht. In der Zwischenzeit helfen wir Dir gern, derlei störende Objekte durch verfeinerte Abfragen weitgehend auszuschließen. Fehlerfrei wirds nie werden, das liegt aber nicht an den Policies von Wikidata. —MisterSynergy (talk) 15:09, 22 December 2016 (UTC)
Ich teile deine Resignation. :-( --Herzi Pinki (talk) 23:00, 23 December 2016 (UTC)
Meinst du einen bestimmten Bot oder irgendeinen bot? Einem bestimmten Bot wird man doch das Handwerk legen können. Auf deine Frage: Der Artikel in der WP:sv deklariert sich als bot-generiert. Wenn man das abfangen könnte, wäre mein primäres Problem schon ein Stück weit gelöst. Und ich sehe dabei keinerlei Kollateralschäden. Schlechte Daten sind auszuzeichnen, ok. Leider keine Ahnung wie, bitte um Hinweis. Und wie ist dann der Rückworkflow zum Ursprung der schlechten Daten definiert? Gibt es vermutlich nicht und die Daten kommen nächste Woche wieder. @mehr Mitarbeiter: man wird das Wartungsproblem nur lösen können, wenn man eingangsseitig drosselt, nicht hinten nach mehr Mitarbeitern rufen. lg --Herzi Pinki (talk) 23:34, 23 December 2016 (UTC)
Hallo zu später Stunde! Ich meine den Lsjbot, der in svwiki, cebwiki und warwiki millionenfach Artikel generiert hat und von dem auch das eingangs von Dir genannte Beispiel kommt. Dessen "Arbeitsleistung" sehe ich höchst kritisch und das wurde ja auch schon aaO vielfach diskutiert. Dass er seine Artikel allerdings als Botartikel auszeichnet, ist eher eine Ausnahme. Ich weiß nicht wie häufig Du in anderssprachigen Wikipedias als dewiki unterwegs bist; meinem Gefühl nach würde ich behaupten, dass fast überall massig Botcontent rumliegt, und das sind dann eigentlich immer irgendwelche ungekennzeichneten vertextlichten Datenbankauszüge. Da schaut niemand danach, ob der Inhalt überhaupt plausibel ist, sondern das wird einfach generiert und dann verrottet der "Artikel" auf ewig. Und es werden eben auch Datenbankauszüge basierend auf User-generated-Content erstellt, wie im Falle von Geonames.
Konsequenterweise müsstest Du das irgendwie alles ausschließen und Wikidata am Ende händisch befüllen, aber dann wäre dieses Projekt keinen Millimeter vom Fleck gekommen. Ich bin mittlerweile vielfach hier zugegen und meine mittlerweile die Qualität einschätzen zu können. Als schwierig sehe ich dabei eher die zahlreichen Lücken an, nicht die gelegentlichen "falschen" Daten. Die gibt es sicher (wäre auch bei handgefülltem Wikidata so), aber die stellen keinen signifikanten Anteil am Gesamtwerk dar. Typische Wartungsarbeit sieht hier häufig auch eher so aus, dass Du viele gleichartige Objekte hernimmst und dann eine bestimmte Eigenschaft auf Plausibilität prüfst, oder schaust ob verlässliche externe Nachweise erbringbar sind. Echter Mist fällt da schnell auf.
Was nun im Einzelnen machbar wäre: ich kenne mich nicht hinreichend mit dem Thema im vorliegenden Fall aus, dass ich eine einzige richtige Lösung anbieten könnte. Nach den bekannten Internet-Kartendiensten gibt es tatsächlich in der Nähe des "Berges" zwei Berge mit demselben Namen. Einfache Koordinatenverdreher oder -umrechnungsfehler scheinen aber nicht passiert zu sein. Wenn es da tatsächlich keinen Berg gibt, dann sollte das Objekt auch keinen Berg auszeichen. Du könntest einen fictional mountain (Q19838114) draus machen. Sind dagegen nur einzelne Aussagen zu dem Objekt falsch, der Rest aber richtig, dann würdest Du eher mit dem missbilligten Rang arbeiten. Die Daten stehen dann noch im Objekt und werden nicht erneut importiert, aber sie erscheinen nicht bei maschinellen Abfragen (durch Wikipedia oder externe Nutzer). Sie sind nur im Webfrontend zu sehen, welches anders als bei Wikipedia im Grunde ein reines Autorentool ist, aber keine Oberfläche für Datennutzer (bei Wikipedia nutzen auch die Leser das Webfrontend, da darf kein "falscher" Content stehen, selbst wenn er als solcher ausgezeichnet ist).
Einen systematischen Rückfluss zur ursprünglichen Quelle der falschen Daten gibt es nicht. In den Wikipedia-Artikeln könnte man Wikidata-Bezug machen, dann sind dort zumindest die Änderungen nicht mehr vorhanden. Geonames müsste von sich aus entscheiden, dass sie basierend auf unseren Daten ihre eigenen Daten verbessern. Punktuell passiert das tatsächlich, weil Wikidata unheimlich viel flexibler ist als die meisten externen Datenbanken und daher überhaupt erst eine brauchbare Plausibilitätskontrolle ermöglicht. Die Regel ist das aber wie gesagt nicht, und extern nachgewiesene "falsche" Daten mit missbilligtem Rang sind auch von seiten des Wikidata-Projektes kein Problem, sondern Projektziel (wie gestern schon gesagt: wir sammeln nicht "richtige" Daten, sondern extern nachweisbare Daten).
Das sollte fürs erste reichen. Ich wünsche eine gute Nacht und ein paar schöne Tage, MisterSynergy (talk) 00:26, 24 December 2016 (UTC)
Danke für die postiv gestimmte Antwort. Dir auch Frohe Christmas (Q19809) und toast (Q154168) 2017 (Q25290) lg --Herzi Pinki (talk) 01:22, 24 December 2016 (UTC)

pywiki problem mit WD

Hallo, 

import pywikibot
dewiki   = pywikibot.Site('de')
page = pywikibot.Page(dewiki,'Bad Tatzmannsdorf')
#page = pywikibot.Page(dewiki,'Villach')
print (">>>", page.title())
item = pywikibot.ItemPage.fromPage(page)

liefert mir 

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-66-3215cb952f87> in <module>()
      2 #page = pywikibot.Page(dewiki,'Villach')
      3 print (">>>", page.title())
----> 4 item = pywikibot.ItemPage.fromPage(page)

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in fromPage(cls, page, lazy_load)
   3906         i._site = page.site
   3907         i._title = page.title(withSection=False)
-> 3908         if not lazy_load and not i.exists():
   3909             raise pywikibot.NoPage(i)
   3910         return i

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in exists(self)
   3454         if not hasattr(self, '_content'):
   3455             try:
-> 3456                 self.get()
   3457                 return True
   3458             except pywikibot.NoPage:

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in get(self, force, get_redirect, *args, **kwargs)
   3921         @raise NotImplementedError: a value in args or kwargs
   3922         """
-> 3923         data = super(ItemPage, self).get(force, *args, **kwargs)
   3924 
   3925         if self.isRedirectPage() and not get_redirect:

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in get(self, force, *args, **kwargs)
   3536                 self.claims[pid] = []
   3537                 for claim in self._content['claims'][pid]:
-> 3538                     c = Claim.fromJSON(self.repo, claim)
   3539                     c.on_item = self
   3540                     self.claims[pid].append(c)

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in fromJSON(cls, site, data)
   4337             # The default covers string, url types
   4338             claim.target = Claim.TARGET_CONVERTER.get(
-> 4339                 claim.type, lambda value, site: value)(value, site)
   4340         if 'rank' in data:  # References/Qualifiers don't have ranks
   4341             claim.rank = data['rank']

/srv/paws/lib/python3.4/site-packages/pywikibot/page.py in <lambda>(value, site)
   4280         'globe-coordinate': pywikibot.Coordinate.fromWikibase,
   4281         'time': lambda value, site: pywikibot.WbTime.fromWikibase(value),
-> 4282         'quantity': lambda value, site: pywikibot.WbQuantity.fromWikibase(value),
   4283         'monolingualtext': lambda value, site:
   4284             pywikibot.WbMonolingualText.fromWikibase(value)

/srv/paws/lib/python3.4/site-packages/pywikibot/__init__.py in fromWikibase(cls, wb)
    673         """
    674         amount = cls._todecimal(wb['amount'])
--> 675         upperBound = cls._todecimal(wb['upperBound'])
    676         lowerBound = cls._todecimal(wb['lowerBound'])
    677         error = (upperBound - amount, amount - lowerBound)

KeyError: 'upperBound'

mit dem alternativen Ort Villach läuft es reibungsfrei. Bad Tatzmannsdorf (Q700166) existiert aber und auch der wikidatalink von de:Bad Tatzmannsdorf funktioniert wie erwartet. Ich hatte zuerst den doppelten Link in Verdacht: Wikipedia und Wikivoyage, aber das temporäre Entfernen des Wikivoyage-Eintrags hat keinen Unterschied gemacht. Ich fange hier mal an, bin aber auch mit einer Weiterleitung an die richtige Stelle zufrieden. lg --Herzi Pinki (talk) 23:13, 23 December 2016 (UTC)

dasselbe Problem mit Götzens (Q667639). --Herzi Pinki (talk) 00:36, 24 December 2016 (UTC)

Ich bin kein Pywikibot- oder Pythonexperte. Daher nur der Hinweis: 

import pywikibot
dewiki = pywikibot.Site('de', 'wikipedia')
page = pywikibot.Page(dewiki,'Bad Tatzmannsdorf')
item = pywikibot.ItemPage.fromPage(page)

Das reagiert bei mir ähnlich. Da ich ausdrücklich de.wikipedia ausgewählt habe, sollte das nichts mit dem Wikivoyage-Link zu tun haben. Wenn ich das Objekt direkt von Wikidata öffne: 

import pywikibot
wikidata = pywikibot.Site('wikidata', 'wikidata')
repo = wikidata.data_repository()
item = pywikibot.ItemPage(repo, 'Q700166')

Dann gibts kein Problem (beides bei https://paws.wmflabs.org getestet). Wenn der Direktzugriff für Dich eine Option ist, kannst Du damit erstmal weiterarbeiten. Ansonsten müsstest Du jemanden fragen, der sich besser auskennt (ich versuche mal @Tobias1984, der meines Wissens da ganz firm ist). --MisterSynergy (talk) 12:31, 24 December 2016 (UTC)

@Herzi Pinki, MisterSynergy: Kann ich im Moment auch nicht nachvollziehen wie es zu diesem Fehler kommt. Ist es eine aktuelle Version von pywikibot? Ist das Beispiel vollständig? --Tobias1984 (talk) 13:01, 24 December 2016 (UTC)
In meinem Fall: ja das Beispiel ist vollständig, und ich habe das mit PAWS probiert -- keine Ahnung welche Pywikibotversion dahinter steckt. Da braucht man den Bot ja nicht selbst zu installieren, sondern nur ein Botscript zu starten und alles ist fein. Trotzdem: Danke für die Rückmeldung! --MisterSynergy (talk) 13:04, 24 December 2016 (UTC)
danke für eure Antworten, wenn auch nicht zielführend. Der Direktzugriff auf WD wie in MisterSynergys zweiten Beispiel ist keine Option, da ich versuche, von WP:de-Artikel aus den zugeordneten WD-Eintrag zu finden und ich keine Q-Nummer habe. Insgesamt tritt das Problem bei folgenden sechs (österreichischen) Gemeinden auf: Bad Tatzmannsdorf, Götzens, Innsbruck, Reith bei Seefeld, Schwaz und Weiz. Bei einem vergleichbaren Durchlauf am 13. November hat der Zugriff über dasselbe Konstrukt für alle Gemeinden funktioniert. lg --Herzi Pinki (talk) 23:49, 24 December 2016 (UTC)
Das Problem ist sehr wahrscheinlich, dass PAWS eine leicht veraltete Version von pywikibot verwendet. Im November wurden upperBound und lowerBound für den Mengen-Datentyp optional. Deine Problemdatenobjekte haben nun bereits Aussagen ohne upperBound, aber die veraltete Version von pywikibot scheint damit nicht umgehen zu können. In der neusten Version von pywikibot ist es geflickt, d.h. ich bin zuversichtlich, dass es bald auch auf PAWS wieder funktionieren wird. Bis dahin musst du allerdings entweder auf eine eigene Installation von pywikibot zurückgreifen oder auf https://tools.wmflabs.org --Pasleim (talk) 09:21, 26 December 2016 (UTC)
Mittlerweile geht das auch wieder mit PAWS. --MisterSynergy (talk) 09:34, 26 December 2016 (UTC)
Danke @Pasleim:, klingt plausibel. Bei mir geht es allerdings nicht in PAWS. Muss ich mehr tun als einen Browser-Neustart, um einen impliziten PAWS update zu bekommen? lg --Herzi Pinki (talk) 01:45, 27 December 2016 (UTC)
Eigentlich sollte ein Browser-Neustart reichen. Kannst du mal folgenden Code in PAWS ausführen und die Ausgabe hier posten?
from pywikibot.version import *
print(getversion())
--Pasleim (talk) 01:59, 27 December 2016 (UTC)
Zum Vergleich: das gibt bei mir im PAWS zurück:
[https] r-pywikibot-core.git (a3e5562, g7699, 2016/12/16, 21:23:11, n/a)
Man kann da auch die Skripte oder seine ganze PAWS-Instanz neustarten; das hilft mglw. auch. --MisterSynergy (talk) 06:32, 27 December 2016 (UTC)
Schaut bei mir anders aus:
pywikibot/__init__.py (37f03bb, -1 (unknown), 2016/11/13, 08:39:23, n/a)
Server niedergefahren, alle notepads niedergefahren, keine Änderung. Mit welchem Kommando geht der explizite restart? --Herzi Pinki (talk) 21:48, 27 December 2016 (UTC)
Jetzt ist's besser, version-update ist offensichtlich gerade erfolgt:
[https] r-pywikibot-core.git (a3e5562, g7699, 2016/12/16, 21:23:11, n/a)
aus meiner Sicht erledigt. --Herzi Pinki (talk) 00:51, 30 December 2016 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Forum/Archiv/2016/12&oldid=1102549620"