Open main menu
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days.


How to mass-populate depicts statements?Edit

I've been hoping that the work over the last year to sync up Commons categories with Wikidata will have a big influence on how we now populate depicts statements - we can go through the category information to add the relevant wikidata items to the depicts statements. However, I think there are currently three big issues with this as we come up to the release of the feature here:

  1. Claims of copyright. Although everything on the Wikidata site is CC-0, including the category sitelinks, presumably someone's going to make the claim that categories added to images here aren't CC-0, which will hold things back (as they did the captions).
  2. Bot access to edit depicts statements. I haven't seen anything about this yet, presumably it will be possible using the same interface as is used on Wikidata, but when I was looking at this for the captions everything had to go through the API, which was painful (and I don't know how to do this for properties).
  3. Closing the loop - being able to then access the depicts statement in wikitext, so we can use it in templates such as {{Artwork}}, and auto-add the categories based on it.

There are also other issues (categories that don't have wikidata items, bot requests to go through, etc.), but I think the above three are the major ones. What does everyone think about this as things stand? Thanks. Mike Peel (talk) 19:48, 1 April 2019 (UTC)

Correct, categories have been named and created under CC-BY-SA licensing.
Mass populating depicts statements, then using them to manipulate image page content, is a ruddy nightmare scenario. We will automatically mass populate Commons with useless cruft like "photo in black and white" or "WWI photo" for photographs taken haphazardly in the WWI period that have nothing to do with the war. Volunteers will run around in circles and never make it meaningful. -- (talk) 20:02, 1 April 2019 (UTC)
@Fae: It wouldn't be the name of the category that you would be taking, just whether or not a particular image had been allocated to it. More difficult to argue that that is protected by copyright.
@Mike Peel: A major problem is that the categories on images very often are not 'simple' categories with a matched Q-number, but are 'compound' categories, for which the Wikidata community has (so far) refused to allow wikidata items to be created. How to deal with this? Jheald (talk) 22:05, 1 April 2019 (UTC)
Regarding (2), QuickStatements for Commons is in the works, I believe.
Regarding (3): A problem again with auto-categorisation is when pictures should be put into direct categories corresponding to SDC/Wikidata statements, and when they should be placed in sub-categories corresponding to multiple SDC/Wikidata statements being present together. Difficult to automate this without a machine-interpretable statement of what a category represents. Jheald (talk) 22:10, 1 April 2019 (UTC)
Not to mention: a given image may have legitimate categories that have little to do with what is depicted. E.g. it would be perfectly appropriate to have a picture of a house designed by person A and dwelt in by person B in the categories for both of those people, neither of whom is depicted. City A's exhibit at a fair in City B might be in the category for City A (as well as city B) even though it does not depict City A. - 01:41, 2 April 2019 (UTC)
— Preceding unsigned comment added by Jmabel (talk • contribs)
@Jheald: I was focusing on overall blockers, the absence of Wikidata entries for some items just reduces the number of depicts statements that could be added, until they have Wikidata items. We could also set up a template here to say "this category is a compound of QXX and QYY" if needed, but that means using qids manually, which isn't particularly nice. (2) I think QuickStatements would have the same issue as pybot with regards accessing Wikibase here to edit the information. (3) is a problem that can be dealt with in stages (like the infobox has gained auto-categorisation functions over the last year), but at the moment we can't do *anything* until we can access the structured data information in a template.
@Jmabel: The way I'd handle that would be to create a category and linked wikidata item for the house, then do depicts=<house item>, and have the category for the house as a subcategory of the people. Similar with an exhibit. Thanks. Mike Peel (talk) 06:54, 2 April 2019 (UTC)
Sure, but that is nothing a bot can do. - Jmabel ! talk 15:50, 2 April 2019 (UTC)
@Keegan (WMF): Any comments? Thanks. Mike Peel (talk) 17:38, 16 April 2019 (UTC)
@Mike Peel: Magnus Manske has ideas, I think. You're best talking to him about it. Keegan (WMF) (talk) 18:52, 16 April 2019 (UTC)
@Keegan (WMF): I'm not sure how Magnus can help here, surely the onus is on the SDC team to provide some way to automate access to the data within MediaWiki/Lua and through some sort of machine-readable/writeable interface at least? Or will everything have to be done by hand/copy-paste? Thanks. Mike Peel (talk) 20:08, 16 April 2019 (UTC)
Oh my apologies, I misunderstood what was being asked of me. There is/is going to be an API for this kind of access with documentation, absolutely, and as far as I know it will be structured in a way to be supportive of community (semi-)automation, depending on how the community wants to do things. As for specific implementation of migration, which is what I thought was being asked of me, that is where I know Magnus has some thoughts about how to get things moving once features are in place, as the community sees fit based on what's proposed. I will have much more developer-centric documentation and outreach going in the near future as things become available. Keegan (WMF) (talk) 20:19, 16 April 2019 (UTC)
@Keegan (WMF): Thanks. I think it would be better to hold off on deploying depicts statements until after the API (and wikitext?) access has been sorted out and is live on the test wiki, so that the discussion about what the community wants to do with automated/semi-automated tools can happen first. Otherwise there's going to be a lot of wasted effort manually populating statements that could be automatically populated, or manual mis-population that has to be cleaned up later. Thanks. Mike Peel (talk) 20:27, 16 April 2019 (UTC)
@Mike Peel: I don't agree with this. Of course it would be great to see this deployed on test-wiki, but I don't think it should delay manual experimentation here. Any manual effort will be thoughtful effort, and will likely help us resolve usage guidelines. Certainly I have no problem with "wasting" my manual efforts if they get reverted. Mass editing is more onerous to revert if we later change our minds about the model. Even if enabled on the live commons, I expect bot approvals to be cautious at first. --99of9 (talk) 00:29, 17 April 2019 (UTC)
@99of9: if you really think "Any manual effort will be thoughtful effort", you should see what I'm right now cleaning up by way of English-language captions added by User: Probably well-intentioned, but not one of them accurate and on the mark. - Jmabel ! talk 00:36, 17 April 2019 (UTC)
@Jmabel: How annoying. I hope they learn something from the experience! --99of9 (talk) 00:44, 17 April 2019 (UTC)
That would almost make it worthwhile, but since it was a smartphone on an IP address that presumably did this all in one session, I'm guessing that, despite being admonished, they never got the message and will do equal damage from a different IP address. - Jmabel ! talk 00:51, 17 April 2019 (UTC)
@Mike Peel: I would take it easy to start with and focus on quality and getting it right. Maybe some tools to do semi-automatic editing, but nothing too large.
Lets focus at first on the featured pictures. We can go through all featured pictures and add the relevant depicts statements. Once we've done that, we can go to the good/valued image. This would give a relatively small pilot set of quite diverse structured data. Based on our experiences we start automating things.
I hope my than we also have other types of statements so we can add things like when, where, by who and more technical metadata. Multichill (talk) 15:15, 17 April 2019 (UTC)
Good idea. Yann (talk) 15:24, 17 April 2019 (UTC)
That kind of manual testing can and should be done on the test wiki before the feature is turned on here, and it can be done alongside the testing of automated tools. I'd prefer to see a delay of the release until the automated access is available - but I've been asking that for the last 10 months with no answer... Thanks. Mike Peel (talk) 20:10, 17 April 2019 (UTC)
Re Mike Peel: I think this is the great idea, because categories include a lot of kinda structured information to files. But I think it is too early. Lets wait for a few month that depicts settles done and other properties are introduced. Juandev (talk) 07:08, 24 April 2019 (UTC)

@Keegan (WMF): *twiddles thumbs*. There's not much that I can do to help here until these issues are sorted. Would it be helpful if I posted them on Phabricator? Thanks. Mike Peel (talk) 18:45, 10 May 2019 (UTC)

  • It would be very very great if VFC (or a new tool) could allow us to put relevant statements to a group of selected files. Christian Ferrer (talk) 11:43, 14 June 2019 (UTC)
    • For such visual editing, it would also be useful to have a tool that could be configured eg to highlight which files within a category or a page or a search or a list of files may already have a particular statement, or combination of statements. This is the other side of what is needed to be able to visually edit SDC statements, as well as useful in its own right. Jheald (talk) 12:36, 14 June 2019 (UTC)
Yes, good point. Christian Ferrer (talk) 17:31, 14 June 2019 (UTC)
To add a tag (wanted tag) to a selection of files, it would be great to have something in this kind :
be able to see all tags (tag list) on a selection of files
in a category (as with VFC)
or uploaded by a specific user (as with VFC)
be able to select from these files :
all the files (in case that none file has already the wanted tag) + the possibility to unselect the files that don't need the wanted tag
files that have the wanted tag among the tags from the tag list, and then to reverse the selection + the possibility to unselect the files that don't need the wanted tag
manually some files (in case that none file has already the wanted tag, and in case that not all the files needs the wanted tag)
to add the wanted tag of your choice to that selection
Christian Ferrer (talk) 15:46, 15 June 2019 (UTC)

Usage not visible ?Edit doesn't show Jura1 (talk) 21:14, 23 April 2019 (UTC)

@Jura1: it's going to take awhile initially for search to catch up to the new database. There's a task to re-index search, which is going to speed things up, but it may take day or two to resolve. Keegan (WMF) (talk) 22:33, 23 April 2019 (UTC)
  • The above is unrelated to cirrussearch. It's important that it works as otherwise people at Wikidata wont know that an item is in use here. Admins may end up deleting an item that appears unused. --Jura1 (talk) 01:37, 24 April 2019 (UTC)
  • Ah, apologies for misunderstanding. I'll see where we are with special pages. Keegan (WMF) (talk) 16:38, 24 April 2019 (UTC)
    • It might be more general than that. If usage isn't tracked, you wont get updates from Wikidata when labels are edited. Jura1 (talk) 11:19, 28 April 2019 (UTC)
      • @Keegan (WMF): Any progress on this? This is a big issue, if eg an item on Wikidata gets split into two narrower items: one needs to be able to find out which Commons pages refer to the old item, so one can edit them to make sure they will be referring to the right one of the two new items. Jheald (talk) 11:42, 6 June 2019 (UTC)
        • @Jheald: apologies for the delay, I've been away from work most of the past month. RIsler (WMF) is going to make a ticket to investigate. I'll add the tracking template here when I have a number available. Keegan (WMF) (talk) 19:42, 10 June 2019 (UTC)

Captions cannot be correctedEdit

Somebody entered captions on one of my images which need to be corrected. However, when I change the text and try to publish it, I get the response Forbidden. How can I handle this? --Uoaei1 (talk) 11:53, 22 May 2019 (UTC)

I think more details would be helpful here :)
Which image is it? What in the page tells you “Forbidden”?
Thanks, Jean-Fred (talk) 13:21, 22 May 2019 (UTC)
@Jean-Frédéric: The image is File:Freiburg Münster rechtes Seitenschiff Märtyrerfenster 01.jpg. I want to change the English caption, so here is what I do: I click on Edit in the Captions frame, edit the text, and press Publish or Enter. The text Forbidden appears under the changed text box, and the change is not accepted. --Uoaei1 (talk) 14:02, 22 May 2019 (UTC)
@Uoaei1: Thanks for the clarifications. I tried and have not been able to reproduce (although given that I’m a sysop, that does not say much :-/). Jean-Fred (talk) 14:22, 22 May 2019 (UTC)
@Uoaei1, Jean-Frédéric: I have less user rights than Uoaei1 as far as I can tell, and I was able to edit the English caption as well. (I removed the trailing period, since on Wikidata descriptions aren’t full sentences, though I’m not aware what the convention for Commons structured captions is. Feel free to revert.) --Lucas Werkmeister (talk) 16:31, 22 May 2019 (UTC)
@Lucas Werkmeister, Jean-Frédéric: Seems to be a problem with the browser. With IE11 it does not work, but with Chrome it does. --Uoaei1 (talk) 18:55, 22 May 2019 (UTC)

