Open main menu

Hiding captionsEdit

Let me get straight into the point:

How do I hide the captions from my view? Any CSS code I can put on my common.css to remove that element?

Thank you. — regards, Revi 10:59, 13 January 2019 (UTC)

Found out the answer myself by looking at the above topic. For those who may be looking for this:
/** Initially posted by Mike Peel */
/** Just hiding captions */
.filepage-mediainfo-entitytermsview { display:none;}
/** Hiding "Structured Data" header */
.mw-slot-header {display:none;}
— regards, Revi 11:04, 13 January 2019 (UTC)
I thought original idea of Structured Data on Commons SDoC hereinafter (or a prototype of it I saw) was putting the SDoC section below the GlobalUsage or something like that. Is it me who has a wrong memory or has something changed thus creating this what the hell design? — regards, Revi 11:12, 13 January 2019 (UTC)
@-revi: There are two gadgets available in your preferences now - one that hides it completely as per the css, and one that collapses it by default but lets you expand it again if you want. Thanks. Mike Peel (talk) 11:48, 13 January 2019 (UTC)
Since I prefer codes on my local page rather than gadgets, thanks for letting me know but I will keep status quo. BTW, if possible, I want to force them to be H2, and moved to elsewhere (let's say, above Metadata section as prototype I recall was). Is it possible with CSS/JS? (Not asking you to do that but just wondering).
I have no interest in using it as currently is (it just sucks) but with the modification to put them away from the top of the page, it would be usable. — regards, Revi 18:20, 13 January 2019 (UTC)
@-revi: You can shrink it using e.g. h1.mw-slot-header { font-size:1.5em;}. as far as I can tell, moving it to a different part of the page is something the WMF would have to do. Thanks. Mike Peel (talk) 19:29, 13 January 2019 (UTC)
I think you can move things around using JavaScript (but because personal JS is loaded at the end, it will "jump around") − see for example MediaWiki:Gadget-CategoryAboveAll.js which moves the category box at the top. Jean-Fred (talk) 21:17, 13 January 2019 (UTC)
@-revi: captions certainly has some design issues that showed up in production that were not visible in testing. The team is working to identify the problems and push the fixes, I've made an update section that you can keep an eye on. Keegan (WMF) (talk) 17:57, 14 January 2019 (UTC)
It would be very useful to make a list of what was missed in testing, so that the problems we had here are less likely to be replicated in the future. - Jmabel ! talk 22:32, 14 January 2019 (UTC)
Oh of course, lists are being compiled and things will be shared. A majority of the issues following the release are bugs/design flaws that can only be surfaced from release into production; in most all software development there are limits to testing environments trying to replicate a live environment, with highly customized configurations, skins, javascript, css rules, abuse filters, etc. that come with all of the wikis.
All these excuses aside, a new testing environment that will be better at finding things has been in the works for the past few weeks, and should be up and live in time for depicts and other statements testing in a couple of weeks or so. In theory, it will be very helpful in reducing bugs in production. Keegan (WMF) (talk) 00:01, 15 January 2019 (UTC)

The CSS element name must have been changed, given that I see the caption stuff despite the css hiding them. — regards, Revi 10:44, 16 February 2019 (UTC)

@Keegan (WMF), you cannot quietly close the thread as if nothing happened. Don't treat us like a mockup testers (I really feel like I am the product) and use consistent CSS element name so I don't need to change it once more. — regards, Revi 01:26, 4 March 2019 (UTC)
@-revi: My intention was not to "quietly close this thread as if nothing happened." I was reading through threads, seeing what was stale, and marking them for archive to clean up this page before we release depicts. Your continued presumptions towards me make me sad. Keegan (WMF) (talk) 17:10, 4 March 2019 (UTC)
Hello @Keegan (WMF): well as you said that you were kind of new to the whole archiving thing, usually on pages like the help desk of WikiProject Korea the template {{Section resolved}} is only placed once the discussion has been... Well... Resolved, archiving inactive threads (which includes unresolved ones) happens after a certain amount of times, usually 7 (seven) days for a resolved one and here around two (2) months for an unresolved one. It's probably best to let the person who started the thread mark it as "resolved" or to let someone else mark it as "resolved" if the starter said that they had their enquiries answered. A stale discussion ≠ a resolved discussion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:55, 4 March 2019 (UTC)
I understand the tag can be removed by anyone, it says so right there on it, but that doesn't excuse what was said. In my opinion the issue is resolved as there is a gadget available for hiding captions, and the thread is stale as the situations have been resolved and there's nothing left to discuss. You don't need to "Well, actually" this. I stand by my statement about revi's lack of good faith in their comment removing the tag. Keegan (WMF) (talk) 18:23, 4 March 2019 (UTC)
Also, I was saying I'm new to setting up an archive bot for a page myself, it's something I've ever done for my own talk page. As I enter my fifteenth year of being a Wikimedian, I'm not new to the archival process. Keegan (WMF) (talk) 18:39, 4 March 2019 (UTC)
@Keegan (WMF):, pardon, I did not mean to question your seniority in any way and I am fully aware that you are "w:en:User:Keegan", a veteran to the project. I just meant that -revi didn't find this thread sufficiently resolved but as the ability to properly hide file captions has been introduced (as our colleague Alexis Jazz 🎺 explained below) I can fully understand your actions. I just do not think that "User:-revi" is sufficiently satisfied with the current situation of file captions on Wikimedia Commons and wants more solutions to be brought forth in this specific thread. Personally I'd like to see more technical discussions directed to the technical village pump and it might be handy to direct people there once file depicts rolls out for technical debate. (COI notice, I'm the bloke that proposed the creation of the VPT, so yeah I'm advertising it). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:46, 4 March 2019 (UTC)
@Keegan (WMF): you should probably take lessons from the whole Jdforrester thing. (though this thread isn't nearly as bad) If you had put a note at the bottom of this discussion saying "Collapse Captions and Hide Captions gadgets are working again." the {{Section resolved}} may have been accepted.. - Alexis Jazz ping plz 19:09, 4 March 2019 (UTC)

Can file depicts help train artificial intelligence?Edit

Soon structured data on Wikimedia Commons will manifest itself with “Depicts” which allows people to categorise images with tags that link to Wikidata pages. These “Depicts” are designed to list every subject depicted in the image and reminds me a bit of how Google Photos works, Google Photos is an online service which can categorise every image in its database by which subjects are depicted in it with mixed success. Because it relies heavily on bots that group images together into categories and is able to search 🔎 images based on what's depicted in them Google Photos is actually quite advanced in how it automatically organises videos and images. Now Google Photos as a service can be improved by humans by letting the software 👩‍💻 via the website "Crowdsource.Google.com" where human beings can help detect certain subjects and give feedback if they are or aren't in a photograph by going through categories. Now file depicts can potentially help software programmes like those in Google Photos to help recognise certain subjects as then us Wikimedia Commons volunteers will add tags as to what subjects are depicted in a photograph.

Now if let's say a company trying to develop image recognition software wants to utilise the data generated through file depicts, could they realistically utilise this data to help train their software? Of course this is a question for years in the future as most files won't have any depicts during "the transitional period"/"the introductory period", but as a long time goal, would they actually be useful for such purposes? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 02:13, 5 February 2019 (UTC)

  • I would think that (in theory) it should be roughly exactly as useful as categories. Whichever approach does a better job will be that much more useful to AI. - Jmabel ! talk 03:26, 5 February 2019 (UTC)
User:Donald Trung: I am already using Commons categories to train a neural network, and it works more or less, but I am hopeful that Structured Commons will make such tasks much easier. If I want to train a neural network that recognizes pictures of dogs, I will need around 10000 pictures of dogs, and Category:Dogs does not have that many pictures, so I will have to use sub-categories. Problem: Sub-categories include so many pictures that do not depict any dog, for instance everything in Category:Books about dogs‎, Category:Cynology‎, and even Category:Salt Lake City Intermodal Hub‎ (because it has a Greyhound station). That makes automatic AI training impossible. On the opposite, "depicts" statements will be much more usable, and concepts link to Wikidata items, which is much easier to link with the rest of the open data world than categories. Cheers! Syced (talk) 02:20, 28 February 2019 (UTC)
  • @Syced: this is exactly what I'm hoping for, websites such as TinEye, Microsoft Bing, and Google already use certain algorithms to find similar images based on colour, but Google Photos tries to take it even further by also recognizing what is actually depicted in the images, unfortunately Google Photos often misses the mark and while we can train it today with https://crowdsource.google.com/imagelabeler/category , it does not have a huge database of images where volunteers have already pre-explained the content of the images, I hope that in the future Wikimedia Commons could help train AI's, we were promised Skynet over a decade ago James Camerondammit, yet many computers still can't find puppies, how is a terminator supposed to target John Conner if it can't recognise his face? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:02, 28 February 2019 (UTC) (obviously the last sentence is in jest, just clarifying it in case anyone thinks that I'm an actual robot supremacist.)
  • Commons could be the first beneficiary of accurate Wikidata items recognition in images: The upload tools could recognize objects in the uploaded image and suggest values for "depicts". This won't be doable for items that don't already have many depictions, though. Syced (talk) 14:26, 28 February 2019 (UTC)

Relevance of captions for internal / external search?Edit

Wondering how the content of captions will influence the ranking when searching for images. Either through WP internal search or through third party external search (e.g. google). Can we use / misuse captions for SEO? Is there a policy about? best --Herzi Pinki (talk) 00:46, 15 February 2019 (UTC)

My opinion is that captions should definitely be used for internal search. Whether it is used by search engines is beyond our control, but I don't think it can be misused that much (similar to descriptions for instance). Cheers! Syced (talk) 02:04, 28 February 2019 (UTC)

Commons: or Help: page for DepictsEdit

Work is wrapping up for depicts, and there's a question about where to link to "Learn more" about depicts statements(design screenshot).

  1. Should the page point to the (currently non-existent) Commons:Depicts or Help:Depicts?
  2. Would someone like to create the preferred page with just some placeholder text until we have more information to publish there?

I've been steering away from creating pages in the community space, but I'm happy to do so if it's considered to be okay. Keegan (WMF) (talk) 17:33, 27 February 2019 (UTC)

I think that we could probably have a help page and a policy/guideline page, right? Or do it like "Help:SVG" where "Commons:SVG" and "COM:SVG" are redirects. It's probably best to let "the community" create them after launch, though it would be wise to post this to the village pump (Mobile 📱) so more eyes will see it first. File captions is at "Commons:File captions" for reference. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:23, 27 February 2019 (UTC)
Oh yes, I'm absolutely for the community creating the policy after the feature launches, and definitely promoting such a page on the village pump is part of the plan. I learned from the captions launch that I did not emphasize the necessity of the page enough, only a few passing mentions, because it took a day or two for the page to be created (thanks, Jean-Fred!) after captions launched. What we do have now is a chicken or the egg situation, where we need to know what to page to link "Learn more" to, but the community preference is to settle on a name once the feature is launched.
We can go head and have it link to Commons:Depicts and let redirects take care of the rest if the community decides on a different page name, but I want to make sure it's okay as an idea with y'all first, at least. Keegan (WMF) (talk) 19:42, 27 February 2019 (UTC)
I think that we need to take a step back and not really look at how the most active users look at it but how the noobs look at it. If you were to give a 12 (twelve) year old the assignment to upload a file to Wikimedia Commons and let them discover everything in the fields, is everything clear to them? As they might not understand file depicts immediately having (even a rudimentary) informational page would be very desirable, people started only talking about file captions when they didn't get it, so the question is, should the product be launched before the manual? I'd say that a draft could be created at a theoretical "Commons:Structured data/How depicts work" or "User:Keegan (WMF)Depicts" which could then be copied to the "Help:"/"Commons:" space to accompany the launch of the feature. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:05, 27 February 2019 (UTC)
@Donald Trung: I'm planning on writing up a short how-to for depicts as I did for file captions on MediaWiki.org, as mw.org is the "canon" host for documentation. It's free to be ported over here to accompany the release. However, the Commons documentation should provide some sort of policy in addition to how to simply use the thing, and that's where the community comes in to draft the policy.
So...yes, I'm happy to write up help and will be doing so, the only question that remains here is: where do we anticipate parking things, so that the developers can go ahead and code in a link? The link can be changed both through redirects here and, if needed, patches to fix in the back end. We simply need a place to start :) Keegan (WMF) (talk) 21:11, 27 February 2019 (UTC)
  Done I went ahead a made a stub at Commons:Depicts. I don’t see why we could not expand it with basic and less-basic information ahead of the launch, as it will be clear that this is not available yet. Jean-Fred (talk) 08:08, 28 February 2019 (UTC)
Thanks. There will be some conversation in the future about whether to provide "Learn more" links for every statement type, or to bundle them all together into a general information page about statements, but depicts solves the problem we have right now. Much obliged. Keegan (WMF) (talk) 17:16, 28 February 2019 (UTC)

Implementing "depicts" in an upload appEdit

Dear all,

I maintain an app used to upload pictures to Commons. I am starting to implement "depicts", and would appreciate some feedback. Here is my vision of how my app will look like in 6 months:

Upload:

  1. The user picks a local picture they want to upload.
  2. The user is asked to enter a caption and description (in their own language).
  3. The app shows a screen that says "What does your picture depict?" with a search field. When the user types "tokyo tow" they see the matching Wikidata items such as https://www.wikidata.org/wiki/Q183536 (actually what they see is the captions of these items, in their own language).
  4. They can choose several. Actually, a few items appear as suggestions: items used recently, items whose label matches the entered caption/description, items geographically close to where the picture was taken.

Search:

  1. The user goes to the search screen.
  2. The app suggests some popular items such as Q183536 (Tokyo Tower), in the user's language.
  3. The user can also search textually for items by label, in the user's language.
  4. The user taps on an item.
  5. A few result images appear at the bottom of the screen (scrolling makes more appear automatically). At the same time, at the top of the screen the suggestions change to show the items that are most depicted in images that also depict the Tokyo Tower, for instance Zojoji and Night.
  6. The user can tap on another item, the search will show images that depict both items, for instance images that depicts both Tokyo Tower and Night. The suggestions change to show items that are most depicted in images that also depict the Tokyo Tower and Night, for instance Illumination.
  7. Tapping more items refines the suggestions again.
  8. No "OR" operation is allowed, only "AND".

What do you think about it? Anything to improve, anything that would not work? Thanks! Syced (talk) 04:15, 28 February 2019 (UTC)

@Syced: Please understand that Commons does not host photos of the Eiffel Tower lit up at night (except any photographed by the lighting designers) because the lighting designs are above TOO in France.   — Jeff G. please ping or talk to me 18:54, 28 February 2019 (UTC)
That's sad news, thanks for the tip :-) I changed the example. Syced (talk) 02:29, 1 March 2019 (UTC)
@Syced: You're welcome.   — Jeff G. please ping or talk to me 12:51, 1 March 2019 (UTC)

Depicts (P180) vs Digital representation of (P6243) ?Edit

What is going to be the status of depicts (P180) versus digital representation of (P6243) ?

Presumably it's only P180 that will initially be available, but should editors be advised to hold off adding P180 to images if P6243 will be more suitable?

Is the development team aware of P6243, and is it intended that "depicts" searches will take it into account? Jheald (talk) 10:12, 28 February 2019 (UTC)

P6243 is only for precise digitization of 2D artwork if I understand correctly? For instance if I take a picture of Mona Lisa from across the room I can not use P6243 right? Syced (talk) 12:48, 28 February 2019 (UTC)
@Syced: Good question. I tried to ask it in the proposal discussion for P6243, but I'm not sure whether I ever got a clear answer. (What do you think?) Ultimately the meaning of the property will get defined by how it turns out to get used... with no uses yet, the boundaries may not be 100% clear. Jheald (talk) 13:29, 28 February 2019 (UTC)
@Jheald: Yes, the dev team has monitored the evolution of P6243. As you mentioned, much depends on how community will actually use it. There are no current plans to include it in depicts searches. RIsler (WMF) (talk) 18:34, 28 February 2019 (UTC)
@Jheald, RIsler (WMF), Syced:Sandra pointed out this question to me. We want to model what is in an image for searching, but also for legal status. I think we'll have three relevant properties here:
  • depicts (P180) - Everything that is visible in the image. We're using categories for this now.
  • digital representation of (P6243) - For a digital representation of a 2D work. This is more a legal focused property. We're using {{PD-art}} for that now. When the original work is in the public domain, the digital representation of that work is also in the public domain. With this property we have that as structured data.
  • New property "includes work" - To cover cases where images include other works. These works can be in the public domain (photo of an old statue) or still in copyright. In that case it should be qualified why the copyrighted work can be included. This would cover Freedom of panorama cases for which we now use {{FOP}} . Cases for which we now use {{De minimis}} would be covered too.
This way we should be able to cover a lot of cases with multiple works involved. Do you agree? I still have to propose the missing property. Probably would also need to create a bit of documentation when to use what property. Multichill (talk) 14:02, 15 March 2019 (UTC)
@Multichill: I think the specific question that was bothering me was this: if it is true that an image is a digital representation of (P6243) a particular work, what (if any) depicts (P180) statements should be added on CommonsData?
My understanding was that in such a case no depicts (P180) statements should be added on Commons -- all such statements should be added on the relevant item on Wikidata.
This is of considerable relevance for phab:T199241 ("If a MediaInfo items depicts something that has its own 'depicts' statements, add those to the search index too") -- the ticket should include the case that a MediaInfo item is a digital representation of (P6243) something with a depicts statement.
We should also be considering the question of how early digital representation of (P6243) needs to be being made available as an option alongside depicts (P180) in user interfaces. Jheald (talk) 15:12, 15 March 2019 (UTC)
@Multichill: Sorry I'm late to this party. Busy days :-). These are all good questions and I wish we had solid answers to them. We've attempted to have some general community discussions on this topic in the past, but it ultimately seemed too abstract for people to grasp without concrete tools to play with. Much may come down to just doing incremental work and seeing how people actually use things so we can model accordingly. Some people think that depicts (P180) should always be used, sometimes in addition to digital representation of (P6243) if necessary. Others like JHeald feel like P180 shouldn't be used at all in the case of a 2D faithful reproduction, and only P6243 should be used along with a 'import depicts statements from the Q item' system like the one in the ticket he mentioned (which we will be revisiting soon). Others view P6243 as not necessarily a "legal focused property", but simply a more accurate one (which is viewed as important among the "data purity" crowd). Which direction is 'right'? I'm not sure yet. As for "includes work", that may be a useful solution, but I wonder how it works with the proposals on [the Wikidata Copyrights modeling https://www.wikidata.org/wiki/Help:Copyrights], and whether we'd be better off simply using that as a guideline for licensing qualifiers on a depicts(P180) statement. I suspect some people may even use this as a counterargument in a property proposal discussion. The dev team is open to building in features that help simplify the complexities, but we also don't want to build stuff that boxes people in, or UX that doesn't reflect real-world workflows (many of which have yet to form). My personal preference is to rely on 'depicts' as much as possible for simplicity's sake, but I feel I may be in the minority there :-) RIsler (WMF) (talk) 02:23, 22 March 2019 (UTC)
From what I can see, this can all be done with depicts (P180), it doesn't need a new property. That matches what we do here with categories - you'd only include an image showing an artwork in the category for that artwork (if it exists), not a whole set of categories saying whether the image shows a dog, cat, person, etc. You can then derive that information from Wikidata if needed, in the same way that the information would be stored in the categories that the category for the artwork is in. Thanks. Mike Peel (talk) 21:11, 27 March 2019 (UTC)
Yes, categories are for what we see and these are replaced with depicts. This is for the template {{PD-Art}}.
For other readers, Mike nominated this property for deletion at d:Wikidata:Properties_for_deletion#digital_representation_of_(P6243). Multichill (talk) 21:24, 27 March 2019 (UTC)
@Multichill: and all: So for File:Mona Lisa, by Leonardo da Vinci, from C2RMF retouched.jpg as an example, rather than simply saying depicts (P180)=Mona Lisa (Q12418) and pulling the rest of the info from the Wikidata item, you want to say digital representation of (P6243)=Mona Lisa (Q12418) and depicts (P180)=person depicted in Mona Lisa  , sky, body of water, bridge, armrest, landscape, mountain, gaze towards the viewer   - and then repeat that information for all images depicting the Mona Lisa? If yes, why? Thanks. Mike Peel (talk) 20:21, 29 March 2019 (UTC)
Ah, I just realised that we're talking about {{PD-art}}, not {{Artwork}}. That explains some of my confusion, but now I'm not sure why we can't just do depicts (P180)=Mona Lisa (Q12418) and get copyright status (P6216) from there? Thanks. Mike Peel (talk) 20:26, 29 March 2019 (UTC)
Depicts doesn't distinguish between an exact reproduction and the painting is in the file.
  • exact reproduction covered by PD-art.

  • Mona Lisa in a larger photo, not an exact reproduction. Here you would use depicts

  • exact reproduction covered by PD-art that depicts the Mona Lisa and two other paintings

  • exact reproduction covered by PD-art that depicts a lot of paintings

  • This is not going to work with only depicts. Of course we're not going to copy all the depicts from Wikidata, those are on the Wikidata item which is connected through digital representation of (P6243). What makes you think I would even consider doing that? Multichill (talk) 20:49, 29 March 2019 (UTC)
    After an off-wiki chat with Multichill, I've withdrawn the deletion request. This seems to be about copyright, not about how to describe what the image depicts. I've made some tweaks to the property description to try to make that clearer, but it still needs more work to clearly explain what this property is for, otherwise it will probably be misused in the future. Thanks. Mike Peel (talk) 21:09, 29 March 2019 (UTC)

    MediaInfo entities RDF representationEdit

    Hey, I have written a first draft of a proposal for an RDF representation of MediaInfo entities with additional data from the MediaWiki files metadata. After a discussion/improvement phase, if the dev team is ok with it, I could submit some changes to the MW extension to emit this format, just like I did for WikibaseLexeme. Tpt (talk) 13:06, 5 March 2019 (UTC)

    Interesting, thank you. I'll pass it along. Keegan (WMF) (talk) 19:19, 5 March 2019 (UTC)
    @Keegan: Any idea what the current hoped-for landing date is for getting a version of WDQS live that includes CommonsData ? Jheald (talk) 22:41, 5 March 2019 (UTC)
    @Jheald: I do not know at this time. I'll be sure to post here when it is. Keegan (WMF) (talk) 17:15, 6 March 2019 (UTC)

    Development update, March 2019Edit

    Greetings,

    I will likely also be sending this message out to the Structured Data focus group, so my apologies in advance if you're going to see this twice.

    A development update for the current work by the Structured Data on Commons team:

    After the release of multilingual file captions, work began on getting depicts and other statements ready for release. These were originally scheduled for release in February and into March, however there are currently two major blockers to finishing this work (T215642, T217157). We will know more next week about when depicts and statements can likely be ready for testing and then release; until then I've tentatively updated the release schedule.

    Once the depicts feature is ready for testing, it will take place in two stages on TestCommons. The first is checking the very basics; is the design comfortable, how does the simple workflow of adding/editing/removing statements work, and building up help and process pages from there. The second part is a more detailed test of depicts and other statements, checking the edge-case examples of using the features, bugs that did not come up during simple testing, etc. Additionally we'll be looking with the community for bugs in interaction with bots, gadgets, and other scripts once the features are live on Commons. Please let me know if you're interesting in helping test and fix these bugs if they show up upon release, it is really hard to find them in a test environment or, in some cases, bugs won't show up in a testing environment at all.

    One new thing is definitely coming within the next few weeks, pending testing: the ability to search for captions. This is done using the inlabel keyword in search strings, and will be the first step in helping users find content that is specifically structured data. I'll post a notice when that feature is live and ready for use.

    Thanks, let me know if you have questions about these plans. Keegan (WMF) (talk) 18:16, 8 March 2019 (UTC)

    I wonder how we can advocate search in Captions? Is it better than search in description? Juandev (talk) 11:28, 13 March 2019 (UTC)

    Usage of "depict" in edge casesEdit

    Everytime I upload a picture, I try to think about Wikidata items it depicts. I usually can find good ones (existing or not yet), but I encountered two subtle cases so far, and added them at the end of the Commons:Structured_data/Get_involved/Feedback_requests/Interesting_Commons_files#Others section.

    Briefly said, it is:

    • An industrial machine with a prominent "Made in Wolverhampton". What is its relationship with Wolverhampton?
    • A "we have moved" notice. What relationship?

    I would love to see your depictions about these. By the way, we should really write down ideal metadata for all images on that page, to make sure we have a clear idea of what we want. Cheers! Syced (talk) 03:02, 13 March 2019 (UTC)

    Captions for a GLAM audienceEdit

    Hello everyone, In two weeks I'm meeting with a French museum who wants to upload their collections (including modern art <3) to Commons. The training will also feature several students in art history. How should I communicate around captions and structured data present and future in a way that is non-confusing, useful to them, and honest ? Léna (talk) 10:28, 14 March 2019 (UTC)

    @SandraF (WMF): I think you might be able to give some advice here? Keegan (WMF) (talk) 17:09, 14 March 2019 (UTC)
    On most modern art, won't there be copyright issues? Artists don't generally transfer their copyrights to those in physical possession of their works, museum or otherwise. - Jmabel ! talk 20:04, 14 March 2019 (UTC)
    Modern art started in the 1860s, so I guess a sizable proportion of it is now public domain :-) I actually took pictures of barely-known Picasso works that might become public domain in half a century, I will try to live old enough so that I can upload them one day ^_^ Back on the topic, my opinion is that good captions are the ones that can be used as-is as thumbnail caption in a Wikipedia article (but without the wikilinks), so I would have a look at https://en.wikipedia.org/wiki/Modern_art and realize that most of the captions are like "Black Square by Kasimir Malevich, 1915", so I would suggest constructing captions as "<artwork title> by <artist name>, <creation year>". I am not a specialist about artwork in Structured Commons so others should answer better than me, but my understanding is that they will have to find the artwork's Wikidata item (create a new one if none exists), link to it from the media with a "depicts" statement (not sure whether this is technically possible already or not) and fill the metadata (genre, artist, what it depicts, etc) at that item. Syced (talk) 09:14, 15 March 2019 (UTC)
    @Léna: The most brutal part of the process is probably going to be the data reconciliation.
    Given that these are museum-grade works of art, each one should probably each be getting a Wikidata item in its own right. That means you don't really need to worry about where the Structured Data project is at, you will be targeting Wikidata directly, a more developed and stable known quantity. There are some tools and workflows already developed for translating collection information into Wikidata items -- User:Multichill has done a lot of this work and created much of this, and can probably point you to wiki-help pages describing his workflow.
    First thing to do is to identify whether any of the collection already has Wikidata items -- probably not, but you never know. For almost all of the collection, though, you can probably assume you're going to need to be creating new items. These can start out as skeleton items at first, and additional information can always be added. But as a rule of thumb, as much as possible of what you want to present on the file description page for the object you should aim to be getting into its Wikidata item. Then when you upload images, you can build the file description pages based on the information on Wikidata, including using templates like {{wrapWD}} or {{label}} to automatically generate linked internationalised strings for field entries based on the labels for items at Wikidata.
    As I wrote at the top, the biggest step in this is likely to be the data reconciliation -- in particular the creator names: does Wikidata already have an item for this creator? Does a new one need to be made? OpenRefine can help you a lot here, but it can still be quite a brutal process. Other fields will also need reconciliation -- eg places of creation, provenance, etc. Places can be surprisingly difficult to reconcile, because Wikidata may have multiple items for the same place in different roles, or multiple places with the same name. Also if you have any subject metadata -- eg genre, style, things depicted in the work -- those are also things to reconcile; and again, you may find new items need to be made.
    The good news is that good Wikidata reconciliation should make Commons categorisation more easy. For example, having identified the Q-numbers for your creators, you can extract with a query which ones already have a creator template here, which ones already have a Commons category, etc. If they don't have a Commons category, you should probably create one once you start uploading images.
    It's worth noting that SDC is not going to make filepages disappear, and it's not going to make the need for categorisation disappear, not even in the mid- to long-term. Uploading projects that don't do proper categorisation are likely to get blocked until they do. So categorisation is something to take seriously. You will need to identify the category structure in the areas of the different aspects of the kind of things you will be uploading, and you may need to refine it. Jheald (talk) 11:03, 15 March 2019 (UTC)
    @Syced: and @Jheald:, thank you for your answers, there is lot of information in them and I will take time to fully digest them properly because they will help me in my practice of mass uploads of GLAM collections. However, the crucial point of my question was missed :) I don't need technical information on how to do uploads or copyright laws, but a communication expertise on how to answer newbies questions around structured data such as "Why there is a structured data area in the Commons file page ?" or "How is it different from the Wikidata item and the description area ?" Léna (talk) 11:22, 15 March 2019 (UTC)
    Session at the recent GLAM-Wiki conference (Tel Aviv) about Structured Data on Commons

    @Léna: For your communications goals, maybe you can find inspiration in some recent presentations about SDC? Check the video on the right for the session on SDC at the recent GLAM-Wiki conference. For captions, I would personally write something like Artist Name: Work Title (year), collection The Museum Collection - that will probably make it most discoverable, and it is very similar to how artworks are 'captioned' in books. There is not really a 'best practice' for this on Wikimedia Commons yet though, and I'd be very curious to hear what your museum contacts themselves would like to see! SandraF (WMF) (talk) 11:32, 15 March 2019 (UTC)

    @Léna: (ec) "Commons is going to have its own database like Wikidata, but with an entry for every image, rather than Wikidata, which might contain an entry for a particular object. It will be coming soon, and you can start to see the first signs of it, but it's not quite here yet. This will be in addition to the conventional description pages and categorisations, which images will continue to have." Jheald (talk) 11:35, 15 March 2019 (UTC)
    @Jheald: But the entries for the subjects will be in Wikidata, right? We already have entries for some photographs (e.g. [1]), so in these cases, there will be a duplicate. This is a rather confusing. Regards, Yann (talk) 10:28, 16 March 2019 (UTC)
    @Yann: Okay, so in the above, substitute instead the wording "Commons if going to have ... an entry for every file" -- i.e. each distinct digitised image with its own description page.
    Literally, "each distinct digitised image with its own description page" already was here before captions, they can only duplicate what exists. The only relevant caption I have seen this week on my uploads was for someone to caption an official photograph of a politician with "bollocks". Luckily as I have the 'captions feature' switched off, I can neither see it on the page, nor edit it. -- (talk) 11:30, 19 March 2019 (UTC)
    Commons will hold information that is specific to the file. Information that relates to the work will be on Wikidata, if a Wikidata item for the work exists, as probably one should most of the artworks in the museum. Jheald (talk) 13:36, 16 March 2019 (UTC)
    After lot of thoughts I'm going to present captions and structured data as an illustration that we are a small movement in term of financial power (why we stayed so many years building a multi-lingual database of multimedia files with a software built for a monolingual encyclopedia) and always evolving (why the structured data is only half-baked) in a complex legal environment (why captions were not generated at first : CC0 vs CC-by-SA and responsibility of content is on the community, not the host). Léna (talk) 11:19, 19 March 2019 (UTC)

    After I express everything in Structured data, will I still need to find categories telling the same?Edit

    Let's say I took a picture, I set its location to "Lincolnshire", I set its "depicts" to "house" and the color of that house to "pink".

    After entering that Structured data, will I still need to spend minutes finding the right category, which in this case would be "Category:Pink houses in Lincolnshire"? (after checking whether "Category:Pink houses in Lincolnshire in 2019" exists or not)

    Or will such categories be converted, with all of their content getting Structured data, and finally the category getting removed? Or on the opposite, will such categories be automatically added to new uploads based on their Structured data?

    Structured data will document a picture among several "dimensions" such as time/location/color/etc, maintaining categories for each possible combination of these dimensions sounds redundant to me.

    Thanks for your insight! Syced (talk) 07:54, 16 March 2019 (UTC)

    @Syced: The answer to your headline question is: Yes. Categories will remain for the foreseeable future. The structured data experiment is being allowed on condition it doesn't mess up the existing ways of doing things. Undermining categories, or encouraging the addition of lots of material without proper categorisation, would be messing up the reliability and expectation of recall of the existing methods of retrieval in just such a way. It's also worth noting that for a long time to come, SDC will contain neither the coverage of data to replicate the retrieval that categories currently give, nor will it have the search methods to know that a pink house in Belton (Q4884760) should be retrieved as being in turn in Lincolnshire, or that searching for a judge means searching for a person with a particular occupation.
    Categories also often have the advantage of being natural units for curation and refinement, that can be annotated. I don't see Commons giving that up lightly.
    I would hope that one day there will be tools that will be able to automatically suggest or refine categories given particular structured data statements. But that won't be possible until we can easily record and retrieve what categories mean in terms of statements and Q-numbers. Until that point, therefore, categorisation will need to carried out by hand.
    But I would reiterate the point I made in the section immediately above. Commons expects uploaders to make a reasonable attempt at decent categorisation. Uploaders that do not make such attempt, including large-scale upload projects, can expect to be blocked until they start to make such an effort. SDC will not materially change this. Jheald (talk) 09:26, 16 March 2019 (UTC)
    I see! I surely hope that Structured data's "Where" search field will be able to dig P131s (located in administrative), just like FastCCI does for categories. Searching for the string "judge" should indeed show you pictures that depict Q16533 (judge) or pictures of items that have Q16533 as the value of any of their properties (easier said than done). Cheers! Syced (talk) 12:59, 16 March 2019 (UTC)
    • On the other hand, if/when Wikidata people finally manage to destroy categorization altogether (with possible prior syphoning off some of its data, to be able to crow about it), then it will be even easier to dupe the innocent bystander about how great Wikidata is and how horrible was the old way, with all those untrendy nerds and their Monobooks and landscape aspect displays. Meanwhile we’re fighting a losing battle against an overhyped, overfunded foe. And to think that when it started Wikidata in Commons was seen as a way to enhance categorization, enabling interesting stuff like multilingual categories… -- Tuválkin 09:34, 16 March 2019 (UTC)
    • @Syced: To be clear, I personally don’t expect you or anyone to add any categories, if you don’t feel like it. Another thing many people don’t understand is that in a wiki what one user wont do another might go ahead and do. -- Tuválkin 09:38, 16 March 2019 (UTC)
    @Tuvalkin: Understood, thanks! I always carefully categorize my uploads, but for the sake of the argument let's say that after taking a picture of a pink house in Lincolnshire, I put it into the categories "Lincolnshire", "Houses", and maybe even "Pink"... would you deem that as acceptable? It is a honest question. Thank you! Syced (talk) 12:59, 16 March 2019 (UTC)
    Much to my amazement, there is a Category:Pink houses in Lincolnshire (only one member so far) but if there weren't, then its non-meta parent categories would be the most appropriate: Category:Pink houses in the United Kingdom and Category:Houses in Lincolnshire. - Jmabel ! talk 02:43, 17 March 2019 (UTC)

    Repetition of Caption sectionsEdit

    Hi,

    On attached:

    I'm seeing two iterations of the caption section each containing two (empty) iterations of the "British English" section. The actual caption is under "English". How did this happen and how can I correct it?

    Murgatroyd49 (talk) 09:32, 18 March 2019 (UTC)

    OK now I'm getting paranoid, it also happened at File:Sutherland Circle.jpg, just after I added that image to a Wikipedia page. Murgatroyd49 (talk) 12:20, 18 March 2019 (UTC)
    @Murgatroyd49: that sounds like a cache issue with MediaWiki that should clear up on hard page refresh. It happens from time to time in all kinds of interesting places. Let me know if it's a regular occurrence for you, or if it's only happening to files you've recently touched. Keegan (WMF) (talk) 17:19, 18 March 2019 (UTC)
    @Keegan (WMF): Thanks I'll keep an eye on it. Murgatroyd49 (talk) 17:32, 18 March 2019 (UTC)

    Early depicts testingEdit

    The Structured Data on Commons development team has the very basic version of depicts statements available  for early testing on Test-Commons. You can add very basic depicts statements to the file page by going into the new “Structured Data” tab located below the "Open in Media Viewer button." You can use the Latest Files link in the left side nav bar to select existing images, or use the UploadWizard to upload new ones to test with (although those images won’t actually show up on the site). The test site is not a fully functional replica of Commons, so there may be some overall problems in using the site, but you should be able to get a general idea of what using the feature is like.

    Early next week I will call for broad, community-wide testing of the feature similar to what we did for Captions, with instructions for testing, known bugs, and a dedicated space to discuss the feature as well as a simple help page for using statements. Until then, you're welcome to post here with what you might find while testing depicts.

    Thanks in advance for trying it out, you'll be hearing more from me next week. Keegan (WMF) (talk) 21:28, 21 March 2019 (UTC)

    Looking promising! At [2], the 'structured data' tab appears, but it's not possible to select it (at least when browsing while logged out). It works OK at [3], so presumably it depends on whether a depicts statement already exists or not (and anon editing at that page works OK). At that second link, how can we get the primary depicts ID into the artwork template? Thanks. Mike Peel (talk) 21:45, 21 March 2019 (UTC)
    Both works to me. Juandev (talk) 22:00, 22 March 2019 (UTC)
    I do not got a way do add depicts in the upload wizard and images do not get displayed with the message "Unauthorized This server could not verify that you are authorized to access the document you requested." But adding depicts to uploaded files works. --GPSLeo (talk) 22:40, 21 March 2019 (UTC)
    That is probably because upload was not set. If developers want us to test it via uploadWizard, they should link it from the Upload file link in the menus below the logo.Juandev (talk) 22:00, 22 March 2019 (UTC)

    Test-Commons do not seem to be working properly, at least I can't see any file over there (all seem to be broken).-- Darwin Ahoy! 00:38, 23 March 2019 (UTC)

    References & deprecation & moreEdit

    After hitting "random file" enough times, I finally found a file with a 'structured data' tab that worked: https://test-commons.wikimedia.org/wiki/File:Godward_Idleness_1900-dupe!.jpg

    A couple of points: Statements ought to be referenced, or to have the capability to be referenced. If the information has been imported from a GLAM's catalogue, it should be possible to record that sourcing on the statement. If a given authority says that an image is of a particular species of plant, it should be possible to reference that authority.

    However, imported data can also be wrong -- for example, an engraving that was previously thought to be of A, but is now known to be of B. It needs to be possible that people used that the image depicted A, because otherwise people may find and add this information; but it also needs to be possible to record that the statement is wrong, by showing that it is deprecated.

    Next: on this image we're showing it as depicts (P180) Idleness (Q19953492), but also depicts (P180) kitten (Q147), girl (Q3031). The latter statements really shouldn't be on Commons -- or at least, not shown as local -- if they can be inherited from Idleness (Q19953492) on Wikidata.

    Finally, looking at the page full-screen on a widescreen laptop (my normal web-browsing mode), there is a vast gulf in the middle of the page between the labels on the left of the things depicted, and the right hand side with links and 'make primary'. This doesn't feel like good design. Surely there should be a maximum on the width of this panel? A mouse-over tooltip to explain that 'Idleness' is a 'painting by John William Godward' (its Wikidata description) would probably be useful too, otherwise (i) just the bare word people might find quite confusing, and (ii) so that somebody who does mouse-over can easily confirm that the statement has been properly coded it is Idleness (Q19953492) and not idleness (Q16323159) that the statement relates to.Jheald (talk) 22:47, 21 March 2019 (UTC)

    I think these image should not get any depicts (P180) for images like this there should only digital representation of (P6243) be used. --GPSLeo (talk) 22:54, 21 March 2019 (UTC)
    Personally I would agree, but if we take that view we should impose it (and make it work) right from the start. I really don't want to be having to search for and clean up a load of bad data down the track "because it was added in an early version". Jheald (talk) 23:00, 21 March 2019 (UTC)
    I'd prefer to keep things simple: just say "this depicts this object" (where that object has a Wikidata item), and we can go from there. digital representation of (P6243) was a bad idea and should be deleted (it's now at d:Wikidata:Properties_for_deletion). Thanks. Mike Peel (talk) 23:50, 21 March 2019 (UTC)
    Hello all. Thanks for testing this feature early. I'll take this opportunity to address a few of the points brought up here. First, as far as depicts vs. digital representation of, this is an ongoing debate within the community and we encourage everyone to continue to work together towards a model/policy that makes sense for Commons. The development team intend to support both properties. In the case of artwork, there are some potential issues with duplicating information that is already stored in a Q item on Wikidata, which is why some time ago we started work on a feature we called 'depicts of depicts', which would essentially "import" depicts data from any depicted artwork that had its own depicts statements on Wikidata. That import was only stored in the search index for the file, and displayed in the file page UI in a special way, but never actually added to the MediaInfo item on Commons. This work (detailed in this ticket) pre-dated the creation of the 'digital representation of' property and the desire of some community members to model the situation differently. We are looking into repurposing our original plans so that they work with the new property. This could potentially be part of the later release where we launch support for all statements. In regards to support for references and deprecation - our initial rollout will not support these features as we need to learn more about real usage in this new context on Commons. References and deprecation are confusing and often inaccurate systems on Wikidata already and we didn't want to introduce those same problems here without putting a lot of thought into the design. We appreciate ideas and feedback as we gradually introduce all these new concepts to Commons. Finally, in a patch that will arrive before we release depicts support, we'll adjust the width of the field so when viewing in fullscreen things won't be terribly spaced out (ticket here). Thanks, as always. RIsler (WMF) (talk) 01:32, 22 March 2019 (UTC)
    @Jheald: deprected? Why? Why not you change wrong item, with the correct one? Or use a different property something like "wrong identification" XY date 2013?
    kitten (Q147), girl (Q3031) shouldnt be on commons? I think the opposite. Idleness (Q19953492) is actually name of the file, so I would set items, which are obvious = painting, woman, cat.Juandev (talk) 22:11, 22 March 2019 (UTC)

    Do not roll out only depicts (P180) without any way to add other statementsEdit

    I think if the structured data gets rolled out only with the option to add statements with depicts (P180) people will start to add the location in these field. I think we only want what the image depicts there and information about the location in an other field like location (P276) or located in the administrative territorial entity (P131). May this could be corrected later by a bot, but I think it would be better to never let people start to misuse depicts (P180). The topic of above is likely about the same issue. --GPSLeo (talk) 23:06, 21 March 2019 (UTC)

    Most of that information should be stored on Wikidata, not here. Mike Peel (talk) 23:57, 21 March 2019 (UTC)
    Hello, all. Thanks for the feedback. We are looking forward to more of these discussions within the community about how P180 "should" be used. What if, for instance, I have a scan of a postcard of Paris? Is it wrong for me to say depicts: Paris ? It would certainly be wrong to say location: Paris, especially if I wasn't in Paris when I took the photo. So what's the "right" way to do it? We have to account for many Commons use cases, and using Wikidata-style structured data to model multimedia is kind of a new thing, so there is much for everyone to learn and discover. With that said, there will certainly be rules for depicts that the community decides upon at some point. We are leaning towards the community using AbuseFilter to enforce those rules, much like Wikidata does in some cases already. RIsler (WMF) (talk) 03:08, 22 March 2019 (UTC)
    I don't think you can say "It would certainly be wrong to say location: Paris". Photographs have a location associated with the position of the camera, and we can also give a location for the depicted subject(s) (camera and subject locations). If you are scanning a photo on a postcard, the camera location of interest would be the camera location that created the original image. There may be other locations; the location where a photo was digitized is unlikely to be of much interest (although the person/organization that digitized it would be recorded); the location where an artist painted a picture (maybe in their studio) could also be different to the point of view of the painting. We do have categories for images that "depict Paris", namely under Category:Views of Paris. --ghouston (talk) 03:19, 22 March 2019 (UTC)

    Points by JuandevEdit

    Hey, thank you for providing us a testing environment. I have few proposals and questions regarding that:

    1. Do we plan other statements than depicts? e.g. objec location, which is the part of broader object - eg painting Mona Lisa stays in Louvre gallery
    2. Would you enable quelifiers to depicts items?
    3. How we will use "depicts" for audio files? Probably same way, but than depicts sounds misleading.
    4. Would be interesting to connect depicts items with image area layers. Let say, there is the panorma of the city and today we can describe different depicted object to the image (maybe extension imagearea could be used also). So it would be interesting to somehow connect both data.
    5. How to fill depicts, when the mane motive of the image is unknown - such images are also hosted in WMC and they are set to categories like Unidentified X? One sollution might be to set the closes item. So if I have unidentified plant the item might be "plant", if U object, item "object". But I thing this is not the right way.
    6. Simmillar question would be non-existent item. Why we cannot set nonexistent values on Wikidata?
    7. hard to find right item - when there are more items of the same name - provide thumbnail from wikidata? This problem is picky even on the Wikidata itself if you have a lot of items of the same name.
    8. and I would redisegn that dropdown menu with items. Its pretty wide, which is mostly not needed, but unecesarry thick

    Juandev (talk) 21:53, 22 March 2019 (UTC)

    I add one point here:
    Thanks, Juandev. I can answer 1-3 at the moment.
    1. Other statements will be released soon
    2. Qualifiers will be enabled, yes
    3. "Depicts" might not be right for audio, the solution is not settled yet
    I hope to be able more questions with time, as many do not have firm answers yet. Keegan (WMF) (talk) 17:25, 25 March 2019 (UTC)

    GlossaryEdit

    I've started a glossary for the project, based on Wikidata's glossary. All edits welcome, feel free to make new entries, etc. Similar guidelines will probably be helpful but we're just getting started. Keegan (WMF) (talk) 18:17, 22 March 2019 (UTC)

    It would probably also be good to have a dedicated "{{Structured data}}" navigational template to link all pages related to Structured Data on Wikimedia Commons (SDC) to. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:20, 22 March 2019 (UTC) Nah, it would probably be better to add "Commons:File captions", and "Commons:Structured_data/Glossary" to "Commons:Structured data/Navbox" and then add the latter to the bottom of those pages. Also to "Commons:Depicts". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:33, 22 March 2019 (UTC)
    I really don't want to be a Nagging Nancy, but there's already another glossary, I propose that the newer one should best only be used for launched features such as file captions, statements, file depicts, Etc. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:39, 22 March 2019 (UTC)
    Ha, I totally forgot about that glossary, but yes they do appear different in scope. The /About one is more high-level to the organization of the project and work, the "new" one is more technically oriented towards features. I'll get links and descriptions for the pages organized next week. Keegan (WMF) (talk) 20:52, 22 March 2019 (UTC)
    Okay, we now have the
    That should take care of it. Keegan (WMF) (talk) 21:01, 22 March 2019 (UTC)

    Strange captionsEdit

    Please see LauraHarvey45 contributions. The first diff to File:Backlit keyboard.jpg says

    "Image by Colin via Privacy Canada. A backlit laptop computer keyboard. Most fingers are on the “home” keys for touch-typing; the ‘U’ key is being pressed. Focus stack of 36 frame combined/retouched using Helicon Focus. Further retouching in Photoshop"

    While "by Colin" might be fine, I have no idea what "Privacy Canada" have to do with it. Is that a website where my image is used? The next two sentences come from the keyboard description, but the focus stack sentences come from File:Philips Series 7000 shaver head.jpg. The rest of User:LauraHarvey45's contributions mention "Gun News Daily", presumably because that website uses those photos. Does anyone know what is going on?

    Does Commons have a help page for Captions? For example, a Caption that was merely a title might be fine on Wikipedia where there is a link to the attribution page, but elsewhere would fail CC licensing terms for not including the author, the specific licence used, and urls/links. -- Colin (talk) 08:52, 25 March 2019 (UTC)

    Just a hint: Commons:File captions --XRay talk 11:39, 25 March 2019 (UTC)
    "Precise guidelines on file captions still have to be developed" :-(. I hope Commons Structured Data is planning to extract licence and attribution info in a structured way, so that automated full legal captions can be generated. I'd still like to know where the above caption info came from. -- Colin (talk) 15:01, 25 March 2019 (UTC)
    Meanwhile, common sense should apply. Don't hesitate to edit if you think you can improve it.
    In particular, certainly feel free to remove false information, and I don't see any reason the caption should mention the photographer unless the photographer is notable. - Jmabel ! talk 15:05, 25 March 2019 (UTC)
    What I'm concerned about is if there is some tool or website that causes such wrong captions to be created. -- Colin (talk) 15:58, 25 March 2019 (UTC)
    “I hope Commons Structured Data is planning to extract licence and attribution info in a structured way, so that automated full legal captions can be generated.” − yes, storing licensing information as structured data is very much on the SDC roadmap (see Commons:Structured data/Development for some more information).
    (that being said, licensing information is probably one of the area where our templating system kind-of-not-too-bad-sort-of-works − see COM:MRD for more information − and from which we should be able already to generate license-compliants by-lines [not using the word caption for this on purpose for clarity], as does the Help:Gadget-Stockphoto ; or the Commons:Attribution Generator [although it’s unclear to me how much it reimplements/hardcodes the MRD functionality…)P
    Regarding the captions here, I guess the best course of action is to ask the user how they wrote them.
    Jean-Fred (talk) 16:53, 25 March 2019 (UTC)

    "Depicts" statements ready for testing and releaseEdit

    Copied over from the Village Pump

    After the resolution of some technical blocks, the Structured Data on Commons team is ready to test and release support for statements on Commons, starting with the depicts property on the file page. Depicts statements are meant to be some of the simplest possible descriptors for a file. For example, File:Square_-_black_simple.svg contains what can be considered a depiction (P180) of a geometric square (Q164). I would like to emphasize that this first release of depicts statements is very, very simple and there is much more to come to build out the feature. Further support for depicts statements, such as in the UploadWizard and with qualifiers, will be released within the next few weeks after the initial support goes live here.

    The development team is looking to make sure of design and functionality for adding, editing, and removing statements. The current plan is to test depicts on Test-Commons for a week to find potentially breaking bugs, do a systems test on Test Commons to discover configuration discrepancies, and then release live into production here on Commons. Once we release the software, there will be bugs that show up here on production Commons that did not or do not show up in testing; the team will work to document, triage, and fix these bugs. If all goes well, depicts will be turned on next week, during the week of 1 April'. I will post in advance which particular day the software will be turned on once that is determined.

    Please help test depicts before it is released here. Testing information is available on this page, and you can leave your feedback on the test talk page. If your testing finds no major concerns or flaws that you'd like to comment on, please let us know that as well. Even a simple “Looks good to me” is helpful feedback. You must be logged in to test depicts; Test-Commons is tied to CentralAuth so your account here should work there without any action from you.

    Additionally, any thoughts or concerns about gadgets or tools that might break because of this launch are appreciated so that the issues can be sorted out to be fixed. These community-developed resources are especially vulnerable to problems when new software is released live and we'd like to make sure people are looking out for them.

    Thanks, let me know if you have any questions about the testing and release process. Keegan (WMF) (talk) 16:44, 26 March 2019 (UTC)

    Thanks for the info Anthere (talk)
    @Keegan (WMF): Probably not ready, see phab:T219450. This caused a serious issue on Commons. Much more testing is needed. Also to avoid the fiasco of captions. Thanks, Yann (talk) 16:07, 28 March 2019 (UTC)
    @Yann: phab:T219450 is a nasty bug indeed. It looks like it's being addressed and a patch is up to get things fixed. I want to be clear about this with you: there will very likely be bugs when we release into production here that we didn't find in testing/the test environment. We're introducing multi-content revision and federated Wikibase into industrial scale use for the first time ever, there's no way to mimic it in testing. I will continue to be clear about this, there should be no expectations that no bugs will show up. It's simply unrealistic. Things may break. If and when this happens the development team will be responsive and fix things. Keegan (WMF) (talk) 17:22, 28 March 2019 (UTC)
    @Keegan (WMF): Of course, there may be bugs on the new feature(s), but deployment should not break the existing environment. Regards, Yann (talk) 17:35, 28 March 2019 (UTC)
    What I'm saying is, with this project we're deploying software that adds a totally new framework to MediaWiki, it's not only working within MediaWiki, and here be dragons. It's impossible to know with 100% certainty with this software bundle nothing will break. The team is doing what it can to mitigate this, including breaking down the release into the most very basic parts, and it will respond to problems, but we're dealing with unknowns because this has never been done before here. Keegan (WMF) (talk) 17:46, 28 March 2019 (UTC)
    There is an old joke, we used to use an our example for responding to "middle management" about production quality issues on the factory floor. "We love quality targets. As you want a target of 3 failures this month, we have broken three units. Can we have our performance bonus early?".
    Of course, that joke was before so-called "Agile" development as understood uniquely in Silicon Valley, where people believe that breaking everything is good, and if they believe it hard enough it might be true. Alternatively, you could invest in reliable, credible, repeatable testing. -- (talk) 18:02, 28 March 2019 (UTC)
    • @Keegan (WMF): This is utterly unbelievable — both the technical mess up, and then the excuses. You guys are supposed to be professional developers, not geeks tinkering with stuff. Seems though we have all the bad aspects of the former (pandering to trends, sabotaging power users, corporate legalese, PR stunts) but none of the professionalism, plus all the bad aspects of the latter («Dude!, we totally trashed the whole rig, live!») yet none of the star-eyed idealism about building a better world in shortsleeves. -- Tuválkin 18:17, 28 March 2019 (UTC)

    Faceted search?Edit

    I was wondering if faceted search is on the roadmap somewhere? Couldn't find an obvious task in Phabricator. As a user I would expect to be able to search for Rembrandt and get Rembrandt (Q5598). Based on that I would expect suggestions like: Paintings/drawings/prints by Rembrandt or streets named after Rembrand. See this query. You can change the "Q5598" in the query with something else to get similar suggestions sometimes with quite unexpected results. Heavy usage items like Berlin might take some time to complete. Multichill (talk) 20:56, 27 March 2019 (UTC)

    Looks like phab:T213360 ("filtered search") is furthest ticket blocked out so far for search refinement, and even then only focussed on what could be a very first step, with deliberately restrained objectives. Jheald (talk) 01:23, 29 March 2019 (UTC)
    @Multichill: I know the development team talked about perhaps getting search to that point. I'm not sure what the technical and content blockers might have been or are. I'll see what I can find out. Keegan (WMF) (talk) 19:30, 29 March 2019 (UTC)
    Thanks Keegan. Right now we're basically only doing full text search with some tweaks. With just depicts enabled faceted search isn't very interesting yet, but once we start adding more metadata like when and where it was taken, it suddenly becomes very interesting. Multichill (talk) 19:39, 29 March 2019 (UTC)

    Searching structured data is availableEdit

    Searching structured data is possible using the standard Commons search bar. I've added search instructions for captions to Commons:File captions; depicts and other statements will be searchable right out of the box when they are released. Keegan (WMF) (talk) 17:46, 29 March 2019 (UTC)

    Switching off watchlist changesEdit

    Hi, when a caption is added it causes an entry in the watchlist so is there some flag that needs to be toggled to ignore these changes? Keith D (talk) 23:14, 31 March 2019 (UTC)

    I do not see a need. Changing the caption is nearly the same like changing the description and there is also no way to not show changes of the description. --GPSLeo (talk) 08:39, 1 April 2019 (UTC)
    It is not like changing the description as it cannot be seen in the wikitext of the page so should be separate and have some way of seeing/hiding such changes similar to wikidata changes. Keith D (talk) 11:20, 1 April 2019 (UTC)
    •   Support Yes, an option for hidding captions editing would be useful. --Yann (talk) 11:51, 1 April 2019 (UTC)
      An option for only displaying captions editing would also be helpful to counter vandalism.   — Jeff G. please ping or talk to me 14:08, 1 April 2019 (UTC)
      The artificial limit of 1,000 changes is also a driver for this. Keith D (talk) 16:10, 1 April 2019 (UTC)
      @Keith D: I agree, but where is "The artificial limit of 1,000 changes" documented?   — Jeff G. please ping or talk to me 03:20, 3 April 2019 (UTC)
      @Jeff G.: It was a change introduced, I think last year, because of performance issues. If you look in preferences under both Recent changes tab the "Number of edits to show in recent changes, page histories, and in logs, by default:" & Watchlist tab the "Maximum number of changes to show in watchlist:" indicate that the Maximum allowed is 1000. Keith D (talk) 16:18, 3 April 2019 (UTC)
    Thanks for the request, it's a good idea. The team will make a Phabricator ticket and work out the details. I'll post the link when it's made. Keegan (WMF) (talk) 19:18, 2 April 2019 (UTC)

    The addition of captions however is tricky... I saw someone (mass?) adding the category name as caption, resulting into abominations. Is anyone monitoring such activities? Nemo 16:31, 5 April 2019 (UTC)

    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:97.126.23.84. 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)

    File names versus descriptionsEdit

    Wiki has long insisted that filenames be descriptive, mostly for the convenience of wiki editors but against military and private sector guidelines regarding filenames for images. Also against file-naming for the purpose of traceability of originator, licensing and attribution.

    An image filename usually starts with the filename assigned by the camera, sometimes augmented or changed by the originator, then augmented again, like when uploaded from flickr to Commons. The final and uniquely identifying filename as uploaded to wiki should NOT be altered by wiki or anybody else.

    An image file should also show a separate and additional line for a description, preferably provided by the originator but alterable if required. This feature is already sorely missed and will become of even greater importance, together with a reliable filename, for Structured Data

    The image pixel size presently displayed under the image need not be in such a prominent position, if displayed at all. Image pixel size is of less informative value since it does not disclose the degree of jpg compression also influential in regards to image file size and image quality.

    As a side note: Wiki's syntax for a Slideshow, a child of Gallery, produces an image of less quality than when displayed in a gallery. This needs to be corrected, or selectable, even if it slows down the loading of images when displayed in a full quality slideshow.

    Respectfully, Bengt Nyman (talk) 13:43, 5 April 2019 (UTC)

    Hi, I disagree about everything of what you said... Regards, Yann (talk) 15:30, 5 April 2019 (UTC)
    I dot understand what you want to say. The captions we have now are captions, in many cases they will be the same like the filename except of some numeration or IDs in other cases the Caption will be the same like the description, because the filename is very short. In the future the filenames could maybe get replaced by never changing IDs, but I think all filenames will be stored anyway an there should be redirects too. --GPSLeo (talk) 16:18, 5 April 2019 (UTC)
    Image filenames should not be used as captions. Images should have a filename and a caption. Two separate lines of information. Bengt Nyman (talk) 19:35, 5 April 2019 (UTC)
    One example File:Close up of Utricularia vulgaris flowers in the Teufelsbruch swamp 04.jpg what would you put in the caption that is not in the file name? --GPSLeo (talk) 20:16, 5 April 2019 (UTC)

    "Requested depicts" (or "Most requested Wikidata items")Edit

    Maybe there should be a feature where Wikimedia Commons users could add depicts which do not link to currently existing Wikidata items, this is a similar to how for example on the Dutch-language Wikipedia there is a list of how often the same red link is used and these non-existing pages are then categorised as "requested Wikipedia articles" and the more often a red link is used the higher it goes on the list. I suggest that we should do the same for depicts where Wikimedia Commons users could add depicts for non-existing Wikidata pages which are then listed (either here or on Wikidata) and could then be created. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:04, 5 April 2019 (UTC)

    @Donald Trung: If you want to add a “depicts” statement and the item doesn’t exist yet, just create the item. Wikidata items aren’t like Wikipedia articles that have to meet a certain encyclopedic standard to not be deleted – if all you have is a name and a rough date when the person lived (i. e. floruit (P1317)), that’s fine for a start. (Later, you can still query for frequently depicted items that are missing certain statements, or have the lowest statement count, or other criteria.) —Galaktos (talk) 21:22, 17 April 2019 (UTC)
    Raises an important issue, though. At the moment there are bots that check, when items are nominated to Wikidata's "items for deletion" page, to see whether they are referred to from statements on any other Wikidata item. Similar functionality will be needed, to check and advise whether the items are the object of any depicts statements on Commons, once an API is in place to be able to check this. Jheald (talk) 22:46, 17 April 2019 (UTC)
    "Wikidata items aren’t like Wikipedia articles that have to meet a certain encyclopedic standard to not be deleted" Er, yes they are, but the barrier for entry is set much lower. See d:Wikidata:Notability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 18 April 2019 (UTC)
    @Pigsonthewing: I didn’t say that Wikidata has no notability criteria. But on Wikipedia even articles for notable subjects may be deleted (or incubated) if the articles themselves lack quality. On Wikidata, in my experience this generally doesn’t happen: even rudimentary stub items are better than nothing. --Galaktos (talk) 17:37, 18 April 2019 (UTC)
    d:Wikidata:Requests for deletions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:44, 18 April 2019 (UTC)
    @Pigsonthewing: If you’re trying to tell me anything with that link, I’m afraid you’ll have to use a few more words than that – I’m no idea what that reply is supposed to mean. (Also, kindly ping me if it’s not too much trouble.) —Galaktos (talk) 11:00, 19 April 2019 (UTC)
    I thing we do not have things as the depict of an image, that is in scope on Commons, but not notable for a Wikidata item. --GPSLeo (talk) 13:14, 19 April 2019 (UTC)
    Regarding SDC there is concern about two things in Wikidata:
    1. Some Wikidata editors have the impression that there is a problem with way too much (self-)promotional content at Commons. I do not know about Commons project details and processes, but reasons may be a deliberately low notability threshold, or Commons' inability to timely remove such content. (There is a similar problem at Wikidata, but due to the fact that the project is already Structured Data only, it is somewhat easier to dealt with it.)
      The concern now is that someone uploads an image to Commons, for example by themselves, and that automatically warrants a Wikidata item as well. There is quite some pressure from communities such as Search Engine Optimizers who deliberately want an item about themselves or their businesses, purely based on self-provided information. This way, Wikidata would quickly be in a position that "everything is considered notable" via the backdoor called Wikimedia Commons, which neither the technical infrastructure nor the community could handle properly.
    2. Commons core content are media files, many of them are user generated content. That is fine, but it sets Commons conceptually somewhat apart from most of the other Wikimedia projects. The problem now is that much of the information which should in future go to the structure data (and in particular to Wikidata itself) is kind of auxiliary content—such as file categorization—and as such usually completely unsourced.
      Wikidata's notability criteria are designed in a way that for each item it should be relatively easy to find external sources that describe reasonable parts of the content within an item. Wikidata is far away from having individual references on each and every statement, but in fact for the vast majority of items there are either sitelinks with proper sources connected, or external identifiers/references in the item in place which point to external sources. However, the key aspect about Wikidata's notability criteria is that entity notability is generated outside of the Wikimedia universe, by a description of the entity in a "serious source" (i.e. not under control of the entity, and typically also not user generated content websites).
    I think in general there is a lot of support for SDC within the Wikidata community, but I would be surprised if there won't be some disputes regarding the mentioned issues in the future. (Disclaimer: I am Wikidata admin) —MisterSynergy (talk) 18:12, 19 April 2019 (UTC)
    Hi, I have mentioned several times at the very beginning of SDC that the notability within Wikidata will be a major issue. Nobody seemed to care until now. But here we are... I think it should be possible to define with objective criteria what subjects are in scope, and therefore warrant a Wikidata for SDC, and what are not, and this only based on current Commons policies. Commons:Notability already exists, and is a redirect to COM:SCOPE. It should probably be deleveloped with more detailed examples. Or may be we can do that on Commons:Depicts? Regards, Yann (talk) 18:33, 19 April 2019 (UTC)
    Well, I am sure that things will settle in a way both projects can live with; as usual, there may be some friction we experience on the way :-) It would be great, however, if existing Commons content such as person data from categories would not simply be (automatically) dumped in Wikidata, particularly in cases where no items exist yet.
    Commons:Depicts is specifically for the depicts statements, but that is only a part of SDC. Although the notability question is related to it (how to use "depicts" if there is no Wikidata item for what is depicted), I think this talk page is probably the best place to discuss the problem. —MisterSynergy (talk) 19:19, 19 April 2019 (UTC)
    With the first version of a "guideline" I started a topic about this here: Commons talk:Depicts#Missing Wikidata items --GPSLeo (talk) 23:12, 19 April 2019 (UTC)

    Depicts statements coming this weekEdit

    The Structured Data on Commons team plans to release support for depicts statements this week, on Thursday, 18 April. The community's testing over the past several weeks helped identify and fix issues before launch, and the development team spent time setting up extensive internal testing to make sure the release goes as well as possible.

    This release is very simple, with only the most basic depicts statements available. There is a significant amount of technological change happening with this project, and this release contains a lot of background change that the team needs to make sure works fine live on Commons before adding further support. More parts to depicts statements, and other statements, will be released within the next few weeks.

    A page for depicts has been set up at Commons:Depicts. As I can't actually write instructive Commons policy or guidelines, I encourage those who have tried out simple depicts tagging add a few lines to the page suggesting proper use of the tool. I also encourage the use to be conservative at first, as we wait for more advanced features within the coming month or two as additional statement support goes live.

    I'll keep the community updated as the plans progress throughout the week, the team will know better within the next day or two if things are definitely okay to proceed with release. Keegan (WMF) (talk) 21:34, 15 April 2019 (UTC)

    Thanks Keegan (WMF). I've had a go at getting the ball rolling on a guide. But I'm afraid I've already hit a contradiction between your encouragement to "be conservative at first", and the discussion at Commons_talk:Structured_data/Get_involved/Feedback_requests/Good_coverage where the proposal suggests very liberal use of generic tags, but the commenters (and I) prefer a more conservative approach similar to steering clear of overcategorization. Should we just stick to the most specific tags for now? --99of9 (talk) 06:40, 16 April 2019 (UTC)
    At this point I would definitely advise people to be specific when using basic depicts. What neither the development team nor community want to happen in the first few weeks is have people populating depicts with statements that can easily wait and go into depicts qualifiers, depicts of depicts, or other statement structures that would make more sense. It's increased workload for sure to go back and restructure things if people have been overly liberal at first, when patience for deeper statement support will be worth it. Keegan (WMF) (talk) 15:31, 16 April 2019 (UTC)
    Ok good, I've clarified the guideline. I'm less optimistic that other statement structures will solve the basic issue of people or bots wanting to tag an image with every single item it depicts a subclass*/instance of. It seems to me that the search should do the drilling down like that. --99of9 (talk) 00:53, 17 April 2019 (UTC)
    @99of9: Ultimately, I think the way round this (as discussed a bit in the 'Good coverage' chat) could be to show inferred search targets as "shadow tags", so that (i) people will be able to see more clearly why a search may or may not have returned a particular page; and (ii) people will be less encouraged to add such redundant tags manually, if they are already visible (albeit greyed-out, or presented differently, or behind a (+) expand button). But this will take additional work, and I think the dev team's priority is quite correct if it is trying just to get something up on the wall as soon as possible, that we can look at and think about. Jheald (talk) 09:15, 17 April 2019 (UTC)
    One question: Will the possibility to add depicts in the upload wizard also get released this week or later? --GPSLeo (talk) 10:12, 17 April 2019 (UTC)
    @GPSLeo: Depicts in UploadWizard will not be released this week, but will be next. Keegan (WMF) (talk) 16:06, 17 April 2019 (UTC)

    Depicts coming tomorrow, 18 AprilEdit

    The development team is going ahead with deployment tomorrow, 18 April, between 15:00 and 16:00 UTC. Some community members are working on developing early guidance on using the feature at Commons:Depicts, and I've added some initial information about searching depicts items when they're live. Keegan (WMF) (talk) 19:29, 17 April 2019 (UTC)

    @Keegan (WMF): In case of any deployment issues, is the WMF working on Friday 19 April? I ask as it's a vacation day in many countries. Thanks. Mike Peel (talk) 19:57, 17 April 2019 (UTC)
    @Mike Peel: that's a great question. Yes, the team is working on Friday, 19 April and will be able to respond to any immediate post-deployment issues, should something happen. Keegan (WMF) (talk) 20:18, 17 April 2019 (UTC)

    The deployment is delayed for a few hours, due to a bug completely unrelated to SDC (T221368, in case you're curious). We'll resume the release when the bug gets resolved. Keegan (WMF) (talk) 15:19, 18 April 2019 (UTC)

    Depicts rescheduled for Tuesday, 23 AprilEdit

    Unfortunately the bug blocking the release was not resolved in time to release depicts today. Releases are not done on Fridays, so the team has rescheduled for Tuesday, 23 April from 15:00-16:00 UTC. I'll continue to keep the community posted as release approaches. Keegan (WMF) (talk) 20:44, 18 April 2019 (UTC)

    Why?Edit

    This Structured Data "feature" is a failure on the order of Flow. Why is this the case? Let us count the ways:

    • Wikimedia did not hold a large-scale consultation like w:en:WP:TPC19, which would have enabled them to get the community's view on it as well as make it less redundant. Which brings us to...
    • It adds needless complication to Commons. All it does is duplicate the file description box, with the main difference being that people actually use the wikitext description template.
    • Making data machine readable would be nice, but is not a priority for readers or even experienced editors like me.
    • Wikitext support is even worse than in Flow; that is to say, there is none.
    • Very poor handling of page protection, one of MediaWiki's most important features.
    • Has an "I accept the terms and conditions" dialog box. Really, there was no way to display that message in a less intrusive and more Wikipedia-like way?
    • IT REQUIRES JAVASCRIPT.

    For these reasons, I have set my adblock to block this disaster from Commons file pages, so I never have to see this abomination ever again. I urge Wikimedia to reconsider the vast amounts of donation money they are putting into a feature that not many people actually like. — pythoncoder (talk | contribs) 16:37, 17 April 2019 (UTC)

    User:pythoncoder, Structured data is a work in progress which came after long period of discussions. I am not sure if you are familiar with Wikidata, but we hope to be able to to store metadata related to all images in similar format, in addition and possibly instead of current wikitext based metadata storage. Being able to query the data, the way we can query Wikidata is very important for maintenance and re-usability of Commons content. I agree that we will have some duplication of metadata since it is being stored in 2 parallel formats, but it is a necessary side-effect. --Jarekt (talk) 18:17, 17 April 2019 (UTC)
    I’m just thinking that 1) you should be able to contribute even if JavaScript is disabled, to provide maximum accessibility, and 2) there should be more work done to reduce duplication (e.g. auto-import description fields to the new system). — pythoncoder (talk | contribs) 19:18, 17 April 2019 (UTC)
    You can contribute to Wikidata with a command line tool, this could be adapted for Commons. --GPSLeo (talk) 20:26, 17 April 2019 (UTC)
    Return to the project page "Structured data".