User talk:Romaine/2023

Latest comment: 4 months ago by Mohammed Abdulai (WMDE) in topic Wikidata weekly summary #607

Toevoeging ", Nederland" edit

Hoi Romaine, wat is het nut van deze wijzigingen? Lijkt me wat overbodige toevoeging in het Nederlands. Multichill (talk) 10:29, 26 December 2022 (UTC)Reply

Hi Multichill, In de wereld zijn er minstens 18 plaatsen die Amsterdam heten. Een plaatsnaam als Aalst ben ik al op zo'n 8 plekken tegengekomen. Alkmaar komt op zeker 4 plaatsen in de wereld voor. Ik kan bijna eindeloos een opsomming maken van plaatsnamen die meer dan 1x voorkomen in de wereld. Bij het invullen van bv een straatnaam is het cruciaal dat de juiste locatie gekoppeld wordt. Het goed kunnen koppelen begint bij een omschrijving die deze basale informatie verstrekt. Ik heb zelf al meermaals meegemaakt dat het land ontbrak, waardoor ik niet goed kon kiezen welke ik moest toevoegen. Ook heb ik al meerdere fouten van gebruikers gezien die ontstaan waren doordat het land ontbrak. Nou zal dit waarschijnlijk bij Amsterdam waarschijnlijk iets minder spelen, toch lijkt het me goed te zorgen dat voor alle straten in Nederland duidelijk is dat ze in Nederland liggen (Amsterdam niet uitgezonderd). Door de vaste opzet van <onderwerp> in <plaats>, <land> overal aan te houden verhoogd dat de kwaliteit. Ook stimuleert het andere gebruikers om de beschrijving beter in te vullen. Verder helpt het ook om fouten te vinden en om dubbele items op te sporen. En je zegt het het voor het Nederlands overbodig lijkt, ik denk dat er genoeg mensen in het Amerikaanse deel van het Nederlands taalgebied kunnen vinden voor wie het niet evident is, evenals voor wie Afrikaans als moedertaal heeft. Romaine (talk) 16:29, 26 December 2022 (UTC)Reply
Het kan jou duidelijk veel meer schelen dan mij. Ik vind het een overbodige toevoeging, maar ga er verder niet over vallen.
Ik weet niet of je de constraints op BAG public space ID (P5207) al hebt gezien, maar Nederlands is compleet en Engels bijna. Multichill (talk) 16:40, 27 December 2022 (UTC)Reply
Hi Multichill, Nee, die had ik nog niet gezien. Ik zal daar binnenkort werk gaan maken.
Ik ben wel een ander probleem tegengekomen: er zijn heel veel straten waarop de BAG public space ID (P5207) ontbreekt. Ik heb al zitten kijken hoe ik dat kan oplossen, maar kwam daar niet aan uit. Heb jij een idee waar de BAG's van de openbare ruimte op te zoeken zijn? (Of kun je dit met een query opvragen en/of botrun toevoegen?) Romaine (talk) 16:49, 27 December 2022 (UTC)Reply
Veel? Ik tel er iets meer dan 1900, dat waren er echt veel meer, zie User_talk:Denengelse#Lekker_bezig_met_de_BAG! en heb ook een kaartje.
Via https://bagviewer.kadaster.nl/lvbag/bag-viewer/ zijn ze wel te vinden zoals ik net voor Dominikanerkerkstraat (Q19012510) heb gedaan. Is wel een hoop werk
https://w.wiki/69i$ geeft ook wel wat suggesties, maar is volgens mij vooral deze correctie. Multichill (talk) 17:17, 27 December 2022 (UTC)Reply
Hi Multichill, Als je het vergelijkt met wat er gedaan is is het niet veel, maar an sich vind ik 1900 items nog steeds veel. Maakt niet uit.
De optie om via die zoekfunctie de straten te vinden had ik nog niet gezien en eerder gemist. Voor alle gebouwen vond ik de ID door op het betreffende gebouw te klikken, maar voor straten werkt dat dus anders. Als Denengelse niet verder komt de BAG toe te voegen kijk ik binnenkort wat ik handmatig kan oplossen. Groetjes - Romaine (talk) 17:32, 27 December 2022 (UTC)Reply
Hoi @Romaine, aan die 1900 kan ik geautomatiseerd niet meer zoveel doen (misschien heb ik items die een subklasse van een straat zijn nog over het hoofd gezien, maar dat zullen er 200 zijn of zo). Het kan zijn dat de straat geen bestuurlijke eenheid heeft, dan kon ik er niks mee. Het kan ook dat de straat inmiddels niet meer bestaat, die zou dan een datum van opheffing (P576) moeten krijgen. Er zijn ook lastige gevallen waarin de straat dubbel voorkomt, dat komt doordat de straten ooit zijn ingeladen uit de postcodetabellen en een adres 'dingestraat 3' kan in de ene gemeente liggen, terwijl de 'dingesstraat' zelf in een andere gemeente ligt - de grens loopt dan tussen het adres en de straat. Die zouden gemerged moeten worden. En er zijn vast nog wel andere rare gevallen! O, en ik zal in de toekomst ', Nederland' aan de beschrijving toevoegen, als ik weer eens een verdwenen straatje tegenkom. Tot slot, misschien vind je [1]https://hicsuntleones.nl/bbdb/ nog leuk om te zien. Denengelse (talk) 22:27, 27 December 2022 (UTC)Reply
Hi Denengelse, Ik ga er binnenkort mee aan de slag! Ik heb gezien dat er een aantal het label missen (en/nl), alias missen, gemeente missen en meer. Als ik ze eerst naloop (en corrigeer) zodat ze allemaal een gemeente hebben, zou je dan een poging kunnen wagen om het aantal verder te verkleinen?
Het vraagstuk van twee weggedeelten met dezelfde naam, maar in een andere bestuurlijk gedeelte, ik weet nog niet wat daarin het beste kan gebeuren. Voor nu zou ik zeggen dat we ze het beste allebei van hetzelfde nummer kunnen voorzien, dan kunnen we op een later moment hier handig mee aan de slag. Mijn eerste insteek zou zijn om ze samen te voegen, maar ik ben niet voldoende bekend in de materie waarom ze überhaupt apart zijn aangemaakt als twee losse items.
Een tijd geleden constateerde ik dat de straten geen identificatie code hadden en dat frustreerde me, omdat ze daarmee een beetje in het niets zweven. Ik ben dus erg blij dat je dit hebt opgepakt en ze gekoppeld hebt!! Dank!!
Mijn voornemen is, als de straten gedaan zijn, een stapje hoger te gaan: de gehuchten, buurtschappen, dorpen, buurten, wijken en steden. Mijn aandacht gaat dan vooral uit naar de labels, beschrijvingen en gemeente (P131), maar ik zie ook dat er nogal wat ook geen identificatiecode van de BAG hebben. Zou dat iets zijn waar je ook mee aan de slag kan gaan?
Als de basis van straten en plaatsen gedaan is, wil ik ook weer verder met gebouwen. Ook die kunnen een BAG gebruiken.
Als ik ergens kan helpen bij het oplossen van probleemgevallen, help ik graag! Laat het gerust weten! Romaine (talk) 22:05, 31 December 2022 (UTC)Reply
Hoi @Romaine, ik kan niks beloven, maar zal m'n best doen. Er zijn trouwens 'maar' iets van 2500 woonplaatsen die een BAG id hebben, en als ik nu kijk zie ik er 2509 in Wikidata staan. Dat is al compleet dus! Je kan wel kijken of de overige plaatsen al een GeoNames id hebben. Denengelse (talk) 19:31, 3 January 2023 (UTC)Reply
@Multichill & Denengelse, Ik ben bezig geweest met het toevoegen van BAG's aan straten/pleinen/stegen en dat is nu voltooid! Van de ongeveer 1900 is dit aantal nu teruggebracht naar 0 (query). Mijn conclusies:
  • De meest voorkomende gevallen waarom het Wikidata-item geen BAG public space ID (P5207) had waren:
    • A. BAG was niet gevonden als gevolg van onvolledig Wikidata item (-> heb ik aangevuld + BAG toegevoegd) of item had afwijkende plaats.
      • In veel gevallen was het puur een onvolledig Wikidata-item dat de BAG deed ontbreken.
      • In veel andere gevallen ligt de straat in gemeente A, maar omdat de gemeentegrens door de berm loopt ligt het adres in gemeente B. (Voorbeeld) In de BAG is alleen de straat van gemeente A opgenomen, terwijl op Wikidata we een item hebben voor die straat in gemeente A en een item voor die straat in gemeente B. Ik heb beide straten hetzelfde BAG-nummer gegeven. Als de conclusie wordt dat die het beste samengevoegd kunnen worden, kunnen ze door de identieke identificatiecode snel opgespoord worden.
    • B. BAG was niet gevonden als gevolg van andere schrijfwijze/naamswijziging. Vaak stond er bv Huppelepupstr terwijl wij Huppelepupstraat hebben of andersom. Ook afkortingen versius voluit. Soms was het ook simpel een spatie te veel of te weinig. Ik heb getracht zowel de BAG-schrijfwijze als de schrijwijze op Wikidata in het item te houden om ze vindbaar te houden, de een werd dan een Label, de ander een Alias. Voorbeelden: letter s te weinig, de -> den, St. -> Sint, Dokter <-> Dr., spatieprobleem A. H. -> A.H., Groenewoudsweg -> Groenewoud
    • C. BAG was niet gvonden omdat de straat is opgeheven:
  • Bovengenoemde kwamen echt heel veel voor. Daarnaast ook nog een aantal:
    • D. Verder hebben we in Wikida een aantal items van straten/pleinen/stegen die wel degelijk bestaan, maar dan alleen informeel en dus geen BAG hebben. -> BAG op unknown value gezet. Voorbeeld: Bianca Castafioreplein
    • E. Ook hebben we diverse items over straten als gevolg van een Wikipedia-artikel, waarin in een artikel twee straten beschreven werden als één geheel, maar in de BAG twee straten zijn. Voorbeeld: Prinses Beatrixlaan in Delft-Rijswijk of Kromme Elleboog in Groningen
      • Het verzamelartikel: BAG op unknown value gezet + has part(s) (P527) met de individuele straten.
      • In de individuele straten: BAG ingevuld + part of (P361) met item van verzamelartikel.
  • Ten slotte nog twee rare tegengekomen: een brug met een BAG en een waterlichaam met BAG.
  • En dan nog deze rare: Baanlaan (Q98121763), aangemaakt door Denengelse... klopt deze wel?
  • Als laatste nog, ik heb twee fouten in het systeem van de BAG ontdekt: twee straten die wel op de kaart van de BAG aangeduid staan, maar beide niet gevonden konden worden via de zoekfunctie. Van beide melding gemaakt. De een is al opgelost: op de kaart stond een verkeerde schrijfwijze die afweek van die via de zoekfunctie gevonden kon worden. De ander is het nog wachten op een oplossing.
