Wikipedia:De kroeg/Archief/20200427

Items in Wikidata werken onbedoeld lokaal vandalisme in de hand?

Ik kwam een gekke bewerking tegen van iemand die aangaf een niet kloppende afbeelding uit een lemma verwijderd te hebben. Echter was er een hele infobox verwijderd waar op het eerste gezicht helemaal geen afbeelding in stond. [1]. Wat bleek; het betreffende Wikidata item bevatte een afbeelding die automatisch ingeladen wordt in infoboxen waar geen afbeelding in stond.[2] Als je dan lokaal gaat bewerken kom je geen afbeelding tegen. Volgens mij geldt dit voor meer waardes die in sjablonen / infoboxen staan. Voor minder ervaren gebruikers levert dit zo onbedoeld vandalistische handelingen op waarbij er veel meer verwijderd wordt dan de bedoeling en voor wie de juiste plek om enkel 1 waarde te wijzigen haast onvindbaar is.

Zouden waardes die via Wikidata automatisch ingeladen worden, ook niet daadwerkelijk fysiek lokaal zichtbaar moeten zijn? Dan kan je in ieder geval lokaal dit soort zaken wijzigen zonder een half lemma te slopen. - Agora (overleg) 18 apr 2020 13:50 (CEST)

We hebben toch helemaal geen afbeeldingen lokaal staan? Afbeeldingen staan op Wikimedia Commons. Ik begrijp waarschijnlijk je vraag niet goed. Ecritures (overleg) 18 apr 2020 14:59 (CEST)

Op de genoemde pagina was de parameter "afbeelding" niet ingevuld. Toch verscheen er een afbeelding, afkomstig uit Wikidata. Daarom haalde de gebruiker dan maar de hele infobox weg. De juiste manier is uiteraard om de afbeelding weg te halen uit het Wikidata-item, zoals inmiddels gebeurd is, en eventueel te vervangen door een juiste afbeelding, maar dat is voor nieuwe gebruikers waarschijnlijk een brug te ver. Eventueel kunnen we verborgen commentaar plaatsen bij de parameter: | afbeelding = <!--Wordt overgenomen van Wikidata indien niet ingevuld-->, want verder is nergens aan te zien dat de afbeelding dan uit Wikidata komt. Wikiwerner (overleg) 18 apr 2020 15:29 (CEST)

Precies, bij afbeeldingen handmatig van commons geplaatst zie je bij de parameter afbeelding de bestandsnaam van de afbeelding op commons. Die verwijderen, verwijdert de afbeelding uit het lemma. Hier was die parameter inderdaad niet ingevuld maar werd via Wikidata de daar ingeladen standaard afbeelding ingeladen zonder enige verwijzing. Zo'n 'wordt overgenomen' tekst is al iets, maar gaat minder ervaren gebruikers niet helpen. Ik zou eigenlijk willen zien dat in zo'n geval bij de parameter afbeelding alsnog de bestandsnaam uit commons geplaatst wordt eventueel met die opmerking dat het via Wikidata ging erbij (of als bewerkingssamenvatting). Maar dan wel dat als je lokaal de afbeelding verwijderd, dit niet automatisch opnieuw gebeurt vanuit Wikidata. Agora (overleg) 18 apr 2020 15:49 (CEST)

Hoi Agora, ik begrijp inmiddels door de uitleg van Wikiwerner wat je precies bedoelt met lokale afbeeldingen. Wat mij betreft ligt de oplossing in het aanpassen van die sjablonen waar alleen automatisch de afbeeldingen van wikidata getoond worden. Dit kan door het sjabloon zo aan te passen dat de parameter 'image' in het sjabloon staat. Indien deze parameter is ingevuld met een bestandsnaam (van Wikimedia Commons) dan wordt die afbeelding getoond; is er niets ingevuld dan wordt de afbeelding getoond die op Wikidata als afbeelding is gekozen. Op die manier kan in het sjabloon altijd een handmatige keuze gemaakt worden voor de afbeelding die gewenst is. Groet, Ecritures (overleg) 18 apr 2020 18:44 (CEST)

Ha Ecritures, ik bedoel nergens lokale afbeeldingen maar wel dat bij afbeeldingen van commons in deze infoboxen op de lokale wiki's wel de bestandsnaam van de afbeelding van commons getoond wordt en met verwijdering daarvan de afbeelding niet zichtbaar is. Het probleem zit 'm hier net in de infoboxen waar geen commons afbeelding staat, maar er wel een standaard afbeelding op Wikidata is. Die laatste wordt dan 'ongezien' ingeladen. En juist op de lokale afbeelding zo'n afbeelding verwijderen is hier het probleem. Dat gaat dus niet en moet via Wikidata. Ik begrijp niet helemaal wat je hierboven bedoeld met hoe het aanpassen van sjablonen dit moet oplossen. - Agora (overleg) 19 apr 2020 15:21 (CEST)