Bain collectionEdit

How can we link between the Library of Congress' Bain collection at Wiki Commons and the same image at Flickr Commons and maybe add that link to Wikidata?

We migrated the entire Bain Collection from the Library of Congress to Wiki Commons and those images also appear in Flickr Commons with crowd sourced biographical information on the people pictured. Can anyone see a way that the identifiers we store at Wikimedia Commons can match any identifier at Flickr Commons so we can migrate the Flickr link to Wikidata and to Wiki Commons automatically? Here is an example where I migrated one by hand: At Walter Simpson Dickey (Q7966031), the entry for the person in the image, I added the link to Flickr which has unique biographical information on the person. Can anyone see a way to automate the linkage? The Wikimedia Commons image uses an LCCN identifier (LCCN2014702600) File:Walter_S._Dickey_LCCN2014702600.tif and the Flickr Commons entry has an identifier: Walter_S._Dickey at Flickr (ggbain.22649). You can see how I added the link from Flickr to Wikidata as an entry for "described at URL".I also added the link to Commons. Is it possible to automate the process? Is there anyplace where "LCCN2014702600" links to "ggbain.22649"? Please note that Flickr is down today as they are migrating the entire database to new servers. --RAN (talk) 15:04, 22 May 2019 (UTC)

  • While not sure about the structured data side of this, we should certainly have a template that both puts the image in Category:George Grantham Bain Collection and has a parameter for the Flickr ID, and which automatically generates the URL on Flickr. - Jmabel ! talk 16:51, 23 May 2019 (UTC)
You would have to investigate MARC records or the LOC API to map LCCNs to specific LOC collection image numbers (it can be done). I do not understand why you would want to link Flickr photos, they are neither the source, nor the LOC original highest resolution image, it's better to get haphazard Flickr readers to use the LOC original catalogue entry. -- (talk) 16:58, 23 May 2019 (UTC)
Read a few of the entries at Flickr Commons, the Library of Congress has the name of the person on the glass plate, only Flickr Commons has crowd sourced data that identifies the person as someone in Wikipedia, and in some cases an exact date and the circumstances of the photo, based on news articles of the time. The current tranche is 1921. Flickr also has corrections where the name of the person pictured is misspelled or been misidentified. I have been adding the people not in Wikipedia into Wikidata and then creating a category for that person here. Flickr is down for a few days while they migrate the archive to new servers ... possibly deleting several million images. They have reneged on their promised 1TB of free storage. Yahoo sold the website to Verizon which sold it to SmugMug, and now they are looking to generate more revenue to pay for the purchase. here is an example of someone not in WIkipedia: Elkan Cohn Voorsanger. RAN (talk) 23:33, 23 May 2019 (UTC)
Another point: The dates are off by 20 years here at Commons, Flickr correctly has the current tranche of photos as from 1921. Commons loaded them as the year "1900". See File:O. Saenger LCCN2014713020.jpg where I changed the date. RAN (talk) 04:10, 27 May 2019 (UTC)
Any progress on this issue? I still do not see a common identifier between Flickr Commons and the same image at Wikimedia Commons "LCCN2014702600" and "ggbain.22649. When I try an laod the image from Flickr to here it finds the correct image already loaded here.
— Preceding unsigned comment added by Richard Arthur Norton (1958- ) (talk • contribs) 22:08, 2 June 2019‎ (UTC)

Adding qualifiers to DepictsEdit

Testing for adding qualifiers to Commons:Depicts statements on the file page and in the UploadWizard is now available on Test-Commons:

Adding qualifiers allows users to further develop depicts statements. For example, depicts: house cat can be extended into depicts: house cat[color:black]. You can find qualifiers in the "Structured data" tab on the file page, or in the "Add data" tab in the UploadWizard.

Currently supported qualifiers are: shown with features, color, wears, applies to part, quantity, eye color, and shape.

Once you've tested qualifiers, please leave your feedback on this page with any questions, comments, or concerns you might have about the feature. (And thank you Lucas who already has, above!) When testing is complete, the qualifiers will be released to Commons both on the file page and in the UploadWizard. Quiddity (WMF) (talk) 22:16, 22 May 2019 (UTC)

Qualifiers on depicts statementsEdit

