User talk:Samoasambia

Hei! Olisitko kiinnostunut osallistumaan Wikimedia Suomen järjestämään Wikidataan perehdyttävään projektiin. Pyydämme osallistujiksi wikipedistejä sekä organisaatioita, joiden kanssa opettelemme yhdessä, heidän aineistoillaan. Järjestämme lokakuun alussa Helsingissä työpajapäivän, jossa esitellään Wikidataa sekä suomeksi että englanniksi. Puhujat ja paikka varmistuvat vähitellen, päivämäärä on 2.10.2015. Valmistelemme myös online-opiskelupakettia suomeksi. Olisi hienoa saada mukaan Wikidataa aktiivisesti muokkaavia tilaisuuteen tai opastamaan/oppimaan online. Projektin työn alla olevat sivut ovat täällä: fi:Wikipedia:Wikiprojekti Avoin kulttuuridata hyötykäyttöön. Voit myös lähettää minulle sähköpostia käyttäjäsivuni kautta.

Toivottavasti tavataan!

Ystävällisesti, Susannaanas (talk) 08:59, 21 August 2015 (UTC)[reply]

Hei! Ei mielestäni ollut ihan oikein tämä yhdistely. Ylen merisää ei ole BBC:n merisää. Ne ovat kaksi eri ohjelmaa. Niiden tulkitseminen samaksi on samalla tavalla väärin kuin jos merkkaisimme fi:Suomen presidentti ja en:President of the United States samaa tarkoittaviksi. --Jmk (talk) 17:39, 30 December 2016 (UTC)[reply]

Hei! Olet oikeassa, en tullut ajatelleeksi tätä. De-, eo-, sv-wikien artikkelitkaan eivät kyllä tähän kohteeseen oikein sovi. Ne käsittelevät aihetta joka suomeksi olisi säätiedotus merenkulkijoille (tällä hetkellä ohjaussivu artikkeliin Merisää) eli yleisesti Merisää-ohjelmia radiossa ja sääennusteita merenkulkijoille meteorologiassa. Voisin ottaa seuraavaksi projektikseni fi-wikissä tuon ohjaussivun muokkaamisen artikkeliksi ja täällä Wikidatassa de-, eo-, ja sv-wikien artikkelien ja uuden fi-wikin artikkelin yhdistämisen uuteen kohteeseen. –Samoasambia ✎ 18:06, 30 December 2016 (UTC)[reply]

Hi, by this revert you removed hill (Q54050) to be a subclass of elevation (Q106589819). elevation (Q106589819) can be considered as superordinate term for mountains, hills, peaks etc... (see descriptions in other languages). Hence, in my opinion hill (Q54050) definitely should remain a subclass of elevation (Q106589819). Please advise. Kind regards, Arjoopy (talk) 14:20, 8 January 2024 (UTC)[reply]

Hi! Based on the descriptions and instance of (P31) value of elevation (Q106589819) I assumed the item is meant to be only a specific place type used by the Finnish National Land Survey (NLS). But I guess it could be turned into a more general term as you have described, or alternatively a new item could be created for that purpose? Maybe the original creator of the item User:Susannaanas could tell what was the purpose behind it? Kind regards, Samoasambia ✎ 14:36, 8 January 2024 (UTC)[reply]

Hi again, in fact there already was a seperate item for the "superordinate" term; which was later merged into the Finnish NLS item considering it describes the exact same thing. Back then I did not oppose this merge; hence I would support turning the item into the more general term. Kind regards, Arjoopy (talk) 12:24, 19 January 2024 (UTC)[reply]

Re https://www.wikidata.org/w/index.php?title=Q124396880&action=history

1. What was the intention?
2. How did you do it? [is there a tool for duplicating?]

CV213 (talk) 19:01, 2 February 2024 (UTC)[reply]

Hey! That was unintentional. I installed the "Duplicate item" user script and found out the hard way that there was no dialog before dublication. I made a request for deletion but ultimately a redirect pointing to the original item was created by an admin. Samoasambia ✎ 19:12, 2 February 2024 (UTC)[reply]

Thank you! See Special:Preferences#mw-prefsection-gadgets - there is a tool for merging. This one has a dialogue :-). But I think, I never changed there anything. Always merge in lower ID. CV213 (talk) 19:23, 2 February 2024 (UTC)[reply]