Hoi Agora, ik bedoel ermee dat een sjabloon dat data geheel of gedeeltelijk van wikidata haalt zo ingericht kan worden dat er lokale informatie aan toegevoegd kan worden. In dat geval heeft het lokaal ingevulde onderdeel (bv de afbeelding) voorrang op het onderdeel dat op wikidata staat. Dus als er plaatje x op Wikidata staan (en getoond wordt) dan kan een wikipedia-gebruiker lokaal plaatje y op de gebruikelijke wijze aan het sjabloon toevoegen. In dat geval wordt plaatje y in de infobox getoond. (Plaatje x blijft dan wel gewoon op wikidata staan, het wordt alleen niet op wikipedia getoond). Voor data (niet afbeeldingen) geef ik persoonlijk de voorkeur aan Wikibridge (zie ergens later in dit topic). Even heel visueel verteld: dan staan er een potloodje achter bijvoorbeeld de geboortedatum of sterfplaats. Indien een gebruiker deze data wil aanpassen dan klikt hij op het potloodje, de infobox opent zich *op wikipedia*, de gebruiker wijzigt de data of vult deze aan en sluit het bewerkvenster weer. Achter de schermen heeft die gebruiker dan de data op wikidata aangepast. Groet, Ecritures (overleg) 19 apr 2020 16:56 (CEST)

(Na BWC:) Ik liep onlangs tegen een vergelijkbaar probleem aan, dat er afbeeldingen in infoboxen verschenen die ik daar niet wilde hebben. Maar in dat geval was het nog erger: als ik dan handmatig een andere afbeelding in die infobox zette, verscheen die niet. (Voor details, zie HIER.) Ik vind het geen juiste gang van zaken dat Wikidata ons afbeeldingen opdringt. Dat is strijdig met het principe van vrije bewerkbaarheid van artikelen. Ik vind het prima dat Wikidata-gegevens worden geïmporteerd voor zover die op geen enkele wijze ter discussie staan, zoals geografische en demografische gegevens. Maar zo iets subjectiefs als een afbeelding, dat is heel wat anders. Een artikel is niet in elke taalversie identiek, en daarom kan het zijn dat in een andere taalversie een ander plaatje gewenst is. Ik heb in het betreffende sjabloon die opgedrongen Wikidata-koppeling met de plaatjes dus verwijderd.

Ik kan me wel iets voorstellen bij het hierboven voorgestelde 'softere' systeem, waarbij een plaatje uit Wikidata wordt geïmporteerd, maar dat dat plaatje automatisch vervangen wordt door een ander plaatje als dat met '| afbeelding=' in de infobox wordt toegevoegd. Maar eigenlijk ben ik ook daar geen voorstander van, want het komt ook regelmatig voor dat je er bewust voor wilt kiezen dat er géén plaatje in de infobox komt, bv. omdat er maar één plaatje beschikbaar is, en je dat liever ergens in de lopende tekst zet.

Wat mij betreft wordt dus die hele opgedrongen koppeling van plaatjes vanuit Wikidata opgeheven. Erik Wannee (overleg) 18 apr 2020 15:59 (CEST)

Over vandalisme gesproken: waarom moest die afbeelding van Anour Kali per se weg? Edoderoo (overleg) 18 apr 2020 18:10 (CEST)

Dat is niet Anouar Kali, maar Gregory Schaken: zie hier. Wikiwerner (overleg) 18 apr 2020 18:17 (CEST)

Iemand had zich bij het in delen knippen van deze foto kennelijk vergist; in het bijschrift staan de juiste namen. Voor onervaren Wikipedianen is zo een fout ook moeilijk te vinden. De persoon die nu beschuldigt wordt van een soort lokaal vandalisme herkende blijkbaar dat de naam niet klopte. Het lijkt mij een incident toe. Maar laat wel zien hoe belangrijk de vrije bewerkbaarheid is, en hoe mooi het is dat fouten gecorrigeerd kunnen worden. Elly (overleg) 18 apr 2020 19:55 (CEST)

Ik heb vergelijkbare slechte ervaringen met automatische correcties vanuit Wikidata. Op 10 april werd een foto van Willem Kapteyn vervangen door een slechtere foto van Kapteyn (ook nog in lagere resolutie), omdat die op 4 april in Wikidata ingeruild was. Ik heb de bewerkingen zowel in Wikipedia als in Wikidata inmiddels teruggedraaid, maar volgens mij zou het de voorkeur verdienen om op de Nederlandse Wikipedia geen automatische aanpassingen uit Wikidata toe te staan, maar Wikidata alleen voorstellen op de overlegpagina te laten genereren ("Wikidata heeft een foto etc", "Wikidata heeft een sterfdatum etc"). Ik ben een grote fan van Wikidata, maar automatische doorzettingen veroorzaken fouten, zoals hierboven blijkt. Vysotsky (overleg) 19 apr 2020 15:37 (CEST)

