User talk:Alicia Fagerving (WMSE)

From Wikidata
Jump to navigation Jump to search

Copied from User talk:AliciaFagervingWMSE-bot[edit]

SE description on Långe Jan (Q712299)[edit]

Hi AliciaFagervingWMSE, I don't read Swedish, but it seems that [1] isn't the ideal description for this item. You might want to check existing P31 before adding descriptions. --
--- Jura 15:45, 12 March 2017 (UTC)

@Jura1:. Looks like Långe Jan (Q712299) is many things all at once. The way that the import is built up it would never overwrite an existing description but in this case where none existed it added the only one which it was aware of. /André Costa (WMSE) (talk) 10:27, 6 September 2017 (UTC)

Add disambiguation[edit]

@Alicia Fagerving (WMSE):Hi, you have added the disambiguation Q10658318 in 127 item. Can you fix the problem? Replace with the correct item (Q10658319 or Q10658320), or if isn't possible delete it. ps. You use a user name with WMSE in the name but I don't think that your edit are connected to the you job in Wikimedia Sverige, maybe is better change the name --ValterVB (talk) 17:57, 17 April 2017 (UTC)

Thank you! I have fixed the links. --Alicia Fagerving (WMSE) (talk) 07:05, 18 April 2017 (UTC)

Another case: can you fix all this kind of edit? Ljungby socken (Q10568332) is a disambiguation item, you have added it in in 137 item. Thanks --ValterVB (talk) 18:13, 26 May 2017 (UTC)

Thank you, I've replaced them with the correct item. --Alicia Fagerving (WMSE) (talk) 13:56, 29 May 2017 (UTC)

Another case: can you fix all this kind of edit? Stenkiste (Q16296988) is a disambiguation item, you have added it in in 159 item. Thanks --ValterVB (talk) 17:32, 4 June 2017 (UTC)

As all of the remaining ones have been replaced by cist (Q1399576). The already removed ones cannot be fixed without re-runnign the bot. As an aside we are adding a mechanism to the bot to ensure disambiguation items are not added in the future. /André Costa (WMSE) (talk) 10:50, 6 September 2017 (UTC)

Mixing building and people[edit]

Your bot mixed some peoples as buildings and added to them heritage statuses. (ex:Axel Hamberg (Q4830282)) --Fralambert (talk) 18:31, 23 June 2017 (UTC)

Hi. This was due to erroneous mappings done on the source Wikipedia. We are adding mechanisms to the bot to blacklist the most obvious cases (such as people). Due to the nature of the imports it's sadly not possible to construct whitelists of allowed P31 values. /André Costa (WMSE) (talk) 11:05, 6 September 2017 (UTC)


Moved to Wikidata_talk:WikiProject_WLM/Mapping_tables/mt_(de)#Malta. /André Costa (WMSE) (talk) 11:41, 22 January 2018 (UTC)


Hi, I saw only today your imports of area (P2046) for national parks. It's nice to have these well-sourced data, but that way the bot did it, it's not really obvious for the client software which value refers to the area of whole park. Here for instance, a Wikipedia template or a sparql query would by default return four different areas for the park. We can prevent that by adding rank: 'preferred' to the area of the whole park as of today. There might be cases where the area has changed over time. In that case, historical values for the whole park should not have rank: 'preferred'. So maybe also add applies to part (P518)  totality (Q2445511) or whatever item can be used to make it clear the value refers to the whole park ? Would your bot be able to fix it ? --Zolo (talk) 12:58, 2 September 2017 (UTC)

@Zolo: I would assume that standard behaviour for consumption )in e.g. Wikiepedia templates) would be to select the item without a applies to part (P518) as default. This is similar to how many properties gets resolved using start/end dates rather than relying on rank. The problem in our case with adding rank: 'preferred' is that there may already be an area (P2046) statement on the item and we cannot say that the imported value should be preferred to that./André Costa (WMSE) (talk) 11:03, 6 September 2017 (UTC)
@André Costa (WMSE): I think it would be nice that a even simple template can return the correct and most relevant value when looking for an area without bothering about a long, and potentially evolving, list of qualifiers (start time (P580), end time (P582), point in time (P585), start period (P3415), end period (P3416), exception to constraint (P2303), including (P1012), applies to part (P518)...). And in practice, many templates seem to rely on ranks rather than date. Same for sparql queries (potentially done by outsider not very knowledgeable about Wikidata usage).
I don't think there are many values in the items that should get precedence over those added by the bot. We can probably sparql-query items that have more than one area for the present date without P518 and check them all by hand.--Zolo (talk) 16:01, 6 September 2017 (UTC)
@Zolo: True. Currently the bot framework that we are using doesn't deal with ranks at all (since I've never had to set them). Adding such functionality would be of interest for future imports of similar data. For these areas I believe a one-off script run is probably the solution. Due to deadlines in other projects I cannot commit to a date by which we will have had time to do it though. /André Costa (WMSE) (talk) 13:53, 8 September 2017 (UTC)

Preferred rank[edit]