Yeah, I have been using the merge tool a lot. At the time I thought my accidental dublicate should have been deleted since having such item/redirect is pretty much useless, but anyways, merging it back was a good solution too. Samoasambia ✎ 22:39, 2 February 2024 (UTC)[reply]

Hei! Minusta tämä kylän muuttaminen Suomen entisen kunnan kyläksi esim. tässä vei asioita väärään suuntaan. Ravattila on edelleen kylä, mutta vain eri kunnassa. Kohteen existing village of a former municipality in Finland (Q21130185) järkevyydestä onkin viritelty keskustelua ainakin sivuilla Talk:Q21130185 ja Property talk:P131#Former administrative units ja luultavasti myös Wikipedian puolella jossain, mutta systemaattisesti tuota ei valitettavasti ole koskaan korjattu. Mielestäni tuo hoituu paremmin noin kuten Ravattilassa olikin eli esiintymä kohteesta kylä ja asettamalla useampi arvo ominaisuudelle located in the administrative territorial entity (P131). Tätä voi tosin olla vaikea automatisoidusti tehdä. Nyt kun katsoin, niin on myös kohde village in Finland (Q47254761), jota voisi tietysti käyttää tuon geneerisemmän kylän sijaan. –Kooma (talk) 10:11, 2 March 2024 (UTC)[reply]

Hei, kiitos kommentistasi! En ollut huomannutkaan noita aikaisempia keskusteluita. Tein alun perin nuo muutokset sillä perusteella, että kylien merkkaaminen Suomen entisten kuntien kyliksi vaikutti olevan yleinen käytäntö. Olen kyllä samaa mieltä siitä, että se on melko turhaa ja harhaanjohtavaa. Korjasin tänään kaikki fiwikin Suomen entisten kuntien kylät -luokassa olevat kylät, paitsi luovutetuilla alueilla olevat, esiintymiksi kohteista village in Finland (Q47254761). Täytyy vielä pohtia, mitä noille luovutetuilla alueilla oleville tekisi. Samoasambia ✎ 16:31, 16 March 2024 (UTC)[reply]

Hi Samoasambia, I've seen that you're doing a good job with anti-vandalism and are a trusted user, so I was wondering if you'd mind if I gave you rollbacker rights? Regards --Wüstenspringmaus _talk 16:20, 23 August 2024 (UTC)[reply]

@Wüstenspringmaus: That would be great, thanks! –Samoasambia ✎ 16:26, 23 August 2024 (UTC)[reply]

 Done thanks for your work here, please make sure you are familiar with our policy. --Wüstenspringmaus _talk 16:34, 23 August 2024 (UTC)[reply]

Hei! Huomasin, että olit muuttanut arvojen järjestystä muokkauksessasi. Onko tuohon jokin helpompi ja nopeampi tapa kuin vain kirjoittaa arvot uudelleen oikeaan järjestykseen? ––Apalsola ^{t • c} 14:16, 10 September 2024 (UTC)[reply]

@Apalsola: Kyllä vain! Asetuksista löytyy pienoisohjelma nimeltä Rearrange Values. Samoasambia ✎ 14:21, 10 September 2024 (UTC)[reply]

Kiitos! Tämä helpottaa monessa tilanteessa. Apalsola ^{t • c} 17:23, 10 September 2024 (UTC)[reply]

Hello, I noticed this edit. What makes you say that Nicole Schütz (Q21608521) and Nicole L. Meyer (Q6042063) are the same person? Korg (talk) 12:21, 17 September 2024 (UTC)[reply]

Hi Korg. Honestly I'm not sure what I was thinking there. They seem to be different persons. I probably saw the cywiki article about Nicole L. Meyer that was falsely linked to Nicole Schütz (Q21608521). Thanks for bringing up the issue, I will fix it. Samoasambia ✎ 12:43, 17 September 2024 (UTC)[reply]

Thank you for the correction! The mistake was made through these edits by Jason.nlw and Llywelyn2000: [1] [2]. Best regards, Korg (talk) 16:03, 17 September 2024 (UTC)[reply]