Ik heb gezien hoeveel wijzigingen er in ~10 jaar tijd zijn. Lijkt me goed om eens na te denken over hoe we de straten up-to-date gaan houden in de toekomst, zowel qua nieuw bijgekomen straten als verdwenen straten. Nogmaals dank Denengelse voor de import van de BAG's, dat ze er niet in stonden ergerde ik me al jaren aan en was een puinhoop. Romaine (talk) 11:47, 6 January 2023 (UTC)Reply
Zo, dat is een hoop werk geweest! Er komen natuurlijk steeds straten bij. Ik was gisteren dagje naar Muiderslot en toen hadden we het er nog over dat Weesp nu aan Muiden aan het groeien is. Daar zijn allerlei nieuwe straten zoals bijvoorbeeld de Loevesteingracht https://bag.basisregistraties.overheid.nl/bag/id/openbare-ruimte/0457300000000302
We zouden natuurlijk met een robot zo nu en dan een rapportje kunnen produceren. Ik zie dat https://w.wiki/6CR5 gewoon output geeft in minder dan 6 (!) seconden. Dan per woonplaats de data bij BAG ophalen en per woonplaats aangeven wat er scheef zit. Multichill (talk) 14:10, 7 January 2023 (UTC)Reply
Weesp is een apart verhaal, want zojuist opgeslokt door Amsterdam. Ik ga binnenkort de straten van Weesp, in opdracht van het Stadsarchief, opnemen in [2]https://adamlink.nl/geo/streets/list - ik zal ze dan ook meteen in Wikidata fixen. Denengelse (talk) 16:50, 10 January 2023 (UTC)Reply
Dank je wel @Romaine, super dat je dat allemaal gefixt hebt! Ik zal de Baanlaan eens uitzoeken, waarschijnlijk is dat een niet meer bestaande straat waar ik een einddatum vergeten ben. Denengelse (talk) 16:47, 10 January 2023 (UTC)Reply