Ik kan me de ergernis van Vysotsky levendig voorstellen, maar een betere reactie lijkt mij, om een interface in te voeren waarmee Wikidata bewerkt kan worden vanuit de infobox of vanaf om het even welk punt waar je gestandaardiseerde gegevens nodig hebt. Dat is waar Wikidata sowieso naartoe moet: vrije bewerkbaarheid en niet, zoals nu, vrije bewerkbaarheid voor nerds.

Als het ontwikkelen van zo'n interface lang gaat duren, zou de voorgestelde stap terug als tijdelijke noodoplossing kunnen dienen — bertux 19 apr 2020 16:00 (CEST)

@bertux, het is nog veel mooier! Die interface bestaat al langere tijd en heet Wikidata bridge. Dan kan je lokaal in de terminologie van Agora (op wikipedia, dus) gegevens in een infobox bewerken. De informatie is gewoon direct zichtbaar op wikipedia en wordt toegevoegd, verbeterd etc op Wikidata. Niks geen gedoe met onderwater-sjablonen, onzichtbare afbeeldingen en andere ongewenste onderdelen. Ecritures (overleg) 19 apr 2020 16:49 (CEST)

Ik denk niet dat Wikidata daar iets mee te maken had. Iemand plaatste op Commons een duplicate sjabloon op de afbeelding en vervolgens verwisselde CommonsDelinker de afbeelding in het wikipedia artikel. Behanzane (overleg) 19 apr 2020 16:41 (CEST)

Wikidata heeft er waarschijnlijk in elk geval iets mee te maken. De dupliceer-actie werd dezelfde dag teruggedraaid, maar zes dagen later werd de afbeelding alsnog ingeruild. Vysotsky (overleg) 19 apr 2020 17:21 (CEST)

De oorzaak ligt niet in de gegevens van Wikidata, maar wel deels in de onbewerkbaarheid van dat project. Wikidata kan alleen een succes worden als je fouten net zo makkelijk kunt verbeteren als op Wikipedia, zonder daarvoor je schrijfwerk op Wikipedia te onderbreken. Dus, zie je een verkeerd gekoppelde foto, dan moet die vanuit Wikipedia met een paar simpele klikken te ontkoppelen zijn, net zo makkelijk als je een Commons-foto van de Sint-Lambertuskerk in Haaren kunt verwijderen van de pagina over de  Sint-Lambertuskerk in Haren. Ook moet je vanuit Wikipedia het automatisch gegenereerde inwonertal van een plaats kunnen aanpassen. En ook moet je vanuit Wikipedia een tabel kunnen maken van modeontwerpers naar geboortejaar door gewoon in een kolomkop 'Modeontwerper' te typen en in de eerste rij 'geboortejaar' en tenslotte op 'Genereer', waarna het ding zelf het juiste aantal rijen en kolommen en een geschikte opmaak bepaalt, uiteraard achteraf wel met de visuele editor aanpasbaar.

Wikipedia is groot geworden door makkelijke, vrije bewerkbaarheid en Wikidata zal klein blijven als het een andere weg kiest — bertux 19 apr 2020 17:03 (CEST)

Ah, ik zie hierboven dat Wikidata Bridge al bestaat. Dat is wat optimistisch voor iets dat nog in ontwikkeling is, maar dit is wel de juiste richting! Dankjewel Ecritures — bertux 19 apr 2020 17:20 (CEST)

(Na BWC) Dat doet die interface toch (Het verbeteren van data die op wikipedia getoond wordt maar gegenereerd wordt van wikidata)?

