Please use "Panel painting", as this will not create false positives for disambiguation links. Cheers! ~~~~
About this board
Welcome to Wikidata, Spinster!
Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!
Need some help getting started? Here are some pages you can familiarize yourself with:
- Introduction – An introduction to the project.
- Wikidata tours – Interactive tutorials to show you how Wikidata works.
- Community portal – The portal for community members.
- User options – including the 'Babel' extension, to set your language preferences.
- Contents – The main help page for editing and using the site.
- Project chat – Discussions about the project.
- Tools – A collection of user-developed tools to allow for easier completion of some tasks.
Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.
If you have any questions, please ask me on [[User talk:|my talk page]]. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.
Best regards! Cycn
Previous discussion was archived aton 2016-06-16.
"Panel" is a disambiguation page
Hi BD2412, I assume you are making this comment because of odd links in infoboxes on English Wikipedia? Let's see how we can solve this. In fact, on Wikidata, panel (Q1348059) is not a disambiguation item at all - it links to normal Wikipedia pages in Dutch, Gaelic and German and it is widely used as the (correct) generic term to describe a flat, usually wooden, painting surface. panel painting (Q55439) is a type of painting, not a material. Maybe @Mike Peel has a suggestion as builder of the enwiki infobox...?
Can the Wikidata value for the English meaning be changed, so that it does not invoke the disambiguation page when called into English Wikipedia? False positive disambiguation links from Wikidata calls are a fast-growing problem. ~~~~
Can you share an example entry/article, please?
The six pages for which I made this fix earlier today - Man in a gorget and a plumed cap (Q21406066), Young Lady Playing a Clavichord (Q23890828), Resurrection of Christ (Q677682), The Baptism of Christ (Q2632688), The Last of England (Q958245), Two Male Heads (Q1851182) - all created a false positive to the English Wikipedia disambiguation page "Panel". This is not the first time. Vladimír Morávek created a link to the disambiguation page, "Director", before I changed it. Théâtre antique d'Orange (Q958961) and Triumphal Arch of Orange (Q1777218) created links to the disambiguation page "Orange" (for which the city and France is very low on the list of meanings).
I'm having difficulties reproducing this. See https://en.wikipedia.org/wiki/Bust_of_a_Man_Wearing_a_Gorget_and_Plumed_Beret - does the dab link still appear after I've added "panel" back to the Wikidata entry? I can't spot it...
Ah, I see it now, thanks. It seems to track back to the WikidataIB call (see https://en.wikipedia.org/wiki/User:Mike_Peel/Sandbox2 which also appears in the WhatLinksHere page), so I think this needs help from @RexxS to fix.
I can't fix it. The problem goes like this:
In the infobox for en:Bust of a Man Wearing a Gorget and Plumed Beret we fetch material used (P186) from Wikidata. that is "panel (Q1348059)" - a wikibase-entity, i.e. a potentially linkable item. So we look for the English site-label in that entry, and there isn't one. That means one of 3 things: (1) the article en:Panel doesn't exist; (2) it's a disambiguation page; or (3) it's a redirect.
Unfortunately, Wikidata doesn't allow us to use a site-label for redirects (so archaeologist (Q3621491) doesn't have a site-label to en:Archeologist, for example). So we have to test whether the page "Panel" exists on the English Wikipedia; if it does, we check if it's a redirect and link it, otherwise we don't link it. The act of checking whether "Panel" exists (or is a redirect) creates a spurious link from "Bust of a Man Wearing a Gorget and Plumed Beret" to "Panel". That is a bug that's been tracked at phab:T14019 for the last 10 years.
I think you'll find my code works exactly as intended (and as I expected, given the bug). I suggest there are two choices: either Wikidata allows site-labels to point to sensible redirects (such as to a subsection of larger article); or the devs fix the bug in T14019.
What about articles having completely different meanings on different Wikiprojects? Or having a disambiguation page on one project but no article corresponding to the meaning of the Wikidata term? Fetching material without prior human oversight seems like a recipe for disaster, even without the disambiguation issue that it is presently causing.
On Wikidata an item's property (like material used (P186)) is linked to one meaning of its value on Wikidata. Items with different meanings on different Wikiprojects have different entries on Wikidata, so no problem arises. For example, if several people were born in several different places all called "Newport", each Wikidata entry for the subject would link to only one of them - that's why we have Q-numbers as unique identifiers.
We don't link to disambiguation pages, for obvious reasons, so it doesn't matter whether the specific meaning of something like "Panel" is on the dab page; it doesn't get a link anyway. Only redirects are linked.
The prior human oversight occurs on Wikidata and calling it a "recipe for disaster" is both facile and disrespectful to the efforts of Wikidatans who are trying to curate the vast amount of data in existence here.
Fetching data from Wikidata for use in English Wikipedia isn't going to go away, so it's no use burying your head in the sand. There is no issue with disambiguation, merely an over-simplistic attitude to article redirects here, and a lack of response from devs to a problem that has been causing problems since 2007 and before. Your indignation and energies would be better spent lobbying for a fix to these structural problems, than putting the blame on editors who are fully aware of these problems and are trying their best to do something about them.
I am one of the most experienced editors on English Wikipedia, and I have found it incredibly frustrating trying to figure out what is causing false positive disambiguation reports to arise for terms like "Panel", "Orange", "Castro", and "Victoria". I can't imagine the confusion these errors cause to new editors trying to contribute to fixing them.
I'm pleased that you're one of the most experienced editors on English Wikipedia, and I'm sorry you find it frustrating trying to figure out what is causing false positive disambiguation reports to arise. But now you know. Perhaps next time you might consider asking someone who knows why they arise, rather than getting frustrated?
I can imagine the confusion new editors experience, and I assure you I've tried to see the sources of the problems fixed. Perhaps you'd like to help them as well by helping persuade Wikidata devs to enable site-linking to sensible redirects and the MediaWiki devs to fix the T14019 bug?
Maybe Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata will fix it in the end, if that goes anywhere...
Structured Data on Commons Newsletter, July 19, 2017
Welcome to the newsletter for Structured Data on Wikimedia Commons! You can update your subscription to the newsletter. Do inform others who you think will want to be involved in the project!
Structured Data on Wikimedia Commons?
The millions of files on Wikimedia Commons are described with a lot of information or (meta)data. With the project Structured Data on Wikimedia Commons, this data is structured more, and is made machine-readable. This will make it easier to view, search (also multilingually), edit, organize and re-use the files on Commons.
In early 2017, the Sloan Foundation funded this project (see documentation). Development takes place in 2017–2020. It involves staff from the Wikimedia Foundation and Wikimedia Deutschland (WMDE) and many volunteers. To achieve this, Wikibase support is added to Wikimedia Commons. Wikibase is the technology that is also used for Wikidata.
Recent developments: groundwork
- A new and crucial technical step (federation) now makes it possible to reference data from one Wikibase website in another. Because of this, it will be possible to use Wikidata's items and properties to describe media files on Commons.
- Another important piece of groundwork is under development: so-called Multi-Content Revisions. This feature allows structured data to be stored alongside wiki text, so that one wiki page can contain several types of content.
- Amanda Bittaker was hired as Program Manager for Structured Data on Wikimedia Commons. Amanda will take care of the overall management of the project.
- Sandra Fauconnier (known as Spinster in her volunteer capacity) is the new Community Liaison. She will support the collaboration between the communities (Commons, Wikidata, GLAM) and the product development teams at the Wikimedia Foundation and Wikimedia Deutschland.
- We have open positions for a UX designer and a Product Manager!
Talking with communities and allies
- Long-term feedback from GLAMs. Besides the Wikimedia community, many external cultural and knowledge institutions (GLAMs - Galleries, Libraries, Archives and Museums) are interested in Structured Data on Commons and are willing to provide feedback on the long-term plans for the project. Alex Stinson, GLAM strategist at the Wikimedia Foundation, is currently in contact with Europeana, DPLA, the Smithsonian and the National Archives of the United States. Alex is also looking for other GLAM institutions who might be able to advise on the long term. If you know of an institution or partner that may be appropriate for consultation, do get in touch with Alex.
- Jonathan Morgan, design researcher, is starting to work on two projects:
- Researching batch upload workflows by interviewing GLAM institutions
- Researching the enrichment, organization and improvement tasks on already uploaded media files by engaging with active Commons contributors. This research follows up on existing research by Wikimedia Deutschland on heavy Commons users.
What comes next?
- The Structured Data on Commons team meets in the week after Wikimania to lay the groundwork for the next steps. This includes new backend development and design work, for better and more clear integration of the structured data in pages on Wikimedia Commons.
- The project's information pages on Wikimedia Commons will receive a long overdue update in the upcoming months. The team will also work on more and better communication channels. Feedback, wishes and tips are welcome at the project's general talk page.
- Join us at Wikimania! We are present at the hackathon, and there will be a session on Saturday, August 12: Structured Commons: what changes are coming?
- Follow the Structured Data on Commons project on Phabricator: https://phabricator.wikimedia.org/project/profile/34/
- Subscribe to this newsletter to receive it on a talk page of your own choice.
- Do you want to help out translating messages about Structured Data on Commons from English to your own language? Sign up on the translators page.
- Stay tuned for requests for input, discussion and participation as soon as the info portal is refreshed (see above). These will also be announced via this newsletter.
Hoi Lymantria, ja, goed punt.... ik vond het zelf 't leukste om het centraal op meta te registreren, want dan 'lokken' we misschien ook nog nieuwkomers uit andere projecten die anders niet aan Wikidata gedacht zouden hebben. Ik zou het persoonlijk liever niet op verschillende plekken parallel doen, want dat is weer extra gedoe... Wat had jij in gedachten?
Nou ja, het duurde bij mij gewoon even voor ik in de gaten had dat ik op meta moest wezen om mijn naam achter te laten. Een lijstje op wd zelf is denk ik wat uitnodigender. Maar twee lijstjes, daar heb je gelijk in, dat gaat gegarandeerd mis. Sais pas.
Ben je gestrand in je 100wikidatadays?
Ja, helaas wel :-(
OK. Na enig onderzoek ben ik (onderbouwd/gemotiveerd) tegenstander van verwijdering van de property, ik zal het alternatief beschrijven op de nominatiepagina. Groetjes!
Hi Spinster, I have added some proposed properties and would like your opinion about those if possible:
- Wikidata:Property proposal/public domain date
Main page translations
Hi Jura1, my apologies, I have made a mistake there indeed, it was not my intention to do that (I was confused with another page). Thanks for fixing it.
Many empty items
Thanks for pointing this out; I had not noticed it in my edit history. It's a QuickStatements (version 2) batch that I ran in the background and that apparently created many empty items (I just saw that it produced many errors but saw no more information than that). Alerting @Magnus Manske - when I re-ran the batch in 'normal' (non-background) mode, it apparently went fine.
KMSKA RKD link
Hoi Sandra, ik heb lekker wat zitten te puzzelen en een hoop schilderijen van het KMSKA automatisch weten te koppelen aan RKDimages. Kan jij eens door KMSKA_RKD_to_match#Auto_added_links kijken of er niets vreemd is gegaan? De koppeling is gebaseerd op zelfde collectie (KMSKA in dit geval), zelfde inventarisnummer en link naar dezelfde RKDartist. De enige fout die ik bij andere collecties ben tegengekomen is dat er van een schilder meerdere schilderijen door elkaar zijn gehaald.
Daarnaast staan er allerlei nieuwe suggesties waar je wellicht wel mee aan de slag wilt.
Property is now used.
This is a kind reminder that the following property was created more than six months ago: MSK Gent work PID (P2511). As of today, this property is used on less than five items. As the proposer of this property you probably want to change the unfortunate situation by adding a few statements to items.
Thanks for the reminder, it had indeed escaped my attention and it's simple to fix. Getting to work.
I am informed :D
Aha! That's the one! Will do.