Wikidata weekly summary #552 edit

Wikidata weekly summary #553 edit

Wikidata weekly summary #554 edit

Samenvoegen gemeentes edit

Hoi Romaine, op Wikidata is het niet de bedoeling dat valide data wordt verwijderd. Op Wikipedia passen we de gemeente aan in de infobox, maar op Wikidata voegen we de nieuwe gemeente toe met preferred rank. Kan je dit herstellen voor de items die je hebt aangepast? Multichill (talk) 20:52, 15 January 2023 (UTC)Reply

Romaine, ben je van plan om nog te reageren? Of moet ik maar gewoon al deze bewerkingen terugdraaien? Multichill (talk) 11:37, 12 February 2023 (UTC)Reply

Wikidata weekly summary #555 edit

Wikidata weekly summary #556 edit

Wikidata weekly summary #557 edit

Wikidata weekly summary #558 edit

Wikidata weekly summary #559 edit

Wikidata weekly summary #560 edit

Wikidata weekly summary #561 edit

Wikidata weekly summary #562 edit

Wikidata weekly summary #563 edit

Wikidata weekly summary #564 edit

Wikidata weekly summary #565 edit

Wikidata weekly summary #566 edit

Wikidata weekly summary #567 edit

Wikidata weekly summary #568 edit