I see that you import birth/death dates e.g. 1935. In Wikidata this record has an unsourced value of 6 maj 1935. As we have templates that imports dates from Wikidata to Wikipedia I think its good if we had a best practices

  1. ) A date with lower precision gets a lower rank
  2. ) A date without a source get a lower rank

Or should that logic be in a template like sv:Mall:Faktamall_biografi_WD? Is there any best practise? Any comments/thoughts from the Template designers: @Larske:@Innocent_bystander: - Salgo60 (talk) 18:03, 20 October 2017 (UTC)

There are functions in Module:Wikidata2 that allow you to prefer sourced claims, and there are functions who take the first claim no matter of how well sourced it is. What you get depend on how you spell the question to the module. The main question here is probably how we should do when there are statements that contradicts the constraints. human (Q5)'s are only born once... -- Innocent bystander (talk) 06:47, 21 October 2017 (UTC)
I added sources with Swedish Film Database (Q1139587) as stated in (P248) and yesterdays date as retrieved (P813) to the more precise instances of date of birth (P569) and date of death (P570) in the example Albion Örtrengen (Q6257418). But I wonder if there is a need to also add reference URL (P854) in this case when there is a SFDb person ID (P2168) (that I also added) from which the ref-url is implicitly given. For the sources with less precision, reference URL (P854) has been entered although it is implicitly given via the Musikverket person ID (P4357) for the object. I guess it is much easier to handle possible site reorganization (i.e. URL changes) within Svensk Filmdatabas if we keep the URL-details, except the ID part, in the formatter URL (P1630) where it belongs instead of spreading it "all over the place". Is this in line with some policy?
@Innocent_bystander: Is it within the present scope of the Wikidata(2) module to dig out these URL's, from the SFDb person ID (P2168) (or other identifiers) via its formatter URL (P1630)? It does not seem to be implemented for birth and death dates in the "Faktamall biografi WD" template. --Larske (talk) 08:13, 21 October 2017 (UTC)
@Larske: From what I know, this is implemented in Module:Cite, and that module does not work differently depending on the calls in the template. -- Innocent bystander (talk) 08:44, 21 October 2017 (UTC)
@Innocent_bystander: We are maybe talking about different things. When I insert the "Faktamall biografi WD" template in the Albion Örtengren article in svwp, I get the reference notes for Birth and Death dates in the infobox, but the links just lead to the svwp article on Svensk Filmdatabas, not to this external URL where I can read about the birth and death dates for Albion Örtengren although all information needed for that is stored within the Wikidata object. --Larske (talk) 12:14, 21 October 2017 (UTC)
@Larske: All information stored is: "P248:Q1139587"+"retrieved date:somedate". Module:Cite can thereafter collect information from Q1139587, but that item lacks essential data to give you more than the name of the database. Since the item was linked to an article on svwiki, it could also provide a link to an article about the database. -- Innocent bystander (talk) 13:09, 21 October 2017 (UTC)
I don't see that there is any "lack of essential data" to get the full external URL from what is stored in Wikidata. Swedish Film Database (Q1139587) doesn't just have a label (name) and a site link to svwp, it also has the SFDb person ID (P2168) among its Wikidata property (P1687). The object Albion Örtrengen (Q6257418) also has a SFDb person ID (P2168) with the value 58540. Put that value into the formatter URL (P1630) of SFDb person ID (P2168), replacing the $1, and you have the wanted result. --Larske (talk) 14:18, 21 October 2017 (UTC)
But are there guarantees that this information is gathered from exactly that id? Could it not have been collected from the id about his wife, or any of the plays he has performed in? What should we do if there is more than one external id in the page about the person or if the external ids has been changed in the history of the item. I'm sorry, this sounds far to fragile to be reliable. -- Innocent bystander (talk) 14:54, 21 October 2017 (UTC)
Maybe no guarantees, but it would anyway be good if the ref-url qualifier could be stated indirectly in some way so that only the values "P2168" (or other property if relevant) and the "58540" (or "the wifes ID" if that is "the relevant ID") is stored in the object for a person and the real reference URL is formed by combining the formatter URL (P1630), the one that is valid for the moment, of SFDb person ID (P2168) with "the relevant ID". Otherwise much of the value of having the formatter URL (P1630) property at all is lost if you ask me. --Larske (talk) 15:16, 21 October 2017 (UTC)
I would love to see external-id-properties to be used in sources. From the WPs point of view, it would be the most valuable way to use them. (From a database-perspective they have other values.) If I remember correctly, Module:Wikidata2/Modul:Cite is already prepared for the use of them in sources. A drawback is that they are maybe not always nicely formatted. -- Innocent bystander (talk) 15:31, 21 October 2017 (UTC)
@Larske: If Statistical database, Land area by localities, population and population density per sq. km. Every fifth year 1960 - 2015 (Q27579148) would be connected to Swedish urban area code (P775) in this way (we have such properties outside of Sweden), we would probably lose the connection with the data when the 2018-report is published. Not for all items, but for those who have been dissolved. The alternative would be that we get a new P775-property every three years. -- Innocent bystander (talk) 06:16, 22 October 2017 (UTC)
@Innocent_bystander: Please explain in detail, preferably with real data in real objects as an example, what you mean by "in this way" and "we have such properties outside of Sweden", if you want me to understand what you are trying to say.
Maybe better to continue this discussion in Swedish on the sv:Wikipediadiskussion:Projekt_geografi/Tätorter_2015 page. --Larske (talk) 06:34, 22 October 2017 (UTC)
Jag minns inte nu exakt vilken property jag tänker på. Jag har varit insnöad på Småorter alldeles för länge. Men jag minns att vi har liknande propertys för USA. Det går att koppla ihop dessa property-ids med US census bureau och få en länk till senaste folkräkningen. Problemet är att städer, citys, towns, Census districts, mfl ändras från en folkräkning till nästa. Det är en liten andel, men ändringar sker ändock. Nyligen har hela USA bytt system med koder. Det vi har på svwiki är efter vad jag förstått föråldrat. En id blir ibland ibland gammal och byts ut. Tusentals ids om proteiner har tagits bort eller ändrats efter att det visat sig vara dubbletter. Skulle vi byggt länkar på det viset i berörda protein-artiklar, skulle länken bli fel. I Sverige har SCB fått hjärnsläpp och gett Sollentuna den tätortskod som Upplands Väsby hade tidigare. Samma sak kan hända med vilken id som helst, och händer hela tiden. Att bygga en kedja från P248->Qxxx->Pyyy->idzzz->P1630->httq:// blir en väldigt skör konstruktion. Det finns så många ställen i denna kedja som inte är stabil över tiden att jag inte tror på idéen. Om Wikidata hade varit en privat konstruktion, så helt ok. Men här kan vemsomhelst gå in i de här objekten och göra ändringar som de inte har en aning om hur det påverkar oss på Wikipedia. Det inte bara kan ske, det sker också. Det flesta problemen beror inte på illvilja, utan på okunskap och brister i kommunikationen, och det inte bara från newbies... -- Innocent bystander (talk) 07:39, 22 October 2017 (UTC)
>>But are there guarantees that this information is gathered from exactly that id?
Working with SBL Dictionary of Swedish National Biography (P3217) that lacks good structure you normally find the father/child relation on the child ==> that the ref for the son property of the father will be another record in SBL ==> I also add that SBL record in the ref section... - Salgo60 (talk) 07:04, 22 October 2017 (UTC)
Jag flyttar första frågan till Malldiskussion:Faktamall_biografi_WD Födelsedatum endast med år - Salgo60 (talk) 16:08, 22 October 2017 (UTC)