En ik denk dat Wikidata allang niet meer 'klein' is: op basis waarvan zou je dat willen vergelijken met welke wiki dan ook (momenteel zijn er 82.500.000 lemma's op wikidata). En vergeet niet dat wikidata niet 'een database voor wikipedia's is'. Het is een database die achter honderden, duizenden apps, websites en platforms zit en waar het op enige wijze data aan verschaft (van Moma, Tate Britain tot educatieve instellingen, culturele apps, Scholia, Wikicite etc etc) De mogelijkheden die het biedt aan wikipedia's is maar een bijvangst vergeleken bij het belang die het heeft voor andere producten. Ik hoef de mogelijkheden van Wikidata helemaal niet te pushen hier op wikipedia; ik vind het wel belangrijk om te laten weten welke kansen er hier op de NLse wikipedia onbenut blijven. Nog (persoonlijke schatting) een jaar of vijf en dan is de allesoverheersende rol van wikipedia in bv zoekresultaten uitgespeeld, aanzienlijk verminderd. De huidige technologie als zoekmachines, AI, personal assistants als Siri, Alexa etc halen hun informatie van wikidata en dat zal alleen maar meer en meer worden. Het lijkt me eerder een probleem dat de wikipedia's (nu) al te beperkt (te klein) zijn om 'the sum of all knowledge' te kunnen omvatten, beschrijven, visualiseren.

Anyway, volgens mij doet Wikidata-bridge precies waar jij om vroeg: wikidata driven data *op* wikipedia aanpassen terwijl je 'achter de schermen' de data op wikidata aanpast. Daar merkt een gebruiker niets van, die past gewoon info op wikipedia aan. Ecritures (overleg) 19 apr 2020 17:28 (CEST)

Dat 'klein' was een beetje stokerig, maar qua bewerkersgemeenschap lijkt het me toch een klein project. Het moet wortelen in de samenleving om met de macht van de massa de macht van het geld voor te blijven. En ja, ik maak me al jaren zorgen over de toekomst van het volkomen archaïsche Wikipedia. Maar eens nadenken over een vorm die een discussie daarover niet meteen laat verzanden in onnadenkende, behoudzuchtige opmerkingen (of onnadenkende verziendheid) — bertux 19 apr 2020 17:50 (CEST)

Ik weet dat het op die manier bedoeld was: en ik beet, vooral omdat ik je input over dit soorten zaken zeer waardeer. Ik denk dat die 'verziendheid' (als ik het goed interpreteer) die ik neerzette, niet voortvloeit uit onnadenkendheid. Ik kijk daarentegen wel verder dan wikidata als 'motortje' voor wikipedia. Vaak wordt daar de mening over wikidata aan opgehangen: dit of dat is niet nuttig, noodzakelijk, wenselijk voor wikipedia *dus* wikidata kan maar beter opgedoekt worden. Als je kijkt naar de relevantie van Wikidata voor andere projecten in bv de culturele erfgoedsector of binnen educatieve en wetenschappelijke organisaties, dan is wikipedia echt maar een kleine 'belanghebbende'.

En wat betreft de grootte van de bewerkingsgemeenschap van wikidata die is oneindig groot. Ik weet dat er in ieder geval in Nederland heel veel meer erfgoedinstellingen, educatieve en wetenschappelijke organisaties zich actief bewegen op wikidata dan op wikipedia. Ik denk dan doe daar je voordeel mee, als wikipedia. (Ik heb voorbeelden gegeven bij de coronacrisis) maar ik kan je op heel veel vlakken voorbeelden geven waar informatie op Wikidata echt veel betrouwbaarder, vollediger, diepgaander is dan op de Nederlandstalige (en ook Engelstalige) wikipedia. Ik kan er nog steeds niet bij waarom we niet gebruikmaken van die informatie om (zelf= mens) artikelen te schrijven voor wikipedia. Ter illustratie: op de Papiamentu wikipedia (als je het nu over een kleine bewerkersgroep hebt) en op andere wiki's van kleine talen, zien ze wel degelijk de waarde in van het automatisch genereren van een wikidata driven infobox. Je hebt namelijk, als beginnende of niet-ervaren gebruiker meteen een basisset van informatie voorhanden die op je scherm wordt getoond. Vergeet ook niet dat Wikidata op verschillende manieren heel veel bronnen en linken naar andere databases met informatie/data toont. Je hebt dus - met het wikidatalemma - direct een goede start voor het schrijven van een artikel (NB niet op basis van de wikidata-gegevens maar door wikidata te gebruiken als een soort ANWB-paddenstoel waarbij verwezen wordt naar veel bronnen. Ecritures (overleg) 19 apr 2020 18:30 (CEST)

Het invoegen van data in lemma's kan op zich best nuttig/zinvol zijn. Wat echter nmm te weinig aandacht krijgt is dat het heel lastig is om als bewerker van wikipedia fouten in die data te corrigeren. Als je zo'n verkeerde foto tegenkomt zou het mogelijk moeten zijn die zonder tussenstappen aan te passen, dan heeft wikidata ook voor de onervaren gebruiker een meerwaarde, nu lijkt het een beetje een bigbrother die zelf bepaald wat wel en wat niet in een lemma/infobox moet staan. Met name het automatisch herstellen van een terechte aanpassing zou niet moeten mogen. Peter b (overleg) 19 apr 2020 21:57 (CEST)

Ik heb geloof ik in dit topic op z'n minst twee keer uitgelegd hoe dat heel eenvoudig geregeld kan worden (door als er niets is ingevuld wikidata te gebruiken en als er wel iets is ingevuld die informatie te gebruiken); maar misschien had je die informatie nog niet gelezen voordat je deze reactie plaatste? Groet, Ecritures (overleg) 19 apr 2020 22:12 (CEST)

Aanpassing WP:BTNI

Voor zo'n veel aangehaalde pagina vind ik de respons hier eigenlijk wat tegenvallen. Staat dit (net als WP:OG) bij weinigen op de volglijst of vindt iedereen de voorgestelde aanpassingen wel prima? Encycloon (overleg) 18 apr 2020 23:12 (CEST)

Ik vermijd langdradige discussies waar het alleen maar om het discussiëren gaat. De intentie is vaak goed en het doel van de initiator is dat dan meestal ook, maar van veel deelnemers niet. Zelfs goedbedoelde kopjes hier in de kroeg, bedoeld om mensen een glimlach te bezorgen worden vaak de kop ingedrukt. Dat ik de kroeg nog op mijn volglijst heb staan is een wonder. Dqfn13 (overleg) 18 apr 2020 23:17 (CEST)

Het is een bescheiden wijziging (verduidelijking) en goed gemotiveerd: geen bezwaar. Zwitser123 (overleg) 19 apr 2020 08:16 (CEST)

BTNI vind ik zo kansloos en het allerbeste voorbeeld van de gemankeerde wikipedia-cultuur. Ik vind het na drie jaar nog steeds verbazingwekkend hoe wikipedianen het gebruiken als een soort werkverschaffing waarbij ze vooral hun eigen voorkeur willen doordrukken. Vrij bewerkbare encyclopedie... wacht maar totdat je door BTNI-fanaten achterna wordt gezeten. Ecritures (overleg) 19 apr 2020 18:32 (CEST)

BTNI zou vooral een raamwerk moeten zijn om ruzie en editwars te voorkomen bij het al dan niet doordrukken van de eigen voorkeur. Je bent inderdaad niet vrij om bewerkingen te doen waar geen steun voor bestaat. — Zanaq (?) 19 apr 2020 18:38 (CEST)

@Ecritures: ik gebruik het zeer zelden, als ik het gebruik dan is het omdat iemand hun eigen foto wilt plaatsen op een plek waar het geen verbetering is. Voor tekstuele wijzigingen waarbij er vooral meer woorden gebruikt worden, terwijl er geen extra informatie bij komt. Dqfn13 (overleg) 19 apr 2020 21:31 (CEST)

De pagina staat idd niet op mijn volglijst, maar het ziet er inderdaad als een verduidelijking uit. — Zanaq (?) 19 apr 2020 18:38 (CEST)

De vermelding van WP:BGN bij spelling moet nog weg. Er is geen enkele reden speciaal deze richtlijn te vermelden want er zijn meerdere richtlijnen over de naamgeving van artikelen. Bij dit specifieke geval volgt later zelfs nog een expliciet voorbeeld: niet Lille in Rijsel wijzigen. Dat is afdoende. ♠ Troefkaart (overleg) 19 apr 2020 20:26 (CEST)

Met BTNI wordt geregeld gedoe voorkomen voordat het ontstaat en daarom is dit zo'n belangrijke richtlijn. Het tekstvoorstel dat er nu ligt kan mijn instemming krijgen. Ymnes (overleg) 19 apr 2020 20:38 (CEST)

Weer bij Lubach

Olifant of dennenappel?

Hallo, we zijn weer bij Zondag met Lubach. Gaat over de beschrijving van dieren ("dennenappels"). :-) Ziko (overleg) 19 apr 2020 23:08 (CEST)