Wikidata weekly summary #569 edit

Wikidata weekly summary #570 edit

Wikidata weekly summary #571 edit

Wikidata weekly summary #572 edit

Terugdraaiing "gelijknamige" en "Brabantse gemeente" edit

Beste Romaine , je hebt een verandering door mij in de nl-beschrijving van de plaats Tilburg, Q9871, ongedaan gemaakt. Daar ben ik het niet mee eens:

"gelijknamige" in "... in de gelijknamige Brabantse gemeente" is geen zinvolle toevoeging en daarom ongewenst op Wikidata, waar label en beschrijving (volgens kennelijk niet serieus omstreden richtlijnen) beknopt horen te zijn.
"Brabantse gemeente" is, waar we op Wikimedia, als specificatie naar regio gewenst is, zoveel mogelijk classificeren naar officiële indeling, niet aanvaardbaar. Tilburg als deel van Brabant is al ongeveer 400 jaar niet echt een ding meer. Tilburg lag in Staats-Brabant en ligt nu in Noord-Brabant. Onderwijl bleef er een "Brabant", het kerngebied van het oude hertogdom Brabant, maar dan veel zuidelijker, in de Spaanse/Oostenrijkse Nederlanden; korte tijd als provincie in het Koninkrijk der Nederlanden. Brabant was centraal in de afscheiding van België (waarbij een lied, de "Braban©onne" een rol speelde). Sinds 1830 (feitelijk) of 1839 (algemeen erkend) was Brabant een deel van België. Tot 1995 bleef Brabant een provincie van België. Het is dus misplaatst om een gemeente in Nederland een "Brabantse gemeente" te noemen ~ Bedenk ook dat Wikidata en Wikimedia niet uitgaan van landsgrenzen, wel zijn er praktisch taalgrenzen; maar Brabant ligt vooral voor Belgische Nederlandstaligen zeker in België (B grenst niet eens aan NB, de hele provincie Antwerpen ligt er nog tussen!).
Op beide punten ben ik dieper ingegaan, niet omdat ik het per dit item heel belangrijk vind, maar omdat het om bredere punten gaat en omdat ik het zorgelijk vind als verbeteringen (ook al gaat het om kleine dingen) worden teruggedraaid naar de vorige minder correcte toestand.
Benieuwd naar je reactie !
Met vriendelijke groet , Paulbe (talk) 22:52, 17 May 2023 (UTC)Reply
Beste Paulbe, "gelijknamige" is wel degelijk zinvol omdat dit woord aangeeft dat er ook een apart item bestaat voor de gemeente met dezelfde naam. Door dit zorgvuldig aan te geven, is men bewuster van de verschillende items en hun verschillen en worden items vaker correct gekoppeld. Heel vaak worden de verkeerde items gekoppeld die dezelfde naam hebben en dat moet weer vervolgens gecorrigeerd worden. Door duidelijke aanduiding met "gelijknamige" wordt het verkeerd linken beperkt.
Dat "Brabantse" alleen zou verwijzen naar een historische regio is onjuist. Zelfs de provincie Noord-Brabant gebruikt veelvuldig "Brabantse". Er staat verder bij dat het om "Nederland" gaat, waarmee er overduidelijk onderscheid is met het Belgische.
Voor plaatsen zijn vier stukjes informatie van belang, wat het is (dorp/plaats/etc), in welke gemeente die ligt, in welke provincie die ligt en in welk land die ligt. Die informatie wordt hier duidelijk, kort en bondig en volgens de algemene gebruiken toegevoegd. Groetjes - Romaine (talk) 23:02, 17 May 2023 (UTC)Reply