Hi, Just saw that you made the following change for the European Parliament and it led to cascading notifications for many European parties. Just wondering what this was about, as there was not much I could see -- just changing the order of logos? Thanks, Julius Schwarz (talk) 06:59, 24 September 2024 (UTC)[reply]

Hi Julius Schwarz, sorry if that caused a huge number of norifications for you. Someone on the talk page asked to add a logo without the text, and after doing so I changed it (with Rearrange Values gadget) to be in the first statement because it just looks a bit nicer in the user interface to have the preferred logo first (eventhough it doesn't make any difference how the data is used elsewhere). PS. if you're interested, please join Wikidata:Wikiproject European Union created by me earlier this year. Samoasambia ✎ 09:59, 24 September 2024 (UTC)[reply]

No worry, I was just curious as to what this was. And thanks for the project invite! Julius Schwarz (talk) 11:30, 24 September 2024 (UTC)[reply]

Thought you might be interested in what's going on with P642: I just (re-)launched a WikiProject for deprecating it, with new tools and better guidance. In case that's something you'd want to contribute any time to. Swpb (talk) 18:09, 3 October 2024 (UTC)[reply]

Thanks Swpb, that's exactly why I got the idea to ping you. I'm following the project with interest and maybe I will find some time to contribute. Samoasambia ✎ 18:34, 3 October 2024 (UTC)[reply]

Cool, thanks! Swpb (talk) 19:41, 3 October 2024 (UTC)[reply]

Hi, I noticed your P27 maintenance queries, very useful, thanks! But would it be possible to query something like

?item wdt:P17 ?value. (a property X, here P17)

?value (wdt:P31/(wdt:P279*)) wd:Q101352. (instead of Q101352, put most generic possible value that should obviously not be inside the property X)

I can imagine this kind of query could easily query out, so if you had a better idea to find misleading data for a property X ? Bouzinac ^{💬●✒️●💛} 12:11, 6 October 2024 (UTC)[reply]

Hi Bouzinac Do you mean like this? Or if you want the value of property X to be a instance of something you could do it like this. Samoasambia ✎ 17:10, 6 October 2024 (UTC)[reply]

Hum not sure. I wanted to find bad values for, in this case, the country (P17). For instance finding typo as in https://www.wikidata.org/w/index.php?title=Q126040428&oldid=2229413214#P27 Bouzinac ^{💬●✒️●💛} 20:14, 6 October 2024 (UTC)[reply]

Thanks again for your help with this bot task. How did you match files from the Common category or from the Wikidata search (which ever you used) with the Wikidata items that match a part of the Commons file title?

I'm looking to do something similar where the file-title would be used to identify the Wikidata item to add some file statement (including a qualifier). I have OpenRefine running and I could import a CSV file of the filenames. I could add an extra column for the sdc:M… if that helps and a column for the extracted title of the Wikipedia article title. I'd like to write to the Wikidata item of the Wikipedia article. How you did it would help. I would also use QuickStatements. Prototyperspective (talk) 15:49, 6 November 2024 (UTC)[reply]

Hi Prototyperspective! I listed all the files in the relevant category with Petscan ([3]), and since all the country export treemaps of 2019 had been uploaded at the same time they showed nicely together in the results list. I copy-pasted the file names into OpenRefine, duplicated the file name column with Split into several columns​ function, removed the repeating parts of the file names with Replace function which left me a column of country names, and finally I just reconciled the country column to Wikidata items, though it needed a bit manual intervention for some countries. Samoasambia ✎ 16:25, 6 November 2024 (UTC)[reply]

Thanks, I'll try that. I just reconciled the country column to Wikidata items How to reconcile with Wikidata item labels? (Or alternatively the label of the en Wikipedia article if you happen to know that) Prototyperspective (talk) 17:19, 6 November 2024 (UTC)[reply]

I just selected "against no particular" type and will mention this somewhere at the help page since matching to labels seems like a common way to use this tool.

• A problem with that is that it shows many items to reconcile with; it should choose the first of these by default and maybe if reconciling with title in specific or via another way that is already possible. Basically I'd like to set all items as matched via the first item it found.
• The main problem for now is I can't export or download the quickstatements. When I click Export Quick Statements file, it just opens an empty new tab and refreshes the page. When I log in and select Wikibase edits and let it do the Wikidata edits, no edits are made despite that some should be made according to the Preview. Prototyperspective (talk) 17:49, 6 November 2024 (UTC)[reply]

Sorry for bugging you, asked here instead now (incl a third problem) and found a workaround for the second problem by now: it still works with the previous version of openrefine. Prototyperspective (talk) 23:18, 6 November 2024 (UTC)[reply]

This is not correct. The Member of the European Parliament is Q3876996. See https://www.europarl.europa.eu/meps/de/256952/NIKOS_PAPPAS/home --Ephraim33 (talk) 16:38, 6 November 2024 (UTC)[reply]

@Ephraim33: Oh, thanks for pointing out. I was looking for items with references pointing to Members of the European Parliament (Q85301215) but who where not MEPs, so that felt suspicious. I reverted my edits and removed the false reference. Samoasambia ✎ 16:48, 6 November 2024 (UTC)[reply]

Hi Samoasambia, thank you for updating the URL match patterns for external identifier properties! To assist, I've created a page that groups the reference URLs that DifoolBot doesn't recognize. The list is ordered with the most unrecognized domains at the top.

For the bot to convert a reference URL into an external ID, the following conditions must be met:

• The property of the external ID must have one applicable 'stated in' value (P9073). Properties with zero or more than one value are ignored. For example, MNBAQ artist ID (P8336) and Christie's creator ID (P4200) on the list, do not have an applicable 'stated in' value. I don't have experience adding these values, so any help you could provide would be greatly appreciated.
• The URL match pattern (P8966) must match exactly; the bot essentially adds a $ to the regular expression.
• For some reason, the script does not understand "\p{L}" parameters in the regular expression, so these are skipped. Works now; I changed from module "re" to module "regex".
• If the regular expression matches but returns multiple groups that are disjoint, and the property has no URL match replacement value (P8967), those are ignored as well.

Difool (talk) 14:26, 12 November 2024 (UTC)[reply]

@Difool: Thanks, that is really helpful! I actually found the page from the bot's edit log a couple hours before you messaged me, and I added/edited match patterns for the most obvious cases. Btw, are capturing groups within the ID capturing group (like here) acceptable or should I make them non-capturing too? applicable 'stated in' value (P9073) needs a some type of website/list/database/work as a value, not an organization, and that often means a new item has to be created for that statement. Libraries are apparently a subclass of a "work" which peaces the constraint but it is not preferable. Samoasambia ✎ 18:21, 12 November 2024 (UTC)[reply]

Yes, capturing groups within the ID group are accepted. If the match returns multiple groups, the first group is used for the ID, as long as all other groups are either empty or contained within the first group (You can find the code here) For example, I changed this regular expression, because sv/en was the first group. Thanks, I'll go ahead and try adding P9073 values to those IDs. Difool (talk) 01:47, 13 November 2024 (UTC)[reply]

Great! Will the unrecognized URLs page get any updates? Samoasambia ✎ 21:56, 13 November 2024 (UTC)[reply]

I've run the script to update the page, but nothing changed. So, I increased the size to 150 items. The list remains unchanged because the bot tracks items it has modified and skips them if asked to modify again. I plan to update this functionality to allow changes after 30 days or so, and then I'll let it go through items with updated URL match replacement values. Difool (talk) 02:01, 15 November 2024 (UTC)[reply]

@Difool: Super great! I think I've now solved nearly all URLs on the list that have a property on Wikidata. I noticed that the theses.fr number is the same as National Thesis Number (France) (P5005) and I added a match pattern to it, but a few days later I realized that the bot would then replace the reference URLs with a wrong "stated in" value (SUDOC, instead of theses.fr). I should go through the bot edits from those days to revert any bad edits. Maybe one way to solve this mixup would be to create a separate URL match pattern property just for third-party formatter URL (P3303)? Samoasambia ✎ 21:41, 3 December 2024 (UTC)[reply]

Yes, I have thought about these theses.fr URLs too. I basically think if the content on both sites is identical, you can use the primary identifier and maybe keep the third-party URL. However, if only the identifier format is the same, but the content differs, you should ideally have separate PIDs, like GND ID (P227) and Deutsche Biographie (GND) ID (P7902). I'm not entirely sure, but I think the theses.fr and sudoc.abes.fr use the same metadata but present it a little bit different. Maybe @Epìdosis has some thoughts?

If you let me know how you'd like the statement to appear, I can have the bot correct the erroneous edits.

Another way to address this mixup is to use qualifiers, for example as shown here. Difool (talk) 02:16, 5 December 2024 (UTC)[reply]

In theory I also think the data in theses.fr and sudoc.abes.fr should also be the same, maybe formatted differently, but I am not fully sure; do you have one or two easy examples to compare? Thanks! Epìdosis 08:55, 5 December 2024 (UTC)[reply]

For example this code 1998IEPP0030: in https://theses.fr/1998IEPP0030 vs. https://www.sudoc.fr/049616749 which is the second link from National Thesis Number (France) (P5005)1998IEPP0030 - Difool (talk) 01:41, 6 December 2024 (UTC)[reply]

@Epìdosis - forgot to ping. Difool (talk) 01:42, 6 December 2024 (UTC)[reply]

I now see that it has been discussed at Wikidata:Property proposal/National Thesis Number. The SUDOC site was chosen as the formatter URL because, at that time, the theses.fr didn't include theses published before 1985. Difool (talk) 01:53, 6 December 2024 (UTC)[reply]

It seems a good reason, and I would add that the information in SUDOC seem much more complete than the data in theses.fr. Epìdosis 09:36, 6 December 2024 (UTC)[reply]

I agree, better to keep the third-party URLs if the URL is not just a redirect or an exact copy of the primary source (e.g. these VIAF pages are pure copies, so there's no need to keep those URLs). I tried to query for similar problematic cases and I deprecated URL match patterns on following properties to avoid any damage by the bot: IMDb ID (P345), UniProt protein ID (P352), ISRC (P1243), Steam application ID (P1733), EU Transparency Register ID (P2657), App Store app ID (P3861), Internet Game Database game ID (P5794), eAmbrosia ID (P9854), YouTube handle (P11245), YouTube handle (P11245).

What do you think about creating a new property of "third-party URL match pattern" to identify the cases when the bot should add an ID property but at the same time it should keep the reference URL? Basically all match patterns for third-party formatter URL (P3303) should be kept in the new property, and maybe with some qualifier (e.g. "has characteristic (P1552) = redirect (Q45403344) or mirror storage (Q654822)") you can signify that it is okay for the bot to remove a matching reference URL despite it being a third-party URL (like the VIAF example above). Samoasambia ✎ 15:12, 9 December 2024 (UTC)[reply]

Creating a new property for "third-party URL match pattern" is a good idea. It follows the distinction between formatter URL (P1630) and third-party formatter URL (P3303). Adding qualifiers for both properties to indicate that the reference URL should be kept or can be removed would be useful. Currently, I track whether the reference URL should be kept for each URL match pattern by myself. I check if the URL can provide additional information, like the name of a person, but I disregard language-specific URLs. Difool (talk) 00:09, 11 December 2024 (UTC)[reply]

I see, that's a lot of work. I'll try to write a property proposal next week. Samoasambia ✎ 16:05, 15 December 2024 (UTC)[reply]

I don't understand the logic you are applying to switch between Wikidata item of this property (P1629) and applicable 'stated in' value (P9073). Can you explain, and do you plan to change issued by (P2378) which I rely on in my queries? Vicarage (talk) 20:43, 12 November 2024 (UTC)[reply]

Thanks for the questions. Property Wikidata item of this property (P1629) should be used when there is an item that matches exactly with the property, so for external ID properties the P1629 items should be subclasses of identifier. Property applicable 'stated in' value (P9073) tells which item should be used as a value for stated in (P248) when the property is used in references. DifoolBot uses these P9073 values in generating proper references out of URLs (see discussion above). A concrete example would be NII article ID (P2409) that has Wikidata item of this property (P1629)NII article ID (Q118976435), applicable 'stated in' value (P9073)CiNii Articles (Q115921507) and issued by (P2378)National Institute of Informatics (Q4346622).

Previously P1629 was often used to note some sort of relationship between an item and a property but later more detailed properties like applicable 'stated in' value (P9073) and class of non-item property value (P10726) were created. DifoolBot needs P9073 values and that's why I made the changes to external ID properties today. I'm not planning to remove any issued by (P2378), they are fine as they are. Samoasambia ✎ 21:26, 12 November 2024 (UTC)[reply]

Hello @Samoasambia, I know that you are not an administrator, and I couldn't find one, but I needed to report this user for vandalism and self-promoting: User:Shangai2k2. Hope you can help out! Kutay (talk) 15:54, 4 December 2024 (UTC)[reply]

Hi, thanks for notifying! We have Administrators' noticeboard, and I just noticed someone had reported the user there a few minutes ago. Samoasambia ✎ 16:00, 4 December 2024 (UTC)[reply]

Thanks! Kutay (talk) 16:07, 4 December 2024 (UTC)[reply]

Logiikka siinä, että located in the administrative territorial entity (P131) arvona oli Suomenlinna (Q22681686) oli se, että P131 arvona olisi tarkin hallinnollinen alue. (jollainen Suomenlinnan-kaupunginosa on). Periaatteessa kai P131 arvoksi voi pistää kunnankin, mutta Helsingin tapauksessa se kattaa jo aika suuren määrän kohteita ja laajan maantieteellisen alueen niin olen itse pistänyt arvoiksi kaupunginosia kunnan sijaan. --Zache (talk) 15:32, 10 December 2024 (UTC)[reply]

Terve! Minusta Suomessa olevista kohteista P131:n arvona olisi parempi käyttää kuntaa, kun taas kaupunginosat, asuinalueet ym. tarkemmat jaot voisi mieluummin pistää ominaisuuteen location (P276). Kunnan/kaupunginosat on määritelty kunnan kaavoituksessa, mikä tekee niistää periaatteessa hallinnollisen alueyksikön, mutta tosiasiassa niiden hallinnollinen merkitys on yleensä todella pieni, lähinnä tontti- ja korttelinumerointia sekä tilastointia. Oliko tuosta äskeisestä muokkauserästäni haittaa Wikipedian tietolaatikkoihin tai muihin mallineisiin? Eikö ne näytä P276:n arvoa? Samoasambia ✎ 15:50, 10 December 2024 (UTC)[reply]

No siis Wikidataa käytetään muuallakin kuin tietolaatikoissa. Esimerkiksi käytän sitä runsaasti erillaisissa SPARQL-kyselyissä ja listojen teossa. Noin rakenteellisessa mielessä, niin kaupunginosien tarkkuudella asettaminen mahdollistaa sen, että kuntaliitoksien jälkeen P131 arvoissa säilyy missä alueellisessa keskuksessa jokin paikka on (koska yleensä vanhat kunnat säilyvät vähintään kaupunginosina).

• Esimerkiksi Nagu (Q203512) on merkittävästi eriasia kuin Korpo (Q305440), niin maantieteellisesti kuin kulttuurihistoriallisesti. Vastaavasti vaikka Säynätsalo (Q1511769) on eri asia kuin Jyväskylä (Q134620). Nämä jakautuvat edelleen pienempiin alueisiin.
• Säynätsalo jakautuu esimerkiksi seuraaviin alueisiin. Muuratsalo (Q954776), Lehtissaari (Q67201908), Säynätsalo (Q11895773) ja Kinkovuori (Q119158102). Periaatteessa se on makuasia pistääkö nuo pienemmät alueet P276 arvoiksi vai P131, mutta esimerkiksi Säynätsalon suuralue jonka nämä kokonaisuutena muodostavat (ja vanha Säynätsalon kunta) on selkeä kokonaisuus joka vähintäänkin kuuluisi Jyväskylästä eroava P131 arvo.
• Jos tätä vertaa isompiin kuntiin, niin Helsingin kaupunginosat ovat väkimäärällisesti isompia kuin merkittävä osa Suomen kunnista ja myös alueilla olevien wikidata-kohteiden määrillä. Esimerkiksi Helsingissä on 12k maantieteellistä wikidata-kohdetta ja todennäköisesti määrä tuosta moninkertaistuu, niin ihan datan käsittelyn kannalta minusta ne kannattaa jakaa pienempiin alueisiin kuin ryhmitellä ne kunnan tasolle kaikki.

Tuo on siis se miten itse olen tuota ajatellut. Mutta tämä on varmaan asia mistä kannattaa kysyä muidenkin mielipiteitä. --Zache (talk) 08:09, 11 December 2024 (UTC)[reply]