Ook bij Lubach lijken ze de licentie van afbeeldingen niet te begrijpen. (Bron: Wikipedia) — Zanaq (?) 20 apr 2020 00:09 (CEST)

Gelukkig hebben ze daar dan weer wel verstand van humor. — Matroos Vos (overleg) 20 apr 2020 02:41 (CEST)

Riviergezicht te Londen (Witsen)

Ik probeer een doorverwijspagina te maken voor Riviergezicht te Londen (Witsen). Ik faal daarin echter. Ik kan mij niet voorstellen dat Willem Witsen de enige was die een schilderij rond dat thema maakte. Ik denk dat ik wat over het hoofd zie. Iemand advies wat past op een doorverwijspagina? The Banner Overleg 9 apr 2020 14:26 (CEST)

Het klinkt vast onaardiger dan ik bedoel, maar soms lijkt het wel een doel op zich, zo'n doorverwijspagina. Lijkt me vaak juist iets wat je oplost als het probleem zich voordoet. Of zie ik iets over het hoofd? Vinvlugt (overleg) 9 apr 2020 14:35 (CEST)

Het doel is het leegmaken van een onderhoudspagina. Die pagina (en de aanmaker daarvan) meent dat er een probleem is dat opgelost moet worden. The Banner Overleg 9 apr 2020 14:43 (CEST)

En welk probleem is dat concreet? Vinvlugt (overleg) 9 apr 2020 15:04 (CEST)

De titel van die lijst is daar duidelijk in: Wikipedia:Onderhoud/haakjes/GeenArtikelZonderHaakjes1. Maar ik heb dit al een keer of veel uitgelegd aan jou. Maar heb je ook enig advies over de originele vraag? The Banner Overleg 9 apr 2020 15:42 (CEST)

Dus je wil een pagina Riviergezicht te Londen die al direct een DP wordt, of eerst een redirect? Dan kan deze later een DP worden als er nog een schilderij- of ander artikel komt met die titel. Nietanoniem (overleg) 9 apr 2020 15:55 (CEST)