Wikidata weekly summary #573 edit

Wikidata weekly summary #578 edit

Wikidata weekly summary #579 edit

Wikidata weekly summary #580 edit

Wikidata weekly summary #581 edit

Wikidata weekly summary #582 edit

Oliver Hill Railway (operator and line) edit

Regarding your recent edit to Oliver Hill Railway (Q53085337), did you perhaps mean to change it to a railway company (Q249556) instead of a railway line (Q728937)? Because there's already Oliver Hill Railway (Q57913894). Or should that be merged into Oliver Hill Railway (Q53085337)? Sam Wilson 06:40, 27 June 2023 (UTC)Reply

Hi Sam, My first thought would then be to merge, as Oliver Hill Railway (Q53085337) already reads mostly as a railway line. Also most one line railway companies currently are the same item as the railway line. But if someone thinks it should be split I am fine with it too. Greetings - Romaine (talk) 07:19, 27 June 2023 (UTC)Reply
Yep, that makes sense. I've merged them. Thanks! Sam Wilson 07:26, 27 June 2023 (UTC)Reply

Wikidata weekly summary #583 edit

Official municipality names edit

Hi,

I get you want to use the common name as the main label for the municipalities but you are also removing the official names as you are reverting the chances, could you not do that please.

Jhowie Nitnek 18:50, 9 July 2023 (UTC)Reply

Hi Jhowie Nitnek, They already have been added as alias. In labels the common name is used, not the official name. (And even then, for Ganshoren (Q366552) it is even questionable for 2 of the 4 labels you changed, as the source you added only gives the Dutch and French name, and not the German or English name.) Please do not change labels to what you consider official, as that is not what should be in that field. Romaine (talk) 18:59, 9 July 2023 (UTC)Reply

Wikidata weekly summary #584 edit

Hiking trails project edit

I just matched a trail section you added worked on with OSM :)

Feel free to join the project, see Wikidata:WikiProject Hiking trails So9q (talk) 18:46, 14 July 2023 (UTC)Reply

Wikidata weekly summary #584 edit

Wikidata weekly summary #585 edit

Wikidata weekly summary #587 edit

Wikidata weekly summary #588 edit

Wikidata weekly summary #589 edit

Wikidata weekly summary #590 edit

Wikidata weekly summary #591 edit

Wikidata weekly summary #592 edit

Foundations edit

In your recent batch you seem to have copied foundation (Q157031) from P31 to P1454. I don't think this was a good idea as this class item is for a generic organization type not for an actual legal form in any particular legal system (cf. Stiftung (Q18631225), foundation (Q18631232), Spanish foundation (Q29555171) etc.). I believe P1454 should have the same none-of constraint that you added to P31. See also related comments here: Wikidata:Property proposal/GLEI ELF#Discussion. 2001:7D0:81DB:1480:2022:D2DF:29E4:A6D9 07:00, 8 September 2023 (UTC)Reply

Hi, At the moment I added the generic foundation to P1454, I expected somehow that by adding this it would stimulate to get the country specific foundations to be added to P1454, but now I am not so sure. I certainly agree with you that the more country specific legal form of an organisation should be added with P1454. For two countries I already have done that, for other countries it still needs to be done. I think it can be a good idea to have a none-of constraint with the text to choose a more specific legal form. Romaine (talk) 16:02, 10 September 2023 (UTC)Reply
I have added the constraint as you suggested. For multiple countries I have fixed the foundation to the one of that country. For some others it is unclear. Another main issue is that many organisations miss the country where they are based. Romaine (talk) 16:44, 10 September 2023 (UTC)Reply