Wrong source[edit]

Hello! Please have a look at this item Q20516656#P31. You added "" as the source. I think it should be "", Is there any reason for this or I we can fix it?--ԱշոտՏՆՂ (talk) 06:53, 23 November 2017 (UTC)

@ԱշոտՏՆՂ: The first link is the source for the imported information. Since the info was imported via Wikipedia we cannot verify that it has not been changed since it was first imported. The second link is added as a qualifier on the ID property though. See Q20516656#P3170. /André Costa (WMSE) (talk) 15:55, 1 December 2017 (UTC)

Historic municipality item[edit]

Hi André Costa, please note [2]. Not sure if it's a general problem.
--- Jura 12:55, 13 December 2017 (UTC)

Thanks for spotting this. These should indeed all be replaced (but keep the reference). I've added a task for this. /André Costa (WMSE) (talk) 20:28, 15 February 2018 (UTC)

Non-response on bot problems and talk page mixup[edit]

Hello Bot! Users try to contact your master on this link (and seemingly others as well as th eone quoted) but they get no reply for months. I was about to request a block on the bot but realised that there may be other talk pages around.

  1. please respond to the problem above (and if you're Andre you've got an email from me either)
  2. please sort out possible talk pages, and hard or soft redirect them to somewhere you notice the questions and problems and respond accordingly

Until then I hold up the block request, since it wouldn't really help the resolution of the problem about bad imports. Thanks! --grin 14:03, 29 March 2018 (UTC)

I've sorted out the redirect. Other than the #Wrong edits section below I don't believe there should be any other issues which had not been responded to. /André Costa (WMSE) (talk) 15:11, 4 April 2018 (UTC)


Programmerare!!! Varför är det jag som sitter och hackar med moduler när vi uppenbarligen har proffs?! Face-smile.svg -- Innocent bystander (talk) 11:58, 13 January 2017 (UTC)