Liefst gelijk een doorverwijspagina maar tot op heden heb ik daar geen kandidaten voor gevonden. Vandaar mijn vraag om hulp. Alternatief is inderdaad het inkorten van de huidige titel. The Banner Overleg 9 apr 2020 16:02 (CEST)

Als al niet duidelijk is wat de titel van de doorverwijspagina moet zijn, is er toch geen probleem? Titel met haakjes is dan voldoende voorbereid op de toekomst. Misschien kijk ik er in ogen van sommigen te simpel tegenaan, maar ik voorkom graag moeilijke zaken. Lekker zo laten is mijn advies. Nietanoniem (overleg) 9 apr 2020 16:23 (CEST)

Ik begrijp dat het vooral een probleem is dat er (nog) geen kandidaten zijn om op die doorverwijspagina te zetten. Mijn, wellicht ook te simpele kijk op de zaak is dan: waarom dan überhaupt een DP aanmaken? Vinvlugt (overleg) 9 apr 2020 16:35 (CEST)

Dat heeft mijn voorkeur omdat er dan geen artikelen van naam hoeven te veranderen. The Banner Overleg 9 apr 2020 17:07 (CEST)

@The Banner, is het een technisch probleem die haakjes, of meer een inhoudelijke keuze? Is er ergens besloten dat haakjes onwenselijk zijn? Ik snap oprecht niet wat er mis is met de huidige titel. Ben trouwens wel benieuwd wat de auteur van het artikel, Pimbrils, ervan vindt. Vinvlugt (overleg) 9 apr 2020 15:57 (CEST)

Haakjes geven aan dat er om een bepaalde reden disambiguatie is gebruikt, maar als er maar 1 titel is, is die disambiguatie niet nodig, zeker vanuit technisch oogpunt niet. Als ik niet vrij vlot een kandidaat voor een DP kan vinden, dan hernoem ik de pagina gewoon. Zodra er toch een tweede pagina komt, komt die doorverwijspagina er immers ook, al dan niet met behulp van een moderator om die pagina weer "vrij" te maken. Dat zou ik The Banner in deze ook willen aanraden. Als de oorspronkelijk aanmaker van het artikel dwars gaat liggen bij de titelwijziging, mag die een goede reden aangeven waarom haakjes per se nodig zijn. Dat ben ik eigenlijk alleen nog maar tegen gekomen bij muziektitels, als de artiest een soort ondertitel verzint als in Pump up the Volume! (I wanna dance) of zoiets. Maar in 9 van de 10 van zulke gevallen is er dan nog zo een titel, die een doorverwijspagina al weer rechtvaardigt. Edoderoo (overleg) 9 apr 2020 17:09 (CEST)

Als een titel dankzij een toevoeging tussen haakjes om de een of andere reden duidelijker is dan zonder haakjes, wat hier volgens mij het geval is, moeten we ze gewoon kunnen gebruiken. Daaraan dienen onze interne regels en afspraken volgens mij ondergeschikt te zijn. Marrakech (overleg) 9 apr 2020 19:40 (CEST)

Dat zet de deur open naar titels zoals Almelo (Overijssel) want "dat is duidelijker voor wie niet weet dat Almelo in Overijssel ligt". Daarom liever alleen als het deel uitmaakt van de naam van onderwerp, zoals in Per spoor (Kedeng kedeng). Het melkmeisje heet ook niet Het melkmeisje (Johannes Vermeer). Wikiwerner (overleg) 9 apr 2020 20:13 (CEST)

Eens met Marrakech. Er is geen reden om aan te nemen dat het angstbeeld van Wikiwerner ook daadwerkelijk bewaarheid wordt. Artikelnamen verduidelijken door middel van een toevoeging tussen haakjes is in een hoop gevallen een verbetering en een nuttige (inhoudelijke) toevoeging. Ecritures (overleg) 9 apr 2020 22:24 (CEST)

Maar in strijd met WP:BENOEM. The Banner Overleg 9 apr 2020 22:41 (CEST)

Beste The Banner, zou je zo concreet mogelijk aan kunnen geven welk probleem oplossing verdient en wat je van ons verwacht? Vinvlugt (overleg) 9 apr 2020 23:19 (CEST)

Zoals in de oorspronkelijke vraag al staat: Iemand advies wat past op een doorverwijspagina? The Banner Overleg 10 apr 2020 00:40 (CEST)

Maar in strijd met WP:BENOEM. The Banner Overleg 9 apr 2020 22:41 (CEST)

Naar mijn mening is dat niet het geval. Ecritures (overleg) 9 apr 2020 23:09 (CEST)

Kunnen we nu weer verder gaan met de oorspronkelijke vraag? The Banner Overleg 9 apr 2020 21:33 (CEST)

Verwacht je echt veel met precies deze titel of met precies dit thema? Zoveel wordt er niet over individuele schilderwerken geschreven. Google leverde niet veel op met river+view+painting+London en Riviergezicht+Londen. De Engelse Wikipedia heeft wel iets met river+view+London, maar niet om van achterover te vallen. Er is gewoon geen reden voor een dp, zoals de anderen, die slimmer zijn dan ik, al impliciet aangegeven hebben. Tip: lees wat goedwillende mensen bedoelen maar niet schrijven — bertux 9 apr 2020 22:42 (CEST)