Wikidata weekly summary #593 edit

Andalusian heritage additions with no references edit

Hi:

I see you are doing a massive uploading of data of Andalusian heritage elements. All the relevant ones uses Guía Digital del Patrimonio Cultural de Andalucía ID (P3318) and are fully referenced mainly from that source. I'm very happy seeing data enriched by other contributors but we are trying to keep the quality of data using referenced information. As far I checked you are not adding references for the has use (P366) values. Could I ask you what's the source you used, please? In case you inferred from P31 values, I can't recommend the practice, since the current use could not be the same of the nature of the building. Thanks in advance. —Ismael Olea (talk) 11:49, 18 September 2023 (UTC)Reply

Hi Ismael Olea, Thank you for reaching out. I moved data that was added with instance of (P31) to has use (P366), as the (former) usage of a mill should be added to P366 instead of P31, while P31 says it is a mill. Please be aware that has use (P366) is also intended to be used for former usage. For both instance of (P31) and has use (P366) a qualifier can be added with the end date if it is known when this usage ended. So it is not a derivative but a moving of the data to the right property. Greetings - Romaine (talk) 12:06, 18 September 2023 (UTC)Reply

Wikidata weekly summary #594 edit

Paper mills edit

You added P31=mill (Q44494) statment to many paper mills[3]. Q44494 per its description is for a grinding device. User:Fralambert now added P279=industrial building (Q1662011) statement to this class item (probably in order to work around constraint violations caused by your edits) but this is confusing and probably wrong as it conflates the device and building housing the device (i.e. mill building (Q56822897)). Paper mill items on the other hand presumably are for either entreprises or factories or factory complexes. My understanding is that grinding devices are not even the main component of paper mills. So your related batches seem rather messy, and I'm not sure how to improve it. I think you should consider reverting these batches. 2001:7D0:81DB:1480:9577:F1EC:BECF:FA11 08:54, 19 September 2023 (UTC)Reply

Hi, A mill is a device which converts the energy from wind, water or animals into power for a certain usage. For how the energy of the mill is used, a property exists: has use (P366). The only thing I did was moving the usage of the mill from P31 to has use (P366). In my country/language there is a clear distinction between a paper mill and a paper factory. I now see that in English the item for paper mill (Q14545258) has as alias "paper mill", so I can imagine that based on what you say, on several items the wrong "paper mill" was added. If that is the case then "mill" should be changed to paper mill (Q14545258). Looking at some items in other countries, I noticed on some items photos with a very distinctive waterwheel. In general reverting "mill" back to paper mill (Q918088) will keep the problem that the wrong type of paper producing object is linked for P31. Romaine (talk) 14:39, 19 September 2023 (UTC)Reply
As I understand, word "mill" has multiple meanings, and also "mill" necessarily doesn't have all meanings that "molen" has and vice versa. If sitelinks attached to mill (Q44494) item are for distinct senses then possibly an item for another sense should split from this item, or sitelinks should be moved to other already existing and appropriate items. Possibly "mill" also has this more general meaning that you suggest ("device which converts the energy /.../ for certain usage). Though, en:wikt:mill doesn't mention it. The latter in addition to "grinding apparatus" and "building housing such a grinding apparatus" mentions only "manufacturing plant for paper, steel, textiles, etc" that could be relevant to paper mills or paper factories.
Per dewiki articles the distinction between "paper factory" and "paper mill" appears to be that the first one has paper machines and the second one doesn't (rather in historical context). So possibly in some items P31 value could have been changed from "paper factory" to "paper mill", or vice versa. Though, it's currently difficult to make this distinction in a clear way for individual sites as the distinction is not clear based on class item descriptions, and also it seems that other languages (including in enwiki article) rather don't make this distinction.
I'm less concerned about has use (P366) values, though I also don't quite understand based on what you prefer P366 over P31 for "paper mill" value for a subject that by its main function is a paper mill.
My main concern is that items that you edited, like Donside Paper Mill (Q71854597), appear to be are for factory or building complex, that may or may not house some sort of grinding device, but is not a grinding device itself. So, at least based on English description in class item and attached en:Mill (grinding) article these P31=Q44494 statements probably don't make sense in most (if not all) paper mill items. So it still seems to me even if previously some P31 values might have been inaccurate then now they are probably all wrong. 2001:7D0:81DB:1480:70B0:841B:2D1B:83F 09:16, 20 September 2023 (UTC)Reply