@Innocent bystander: För att det finns tillräckligt med data runtomkring oss så att det räcker till alla... Och blir över ;) --Alicia Fagerving (WMSE) (talk) 12:07, 13 January 2017 (UTC)
Jovars, det känns som jag inte kommer att bli klar med uppdateringen av småorterna tills nästa publicering 2018. Mycket kan förstås göras med robotar och script, men identifiera vilken artikel/objekt som hör till vilken post på SCB måste i princip göras för hand. -- Innocent bystander (talk) 12:14, 13 January 2017 (UTC)
@Innocent bystander: Förstår att namngivningen inte alltid stämmer överens mellan wikipedia och scb. Hur gör du när du lägger till befolknings/arealuppgifter? Kan den processen förbättras på något sätt? --Alicia Fagerving (WMSE) (talk) 13:31, 13 January 2017 (UTC)
Jag jobbar främst nu med småortsrapporten för 2010, för att få in Småortskoden på rätt ställe överallt. Jag har kanske gjort det i 2/3 av alla fält i SCB-rapporten. Det är lätt att göra fel, så jag vill inte hålla på länge åt gången med det, för att inte bli för trött och tappa koncentrationen. Därför hoppar jag också mellan landsdelarna. Du anar inte hur tröttsamt det kan vara att ta den ena posten om en lite by I Falu kommun efter den andra. Då blir det mer fart och fläkt om man får åka runt lite.
Då lägger jag in alla data jag hittar hos SCB, istället för att vänta på en robot som kanske aldrig kommer.
User:Pajn har redan gjort en körning med alla folkmängd- och area-data från 1995-2010. Men hn lade inte in data I de objekt som inte hade P776 (det har tillkommit många sedan dess) och inte i de objekt som krånglade till inläggningen för hn. Fanns det redan folkmängd eller area angiven, så hoppade hn dessa objekt.
Några saker som krånglar till det, är att gammal data kan ha "preffered rank". Då behöver man åtminstone ändra denna till "normal rank" för att datan ska visa sig på WP.
Orter som ligger I mer än en kommun, kan vara röriga, det måste vi lösa för hand.
Artiklar som handlar om mer än en SCB-ort blir lätt stökiga. Ta Utansjö (Q28049555) som exempel. "Import" från WP funkar inte i fall som dessa. Det funkar dåligt att ha data för mer än en SCB-post I samma objekt. Min manuella genomgång är också för att identifiera sådana artiklar.
Vill du fortsätta Pajn's arbete, så får du gärna göra det! Det finns många orter som ännu inte fått P776, isht I 2015-rapporten. Men vi kan inte vänta på det!
En sak som inte vore fel om vi kunde lösa, är inlägg av determination method (P459) som qualifier till alla folkmängdsdata vi har. Problemet har varit att ingen vetat vad man ska lägga in här. Men jag är nu böjd att tro att det bästa vore att lägga in "tätort i Sverige" respektive "småort" I denna qualifier. Bara lägga in "folkbokföring" är inte tillräckligt för att beskriva hur SCB-orter avgränsas. Att metoden ändrats varje gång sedan 1890, är nog inget vi kan hålla på och strula med. Man skulle kunna använda sig av "källan" för att avgöra vilken qualifier som ska användas var. Enda undantaget är tätortsrapporter 1960, som också beskriver föregångaren till våra dagars småorter. Men där kan man se vilket värdet är (<200), och göra undantag för dessa. -- Innocent bystander (talk) 14:01, 13 January 2017 (UTC)
Jag får ta mig en titt på allt detta, nu har jag gjort en snabb sökning: objekt med småortskod utan befolkningsmängd (230ish) eller utan area (280ish). --Alicia Fagerving (WMSE) (talk) 14:19, 13 January 2017 (UTC)
@Innocent bystander: Dessa kan man alltså köra med bot, om småortskoden är korrekt. Hade jag varit du så skulle jag nu satsa på att lägga till P776 där det saknas, och kanske strunta i siffrorna. Har inte sett på scb's rapporter än, med xls borde inte vara så svårt att extrahera data från. --Alicia Fagerving (WMSE) (talk) 14:30, 13 January 2017 (UTC)
Mja, bara lägga in där det inte finns något P1082 ger inte så mycket. Det finns de som var tätorter 1960 och har folkmängd från då, men inget från tiden när de var småort från 1990 och framåt.
Jag vill inte bara lägga in P776, jag vill även lägga in P31 och P131 med hyfsade källor. Lägga in startdatum och slutdatum för P31:småort/tätort ser jag som viktigt, något som inte heller är lätt med robot, särskilt som vissa SCB-rapporter inte är digitaliserade. -- Innocent bystander (talk) 15:24, 13 January 2017 (UTC)


Ser du experimenterar med RAÄ-nummer. Det finns en disk på Property talk:P1262 du bör vara medveten om. Frågan där är om det ska användas som qualifier till Swedish Open Cultural Heritage URI (P1260). Det är möjligt, att det inte är en optimal lösning, så det kan tas upp för diskussion igen! Ett problem med att inte ha denna som qualifier, är att det kan finnas flera P1262-claims och flera P1260-claims, utan att semantiskt visa vilken som hör till vilken. -- Innocent bystander (talk) 10:49, 20 January 2017 (UTC)

@Innocent bystander, André Costa (WMSE): Ja, det är nog bra att reda ut innan den stora importen. Just nu ser det ut som att P1262 används "rakt av" i de allra flesta fallen, men så är det bara ~1000 items mot de 145 000 som finns i databasen. --Alicia Fagerving (WMSE) (talk) 12:53, 20 January 2017 (UTC)
phab:T155825 --Alicia Fagerving (WMSE) (talk) 12:57, 20 January 2017 (UTC)