I just noticed that qualifiers on depicts statements went live on Test Commons. Looks exciting, and I assume you’re interested in feedback :)

  • Neither the qualifier property nor the value are linked: they are just shown as plain strings. This makes it impossible to validate that they’re correct: for example, the value for an “eye color” qualifier should be blue, the eye color, and not blue, the color. Also, the work-around Jean-Frédéric mentioned above doesn’t work due to this – as far as I can tell, it’s not possible at all to see the item ID of a qualifier value in the UI, neither in view mode nor in edit mode. (You can get it via the API, of course.)
  • Speaking of which, why is “eye color” a possible qualifier? That should be a property of the value item, not of the particular “depicts” statement.
  • The input for “quantity” has two sets of plus/minus buttons, one by OOUI to the left/right of the input and one, presumably by the browser, inside it. (I’m on Firefox 67 under GNOME 3.30, looking at --Lucas Werkmeister (talk) 11:39, 22 May 2019 (UTC)
I agree with Lucas Werkmeister on these points. How possible qualifiers were chosen? Why are they hard coded? Ayack (talk) 09:45, 23 May 2019 (UTC)
I agree with you and as with Ayack I'm wondering about the how possible qualifiers were chosen? What the rationale behind them?.--Vulphere 12:35, 23 May 2019 (UTC)
Plaintext is a real problem, I didn't get this, is this a bug? -- Rodrigo Tetsuo Argenton m 06:50, 25 May 2019 (UTC)
Lucas Werkmeister, imagine a paint, and you include as a depict: "person", eye colour could be a qualifier of that person, also hair colour, the problem is the way that they present that to us. -- Rodrigo Tetsuo Argenton m 07:40, 25 May 2019 (UTC)
@Quiddity (WMF): Could you explain us how possible qualifiers were chosen? They don't match those listed by the community on Properties table. Thanks. Ayack (talk) 08:25, 3 June 2019 (UTC)
@Keegan (WMF): Any answer please? Ayack (talk) 18:15, 12 June 2019 (UTC)

No constraints on qualifiers?Edit --Roy17 (talk) 22:29, 22 May 2019 (UTC)

Vandal heaven. - Jmabel ! talk 00:05, 23 May 2019 (UTC)
@Roy17: Over on Wikidata, there are no string restrictions on the properties you can use, nor on the values you can set.
On the reason why this is so, I find this 2013 post by User:Denny, Restricting the World, very enlightening.
There are, however, property constraints to flag things that do not make sense, such as eye color (P1340)=Michigan (Q1166) − I expect that we develop something like that for here as well, to surface issues.
@Jmabel: I’m curious, why do you think this is particularly “vandal heaven”? After all, in the non-Wikibase parts of Wikimedia Commons, we also do not restrict editing − for example, we technically allow such categorisation (an edit which, incindentally, persisted for 2 years before I noticed it :-).
Jean-Fred (talk) 08:56, 23 May 2019 (UTC)
Vandalism is one consequence, but I am more concerned about accidental mistakes. For example, white is a colour, but is also commonly a surname and a type of humans. Square is a shape, but is also a kind of public space. If a user chooses an item of a wrong group, a constraint warning would be helpful.--Roy17 (talk) 10:55, 23 May 2019 (UTC)
@Jean-Frédéric: Because I don't think at this time this content is being comparably well monitored. - Jmabel ! talk 16:49, 23 May 2019 (UTC)
Any short summary of the Dennys Restricting the World? Juandev (talk) 14:15, 8 June 2019 (UTC)
@Juandev: Don't restrict relationships, you can put Paris in a country named "goat cheese" if you want.   — Jeff G. please ping or talk to me 15:15, 8 June 2019 (UTC)

Qualifiers on depictsEdit

Hello, after tried the new qualifiers on depicts statement on TestCommons I must say that I'm impressed with this neat new feature and I'm looking forward for further development.--Vulphere 12:33, 23 May 2019 (UTC)

Feedback about qualifierEdit

  • It was a little bit strange the list of default qualifiers, is this just random examples?
    • Why do not use qualifiers as at Wikidata, give some default items (better than this ones, and that changes do to the entry), but give us the possibility to choose a wilder variety.
    • With this qualifiers I can't describe anything, I can't properly describe a person, for example the hair colour, the skin tone,... imagine a bird, a fish... a paint... would be better took the Wikidata way to this.
  • It's quite difficult to understand some items without explanation (as we have at Wikidata), for example "shown with features", we already have this explanations, it's a matter of implement it.
  • Why the plained-texts, not links?
    • It should be links, and if they return a category here, from the wikidata item, also show this.
  • Why "quantity" have this + and - ? Seems not necessary.
    • This should have a "unit" as optional as in Wikidata...
  • Individual "edit" button would be nice, image a media with a lot of entries: d:Q10301958, imagine that you want to change one thing...
  • The so thin distance between the items could generate an accessibility issue.
  • And stills weird a separate tab for the data and the no mirror possibility from a Wikidata item.
  • Thank you for all the efforts, it's a good addition. -- Rodrigo Tetsuo Argenton m 07:37, 25 May 2019 (UTC)

Avoiding repetitive data entryEdit

Great job on the depicts screen in UploadWizard! Being that more functionality is being built into structured data on Commons, it's starting to get repetitive having to enter similar data twice. It would be very helpful to have the following functionalities in the wizard:

  • A button to make the caption and description identical (minus wikimarkup). Most of my descriptions are a phrase or sentence anyway, and it would be helpful not to have to copy-paste all of them twice.
  • Auto-suggesting categories from the depicts statements, and vice-versa. Bonus points if it can figure out categories that are overlaps of subjects and locations (which would be easier if/when the "located in the territorial administrative entity" property is enabled).

Also, the captions should really be under the structured data tab. Thanks! Antony-22 (talk) 13:59, 28 May 2019 (UTC)

I am adding captions and depicts but I how do I edit them?Edit

Having added captions and depicts on my recent uploaded images, I now wish to check them and probably modify some. To my surprise, they were not present in the File meta-data. What has happened to it? Kerry Raymond (talk) 04:05, 29 May 2019 (UTC)

Not sure what you mean exactly by “they were not present in the File meta-data”? Checking for example File:4WDs at Inskip Point, 2009.jpg, I can see the caption “4WDs at Inskip Point, 2009” just below the picture ; and by switching to the “Structured data” tab, I can see the depicts:Q6038192. Jean-Fred (talk) 09:04, 29 May 2019 (UTC)
I do not see them when I go into either Edit (source) or Edit (visual). Information about a file needs to be stored there. Kerry Raymond (talk) 20:52, 29 May 2019 (UTC)
I note it clearly says at Commons:File captions that they are stored on Commons not Wikidata. Kerry Raymond (talk) 20:59, 29 May 2019 (UTC)
Editing these in Edit (source) is basically the "serialization/unserialization" proposal I've made several times and been ignored. But (for what it's worth) you should be able to edit them in the same place where you see them on the file page. Is that not working for you? - Jmabel ! talk 21:53, 29 May 2019 (UTC)
OMG, you mean on the "view" photo screen, we have a means to *edit* certain information, which isn't available in the Edit screen. Did we just abandon all UI design principles? Viewing is one modality, editing is another. Also, if it's not in the File, how can we can tools like AWB to work with it? There are often times when you need to fix a batch of misidentified photos. Recently I got confused by a batch of photos of sugar mills and mistook Racecourse Mill for Pleystowe Mill. Right now, it would seem that using plain old Edit or tools like cat-a-lot or AWB, that a user could change information in the File, e.g. description, categories, but not update the caption and depicts to match. This seems to me to be a recipe for inconsistency, particularly so if the user who uploaded the photos didn't supply the caption/depicts in the first place and someone else subsequently added them based on the description originally provided. All this information needs to be editable in the same place. By all means, squirrel away a *copy* on Wikidata (or wherever captions/depicts are being hidden, nobody has answered yet where they are), but keep it in the File, so when it is edited, it gets updated. Kerry Raymond (talk) 13:54, 30 May 2019 (UTC)
“nobody has answered yet where they are” → This is explained at Commons:File_captions#Where_are_captions_stored?:

"Captions are stored on Wikimedia Commons, as part of Wikibase. They are not stored on Wikidata. While Wikibase is indeed powering Wikidata, it is also deployed here on Wikimedia Commons."

(As I believe I wrote that sentence, please let me know if it is unclear so I can improve it. Happy to add a “...but not as part of the wikitext” or smth to that effect.) Jean-Fred (talk) 20:04, 30 May 2019 (UTC)
Went ahead and tried to be more explicit. Jean-Fred (talk) 17:37, 31 May 2019 (UTC)

Multiple depictsEdit

What do you do when there are multiple Wikidata elements with the same name? e.g. Landsborough railway station. Sometimes you get some additional text that disambiguates them (as happened with Landsborough), but sometimes you don't. Kerry Raymond (talk) 04:11, 29 May 2019 (UTC)

@Kerry Raymond: I think the most sensible approach is probably to open a new tab and visit Wikidata in that, using its search facility to find the right item, then paste the 'Q' number into the editing box on Commons. While you're on Wikidata, you could also add a suitable description to the item so that the next person has a better chance of finding it. --bjh21 (talk) 12:37, 29 May 2019 (UTC)
@Kerry Raymond: When doing the equivalent operation on Wikidata, you can middle-click to open a new tab with the items − this is not possible here, and filed as phab:T224604.
Your best workaround is probably 'choosing' a value, as it does not save the claim right away. That way, you get a hyperlink to the Q-item, so you can investigate which item you have just selected before saving it. Jean-Fred (talk) 16:12, 29 May 2019 (UTC)
And for people who don't want to use Wikidata? This is why the information needs to be in the File, so it can be changed by the usual edit processes including AWB. Kerry Raymond (talk) 20:57, 29 May 2019 (UTC)
@Kerry Raymond: If you don't want to use Wikidata, you will find it hard to populate depicts (P180). Every time you use the "search" box under depicts (P180), you're searching Wikidata, so to avoid it you need to get your 'Q' numbers from somewhere else, and even then they'll be looked up in Wikidata when you enter them. --bjh21 (talk) 10:12, 30 May 2019 (UTC)
You misunderstand me. "Open a new tab and visit Wikidata, using ... Qnumber ...." is not an instruction you can give to an average Commons user who knows nothing about Wikidata. If you seriously want people uploading photos to engage with "depicts" (and I think people can understand what "depicts" means in a general way without having any knowledge of p180), then the Upload Wizard needs provide a way to do it that doesn't need them to know about Qnumbers, Pnumber nor require them to access Wikidata. I train new users. Uploading photos is a massively hard topic to teach to new people, so expecting them to also know about Wikidata to do it is NOT the way to attract new contributors. Remember depicts is in the standard "Upload Wizard". If we are serious about it being a "Wizard", then it do something clever. For example, make guesses from the Commons categories as suggestions, or ask them for a Wikipedia article it relates to (and then map whatever they choose to Wikidata under the hood). Use other systems of identification to make it easier for them to indicate what is being depicted, with Wikidata being just one choice not the only choice. Kerry Raymond (talk) 13:40, 30 May 2019 (UTC)
I understand your concerns and agree to them up to a certain degree ; but I’m not sure I follow «  ask them for a Wikipedia article it relates to (and then map whatever they choose to Wikidata under the hood). » − in some way, since Wikidata is more than the unions of all Wikipedias, then this is exactly what is happening.
Also not sure I follow that new users would be able to add categories, but not to add depicts − I can certainly agree that experienced Commons users are more familiar with categories than Wikidata (that’s kind of still my case ^_^); but I would imagine a new user to instinctively fare better with depicts and its multilingual and fuzzy search than with the monolingual, somewhat arbitrary named Commons categories.
Jean-Fred (talk) 15:07, 6 June 2019 (UTC)

