About this board

talk

Previous discussion was archived at User talk:CamelCaseNick/Archive 1 on 2020-10-09.

Pyrog (talkcontribs)
Reply to "Wrong OpenStreetMap key image"
McSearch (talkcontribs)
CamelCaseNick (talkcontribs)

Das stimmt. Dort steht tatsächlich, es seien Stolpersteine. Nur stimmt die Kantenlänge von 15 cm nicht mit denen von Gunter Demnig überein, der sonst knapp 10 cm hat. Auf den Bildern kann man erkennen, dass die Schrift viel sauberer gesetzt scheint – vllt. maschinell? Das sieht man so bei Stolpersteinen von Demnig nicht. Auf https://www.visitliberec.eu/de/vse-o-liberci/turisticke-cile/socharske-objekty/?view=min&cat=zajimavosti_a_cile&detail=23528 steht auch, es seien Stolperstein-inspirierte Gedenksteine.

Reply to "Deine Änderung bei Q43653261"
M2k~dewiki (talkcontribs)

Hallo CamelCaseNick,

vielen Dank für das Verbinden und Pflegen von bestehenden WD-Objekten mit neuen Artikeln bzw. Anlegen von neuen Objekten. Unterstützen können dabei unter anderem

Für die Unterstützung anderer Benutzer gibt es unter anderem

Call for participation in a task-based online experiment

1
Kholoudsaa (talkcontribs)

Dear CamelCaseNick,

I hope you are doing good,

I am Kholoud, a researcher at King's College London, and I work on a project as part of my PhD research, in which I have developed a personalised recommender system that suggests Wikidata items for the editors based on their past edits. I am collaborating on this project with Elena Simperl and Miaojing Shi.

I am inviting you to a task-based study that will ask you to provide your judgments about the relevance of the items suggested by our system based on your previous edits.

Participation is completely voluntary, and your cooperation will enable us to evaluate the accuracy of the recommender system in suggesting relevant items to you. We will analyse the results anonymised, and they will be published to a research venue.

The study will start in late January 2022 or early February 2022, and it should take no more than 30 minutes.

If you agree to participate in this study, please either contact me at kholoud.alghamdi@kcl.ac.uk or use this form https://docs.google.com/forms/d/e/1FAIpQLSees9WzFXR0Vl3mHLkZCaByeFHRrBy51kBca53euq9nt3XWog/viewform?usp=sf_link

I will contact you with the link to start the study.

For more information about the study, please read this post: https://www.wikidata.org/wiki/User:Kholoudsaa

In case you have further questions or require more information, don't hesitate to contact me through my mentioned email.

Thank you for considering taking part in this research.

Regards

The Anome (talkcontribs)

Hi Nick,

Thanks for the explanation. It was indeed the "Ü" that was baffling me. The Anome (talk) 18:35, 28 July 2022 (UTC)

The Anome (talkcontribs)
CamelCaseNick (talkcontribs)

Yes, there is a purpose behind this edit. But first, Thank You for noticing it and letting me know.

The original regular expression is invalid, so I tried to fix it and also prohibit leading zeros, a zero as superscript or subscript and curly braces around a single digit.