Import of monuments from Poland[edit]

Cześć, I'm interested in status of migrating database of Polish monuments to Wikidata. Is there something I can help? Thanks to @André Costa (WMSE) (kudos!) I've found Wikidata:WikiProject WLM/Mapping tables/pl (pl) and it mostly looks good, it's possible to extract some dates from `nazwa` in easy scenarios. I would love to see test run and/or source code for bot. Cheers, Yarl (talk) 11:07, 17 February 2017 (UTC)

Hello @Yarl:!
It's great that you'd like to help us -- it's been my impression that the Polish dataset is one of the largest and most detailed in the database, so it's definitely worth working on.
As for the source code, it's available here. The Polish part is only an outline right now, but I've had a look at the data in order to identify possible difficulties.
Here are questions that come to my mind right away:
Thank you for bringing my attention to the nazwa field -- it does look like many of the items contain dates of some sort. I assume that an item like klasztor ss. Służebniczek Niepokalanego Poczęcia NMP, 1890 would be an easy case, where 1890 can be used as inception (P571). If we look at this list as an example, there are some items with multiple dates:
* Szkoła Realna, ob. liceum salezjanów, 1913-1916 -- does this represent the beginning and the end of the building works? My interpretation is that 1916 can be used as the year in which the building was completed.
* dwór, 1920-1930, 1984 -- what do the multiple dates mean in this context?
Does the id/registrant_url (such as 600985) mean anything?
As for numer, it's my understanding that in order to save it as a Polish cultural heritage register number (P3424), it should be converted like 329/A z 28.12.1993 (WUOZ - A/483) -> 329/A. The date can then be used as a point in time (P585) qualifier (it's the date when the object was entered into the heritage register, right?). But some objects have multiple entries in this field, for example A/1027 z 15.09.1971 i z 16.02.1994 or A/151/67 z 27.03.1935, A/139/425 z 28.10.1958. I think I've also seen examples using a semicolon. Do you have any idea how these should be interpreted? I imagine the earliest date would be the most important one...
Finally, is there some official government website or publication that contains the entirety of the register?
Thank you for your help, it's really apprieciated -- oh, and keep in mind that this is by no means urgent. Miłego dnia :) --Alicia Fagerving (WMSE) (talk) 11:54, 17 February 2017 (UTC)
And some thoughts about the administrative division fields, especially gmina since that's the lowest level division. In the vast majority of cases, the value looks like gmina Pawłów, i.e. with the actual word gmina in it, which is easy to map to Gmina Pawłów (Q554621) by going through the corresponding plwiki article. But there's also a number of items with single-word values, like Sieradz. Polish Wikipedia has an article on Sieradz, which is a city, and one on Gmina Sieradz, which is the administrative unit the city belongs to. It seems most logical to use the latter as located in the administrative territorial entity (P131), as, if I understand w:Administrative divisions of Poland correctly, a gmina is the lowest unit of the administrative division. I have found several examples like this where the content of the gmina field does not contain the actual word gmina. Is there a particular reason for this, and do you have any idea how this could be interpreted? --Alicia Fagerving (WMSE) (talk) 12:59, 17 February 2017 (UTC)

I will add remarks here, we can also move further discussion there for easier documentation.

Regarding last one: you don't need to care about gminas, and generally administrative divisions, at all, because we won't add them. All we care is miejscowosc which will end in located in the administrative territorial entity (P131). I'm pretty sure this is the correct way (that's how I cleaned up all current monuments entries in Wikidata), take a look at data imported in England. Yarl (talk) 17:09, 18 February 2017 (UTC)

Hi Alicia, two quick questions:

  1. I'm wondering how do you plan to upload monuments? By number in database or gmina by gmina?
  2. Do you believe it will be possible to start test upload by early March?

Yarl ✉️️  17:51, 26 February 2017 (UTC)



I noticed that your bot added this self-refering claim (Special:Diff/465511428):

< Surahammar (Q33798) View with Reasonator View with SQID > location (P276) View with SQID < Surahammar (Q33798) View with Reasonator View with SQID >

This seems to make no sens so I reverted it. Could you take a look and check it please? (to other edits too, Special:Diff/465511396 seems a bit odd).

Cdlt, VIGNERON (talk) 12:26, 26 April 2017 (UTC)