Uploading multiple imagesEdit

If you are uploading multiple images in one hit, it is not clear what is happening with the depicts. Is it going on all of them or just one of them. It seems as soon as you publish one of them, it doesn't let you go back to add the depicts the others, which is begging the question of what is happening with the other images, are they getting a depicts of not? The workflow is quite confusing, whereas it seems more straightforward with the caption (you either fill it in manually or do a "copy"). The depicts should be handled in the same way. Kerry Raymond (talk) 04:19, 29 May 2019 (UTC)

That's an interesting point to consider from the user experience perspective, thank you for leaving it. Keegan (WMF) (talk) 19:44, 29 May 2019 (UTC)

Archiving mess-upEdit

It appears we have two archive pages, created and fed by two different bots

Does anybody have a good tool to merge the two? Jheald (talk) 17:21, 2 June 2019 (UTC)

Mirror from WMC leaves no block of SDEdit

I have tried to upload a file to test wiki, than I got its mirror from Wikimedia Commons[] and I have realised, I cannot add any structured data. Juandev (talk) 13:15, 8 June 2019 (UTC)

The test environment is configured to mirror content as the wikis do. It can be a problem if uploading a duplicate file (as you ran into), but it's necessary for making sure changes don't break the configuration. Keegan (WMF) (talk) 20:53, 11 June 2019 (UTC)

Qualifiers testingEdit

Rendering problem in FF