Per bertux. (Zie bijvoorbeeld ook de eerste reactie van Vinvlugt die het algemene gevoel goed weergeeft) En qua riviergezicht (op de Thames) zijn de schilderijen van Monet nog onvergetelijker dan die van Witsen bijvoorbeeld; al zijn die specifiek vernoemd naar de 'Houses of Parliament'. Groet, Ecritures (overleg) 9 apr 2020 23:18 (CEST)

Ik ben bijna altijd voorstander van waar mogelijk disambigueren, maar hier eigenlijk niet zo. Als er meer (bekende) schilderijen zijn met de naam Riviergezicht te Londen, is disambigueren hier gewenst. Anders niet natuurlijk, tenzij Riviergezicht te Londen ook nog de naam is van iets anders (een boek bijvoorbeeld, weet ik wat). @gebruiker:The Banner: hoe weet je eigenlijk zo zeker dat er meer schilderijen met deze naam zijn, heb je daar ook bronnen voor?

Overigens hoort deze discussie eigenlijk in Wikipedia:Doorverwijscafé, lijkt me. Overzetten? De Wikischim (overleg) 9 apr 2020 23:35 (CEST)

Wat is het precieze voordeel van het overhevelen van deze discussie? Vinvlugt (overleg) 9 apr 2020 23:46 (CEST)

We kunnen Wikipedia:Doorverwijscafé natuurlijk ook gewoon opheffen. De Wikischim (overleg) 9 apr 2020 23:52 (CEST)

Dat lijkt me geen goed idee. Wat me wel een goed idee lijkt, is niet te snel te opperen dat een discussie verplaatst zou moeten worden. Vinvlugt (overleg) 10 apr 2020 12:32 (CEST)

Ik heb geen enkel bewijs dat er meer zijn, Wikischim. Het verbaasde mij dat ik er geen kon vinden en vroeg dus om hulp bij het vinden daarvan. Met inderdaad een kans dat er nul suggesties zouden komen. Maar er wordt aan alle kanten opvallend slecht gelezen. Daarnaast, Wikischim, gaat het hier niet om een vraag over de doorverwijspagina zelf maar voor suggesties voor items voor en dp. Dat kan beter op een breder platform. The Banner Overleg 9 apr 2020 23:56 (CEST)

Als de premise ('er moet een dp komen') verkeerd is, dan heeft het niets met slecht lezen te maken dat er nul suggesties komen. Dat heeft te maken met het feit dat de meesten hier vinden dat er geen noodzaak of nut is om een dp te maken als er geen andere items zijn die op een dp vermeld moeten worden. Je verwart het middel met het doel. Ook een titel met haakjes kan gewoon op zichzelf bestaan zonder dp. Ecritures (overleg) 10 apr 2020 00:02 (CEST)

Mag ik je aanraden de oorspronkelijk vraag eens te lezen? The Banner Overleg 10 apr 2020 00:38 (CEST)

Er zijn natuurlijk zeer veel schilderijen gemaakt van de Thames in London. Waarom die dan "riviergezicht te Londen" zouden moeten heten is mij volstrekt onduidelijk. Er zijn talloze titels te bedenken, zoals zicht op de Thames, de rivier Thames in Londen, etc. etc. Bovendien is volstrekt onbekend hoeveel Nederlandstalige schilders de Thames geschilderd hebben. Totaal zinloze doorverwijspagina dus. Elly (overleg) 10 apr 2020 00:06 (CEST)

Mag ik je aanraden de oorspronkelijk vraag eens te lezen? En nee, ik denk niet nedercentrisch. The Banner Overleg 10 apr 2020 00:38 (CEST)

antwoord = je faalt + er hoeft niets op een dp + er hoeft geen dp te komen. dus je krijgt geen antwoord want de vraag is niet zinvol. krijg ik antwoord op deze vraag: wie komt er nog meer op mijn paasbrunch? antwoord geen. er komt niemand meer bij want ik geef geen paasbrunch. ook een vraag die niet zinvol is. Elly (overleg) 10 apr 2020 09:42 (CEST)

We zijn op de wereld om mekaar te helpen, niewaar The Banner Overleg 10 apr 2020 11:19 (CEST)

(na 2x bwc) Tip: hernoem het artikel naar de titel uit noot 1: De Theems bij Londen (Witsen). Ook Jan Toorop heeft een schilderij gemaakt dat met die titel wordt aangeduid De Theems bij Londen (Toorop). Is zelfs een boek over verschenen omdat het roofkunst was. Dan zijn de haakjes nodig en nuttig. O wacht, dan blijft er natuurlijk nog steeds een redirect met haakjes over... Wat doen we daar dan mee? Met vriendelijke groet, Gasthuis(overleg) 10 apr 2020 00:07 (CEST).