And apparently, there is a similar problem on this 23 items : Österbybruk (Q298344), Stavsjö (Q528450), Forsmark (Q1281247), Lövstabruk (Q1966481), Virsbo (Q2242516), Karmansbo (Q2267478), Gysinge (Q2339533), Söderfors (Q2393606), Granbergsdal (Q2483762), Klenshyttan (Q2527218), Ramnäs (Q2662195), Karlholmsbruk (Q2702448), Åkerby (Q2719470), Skultuna (Q3051144), Gravendal (Q3888211), Ekeby, Vänge, Uppsala (Q10480518), Q10512615, Huddunge (Q10526845), Q10527173, Q10543808, Q10572701, Norn iron works (Q10602389), and Q10651057.
Hi @VIGNERON:. It looks like there were many bad manual mappings in this dataset, i.e. links in lists that have later gotten redirected. Thanks for reverting. We'll investigate if it is possible to isolate these cases and import them as new items instead. /André Costa (WMSE) (talk) 11:47, 6 September 2017 (UTC)
@André Costa (WMSE): thank you for the explanation and good luck for fixing it (I know how complicated it can be). There is still some self-link :
SELECT ?item ?itemLabel ?coord WHERE {
  ?item wdt:P276 ?item ; wdt:P625 ?coord .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
Try it!
Cdlt, VIGNERON (talk) 13:18, 6 September 2017 (UTC)
Thanks. What I'll wish for this Christmas is better tools for splitting items =) /André Costa (WMSE) (talk) 14:19, 8 September 2017 (UTC)

bot hint[edit]

Hi Alica, regarding this edit of your bot: [3], you are using nachgewiesen in: Monuments database as a source for your statement, but this is just generated from wikipedia sources and not a reliable source for anything. Please use the orginal external sources in this case. BTW: the statement is wrong, it is not a Burg / Castle, but an alpine hut. regards --Herzi Pinki (talk) 07:39, 25 August 2017 (UTC)

Hi @Herzi Pinki:. The source statement should be considered akin to imported from Wikimedia project (P143)  English Wikipedia (Q328). I.e. help for someone who wants to know where the information comes from but not a source per se. Note that WD:BOT rules require statements be sourced and recommends this way for data that doesn't come straight from a source.
The burg matching seems to be related to a bug in the code. We'll look into how common this was. /André Costa (WMSE) (talk) 11:20, 6 September 2017 (UTC)

monument id should not be part of description[edit]

moved to Wikidata_talk:WikiProject_WLM/Mapping_tables/at_(de) --Herzi Pinki (talk) 19:34, 6 September 2017 (UTC)

Koordinater på svenska kyrkobyggnader[edit]

@André Costa (WMSE): Har du/ni någon möjlighet att se över koordinaterna på svenska kyrkobyggnader? I Q10509726 hittade jag nu koordinater importerade i Wikidatas ungdom med "svenskspråkiga Wikipedia" som källa, trots att det aldrig ser ut att ha varit några koordinater i berörd artikel. Koordinaterna pekade i riktning mot Leksands kommun, isf Ludvika kommun. Koordinater fanns ju dock I "lista över skyddade kyrkobyggnader" så jag lade in dessa. Koordinaterna lades in av en användare som hellre lade in mycket data än bra, så jag blir inte jätteförvånad över om det finns många fler missar av denna typ. -- Innocent bystander (talk) 19:08, 11 September 2017 (UTC)

@Innocent bystander: Om jag minns rätt så lades det inte till koordinaten om itemet redan hade den, oavsett källa, för att undvika att ha items med två koordinater. Därför finns det ca. 2000 items där koordinaten är källbelagd med svenskspråkiga Wikipedia och inte har uppdaterats. --Alicia Fagerving (WMSE) (talk) 07:11, 12 September 2017 (UTC)
Exakt, vore det möjligt att byta ut dessa ofta undermåliga koordinater? Vi har redan gjort detta med de småorter som kunde få nya koordinater med "anges i Småorter 2005 (Q25976776)" som källa och det stötte inte på några problem här. -- Innocent bystander (talk) 07:18, 12 September 2017 (UTC)

Daguerreotyp painting[edit]

Hi Alicia, hope you're doing well. It's a bit strange that Q43221454 is classified as a painting by the museum. Maybe you can look into this? Multichill (talk) 11:37, 14 January 2018 (UTC)

Taking a look in their data it does in fact look like they set "Kategori:Måleri, Målningar" (Category:painting) and "Sakord: Målning" (keyword:painting). The only indication that it is something else is in "Tillkomst: Fotograf: Valdemar Renard" (Creator: Photographer: Valdemar...). /André Costa (WMSE) (talk) 14:17, 4 April 2018 (UTC)

Wrong edits[edit]

Hello! Your bot, AliciaFagervingWMSE-bot did completely wrong edits. First of all, it added unnecessary and wrong items to located in the administrative territorial entity (P131), for example here. We need only one item, not two or more. In this case, the city/village is what we need, not the county. Second, it added many false counties (e.g. Q12723639 is in Q190711, not in Q184797). In my opinion, all of these edits should undo. Bencemac (talk) 19:15, 2 March 2018 (UTC)

The imports all take their data from the Monuments Database (explained at c:Commons:Monuments Database), using the mapping specified at Wikidata:WikiProject_WLM/Mapping_tables/ro_(ro) (for Romania). It is in turn just taking it's data directly from the Wiki Loves Monuments tables on Wikipedia. For Romania the technical settings are defined at [4] but in short it comes from these pages. To fix something which is wrong in the Monuments Database you therefore have to fix the underlying error on Wikipedia. Starting from a Wikidata entry with an imported error you can look at the reference to get the url to the entry in the monuments database. That entry states the Wikipedia page under "source" and and "id" allows you to identify which entry on that page it is.
So anything which is completely wrong and was imported is therefore caused by an error on (e.g. w:ro:Lista monumentelor istorice din județul Mureș - Z for Q12723639). When importing we tried to do some sanity checks (e.g. not importing multiple located in the administrative territorial entity (P131)). That said if Wikipedia says one thing and Wikidata another then there is no way to automatically determine which is correct (or the more appropriate), hence the Wikipedia value is also imported.
I have full understanding that these things can be frustrating. It is worth noting however that out of more than 30,000 items imported on Romanian heritage less than 3,500 had items on Wikidata before and my guess is that only a fraction of these experienced the problems you mentioned above. It also looks like it doesn't affect most of the Properties which were imported for each affected item. /André Costa (WMSE) (talk) 15:04, 4 April 2018 (UTC)

a crucifix is not a mill[edit]

The bot described a crucifix as being a mill [5] [6]. What is the source for this wrong description (that lead later to wrong categorization of the photos in commons through another bot) ? Thanks, best regards, --Niki.L (talk) 11:49, 16 May 2018 (UTC)

My guess is that Wikidata:WikiProject_WLM/Mapping_tables/at_(de)/types accidentally matched Mühle in Teufelsmühle. /André Costa (WMSE) (talk) 08:55, 21 May 2018 (UTC)

Wrong edit - a wayside shrine is not a mountain pass[edit]

Your bot AliciaFagervingWMSE-bot added monument claims to the mountain pass Preiner Gscheid Pass (Q1794599). How could this happen? I will fix this manually... -- Hofoen (talk) 08:27, 30 May 2018 (UTC)

@Hofoen: My guess is that this is caused by the same issue as the error mentioned above. /André Costa (WMSE) (talk) 11:25, 18 June 2018 (UTC)

Items with multiple codes for Romania[edit]

Hi Alicia and André. I've noticed that the heritage bot added several codes to some items listed here. I suspect the grouping was done by article. While not strictly incorrect, I think it would be better to have one item per code, since in some cases the different codes can be hundred of km away. If this is too complicated for you, I can fix the issues myself, but I want to make sure that the bot will not "correct" me afterwards. Please advise on the path forward.--Strainu (talk) 07:14, 23 June 2018 (UTC)

Hi @Strainu:, thanks for letting us know. All of the heritage importa should have a safety mechanism built in preventing them from adding any claims if the item already contains a different id. That rule should have taken precedence over any links on the source wiki. Obviously that mechanism has failed here :( The claims should be removed and added to new items and the Wikipedia links updated (I guess that can only be done manually). I'll also take a look at what went wrong in the underlying logic /André Costa (WMSE) (talk) 07:15, 25 June 2018 (UTC)
I have a similar issue with heritage sites in Romania: The ro.wp infobox uses Wikidata to retrieve the county and municipality where the site is located. This requires that, for every heritage site, located in the administrative territorial entity (P131) point to the municipality in which the site is located, not the county (as it was initially during import). For now, I'll just make some of these changes manually. I just hope no bots will come to "correct" me afterwards. -- —Andreitalk 08:53, 29 October 2018 (UTC)


I restored an older version of Holmöarna (Q3545909) to remove all the statements and descriptions your bot added about it being a nature reserve. The nature reserve does not cover all of the islands and has properties (such as inception (P571)) which are illogical on an item for a group of islands. You should create a new item for it instead. - Nikki (talk) 10:01, 28 July 2018 (UTC)


Good morning! I have been working with Cultural monuments lately and can find some editions made by members of WMSE like Agusastugan (Q30316427) as instance of (P31) ensemble of buildings (Q1497375) by AliciaFagervingWMSE-bot in 2017 having raa/bbr/21300000014319 described as individual listed building complex (Q24284072) and Q20871954 as building (Q41176) created by User:Väsk having in 2015 having raa/bbr/21300000014319 described as enskilt byggnadsminne (Q20871913)

I am not quite able to differ between these two Properties. Can you help me with the difference since they are bearing the same raa identificator and that to my understanding Agusastugan probably is one specific stuga located in Agusa (Q10403678) and is described in the Sv:article as Agusastugan är en vinkelbyggd korsvirkesgård från de första decennierna av 1800-talet med möbler, husgeråd, kläder, och verktyg från slutet 1800-taletI can also see that the house is used as hemstadsmuseum, but suppose that none of the above items is covering that as long as no instance of (P31) with musemum or a subclass there of are mentioned.

For the sake of good order I am also pinging @André Costa (WMSE): Breg Pmt (talk) 09:37, 6 October 2018 (UTC)

I've answered on my talk page/André Costa (WMSE) (talk) 07:20, 15 October 2018 (UTC)

Guy Fawkes edit warring[edit]

Your bot is edit warring at Guy Fawkes (Q13898). It is inserting a citizenship for a country that did not exist at the time Guy Fawkes lived.

First edit, reverted my human editor:

Reversion of human editor:

I have reverted your reversion. Jc3s5h (talk) 14:58, 30 October 2018 (UTC)

Same problem with adding Q183 on various items. --Dorades (talk) 16:10, 31 October 2018 (UTC)
I have notified administrators at Wikidata:Administrators' noticeboard#AliciaFagervingWMSE-bot adding incorrect information. Jc3s5h (talk) 17:22, 31 October 2018 (UTC)
Same applies for Netherlands (Q55), which ain't valid after 1815. Sjoerd de Bruin (talk) 15:10, 1 November 2018 (UTC)
@HHill: @Sjoerddebruin: @Ymblanter: @Jc3s5h: @Dorades: The information comes from the source that we're working with, i.e. the catalog of the National Library of Sweden. It does look like the information in the source is often not nuanced enough, especially when it comes to dates and nationalities. Having reviewed this, we will not continue with uploading data from this source. --Alicia Fagerving (WMSE) (talk) 12:00, 8 November 2018 (UTC)
I will unblock the bot now, but please be careful.--Ymblanter (talk) 12:03, 8 November 2018 (UTC)
Thank you! --Alicia Fagerving (WMSE) (talk) 12:04, 8 November 2018 (UTC)

Hugolinus de Urbe Vetere (Q26896768)[edit]

Hi Alicia,
what exactly makes Hugolinus a citizen of Sweden? Lexikon des Mittelalters (vol. 5, col. 180) gives no clue, he seems to have spent much of his life in what is now Italy and France, see also ALCUIN. country of citizenship (P27) is IMO quite problematic, cf. Property talk:P27#medieval and early modern persons. --HHill (talk) 20:08, 31 October 2018 (UTC)

  • Similarly: Terence (Q172048) citizen of Italy? What's the cleanup plan for these anachronisms? --- Jura 17:19, 9 November 2018 (UTC)

About "human biblical figure"[edit]

I am surprised by these edits by User:AliciaFagervingWMSE-bot, where "instance of = human" is added, whereas "instance of = human biblical figure" was already existing.
LIBRIS says "biblisk patriark", so perhaps it could be better to add the LIBRIS reference to the already existing "human biblical figure" value, instead of adding the "human" value?
Regards --NicoScribe (talk) 00:27, 24 November 2018 (UTC)

Romanian heritage sites[edit]

Hi! I do not know what went wrong with your bot but in a lot of Romanian heritage sites it entered a wrong county and a wrong English label. E.g. Q794171 was set by your bot to be in Sibiu county but as a matter of fact it is in Mures county - you can check it by the village where it is located = Q830587 or the LMI-code which begins with "MS". Other wrong items: Q1106887, Q780987, Q20430167 etc. Please correct them with your bot; I've already corrected Q18547684, Q18542234, Q18545178, Q1226245, Q791124, Q541901, Q1121823, Q1462142, Q794171, Q1110987 but it seems it's too much to be done manually. Hkoala (talk) 19:44, 1 December 2018 (UTC)

Hi! Can you help me to correct the mistakes made by your bot? --Hkoala (talk) 07:26, 18 February 2019 (UTC)

Hi @Hkoala:. Thank you for noticing this error! I've found these affected items (items that have a Romanian heritage code that begins with something other than "SB" and also a located in the administrative territorial entity (P131) statement with Sibiu County (Q184797). I'm going to remove these statements and the erroneous descriptions. It looks like quickstatements and other tools are acting up, so I can't do it right now, but I'm going to run this edit batch as soon as they're fixed. --Alicia Fagerving (WMSE) (talk) 09:20, 18 February 2019 (UTC)

In the meantime I started to correct them manually (+adding the hu labels) but then I stop now. Thanks. --Hkoala (talk) 09:22, 18 February 2019 (UTC)


We changed the way we handle attributed works. You might need to update some bots before doing a new import. Multichill (talk) 11:09, 2 December 2018 (UTC)

Franz Kafka[edit]

In these edits you claimed that Franz Kafka (Q905) (died 1924) was a citizen of the Czech Republic (Q213) (formed 1993). I suggest you have a good look at the database at that you were importing, because if that sort of nonsense is typical of its data integrity, you're going to need to rollback a lot of changes. --RexxS (talk) 01:05, 5 January 2019 (UTC)

Similarly, the bot claimed that Laozi (Q9333) (6th century BC) was a citizen of People's Republic of China (Q148). --Yair rand (talk) 19:27, 10 February 2019 (UTC)
Looks like there are a very large amount of these mistakes. I recommend reverting the entire run. --Yair rand (talk) 03:00, 13 February 2019 (UTC)
@Yair rand, RexxS: We have noticed the low data quality in National Library's database and we are not going to use this data anymore. I am going to look through the edits that use that source and remove the citizenship statements that use Libris as a source. --Alicia Fagerving (WMSE) (talk) 10:50, 18 February 2019 (UTC)

Bug: Incorrect Given Name assignment "de"[edit]

Hi. I noticed that your bot is incorrectly adding "de" as a Given Name to people who have this phrase in their names (e.g. Q312630 [7]). That doesn't seem quite correct and should probably be changed. BMacZero (talk) 02:00, 18 February 2019 (UTC)