So here are some of my points from qualifiers testing:

  1. any way to explain, what the qualifiers means? Fairly I dont understand some of them (e.g. shown with features), what they mean and how to fill their values. You may say, you can have a look to Wikidata, but do we want all Wikimedia Commons users to study Wikidata? I think no, we should have it as clear as possible. + I think, that some of the translations to Czech are missleading (eg. quantity = počet instancí (en: number of instances).
  2. on the other side if I think, I undertand the qualifier, I dont know how to fill it with values - e.g. applies to part. What if I set =yes (Q6452715) ?
  3. the graphical design looks to me good and undersandable
  4. speakers of some languages might have a problem with values. E.g. dog can be black and cat can be black, but in Czech dog is "černý", but cat is "černá". So for Czech speakers filing qualifiers would not be so smooth as for English as they should thing about the infinitve word. What about some gramatical aliases for certain languages, whout it be possible? What I can see now, that in some languages, this is fixed by d title, so instead of title Green in pl there is title Green color, which makes it more understandable. So this may help to fix the problem I am writing above.
  5. for those, who are not deeper familliar with Wikidata, what are quantifiers? Do they represent Wikidata items? Will be there infinite number of qualifiers? How new qualifiers could be added?
  6. see the rendering problem I have encountered in FF
    1. This is not caused by rendering, but by the fact, that you can save even you have no value for the another quantifier. So you cannot save, when first quantifiers is not selected, but you can save, when others quantifiers are null. Is this a bug than? But I also see, this is happening before I reload the page. So if you reload the page, there are no empty "lines" as before. Juandev (talk) 14:10, 8 June 2019 (UTC)
  7. now its slightly confusing that you can add more statements, becuase if you add the firest, there is an option to start editing the qualifiers, so this may be confusing some people
  8. could we set quantity automaticaly to 1 if not set? Why we can set nengative quantity? For what this is usefull in file description?

Juandev (talk) 14:02, 8 June 2019 (UTC)

@Juandev: Thank you for testing and leaving feedback. The team will look it over. Keegan (WMF) (talk) 17:44, 10 June 2019 (UTC)

URL link to Structured data tabEdit

Is there a way to link Structured data tab via URL. I.e. someone can follow a link and display file with Structured data (no need to click on Structured data tab)? Juandev (talk) 23:01, 8 June 2019 (UTC)

@Juandev: It seems you can only link to #ooui-php-8, e.g. File:Commons testwiki, rendering problem.png#ooui-php-8. But that doesn't open the tab and is also just a dummy, unstable ID and link then (see #Hide Structured Data tab?). --Marsupium (talk) 23:42, 8 June 2019 (UTC)

I see.07:14, 9 June 2019 (UTC)Juandev (talk)

Where on WikidataEdit

I wonder, that WMC files are already present on Wikidata also, arent they? Will they be in special ns? Will they be publicaly available? When? Juandev (talk) 23:03, 8 June 2019 (UTC)

I’m not sure I understand your question − what do you mean by “present on Wikidata”?
As far as I know, no, Commons files are not present on Wikidata (except in the sense that every Commons file has a 'shadow presence' on all wikis, eg d:File:Example.jpg).
Jean-Fred (talk) 11:54, 9 June 2019 (UTC)

It was somewhere said by development team, that every file will have its page on Wikidata. Juandev (talk) 06:05, 12 June 2019 (UTC)

This is not something that I'm aware of from the development team. That's up to the communities to decide. Keegan (WMF) (talk) 17:27, 12 June 2019 (UTC)
No, not every file will have a page on Wikidata. You're probably mixing up concept. Every file here on Commons will have a structured mediainfo item here on Commons.
So for example the file File:Tonicella insignis.jpg has mediainfo M5150233 which you can see
In some cases the depicted work is notable enough to (already) have an item of it's own. See for example File:Sandro Botticelli - Madonna and Child with St. John the Baptist - 2014.85 - Indianapolis Museum of Art.jpg. This file already links to Madonna and Child with St. John the Baptist (Q27897025) in the Wikitext. The file itself has mediainfo M65747301 in which you can also see the link with Wikidata.
Does this clarify it for you? Multichill (talk) 17:49, 12 June 2019 (UTC)
Thx, now I understand it well. Hope, we can have here than the oportunities of SPARQL as on Wikidata or something less techy. Juandev (talk) 08:05, 13 June 2019 (UTC)

Popups for the qualifiersEdit

  • Hello, I just made a few tests in Test-Commons,
I see there is a predefined list of possible qualifiers. I think it may be useful to have a kind of help pop-up for each qualifiers with a short explanation on the function of the qualifiers, as well as an example for each. Or maybe a help page easily available.
Has it been envisaged to put qualifiers for the qualifier given values, example I put:
sky (Q527) shown with features (P1354) cloud (Q8074)
cloud (Q8074) quantity (P1114) 3
or is too complicated?

Regards, Christian Ferrer (talk) 21:18, 11 June 2019 (UTC)

@Christian Ferrer: when other statements are released, the drop-down box will be replaced with an auto-suggest box from Wikidata. I believe this should contain the labels, which will help. Additionally, there are more designs in the works to be tested to provide some aspects of linking to Wikidata that will not be in the first release, but will be within the next few weeks after launch. Keegan (WMF) (talk) 17:33, 12 June 2019 (UTC)
Is it just me, who does not see thumbnails on Testwiki? Juandev (talk) 06:08, 12 June 2019 (UTC)
Thumbnails are not working. Keegan (WMF) (talk) 17:33, 12 June 2019 (UTC)
  • I think will be good idea to have domain-specific lists of qualifiers. For example:
    • age (adult, immature, larva, etc), sex, action (drinking, bathing, copulation, etc) for animals;
    • part (flower, leaf, fruit, bark, etc), and state (living/dead) for plants;
    • interior/exterior, spaces (for religious building) for building.
  • EugeneZelenko (talk) 22:23, 12 June 2019 (UTC)
@EugeneZelenko: some suggestions:
Hope this helps, Jheald (talk) 15:24, 20 June 2019 (UTC)
I agree that identifying some common qualifiers and values for different particular sorts of objects would be a useful thing to start documenting, as suggestions for people. Jheald (talk) 15:30, 20 June 2019 (UTC)
This query may be of use: It identifies the most common qualifiers currently used on depicts (P180) statements on Wikidata, with the top 10 classes of items that each one is used on, and a sample item with a depicts statement on which the qualifier is used. Jheald (talk) 16:31, 20 June 2019 (UTC)

Logic behind SD deploymentEdit

Hi, I don't understand the logic behind the deployment of Structured Data on Commons. I expect to start from the general going to the particular, but the first deployed item was Captions, which is very minor issue in the grand scheme. Then we have Depicts, and then Qualifiers, when we still don't know where and how the item for the files themselves will be stored. Before these items, I expect to have a general framework which need to include the important parts like Author, Licence, Date, Source, etc. Could you please explain when this will be available, and how and where they will be stored? I would like to see a general design with a graphic showing where and how each item is stored. Regards, Yann (talk) 05:16, 12 June 2019 (UTC)

They said, they will go peice by piece not to confuse WMC community, but deffinitely to see hole framework know would be great. Juandev (talk) 06:10, 12 June 2019 (UTC)
(edit conflict)
Hi Yann,
Have you seen Commons:Structured_data/Development and the roadmap at File:Roadmap for Structured Commons development - version 2017-10-31.pdf? Keegan or Sandra would be able to comment better where we are on it right now (I believe it has shifted a bit) but I understand it still holds.
Your raise interesting questions, and while I don’t have special knowledge of the planning let me try to answer it. I think part of the issue is to focus on the user-facing features, which overlooks all the "under-the-hood" work. For example, captions were indeed the first specific element to be deployed, last January − but behind that limited feature, was the installation and enablement of a whole new extension, WikibaseMediaInfo (itself was the culmination of months for work on multi-content revisions).
Similarly, depicts: is a fairly contained release − but with it goes significant work in developing the search infrastructure around statements in general.
So, I don’t know if I’m being clear, but my understanding is that we are indeed starting from the very general − but every few steps in the general, we get a new small feature which is now made possible.
Regarding “how the item for the files themselves will be stored”: my understanding is that all this information will live in MediaInfo, in the Wikibase instance of Commons − where depicts: (and captions) are already stored. As for design documents, would File:Structured Data on Commons - which information goes where - version 2017-10-31.png and File:MediaInfo Entity Page.png be what you are looking for?
Hope this helps! (and if anyone notices mistakes in the above, please do correct me ^_^)
Jean-Fred (talk) 07:12, 12 June 2019 (UTC)
Hi Jean-Fred,
I would like to see a complete schema, not a mock up.
Among unresolved issues are,
  1. Who are the notable vs. non-notable editors? Who will decide that and how is it decided? (at least you should be able to produce criteria on which this would be decided)?
  2. Currently some depicted items have their own Wikidata entry. Will that be the general case? Who will decide that and how is it decided?
I see that these fundamental questions yet not properly addressed, and the current deployment, as putting the cart before the oxhorse.
As for the roadmap, it seems way behind schedule if I read correctly page 12. Regards, Yann (talk) 10:23, 12 June 2019 (UTC)
Hi Yann. Jean-Fred has it mostly right, as far as the technical work and deployment goes. The software is being implemented in large part to make sure the technology works, without major disruption. Structured data items are stored on Commons in Wikibase, as Jean-Fred also mentions, with Captions being stored as wikitext within Wikibase. The remaining questions you raise are those of however the community decides to organize and implement a schema. There have been several discussions about this over the past couple of years with various (sometimes) competing viewpoints being expressed, but at this time a complete schema has not been created by the community. The primary reason for this, in my understanding from talking with various community members, is an overall desire to not put the cart before the horse - the development team should design and code an architecture for the community (the horse) to develop structured data (the cart), and when that architecture is available then the community will put together its schema.
The software pieces for this are all coming together very quickly, as I updated the development page yesterday to reflect the next 4-6 weeks. "Other statements" will cover things like Author, Source, Date, and other relevant information that is generally found in the description template. As the final parts are released, I anticipate the community coming together to make the decisions for the questions you are asking. Keegan (WMF) (talk) 17:57, 12 June 2019 (UTC)
@Jean-Fred, Keegan (WMF): SD is not a project by the community, although most people here support it. So your statement “the community should decide” is quite strange. So far, the community followed rather than led this project. I am quite sure that the community would have implemented it in a different way. The Author, Source, Date and License are the most important information for any file. Without any of these items, we don't know what is its copyright status, and we cannot keep a file here. The implement of these items affects the whole design. That's why their integration into SD should have been done first. "Depict" is related to the scope, and comes later. Regards, Yann (talk) 06:31, 13 June 2019 (UTC)
SD is how the WMF developers coup with Wikimedia Commons's wishes to internacionalise categories and to fix other bariers in the project. Juandev (talk) 08:08, 13 June 2019 (UTC)
While I welcome the idea, this is not how the project was presented to the community. Specially, it was expressly said that Captions won't replace Categories, which confused many people, including me. Regards, Yann (talk) 11:29, 13 June 2019 (UTC)
I assume you mean either "Captions won't replace Descriptions" or "Depicts won't replace Categories"; captions clearly can't replace categories in any scenario.
I certainly hope Depicts won't replace Categories. As far as I can see, Depicts is sort of a glorified Flickr tag. Over a year ago, I made a proposal as to how Depicts could supplement and assist the Categories system; the only person who engaged me raised purist hair-splitting epistemelogical concerns, so I walked away from it. If there is an interest in my fleshing out my proposal again, I'd be glad to. - Jmabel ! talk 16:00, 13 June 2019 (UTC)
I don't think that Depicts is fundamentally different then Category. Both could be abused but imprecise or overbroad classification. Another issue is qualifier versus dedicated category, for example exterior/interior of building. --EugeneZelenko (talk) 19:17, 13 June 2019 (UTC)
@Jmabel: Why do you see it as a glorified Flickr tag? As far as I know, Flickr tags are free-form (it’s not a constrained vocabulary), text-based (and not multilingual), and there’s no relationship between tags (no concept that eg a cat is also a mammal) − that’s just off the top of my head, but that’s already a very different animal than Wikidata-based depicts, which is not free-form, is multingual, and uses rich concepts (lots of properties are attached to whatever concept you use for depicts) and there’s a (admittedly work-in-progress) ontology defining relationships between items. Jean-Fred (talk) 22:10, 13 June 2019 (UTC)
@Jean-Frédéric: Hence the "glorified". - Jmabel ! talk 01:19, 14 June 2019 (UTC)
@Jmabel: Ah, sure :D. By that definition, I would then say that categories also a glorified Flickr tag − a somewhat even less glorified one ;-) Jean-Fred (talk) 08:30, 14 June 2019 (UTC)
  • I'm a bit skeptical about the direction taken with depicts (P180). At Wikidata, one tries to avoid excessive use of qualifiers, but maybe Commons finds a way to avoid ending up with Flickr tag clouds. Jura1 (talk) 08:01, 12 June 2019 (UTC)

Increased number of edits on d:Property:P180Edit

Maybe it's the GUI here, but we get more odd edits on that page on Wikidata. Mostly by people trying to describe an image on Commons. In the meantime, the page is semi-protect, but this still happens with autoconfirmed users. Jura1 (talk) 06:41, 12 June 2019 (UTC)

digital representation ofEdit

How is this diff possible? I thought "depicts" was the only property supported at this time. Ayack (talk) 13:17, 14 June 2019 (UTC)