Incorrect use of subclass of (P279) edit

Hello –

This edit to "area" (Q1414991) was in error. Because subclass of (P279) is transitive (for example, see this tree of parent classes), such errors lead to numerous false inferences. When using instance of (P31) and subclass of (P279), check the description of the item you use as the statement value, and make sure your use complies with Help:Basic membership properties. (In particular, "A" is a subclass of "B" only if all instances of "A" are also instances of "B".) There is often another property that can accurately express the relationship you had in mind; in this case, has characteristic (P1552) works better. You can search through available properties here. Thanks! Swpb (talk) 07:16, 21 September 2023 (UTC)Reply

Hi Swpb, I know how instance of/subclass of works, at least in most cases. So I do not mind that you change it back, but please have a look at the situation why I added it. The reason why I added is the following. I came across Twente (Q1455944) and noticed that demonym (P1549) gives a constraint notice that area (Q1414991) needs to be a subclass of toponym (Q7884789). If you know another solution to make the constraint notice disappear by solving the constraint, I would be happy to know. Romaine (talk) 02:16, 22 September 2023 (UTC)Reply
First, that's not what the constraint says. It says that items with the property demonym (P1549), in this case Twente (Q1455944), should be instances (directly or not) of one of the given set of classes. But toponym (Q7884789) is just the first class in that set, and the constraint does not say it's correct to make any item be an instance of one of those classes, e.g. by making area (Q1414991) a subclass of toponym (Q7884789). And of course, a little logic also tells us that's not right: an area (Q1414991) is a kind of place, and a toponym (Q7884789) is a kind of name, and places are not names. The right answer is to think about what an area (Q1414991) is, see if there is an appropriate parent class in the set given by the constraint, and if not, add one if appropriate. So let's see: the closest thing to a parent for Twente (Q1455944) listed by the constraint (as it was before I fixed it) is geographic location (Q2221906). However, this just refers to a single point, not a region. Now, Twente (Q1455944) is also an instance of geographic region (Q82794) – would it be appropriate for demonym (P1549) to be used on instances of geographic region (Q82794) generally? I think so, so I added geographic region (Q82794) to the set of classes allowed by the constraint. Presto, the violation on Twente (Q1455944) disappears, and I haven't made any illogical statements to do it. The point is, when you see a constraint violation, don't just do the first thing that makes it go away – think about what you're doing. Swpb (talk) 14:00, 22 September 2023 (UTC)Reply
At the time I added toponym, I thought it would make sense and logic to make everything with area (Q1414991) a toponym, otherwise I would not have added it. But I can imagine I missed something. Thank you for the solution. Romaine (talk) 16:37, 22 September 2023 (UTC)Reply
That doesn't makes sense. There are about 456 instances of area, and all of them are places, not names of places. A thing is not its name. Swpb (talk) 17:01, 22 September 2023 (UTC)Reply

Wikidata weekly summary #595 edit

Wikidata weekly summary #596 edit

Call for participation in a task-based online experiment edit

Dear Romaine,

I hope you are doing well,

I am Kholoud, a researcher at King's College London, and I am working on a project as part of my PhD research, in which I have developed a personalised recommender model 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 model 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 in a research venue.

The experiment should take no more than 15 minutes, and it will be held next week.

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/1FAIpQLSfA1wfdBfCRlcG3WhDyc-V8lzgPNx3fDFCNXkyn4CSwahXZ_A/viewform?usp=sf_link

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

For more information about my project, 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 Kholoudsaa (talk) 22:14, 5 October 2023 (UTC)Reply

Wikidata weekly summary #597 edit

Wikidata weekly summary #598 edit

Wikidata weekly summary #599 edit

Welcome to the 600th Wikidata Weekly Summary! edit

Wikidata weekly summary #601 edit

Wikidata weekly summary #602 edit

Wikidata weekly summary #603 edit

Wikidata weekly summary #604 edit

[Wikidata] Weekly Summary #605 edit

Wikidata weekly summary #606 edit

Wikidata weekly summary #607 edit

Wikidata weekly summary #608 edit

Return to the user page of "Romaine/2023".