User talk:CamelCaseNick

talk

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

Why?

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.

Yes, exactly, it is based on that. I have removed it in Special:Diff/1508501224.

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

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)

Ja, das kann ich. Wie ist es mit folgender: https://w.wiki/veU? Das sind die 69 Stolpersteine ohne stolpersteine-hamburg.de Stolperstein identifier (P8804) mit Label, Stadtteillabel und in der letzten Spalte, ob sie ein replaced by (P1366) oder dissolved, abolished or demolished date (P576) haben.

Oder doch besser: https://w.wiki/veW. (um deprecated statements mitzunehmen) Damit sind es 59. (Ansonsten sollten auch die Liste unter User:CamelCaseNick/Stolpersteine/Hamburg aktuell sein.)

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.

Ich schau mir das zeitnah an.

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

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.

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"?

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

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

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.

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)

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?

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)

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

CamelCaseNick zum Beispiel in Q106191770, dort in der Beschreibung fügen Sie das Schlüsselwort in das Lexem "Google Information Panel Identifier" ein. André L. P. Souza /Fala/(discussão) 22:13, 1 August 2021 (UTC)

CamelCaseNick es hat funktioniert. habe ich erreicht. Es war wirklich Mozilla. Danke für die Hilfe. André L. P. Souza /Fala/(discussão) 23:03, 1 August 2021 (UTC)

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.

Keine Ahnung, das war ein Bedienfehler. Danke für den Revert. Da fehlt noch eine Adresse zwischen 1911 und 1931, die Geschichte steht im WP-Artikel. Es gibt auch WD-Objekte zu den alten Gebäuden. --Minderbinder (talk) 13:46, 8 July 2021 (UTC)

Danke für die Items. Die sind gerade in Abfragen aufgetaucht mit denen ich meine Beobachtungsliste automatisch befülle. Ja, der Standort Duwockskamp fehlt. (Schade, dass vor jenem Gebäude gerade die Baustelle ist. Ich werde wohl mal ein Foto machen, wenn die weg ist.)

Also so sehr stört die Baustelle nicht, ich war am Wochenede da: https://commons.wikimedia.org/wiki/Category:Duwockskamp_1 --Minderbinder (talk) 14:03, 8 July 2021 (UTC)

Die habe ich weiter westlich in Erinnerung.

Hi, I rerverted your edition on Q798747 because cantons are no administrative unities in Luxembourg. B.r. --~~~~

Ah, yeah. Then instead of removing them, it is better to move those statements to location (P276). I've done that now on Mondorf-les-Bains (Q798747).

Hi,

I have a question to your edit on "Potsdam-Rehbrücke station" (Q55630330): Your have removed from the adjacent station the 'connecting service' and the 'towards' statement. Can you please tell me the reason for this? I have added all Stations to the RE7 and also the termination points. It is useful if you put this information with a query to a map. So could you please explain this change or undo your edits?

--~~~~

It is meant for direct physical adjacency via rail, and not via connection services. In a lot of countries Wikidata those are properly added, sadly in Germany a lot of railway line (Q728937) get mixed with services. So it is not an adjacent station (P197), because the RE7 does not have every station of Berlin-Blankenheim railway (Q323156)    as a halt. towards (P5051) of course can be added and should be either Berlin-Charlottenburg station (Q702596) or Blankenheim Trennungsbf.

Hello, I noticed you changed items groups of stolpersteine for items for single ones. My opinion is - you should create new items and use has part (P527) for linking singles with group. And at least, when you duplicated it, you should change images for single stolperstein, all exists in c:Category:Stolpersteine_in_České_Budějovice. JAn Dudík (talk) 08:51, 16 April 2021 (UTC)

From time to time I check whether instance of (P31) stumbling stone (Q26703203) are only used for single stolpersteine. I usually kept the group items, but not yesterday. I now have restored them and should look like they usually do and have swapped out the images for those depicting the individual ones.

Danke für die umfangreichen Korrekturen bei den falsch gematchten Memorial Book Bundesarchiv ID (P7571)-Daten! Kann ich dich dabei unterstützen oder ist die Arbeit schon erledigt?

Ich verwende Heuristiken, wo etwas schiefgegangen sein könnte:

• die Constraint reports für unique value
• den Report für identical birth and death dates
• eine Abfrage für Personen mit zwei abweichenden Geburts- und Sterbedaten mit Memorial Book Bundesarchiv ID (P7571) als Fundstelle

Ansonsten müsste man wahrscheinlich Contributions alle durchgehen? Diese Tools/Abfragen geben aber auch nicht mehr so viele Fehler aus. Aber es ist so schwierig zu sagen, ob sich das Thema dem Ende neigt oder ich einfach nicht richtig suche.