Yeah, noticed that too :) User:Multichill is going through the API, so I guess there’s no restriction there − I imagine "depicts" is the only property supported in the front-end (actually, I’m positively pleased that the UI deals with this arguably unexpected situation in a very sane manner). Jean-Fred (talk) 13:29, 14 June 2019 (UTC)
Ultimately I would prefer to see depicts (P180) not to be used when digital representation of (P6243) is present. But perhaps for the moment it makes sense to have both. Jheald (talk) 14:22, 14 June 2019 (UTC)
Yes, correct, I use the API. I first checked if the interface wouldn't explode (that didn't happen).
I deliberately choose to add both digital representation of (P6243) and depicts (P180) for these works. Let's take this not so random gallery:
  • Notice the sliding scale. I don't want to have people argue or edit war over to use depicts (P180) or digital representation of (P6243). So my reasoning:
    And when people are searching for a Mona Lisa image, shouldn't they get all of them? We should probably add a bit of search boost to the ones that also have digital representation of (P6243). For the inheritance of the depicts statements on linked paintings I opened phab:T223815. Multichill (talk) 15:48, 14 June 2019 (UTC)
    @Multichill: You seem to be ahead of me here - I'm still waiting for my questions at #How to mass-populate depicts statements? to be answered. How are you accessing the data through the API - when I tried doing that for captions, it was very painful. And how did you get community approval for your bot task? (Again for captions, my proposal went down like a lead balloon.) Thanks. Mike Peel (talk) 19:20, 14 June 2019 (UTC)
    The API here is exactly the same as on Wikidata, the hard part is that the usual Pywikibot abstraction layers (site objects, page objects, etc.) are not in place yet so you have to bypass those for now and directly use the lower level functions to talk with the API. During the hackathon in Prague I wrote a couple of prototypes to do structured data editing.
    I wrote a bot to import captions from POTD templates (example edit). These are already written like captions and we have quite a big archive of these going back many years. Of course open source code. Some concerns were raised about copyright and I don't want to get dragged into that discussion right now, so I didn't follow through
    Statements like depicts (P180) on the other hand, don't raise copyright concerns. My approach is to add statements that don't introduce new errors. It might occasionally propagate a user error for example when someone misidentified something.
    With that in mind I first focussed on taxon items of species (sample query and sample edit). These images only get added to species becuase it's an image of the species. That seemed to work quite well. depicts species code. I picked this subject because it was easy to do. After that I switched to doamins I'm more active in.
    As you might know I'm adding links between painting items on Wikidata (almost 400.000 painting items these days) and images of artworks here on Commons Category:Artworks with Wikidata item contains 230.000 files). My first step here with structured data is to add statements on the files of paintings that are in use on Wikidata (sample query and example edit. This way the semi-structured data we've been collecting for a while is finally structured data, source.
    Back in the day I started Wiki Loves Monuments and the monuments database. We always asked people to identify what monument is in the file. For the Netherlands I also imported a large historic archive where people use(d) {{Possible Rijksmonument}} to identify the monument in the image. Currently we have 424,161 Rijksmonumenten with known IDs. I'm adding the depicts to the ones that have one {{Rijksmonument}} template (example edit). The code can probably be expanded to work on other countries, but I'm not sure if the data quality is high enough in every country. Potential is around 3 million files.
    Another good subset to work on is images of people. See this sample query, but if you look a bit close you'll notice weird things happening; In some rare cases we use a work (or a grave) to illustrate an item about a person. Perfectly valid on Wikidata, but we don't want to get that imported over here. So a bit more filtering like removing visual artists or using some computer vision to identify portraits needs to be able to fully automate an import here.
    We have over 350.000 files with depicts now and counting. In absolute numbers that is quite a nice increase (from 50.000), but in relative numbers it's just over 0,6% of all files. Multichill (talk) 15:14, 15 June 2019 (UTC)
    BTW, what I can see, that once the statement is there, you can edit it. Even on the beggining its gray and it looks like, you dont have rights for the block, finnally it worked. Juandev (talk) 15:31, 20 June 2019 (UTC)

    LUA access?Edit

    @Keegan (WMF): when can we access structured data with LUA? Or is that already possible and I missed it? Multichill (talk) 09:33, 17 June 2019 (UTC)

    @Multichill: my understanding from the last discussion held here, and confirmed by RIsler (WMF), is that there are no current plans from the SDC team to work on Lua support; I do not know what WMDE's plans might be in this regard. When SDC is feature complete, the team is aiming to provide identical functionality to what you'd achieve with Lua through either SDC code itself, or support for javascript tooling to do the work. You're welcome to pitch your particular use case for Lua here, the team will keep it in mind when planning out future work. Keegan (WMF) (talk) 17:48, 17 June 2019 (UTC)
    Hm, without Lua access a good part of SDC seems to be in vain. Without it, currently unstructured data from the wikitext slot can't be replaced by the structured data. Then we manage the data twice in parallel? With Lua access current license tags and much of stuff currently in templates like {{Information}} can be moved to SDC and still be displayed in a nice way. Javascript client side code doesn't seem like a good option for that. Best, --Marsupium (talk) 19:11, 17 June 2019 (UTC)
    Thank you for sharing that. Building support for use cases is the best way to get Lua moved up in priority lists. I have no idea how successful the request(s) will be, but writing them down is a start. Keegan (WMF) (talk)
    @Keegan: Exactly what Marsupium says. Part of the point of SDC is to be able to migrate data from templates to SDC, with the information still visible as before in the templates on the file page, but drawn from data stored in the SDC rather than wikitext. Without Lua, how is it proposed to be possible to achieve this?
    Simple parser functions are not going to be sufficient. There is an idea, I think, to provide some mechanism for editable fields in templates, functionality currenly provided on many Wikipedia templates via Lua, to be via some new system of hooks (can you confirm this?). But the experience from Wikipedia is that sometimes it is necessary for fields in templates to present information combined from multiple wikidata properties in quite complicated ways. On Wikipedias that has required Lua. Without Lua, what is the envisioned routemap to achieve this?
    It's been hard enough migrating templates to Lua, which was specifically chosen for the job. The idea of templates now going to need to be some bespoke Frankenstein combination of wikitext and Lua and javascript is just too much of a nightmare to imagine. As well as likely going to be an uncached performance nightmare, too. And likely a real brute for scraper-based tools to decipher, as well. Jheald (talk) 20:28, 17 June 2019 (UTC)
    To add to what I wrote above, it's useful for SDC data to be accessible through similar mechanisms that Wikidata is currently accessible, so that methods coded in existing modules can be worked from and can be adapted to serve the new data. Also, because the mechanisms will need to draw on a mix of SDC and wikidata. A concrete example of the sort of facilities currently being offered through Lua modules is the ability to distinguish when a value in a template is being filled directly from Wikidata; when it is being filled from a local value that matches Wikidata; when from a local value because there is no data on Wikidata; and when from a local value that is overriding Wikidata -- with the page categorised accordingly (sometimes further split between checked differences and unchecked differences). The categorisation, which is then available from SQL, as well as for straightforward browsing, has proved very valuable for tracking and supporting the migration of information to Wikidata. This is just one of the ways Lua has been used in templates in conjunction with data. Pinging @Jarekt, RexxS: who may wish to highlight some further particularly valuable ones. Jheald (talk) 11:17, 18 June 2019 (UTC)
    Without LUA the data is inaccessible and we can't migrate away from the semi-structured data. LUA has been key in the migration of redundant data in templates like {{Creator}} & {{Institution}}. Without any LUA support planned, importing data is useless and I might as well stop.
    Not sure how difficult this is form a technical perspective. Basically all the LUA is already there, it just needs to understand how to fetch data from mediainfo (M<something>). The Wikibase guru's at Wikimedia Germany can probably make an educated guess how much effort is needed for this. Multichill (talk) 15:06, 18 June 2019 (UTC)
    Thanks for the additional comments, @Multichill, Jheald:. I'm going to ping @Jarekt: here as well since he started the last conversation around Lua. The engineering teams are going to investigate, I'll get back to you with the results. I do not have a timeframe at the moment. As Multichill mentions it'll likely take some coordination with WMDE, so it might take a bit of time. Keegan (WMF) (talk) 15:55, 18 June 2019 (UTC)
    A month ago, I created phabricator:T223792 requesting access to structured data with LUA. I was assuming that since Lua already has capability of interacting with Wikibase software used by Wikidata and SDC, than it should be a simple task to reconfigure it to allow access to SDC. --Jarekt (talk) 12:50, 19 June 2019 (UTC)
    I completely agree with Multichill and others that this is essential. Not having it is already seriously holding back the integration of P180 etc. in templates, and it's only going to get worse as time goes by. As Lua support is also pending for Lexemes, perhaps there could be common work here with @Lea Lacroix (WMDE), Lydia Pintscher (WMDE):? (see discussion at phab:T212843.) Thanks. Mike Peel (talk) 18:50, 18 June 2019 (UTC)
    As a long-term goal, I want to be able to see Wikipedia use dynamic list articles – that is, list articles which are generated on-the-fly (with short term caching, of course), so that a reader can ask for a list of the current leaders of EU countries, for example, and see an article that is up-to-date, with relevant images and associated information which has been created by pulling in data from WD and SDC seamlessly. Even for more static collections (let's say, major bridges in Hungary built in the 19th century), the appeal of being able to have the best images currently available is enough for me to enthuse about having the technology to interface via Scribunto with SDC. If you need more user-cases, I'm happy to come up with more ideas. And once the API is exposed to Scribunto, I'm happy to write custom Scribunto modules to allow template editors on Wikipedias to make use of that. We need to be imaginative in looking forward: make the technology available and we'll find lots of ways to use it. --RexxS (talk) 22:23, 18 June 2019 (UTC)
    Yes, like this fr:Liste des peintures de paysages par Paul Cézanne? Regards, Yann (talk) 05:57, 19 June 2019 (UTC)

    I imagine that in the future we will start using SDC for storing information currently stored in {{Information}} templates. Majority of files on Commons are photographs taken and uploaded by Commons users, if we could use SDC to store information on author (author (P50)) might not work, see phabricator:T127929), date (inception (P571)), and source than for majority of images on Commons we could migrate most of the content of {{Information}} templates to SDC. However ideally the interface would not change for users of Commons so we could rewrite {{Information}} template in LUA (see draft at Module:Information). Rewritten {{Information}} template would take either local values, provided as arguments of the template or properties from SDC. That would be analogous to the way currently {{Artwork}} or {{Book}} templates merge local arguments with the info pulled from Wikidata. Ideally, if we do it right, the look of the template would not change much as we switch from one form of data storage to the other. Also in the future we might use projects like m:Wikidata Bridge to edit SDC properties from the {{Information}} template. If we want to take this route we would need at the minimum to be able to access SDC from LUA. --Jarekt (talk) 13:29, 19 June 2019 (UTC)


    I'm copying over an update I put in the tracked Phabricator task:

    Sorry about the delay in the update, but I'm currently meeting with the SDC team in person and we're discussing this task in real-time.

    The SDC development team is going to have to look into what it takes to get this done - or if not this, some other technical solution that would allow the dynamic updating of templates from structured data. The team currently is unable to do this on their own, so it will require some external partnership to make this happen and WMDE does not have the resources to assist with this task.

    So, this is going to take some time to complete. I have no idea how long for a timeframe, the team will have to talk to other teams and figure out how to make this happen. But they do know absolutely how important this is to the community's plans for the project, and the work is definitely something to do once resourcing gets worked out. Keegan (WMF) (talk) 19:06, 26 June 2019 (UTC)

    Geographic location of depiction ?Edit

    Instead of adding a bunch of depicts (P180), I'd suggest creating a property with preferable a single value for this information.

    Sample File:Valle_dell'Orfento.jpg has P180 values: Italy, Abbruzo. Unless a more precise value can be found, I'd just add "geographic location of depiction"=Abbruzo. This would likely be near GPS coordinates of the point of view.

    Existing properties like "location", "country", etc. don't seem particularly suitable for this use on Commons.

    If this has already been discussed somewhere, I'd be glad to read the discussion. Jura1 (talk) 13:34, 17 June 2019 (UTC)

    It is mentioned here Commons:Depicts#Items_expected_to_be_covered_by_other_statements I also proposed this on the talk page Commons_talk:Depicts#Add_no_location_policy. I think a broader discussion did not start because everyone wants to wait till the other statements are available. --GPSLeo (talk) 17:57, 17 June 2019 (UTC)
    • I think we could propose/create it now and, unless the experiments with other properties break things, arrange for it to be activated. Jura1 (talk) 18:36, 17 June 2019 (UTC)
    I think we do not need new properties there are already location (P276) and located in the administrative territorial entity (P131) we just need to wait that these and all the other useful properties can be activated. --GPSLeo (talk) 19:05, 17 June 2019 (UTC)
    Based on my experience on Wikidata, I think using P276 ("location") and P131 ("located in subnational entity") might confuse things. Maybe narrative location (P840) or offers view on (P3173) could do, but both aren't particularly suitable for photographs.
    For cases where this differs, one probably needs a property for "location of point of view" as well (with item values, similar to coordinates of the point of view (P1259) which requires coordinates). Jura1 (talk) 19:15, 17 June 2019 (UTC)
    For now I would focus on what we have (depicts (P180)) and gently remind people that this is just the start and they should try to put everything in depicts. Multichill (talk) 14:53, 18 June 2019 (UTC)
    You mean, "people" except yourself? Jura1 (talk) 10:17, 20 June 2019 (UTC)
    I agree with guys, I would be patient and wait for the deployment of a specific statement. On the other hand you are slightly right. People may get lost in this slow deployment of statments and try to overpass their non existence. Juandev (talk) 15:35, 20 June 2019 (UTC)

    Qualifiers for depicts coming this weekEdit

    The Structured Data on Commons team plans to release the first version of qualifiers for depicts statements this week. The team has been testing the feature with the community for a month, and are ready to turn it on for Commons on Thursday, 20 June, between 11:00-12:00 UTC. Adding qualifiers allows users to further develop depicts statements. For example, depicts: house cat can be extended into depicts: house cat[color:black]. You will be able to find qualifiers in the "Structured data" tab on the file page, or in the "Add data" tab in the UploadWizard. This version has a drop-down menu to select qualifiers; an update in the near future will replace the drop-down with an auto-suggest box.

    I'll keep the community posted when qualifiers go live on Thursday, after the team makes sure everything is configured and working as expected. Keegan (WMF) (talk) 19:39, 17 June 2019 (UTC)

    @Keegan: Can you update on whether there has been any progress towards SPARQL querying of SDC information? With the addition of qualifiers, we really need it to keep track of what's going on across the data, and to identify patterns of erroneous or malevolent misuse. Jheald (talk) 20:39, 17 June 2019 (UTC)
    @Jheald: work on RDF and SPARQL is not being done by the SDC team, so I have little additional information beyond what's happening on Phabricator. T221917 - Create RDF dump of structured data on Commons is active as recently as last week, that's probably a good ticket to start exploring the work as it develops. Keegan (WMF) (talk) 21:26, 17 June 2019 (UTC)

    Half a million depicts statementsEdit

    About 8 years ago I wrote User:Multichill/Next generation categories. The depicts statements are the first step here on Commons to implement that. To give the project a push in the right direction, I have been using a bot to import statements (see previous topic for the how part). We just passed a bit of a milestone, we currently have over half a million depicts (P180) statements. In absolute numbers this is a good start, in relative numbers this is about 1% of all (54M) files so we still have a long road ahead of us. I think bots are a good way to quickly increase coverage, but we shouldn't compromise on quality. Multichill (talk) 10:09, 18 June 2019 (UTC)

    Cool, but without you guys, we cannot go further - we cannot add so many information manualy, we would need some semi automated or fully automated way to mine them e.g. in categories. Juandev (talk) 15:37, 20 June 2019 (UTC)

    Qualifiers for depicts is now availableEdit

    Qualifiers in depicts statements is now available on file pages and in the UploadWizard. The option to add, edit, and remove qualifiers appears when editing structured data.

    With this feature, depicts statements can be fully described. A statement that may have been previously limited, such as depicts: house cat, can now be stated as depicts: house cat [color:black]</black>.

    There are a few known issues found in testing that are being worked on that were not significant enough to block release. Fixes should be in place soon.

    The qualifiers chosen for this first release are qualifiers for depicts on Wikidata (as set by the property constraints) plus a couple of others being tested. Hard constraints prohibiting other qualifiers from being entered are not in place, as they are not in place on Wikidata. This first version of qualifiers does not show a warning if the qualifier is outside the constraints as it does on Wikidata, and a warning on Commons is something the team is willing to look into if the community would like.

    Additionally, the dropdown menu suggestions when entering a qualifier are limited in the first “depicts only” release. In the near future, as we release support for all statements, qualifiers will use auto-suggest boxes and the list of returned suggestions will have much wider coverage and range.

    Lastly, this first version of the feature does not display qualifier text as links to their associated Wikidata properties, but links will be present in a later release.

    The development team looks forward to seeing the use of qualifiers in statements, and welcomes any comments or questions about the feature here on this talk page. Keegan (WMF) (talk) 14:07, 20 June 2019 (UTC)

    When qualifiers will be arbitrary? Current set is very limited and targeted mostly on photos of people. See my comment on #Popups for the qualifiers about qulifiers sets for other domains. --EugeneZelenko (talk) 14:17, 20 June 2019 (UTC)
    Perhaps worth noting that, as used on Wikidata at least, the "allowed qualifiers constraint" for properties has been seen as pretty advisory, and tends to have evolved without much regard for completeness. (It's often wildly incomplete, with regard to generic qualifiers that may be very standard, but no so often used). As a result, if a qualifier makes even a bit of sense for a property, it's generally been pretty non-controversial for an editor to just edit the list and add it.
    Given the significance of depicts (P180) for Commons, we should probably have a section on the Commons:Depicts page listing the qualifiers and how to use them / what they mean -- ie that applies to part (P518) is to indicate a part of the image eg "top left", while depicted part (P5961) should be used to indicate the part of the depicted object, eg "head" or "interior", which shown with features (P1354), wears (P3828), expression, gesture or body pose (P6022), etc, can be used to further describe. Jheald (talk) 14:33, 20 June 2019 (UTC)
    @EugeneZelenko, Jheald: restraints for qualifiers will be removed in version two, with the drop-down being replaced by an auto-suggest that can be ignored. You can try out version two on Beta Commons, keeping in mind you're seeing the early version two there. Still some more work to be done before release. Keegan (WMF) (talk) 16:39, 20 June 2019 (UTC)


    Hey, I am still not understanding some qualifiers (e.g. shown with features, applies to part). Could you link me somewhere, where they are explained? I still thing, that the translation is missleading, where can I fix their translation? Lasty I thought the limited amount of qualifiers is just for testwiki. So when more qualifiers will arive? Juandev (talk) 15:27, 20 June 2019 (UTC)

    @Juandev: the documentation for qualifiers here on Commons needs expanding as the community decides on its rules here, but you can find more information about qualifiers in general at Help:Qualifiers on Wikidata. The Structured Data development team is planning to provide links for more information in the software with its next release, as well as the ability to add more qualifiers then. The software is almost ready for testing, so it should be out in two to four weeks. I'll keep this page updated with testing information.
    As for translations, I'll get back to you with the link. Keegan (WMF) (talk) 22:04, 20 June 2019 (UTC)

    New items orderEdit

    I would say it would be more confortable to add new items on the top, not on the bottom. Image the situation, you have many items for file, every time you want to edit its qualifiers, you should scrool down and than up to add a new item. This is unnecessary time consuming. Juandev (talk) 15:27, 20 June 2019 (UTC)

    Depicts for backgroundEdit

    If background (kind of technical term) is an important part of the file, can I set it, like I did in the case of this image? Juandev (talk) 15:27, 20 June 2019 (UTC)

    Linking and describing to qualifiersEdit

    When linking to Wikidata items in the qualifiers, I would like to be able to click on and link to that concept just like we are doing right now with the object of depict. Moreover, as a user, I need the definitions of the qualifier properties -- which should also be linking to the property on wikidata, or when I hover, bring in the description field. Sadads (talk) 17:09, 20 June 2019 (UTC)

    @Sadads: linking should come within a few weeks when we release other statements and version two of qualifiers. Keegan (WMF) (talk) 20:01, 20 June 2019 (UTC)
    @Keegan (WMF): Okay -- just wanted to make sure that was on the radar: it didn't look like it was in V2 on Beta Commons. Sadads (talk) 21:10, 20 June 2019 (UTC)
    Right, it's not on beta yet, still in design I believe. Keegan (WMF) (talk) 21:42, 20 June 2019 (UTC)

    Edit summary missing change to depictsEdit

    Could we add something to the edit summary that describes what happens? Like "Modified qualifier for [X STATEMENT]?" Sadads (talk) 18:16, 20 June 2019 (UTC)

    Like this? Yes, that would be helpful. Multichill (talk) 19:17, 20 June 2019 (UTC)
    This is something that the team would like to do, but there's some technical overhead challenges in pulling the pieces together to generate a summary that's more useful than what we have now. I've added the parent task to this thread, but you can also find the same feature request that Jean-Fred filed, and Ramsey's followup explanation there. Keegan (WMF) (talk) 20:51, 20 June 2019 (UTC)
    @Keegan (WMF): -- I am not asking for the labels for the items -- just the fact that you are editing qualifiers -- right now it looks like, in the edit summary, like any other change to a statement. Sadads (talk) 21:10, 20 June 2019 (UTC)
    Sure, my response is more immediate to the possible presentation shown by Multichill's bot. The team is aware that the current edit summary is less-than-desirable, I'll get back to the community here when I know more about what may or may not change there. Keegan (WMF) (talk) 22:05, 20 June 2019 (UTC)

    Inconsistent mediainfo API outputEdit

    Statement vs claim

    Another thing hindering development on top of the API first noticed by Magnus: Inconsistent API output tracked in Phab:T149410. Lucas also pointed out Phab:T222159. If I would be developing this, I would do everything exactly the same as Wikibase on Wikidata and only do things differently when I have a damn good reason. Why isn't that practice applied here or what is the damn good reason for these changes? @Keegan (WMF): can you ask around? I'm afraid we'll uncover more inconsistencies.. Multichill (talk) 09:20, 21 June 2019 (UTC)

    @Multichill: from what I can tell, claims have always been called statements in MediaInfo since WMDE initially wrote the extension, I'm certainly not aware of any recent changes by the SDC team that would relate to that. Perhaps WMDE had a reason? I'm not sure. Anyway, consistency is good, the team is going to have a look at the ticket. Keegan (WMF) (talk) 15:35, 21 June 2019 (UTC)
    RIsler (WMF) is checking to make sure about the background and affirm any other inconsistencies or changes. Keegan (WMF) (talk) 15:40, 21 June 2019 (UTC)
    Picture on the right might be useful for the relation between claim and statement. Multichill (talk) 15:45, 21 June 2019 (UTC)

    Temporary 9 month issueEdit

    @Keegan (WMF): In September 2018 it was noted that we would be temporarily unable to read old revisions as source text [1]. I recently ran into this problem when trying to undo old revisions that were made in error, without disturbing newer revisions [2]. Has anything been done in the past 9 months to restore readability? When will this be solved? Sincerely, Taketa (talk) 10:33, 2 July 2019 (UTC)

    @RIsler (WMF): You said "The ultimate point is that there *will* be a way to view the Wikitext of a past revision, we just haven't settled on the best way to do that yet." Have you settled on the best way to do this yet? Sincerely, Taketa (talk) 10:36, 2 July 2019 (UTC)
    I'll see where we are here, but at the end of the post that "The team may try to look into other ways of serving the entirety of old wikitext page revisions, but it will not be possible in the near future," with RIsler commenting later in the thread that the software team responsible for writing Multi-Content Revisions may look at something in the future, but that the change we put in place would stay through at least v1 of Structured Data. We are still releasing v1 of Structured Data. The word "temporary" is not found in my initial post for good reason - this isn't temporary.
    You can still access the old revision wikitext, but it requires two extra clicks instead of being shown in the diff view. Click on the old revision , click "edit source" and there you have access to copy the old revision. Keegan (WMF) (talk) 15:47, 2 July 2019 (UTC)
    I understand the software is permanent, but as I understood it the problem would be temporary, since you were looking for a way to view the old versions. In this specific case the problem was that both myself and two Commons admins (who I checked with on IRC to see if I was missing something) could not view the full old version text. Currently on the same page everything works fine. I cannot replicate the error anymore, so my point seems moot. It is the first time this happens for me. I will come back to it if it happens again. All the best, Taketa (talk) 12:24, 3 July 2019 (UTC)
    Okay, sounds good. Thank you. Keegan (WMF) (talk) 15:38, 3 July 2019 (UTC)


    Is there a way to make it visible? Looking at categories or even file description pages, there is no way to know if a file has one or several depicts-statements or not. Jura1 (talk) 14:29, 6 July 2019 (UTC)

    +1 I don't remember when and where but I already suggested that the words "Structured data" in the file page be in blue when there is at least one depict statement. Another idea could be a little number 3, near the words, that says the number of depict statements. Christian Ferrer (talk) 15:20, 6 July 2019 (UTC)
    (See also previous related discussion at Commons_talk:Structured_data/Archive_2019#A_distinctive_appearance_for_the_files_that_have_depict_statement(s)_(or_other_structured_datas...) Jean-Fred (talk) 16:45, 6 July 2019 (UTC))
    • Following the previous discussion, it seems that no steps have been taken to implement this in one or the other way.
    For file description pages, could this be done by css?
    For categories, I started using query server. Jura1 (talk) 16:48, 9 July 2019 (UTC)
    As I'm understanding, the question is whether there can be a way to identify from the file page if the structured data tab has any data in it. Is this correct? Keegan (WMF) (talk) 15:47, 10 July 2019 (UTC)
    For categories, that would be sufficient. Maybe with a gadget as for uses and descriptions?
    For file description pages, the data should also be visible: I don't see the point of opening the description page, clicking on the tab to see what's there, possibly clicking again to re-read the description as it disappeared, then clicking once more to add something.
    Obviously, the whole thing might become less an issue if one uses some tool to search for images and add statements. Jura1 (talk) 16:19, 10 July 2019 (UTC)

    Link Wikidata items directlyEdit

    Instead of linking <> could you link <> directly? Jura1 (talk) 15:19, 8 July 2019 (UTC)

    Might I ask what the advantage of this would be, or what the difference is? I genuinely do not know, and I'm curious. As far as actually doing it, I think the team is still working on when and how exactly to link to Wikidata, so the designs are still in draft and it might be possible if there's a compelling reason. Keegan (WMF) (talk) 19:48, 8 July 2019 (UTC)
    When creating items there, adding statements here and going back there, I was wondering why I should be needing to load a redirect merely because I got back there from Commons? Oddly, even if I had created an item myself, it appears as an unvisted link in my browser? Did you notice that too? --Jura1 (talk) 19:52, 8 July 2019 (UTC)
    Okay, good point. I wasn't sure if the special page was providing some sort of specific function for the redirect (like Special:MyLanguage does). Thanks, I'll inquire. Keegan (WMF) (talk) 20:32, 8 July 2019 (UTC)

    IRC office hour on Thursday, 18 JulyEdit

    The development team is going to hold an IRC office hour on Thursday, 18 July, from 17:00-18:00 UTC. Bring whatever topic you'd like to discuss; current items include the testing of "other statements" (more on that coming this week), properties that Commons may still need created on Wikidata, how the Foundation may provide Lua support, among others. I'll post reminders as we get closer to the date. Keegan (WMF) (talk) 17:17, 8 July 2019 (UTC)

    There's been delays in getting some bugs fixed and designs worked out, so testing for other statements will not be available this week. We're still holding the IRC office hour next week, I'll send out rounds of notices about it on Monday. Keegan (WMF) (talk) 17:08, 12 July 2019 (UTC)

    Reminder: this weekEdit

    The IRC office hours are taking place this week, Thursday, 18 July. I'll post another reminder before the event. Keegan (WMF) (talk) 22:49, 15 July 2019 (UTC)

    Return to the project page "Structured data".