My reasoning behind the changes are:

  1. [0-9]+(\^([0-9]|{[0-9]+})?_([0-9]|{[0-9]+}) has a missing closing bracket.
  2. [0-9]+(\^([0-9]|{[0-9]+}))?_([0-9]|{[0-9]+}) has it added, but uses [0-9] instead of the equivalent \d making it harder to understand with all those brackets.
  3. \d+(\^(\d|{\d+}))?_(\d|{\d+}) uses \d instead, but still matches notations with leading zero digits like 0_{01} or 011_3. So I replaced \d+ with ([1-9]\d*|0). (either a single 0 or a non-zero digit followed by an arbitrary amount of digits).
  4. ([1-9]\d*|0)(\^(\d|{([1-9]\d*|0)}))?_(\d|{([1-9]\d*|0)}) is it then, but neither subscript nor superscript can be 0, so I removed those options:
  5. ([1-9]\d*|0)(\^(\d|{[1-9]\d*}))?_(\d|{[1-9]\d*}). And last but not least, using curly braces around a single digit is not needed (e.g. 0_{1} should be 0_1). For that, I replaced [1-9]\d* with [1-9]\d+ making omitting them mandatory.
  6. ([1-9]\d*|0)(\^(\d|{[1-9]\d+}))?_(\d|{[1-9]\d+}) is what I wanted to enter, but I suppose due to encoding issues \d+ became instead, resulting in
  7. ([1-9]\d*|0)(\^(\d|{[1-9]\Ü}))?_(\d|{[1-9]\Ü})

I updated the regular expression. This time without the issue.

By the way, the reason 0_1 should be allowed, but 00_1, 0_{1} or 0_{01} shouldn't, is to avoid a possible by-pass of distinct-values constraint (Q21502410). Otherwise, these four could have been leading to duplicates of unknot (Q1188344) without a constraint violation.

Gikü (talkcontribs)

Why?

Gikü (talkcontribs)

Ok, I see, it seems you based that on Special:Diff/1004979569. That was an inaccurate claim; in 2019 a small building on the same address was demolished, but the main 2 buildings of the protected monument stayed. Please revert your edit if you agree.

CamelCaseNick (talkcontribs)

Link zu stolpersteine-hamburg.de

5
NordNordWest (talkcontribs)

Moin! {{P|8804}} wird jetzt 5908-mal verwendet. Könntest du eine Abfrage machen, welche Stolperstein-Einträge das Property nicht haben? Viele Grüße, NNW (talk) 19:05, 24 January 2021 (UTC)

CamelCaseNick (talkcontribs)
CamelCaseNick (talkcontribs)
CamelCaseNick (talkcontribs)

Wenn man nur die aktuellen Stolpersteine betrachtet und die nach Diskussion:Liste der Stolpersteine in Hamburg#Stand 1. September 2020 fehlenden Stolpersteine entfernt, sowie die Kopf- und Zusatzsteine (Es sind Q104650063, Q100489663 und Q100900632 dazugekommen.), kommt man auf https://w.wiki/vnM. Das sind 12 Stolpersteine und die 8 Stolpersteine für Sarason und Blumenthal am Rothenbaum. Da hier für vier Menschen je zwei Stolpersteine verlegt wurden an derselben Adresse, war ich mir unsicher, welcher Stolperstein von stolpersteine-hamburg.de gemeint war.

NordNordWest (talkcontribs)

Ich schau mir das zeitnah an.

Friniate (talkcontribs)

Hi, I've noticed that you have reverted all my actions on the Stolpersteine's lists in Italy. Could you explain why? They are the exact same lists! See for example Q28382014 and Q86673755

CamelCaseNick (talkcontribs)

I can keep track of which municipality with Stolpersteine is listed in which Wikimedia list on a given Wikipedia. As you can see, qualifiers on is a list of (P360) differ. That way, automatic lists like User:CamelCaseNick/Stolpersteine/municipalities can be created, to find Stolpersteine in Wikidata that are missing on a given Wikipedia. To list the correct list article, the exceptions have to be exact.

In this case, the Italian Wikipedia has made distinct lists for some municipalities that are hence not part of the region's list. Therefore, they are not the exact same list, so they shouldn't be merged.

Friniate (talkcontribs)

Yes, I had guessed after my message, that the reason was the different organization of de and it.wiki. But, the problem it's not that it.wiki has specific lists for some municipalities (de.wiki has them too, of course, when you have more than 100 Stolpersteine in a city you have no choice), but that de.wiki in 5 regions out of 20 (Latium, Lombardy, Piedmont, Tuscany and Veneto) has almost emptied the articles and moved all the Stolpersteine in provincial lists. Therefore there is that difference between the qualifiers. But I think that it's impossible to have the identical organization of a certain topic in two different wikis, so a bit of flexibility is needed. Before wikidata, we would have obviously had interwikis between the article on de.wiki about Stolpersteine in Lombardy and an article on it.wiki about Stolpersteine in Lombardy! In this way, we loose all the interwikis (with the category on commons sometimes linked to the "it.wiki element" and sometimes to the german counterpart), with a great loss of connection between the different projects (and that is what 'data is about after all). I've not well understood the argument about your lists: the article on de.wiki about Stolpersteine in Lombardy has no Stolpersteine whatsoever, can't you simply link to the lists on the provincial level? And as for the qualifiers, can't we just add a double qualifier, "list" and "list of lists"?

Friniate (talkcontribs)

On the contrary, Q28047120 should be splitted for example (metropolitan city Venice =/= [municipality of] Venice)

Friniate (talkcontribs)

I'm sorry to bother, but do you agree with my point, or not?

CamelCaseNick (talkcontribs)

No, I'm sorry, I just missed your reply.

Regarding flexibility: Yes, when you look at the goal of having sitelinks for the same content on multiple Wikipediae, those I would consider the same, however that is not the only reason for Wikidata's existence. It is machine-readable structured and linked data, that describes the same concepts as the Wikipedia articles do – well mostly: Sometimes it makes sense to combine multiple related entities into one article (church buildings at the same place over time etc.) – and, in this case, to structure list articles differently.

I use Wikidata to automatically find mistakes or curiosities. For example, I have found duplicate lists in the German Wikipedia using those statements. If lists of Stolpersteine in Lombardy (Q28382014) and stolpersteine in Lombardy (Q86673755) were merged, a query for checking such duplicates would think that Stolpersteine in Metropolitan City of Milano (Q108098335) would already be covered, as Milano is in the Lombardy.

I agree with your point, and it does not render mine invalid. You see: There is no unambiguous way of handling this and making everybody happy, since Wikidata's purposes and goals are in inner contradiction.

And regarding Venice: As you can see at Special:Diff/1276761956 – the scope of the German list has changed. That occasionally happens. So thanks for handling that.

That is something, as you pointed out, happened to other German list articles, so yes my statements are outdated. If I encountered them now, I would use Wikimedia list of lists (Q33532284) instead.

Reply to "Merging Stolpersteine"
André L P Souza (talkcontribs)
Hallo. Vielen Dank, dass Sie mir die ganze Zeit geholfen haben.
Kurzerhand wollte ich lernen, wie man den Google Knowledge Graph verwendet, um nicht die ganze Zeit unnötigerweise WikiData "verändern" zu müssen.  Kannst du es mir bitte beibringen? André L. P. Souza /Fala/(discussão) 23:37, 28 July 2021 (UTC)
CamelCaseNick (talkcontribs)

Vermutlich bin sich so darauf gestoßen: Ich korrigiere einige Fehler von Google Knowledge Graph ID (P2671) (Database reports → Constraint violations → P2671) und Freebase ID (P646) (Database reports → Constraint violations → P646).

Worum geht es genau? Ist die Frage, wie man die korrekte ID findet? Es gibt mehrere Methoden:

  • Es gibt zum einen eine dedizierte Suche dafür: https://angryloki.github.io/mreid-resolver/
  • Zum anderen kann man direkt die Google-Suche nutzen:
    1. Man kann nach der gewünschten Entität suchen.
    2. Wenn man ein Knowledge panel vorliegen hat, kann man auf Teilen klicken und diese URL (beginnt mit g.co/kgs/) direkt aufrufen.
    3. In der URL ist der Parameter kgmid zu finden. Diese kann man entweder manuell herauskopieren oder man nutzt z.B. Wikidata for Firefox.
  • Falls es kein Teilen-Button gibt, kann man neben der Google Maps Customer ID (P3749) ggf. auch die Freebase- bzw. Google-Knowledge-graph-ID aus Google Maps fischen. (Näheres unter Property talk:P3749 § Bookmarklet)
  • Wenn man bei Google Trends ein Thema (und keinen Suchbegriff) sich ansieht, steht die ID im Parameter q in der URL.

Gerne auch nachfragen, falls etwas oben unklar ist. Oder war etwas anderes gemeint?

André L P Souza (talkcontribs)

CamelCaseNick danke für die erklärungen. Aber ich wollte auch lernen, wie man ein Schlüsselwort erstellt, um die Google-Suche umzuleiten, wie Sie es schon oft getan haben. Vielen Dank. André L. P. Souza /Fala/(discussão) 22:04, 1 August 2021 (UTC)

CamelCaseNick (talkcontribs)

Es tut mir leid. Ich verstehe nicht genau, was ich getan haben soll bzw. erstellt haben soll.

André L P Souza (talkcontribs)
André L P Souza (talkcontribs)
CamelCaseNick (talkcontribs)

Dort habe ich nur in Special:Diff/1396094787 die korrekte Google-Knowledge-Graph-ID hinzugefügt, die ich über eine der von mir oben beschrieben Methoden gefunden hatte. Wenn es funktioniert, ist das ja schön.