Gasthuis, het artikel heeft de titel die het Kröller-Müller, waar het doek hangt, eraan heeft gegeven (zonder de toevoging Witsen), dus die zou ik niet lichtvaardig veranderen — bertux 10 apr 2020 00:12 (CEST)

Het RKD, toch niet de minste, geeft het schilderij de titel Gezicht op de Thames in Londen. In een Kröller-Müller-catalogus uit 1921 krijgt het al wel de titel Riviergezicht te Londen. Toen was het schilderij overigens nog 77 bij 97 centimeter. Inmiddels is het volgens ons artikel gegroeid naar 79 bij 100 centimeter. Kwestie van op tijd water geven, denk ik. — Matroos Vos (overleg) 10 apr 2020 00:36 (CEST)

Die redirect komt niet in de onderhoudslijsten en staat mij dus niet in de weg. En voor Gasthuis, Bertux en Matroos Vos: als jullie nu kijken wat dan wel de juiste titel is, dan kan ik op basis daarvan verder werken. Inclusief Toorop. The Banner Overleg 10 apr 2020 01:15 (CEST)

Dé juiste titel van een schilderij bestaat lang niet altijd. Het is sowieso pas sinds enkele eeuwen de gewoonte om schilderijen een naam te geven. Veel titels zijn ook eerst later door kunsthistorici, kunstcritici, conservatoren, verzamelaars etc. verzonnen. Rembrandt heeft zijn beroemde schilderij zelf nooit De Nachtwacht genoemd. En iemand als Mondriaan liet het bedenken van titels bij tijd en wijle rustig aan de kunstverzamelaar Sal Slijper over.

Kunstenaars willen de titels van hun schilderijen ook nog wel eens wijzigen. Een mooi voorbeeld daarvan is Manets befaamde Le Déjeuner sur l'herbe, dat hij aanvankelijk onder de titel Le Bain exposeerde. Om de kleinburgers van zijn tijd nog net wat meer te provoceren, koos hij pas later de huidige, uitdagende titel – immers, de aanwezigheid van een naakte vrouw tijdens een picknick is oneindig veel schokkender dan een zich naakt badende vrouw. Afunctioneel naakt, zogezegd.

Hoe het precies zit met de wat zouteloze, louter beschrijvende titel(s) van dit schilderij van Witsen zou ik niet weten. Wellicht zijn ook die pas later verzonnen door een stelletje brave kunstklerken, maar hopelijk kan de schrijver van het betreffende lemma je daar aan de hand van de gebruikte catalogus meer over vertellen. — Matroos Vos (overleg) 10 apr 2020 06:56 (CEST)

Met dat stelletje brave kunstklerken heeft Matroos Vos ongetwijfeld gelijk; ik heb geen indicatie kunnen vinden dat Witsen al zijn werk benoemde. Zie bijvoorbeeld: Een enkele keer kan men vraagtekens zetten bij de topografische beschrijving van een prent. Zijn bij nummer 150 werkelijk de torens van de St. Nicolaaskerk te zien? Het lijkt eerder het silhouet van De Posthoorn aan de Haarlemmerstraat. Aan het groeien of krimpen van een werk hoeft geen Pokon of kookwas te pas te komen: Witsen maakte vaak meerdere, soms sterk gelijkende versies van een werk en het Amsterdamse doek dat de RKD beschrijft is dan ook een ander dan het Otterlose uit het artikel van Pimbrils. De RKD noemt ook nog twee aquarelversies.

Zelf zou ik de stroomopwaarts zwoegende sleepboot in de titel verwerkt hebben, maar het lijkt me, dat de naam die de Veluwse verzamelaars kozen maatgevend moet zijn, aangezien Pimbrils specifiek het olieverfschilderij uit de Kröller-Müller-collectie beschrijft — bertux 10 apr 2020 10:41 (CEST)

Dank bertux en Matroos Vos voor al deze boeiende informatie! Dít is nu precies wat het zo leuk maakt om samen te werken aan een encyclopedie. Ecritures (overleg) 10 apr 2020 11:14 (CEST)

Nou, de conclusie lijkt te zijn dat iedereen slecht leest behalve een, en dat we over kunnen gaan tot de orde van de tweede paasdag! (P.S. Iemand gisteren Paulien Cornelisse gezien? Over mensen die niet in problemen maar in oplossingen denken: "ja maar dan toch wel in oplossingen voor problemen, mag ik hopen?" 😉) Vinvlugt (overleg) 13 apr 2020 15:13 (CEST)

Och, ik heb simpelweg de conclusie getrokken dat deze discussie geen oplossing levert. En dus doe ik niets, ter meerdere eer en glorie van de encyclopedie. The Banner Overleg 19 apr 2020 17:48 (CEST)

Heerlijk, deze bescheidenheid! Vinvlugt (overleg) 20 apr 2020 09:37 (CEST)