Commons talk:Structured data/Get involved/Feedback requests/Depicts testing

There appear to be no statements about copyright. By default CC-BY-SA applies to Wikimedia Commons user contributions. --Fæ (talk) 16:55, 26 March 2019 (UTC)Reply

Depicts seem like categories that directly link to Wikidata so CC-0 seems an acceptable license for depicts since it functions like categorization that plays well with Wikidata. Abzeronow (talk) 17:14, 26 March 2019 (UTC)Reply

All contributions on Commons are CC-BY-SA by default. Anything else needs a warning and probably more extensive system interface changes to avoid misleading contributors on copyright. --Fæ (talk) 17:21, 26 March 2019 (UTC)Reply

There is a CC0 notice the first time structured data is used. Every single page also has Files are available under licenses specified on their description page. All structured data from the file and property namespaces is available under the Creative Commons CC0 License; all unstructured text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this site, you agree to the Terms of Use and the Privacy Policy. The footers were updated over a month ago. Keegan (WMF) (talk) 18:23, 26 March 2019 (UTC)Reply

Oddly, I had never seen that fundamental change to Wikimedia Commons. Where was the proposal and community consensus? --Fæ (talk) 17:01, 27 March 2019 (UTC)Reply

I posted a notice on Village Pump/Copyright and opened up a discussion on the SDC talk page. VP/C suggests using the talk page of the message for the proposed change, but as a system message no such page exists locally. Thus, the SDC talk page with VP/C notice. Keegan (WMF) (talk) 19:09, 27 March 2019 (UTC)Reply

No proposal.

No consensus.

Shocking. --Fæ (talk) 07:41, 28 March 2019 (UTC)Reply

Fæ, this posture that you are adopting here in this discussion is not helpful, remember that WMF staff or not, they are people, that have feelings.

And CC-by-sa do not make any sense to depicts, depicts are information that do not demand creativity, they are pure data that's not admissible copyright. This is the base of Wikidata.

The first warning is more than enough to the volunteer. Thank you for the attention.

-- Rodrigo Tetsuo Argenton ^m 05:20, 30 March 2019 (UTC)Reply

Looks good to me. Orphée (talk) 21:14, 26 March 2019 (UTC)Reply

Till the depicts get release we should create a good page that describes the usage of depicts and all that is important to know.(Commons:Depicts) In best case that should be translated to the most common languages. --GPSLeo (talk) 13:42, 27 March 2019 (UTC)Reply

Personally, I think a simple start will go a long way. A helpful example with a popular file would probably be good to keep people on track. For example, the 2018 Picture of the Year File:Evolution_of_a_Tornado.jpg depicts (P180) tornado (Q8081). There are deeper ways to structure this, sure, and they are coming in the next few weeks, but for now understanding the basics will go a long way. Keegan (WMF) (talk) 16:50, 27 March 2019 (UTC)Reply

That is the question, dose the photo only depict tornado (Q8081) or dose it also depict a timeline (Q186117) you could also say what is depicted is photomontage (Q828107). I think people will ask this, like me, so we should have a answer for this even if the answer is "other statements to structure these information will be released in the next weeks please wait". --GPSLeo (talk) 23:55, 27 March 2019 (UTC)Reply

Sure, and "coming soon" would be what I'd recommend. Keegan (WMF) (talk) 19:15, 28 March 2019 (UTC)Reply

I find surprising that when you click on "Structured data", you no longer see "Summary", "Licensing", etc. It makes sense, but the current design suggests that the "File information" tab stops above the "Summary" section. There should be a border that delimits the content of the tab.

Otherwise, it is promising. Ayack (talk) 16:59, 27 March 2019 (UTC)

Agreed. When not everything is ported to Structured Data for now, I prefer the old-fashioned file descriptions being displayed regardless which tab I have clicked.--Roy17 (talk) 19:43, 27 March 2019 (UTC)Reply

I played around with the new depicts feature.

• The workflow is solid. It's intuitive and it makes sense
• The appearance of the chrome itself is great. We have a lot of trouble striking this balance in our world. We have the Monobook/Vector oldschool minimalist aesthetic, and with OOUI we have something a bit more modern but a little heavy on the chrome sometimes (especially in contrast to the relatively ascetic Vector skin). But in this case it looks the chrome of OOUI was dialed back a bit and we are left with its core essence. Good work!
• Being able to nest/qualify statements would be nice but I understand that will take more work.
• Wikidata is kind of messy sometimes. For example, you have the generic concept of "grass" but also different species of grass. People are probably going to conflate related concepts a lot and we should anticipate this.
• What are your thoughts on people using "depicts" when it would be more technically correct to say "instance of"? We model editions of works on Wikidata, and may upload the original to Commons from time to time. And as a workaround people will probably say "this file depicts this given work" even though the file doesn't depict it, it is it. This is a problem from a data modeling point of view but probably not from a day-to-day use point of view.
• If you can figure out a way to add complication to this UI it could become the new default for Wikidata maybe?

Harej (talk) 17:01, 27 March 2019 (UTC)Reply

I've tried out the structured data interface / depicts property on Test-commons. I'll try to summarise my experience.

• My first problem was finding a fresh file to try out the testing on. Most of the "Random file" links there were to description pages that had no file uploaded to match. It's hard to say what something depicts when you can't see it. The ones where an image was showing already had been used for testing, and I wanted to try to create a fresh entry.
• So I next tried to upload a few files of my own. Unfortunately the "Upload file" link took me to a non-existent page for the upload wizard. I'm pleased that Juandev has now added a link to Special:Upload on that page.
• Once I decided to simply go to Special:Upload manually, I was able to upload a few of my own files that I had uploaded to Commons in the past (so no arguments about licensing).
• When I eventually was able to edit File:Adaptor (yoke to DIN).jpg, I found it fairly straightforward to create values for depicts (P180).
• I found it easier to search for the item on Wikidata and insert its Q-value in one case, as I needed ISO metric screw thread (Q389798), but when typing "screw", "screw thread", "metric thread", the item (or anything usable) was not found. You need your AJAX to return results from within the search targets, not just the ones beginning with the same letters.
• As I don't know how to generate the numeric coordinates for regions of an image, I didn't add those qualifiers. There needs to be some documentation if folks are going to be expected to do that.

Now, I know a lot of that looks like criticism, but I really found most of it quite intuitive, and quite familiar (although I'm used to working with Wikidata and with SDC captions). Obviously, you'll be polishing the "rough edges" before going to production. For me, the most important thing to fix is getting the search to look inside Wikidata labels, rather than only matching the start of the label. Cheers --RexxS (talk) 21:39, 27 March 2019 (UTC)Reply

I tried uploading the same image, File:Derwent Water landing stages, Keswick (geograph 6089675).jpg, to both the live and test sites, using categories (via HotCat) on the live site and depicts (P180) on the test one. I found the descriptions on Wikidata items to be an advantage: they generally helped me to be confident I'd found the correct category. On the other hand, working out whether the depicted craft was a ship (Q11446) or a boat (Q35872) was tricky even when I looked at the Wikidata pages. I cheated a bit in that case on live Commons: Category:Boats in Cumbria exists, but Category:Ships in Cumbria doesn't.

One thing I did miss from HotCat was the “↓” button, which shows subcategories of the chosen category. This allows me to start with category that I can guess the name of (like Category:Boats in Cumbria) and then see if there's a better subcategory. On Wikidata, I think the equivalent would require following reverse property links, including subclass of (P279), instance of (P31), and location (P276), which might be quite exciting to implement. The lack of intersection categories would also make finding a suitable starting point tricky, For geographical subjects like this, suggesting instances close to the camera location might work.

Overall, I'm favourably impressed.

I miss an easy way of adding relative position within image (P2677) if we should start use Depict we need to locate what part of the picture we speak about example. Next step is that we generate en:IIIF and just displays that part in Wikipedia articles etc... - Salgo60 (talk) 06:15, 28 March 2019 (UTC)Reply

  Agree. It should be nice. --Yiyi (Dimmi!) 07:23, 28 March 2019 (UTC)Reply

@Salgo60 and Yiyi: It looks like that is in the roadmap for April] -- though they look to be a bit behind in terms of deploying the features. Sadads (talk) 13:05, 28 March 2019 (UTC)Reply

Yes, we will have support for relative position within image (P2677) (including via an update of the image annotations functionality so you can just draw a box). Yes, we are a little bit behind schedule on that :) RIsler (WMF) (talk) 14:16, 28 March 2019 (UTC)Reply

RIsler (WMF), we will have to manually redo the already existent files with notes, as File:Vista panorâmica do centro de São Paulo.jpg?

Or we may have a way to do that with a tool? -- Rodrigo Tetsuo Argenton ^m 05:28, 30 March 2019 (UTC)Reply

The workflow is easy. I think it's a good idea you decided to change "make primary" to "mark as prominent" because I initially thought I could only mark one item as primary.

This might be more of a wikidata problem, but I would like better search options for the items. For instance, my image depicted a fence so I chose fence (Q148571) but I would have liked to be more specific. One way to achieve this would be to see all the subclasses of that item (I guess a Sparql query would be able to show them).

One thing I really liked is that items are displayed and searchable in my native language. However, it took me some time to find out that changing the language achieves this and seems to only work when logged in. --Sohmen (talk) 09:55, 28 March 2019 (UTC)Reply

Thought of one more thing: It would be nice to see an image of items in the suggestions below the search bar while searching so that I can already see if that item might be what I'm looking for. --Sohmen (talk) 10:10, 28 March 2019 (UTC)Reply

Congrats, the prototype looks very good! I have just have a mixed felling about the internal usage of ranks to mark elements are "as prominent". For statements on Wikidata items, the "preferred" rank is used for most current statement or statements that best represent consensus. Here, all values of "depicts" are as "consensual" as the others, there is just an importance relation. Using it is a bit misleading for users of MediaInfo JSON format (data reusers and bot makers). Using a qualifier for encoding preeminence is maybe a better way to go, even if it looks a bit over engineered. Tpt (talk) 10:16, 28 March 2019 (UTC)Reply

Hey. Thanks for the hard work on SDC. I think we should add a link to creating a new Wikidata item in this tab. So far, if I input a non-existing item it will just render: "No results found." But I could be adding meaningful information, and it'd make sense to direct me to a place where I could straightforwardly create a new item which would then be added to the list of items portrayed in the image. Does this make sense? --Joalpe (talk) 11:57, 28 March 2019 (UTC)Reply

Interesting idea. Thanks for sharing it! Keegan (WMF) (talk) 18:04, 29 March 2019 (UTC)Reply

I was writing the same idea, but as you already did, I'll just give my support, this also could increase the inclusion of new items at Wikidata.

-- Rodrigo Tetsuo Argenton ^m 04:27, 30 March 2019 (UTC)Reply

In the interface for the "Search to add items" interface for the depicts, Mona Lisa is used as an example: though, in principle I agree with having a highly specific example there, doesn't the "Mona Lisa" example confuddle the faithful reproduction of 2d cultural work problem with depicts? (shouldn't that be done with a secondary property). Could we do something more iconic but clearly belonging in photography "depicts" like "Taj Mahal" or "Great Pyramid of Giza". Sadads (talk) 13:14, 28 March 2019 (UTC)Reply

Fair point. The original idea predated creation of the "digital representation of" property. We can update it easily enough. RIsler (WMF) (talk) 14:13, 28 March 2019 (UTC)Reply

Yes, that is weird, and could have a more wide examples, "house cat" and "mountain" are very similar examples, I would prefer something like "anatomical model", "mountain"... it's hard to explain. -- Rodrigo Tetsuo Argenton ^m 04:36, 30 March 2019 (UTC)Reply

How will vandalism be detected or even searched for?

The reality is that vandals are already misusing "captions" to add "bollocks" to photographs of politicians, yet we can neither search for it, nor is it even visible in the normal wikitext. --Fæ (talk) 13:26, 28 March 2019 (UTC)Reply

I think just the same way like Wikidata is Dealing with vandalism --GPSLeo (talk) 17:13, 28 March 2019 (UTC)Reply

Good joke, thanks. With no ability to see vandalism in the first place, there is no "dealing with vandalism". --Fæ (talk) 18:21, 28 March 2019 (UTC)Reply

Search works for captions and statements right out of the box now. Put a word into Commons search, it will crawl everything. Keegan (WMF) (talk) 17:34, 29 March 2019 (UTC)Reply

I know this is still being developed, but it'd be nice to be able to include the set of possible qualifiers, already used on Wikidata, like relative position within image, shown with features, color, applies to part, and so on. This would be amazing! --Joalpe (talk) 19:47, 28 March 2019 (UTC)Reply

Absolutely, qualifier support will be up for testing only a matter of weeks after depicts support is released. Keegan (WMF) (talk) 22:20, 28 March 2019 (UTC)Reply

Actually not many comments for now, I tried to use it on a file I uploaded here on commons but I could not seem to get it to work (no tab to select) so I uploaded another test version of it on the test site and then it seemed to work just fine.

It does seem possible to enter the same item multiple times (see my tests at https://test-commons.wikimedia.org/wiki/File:Grote_Wade_test.jpg for that) where I have added the item "street Q7900" a couple of times, which might not be intended. would recommend to only be able to have every item (Q) once unless I am missing a reason why that should be possible/actually needed.

Short thoughts; Interesting concept, very simple to use. Redalert2fan (talk) 19:04, 29 March 2019 (UTC)Reply

Once we have qualifiers, adding an item multiple times will be useful - for example, if a painting depicts a red dress and a blue dress (which is different from a red-and-blue dress). - PKM (talk) 20:12, 29 March 2019 (UTC)Reply

1. First thing that I notice is the separation between the data and the file information, this is not a good idea! You are creating a new click for the viewer. This shouldn't be separated.

Would be better to follow the current structured examples that we have:

File:Independence of Brazil 1888.jpg

2. Another issue that I notice, we don't have any warning if we include the same item more than one time.

3. The colour... why this is grey??? Jesus! Why not white, or some not boring and ugly colour? The design here reminds me 1990's webpages. Seems not important, but it's! Seems old, derail the importance of the website for some people. White, pleas, move to white.

4. There's no warning to you save your edits, and you can simply loose everything, for not save the edits and close the page.

5. Would be nice if the Wikidata item reveals a Category at Commons, it appears as a blue link in the depicts, now it's only a bold text that do not create any via to explore Commons.

6. Would be positive include references, as Wikidata have, because some images could be controversial, and include a reference could diminish some possibles issues.

7.a. How automatic importation will work? Thanks to some amazing work that some Brazilians did, some paintings and photos already have a very very good depicts descriptions as d:Q10301958 at Wikidata, how we can import this?

7.b. And how future images of this painting will automaticity have this descriptions? Because now, I can simply click on "edit" and copy all the info from one painting and mirror the info, or maybe volunteers want simply click and bring all this info already made... I do not want to do several times the same work over and over again, include one by one, if there is a file already well done...

8. How this will work on the search? If I look for "trees" today the search will indicate the category, and files with the name tree, and description, how this will work when it will be online? Because I couldn't find the upload that I did using the depicts that I included.

For now, that's it. -- Rodrigo Tetsuo Argenton ^m 04:23, 30 March 2019 (UTC)Reply

PS: 9. Would be important to have a "instance of " this is a photograph, a video, a painting (digitalised), a presentation,..., this would be important, and could improve our search.

I think this is great, first of all!

I had a slight problem when I first tested, but it disappeared. When I navigated away from the page in the middle of working, the statements had disappeared. I was not able to reproduce this.

In general, the generous use of screen estate worries me when more options become available. On the positive side, it forces the design to be understandable and simple.

I will be interested to read and write the statements via the API and search them. This will require a lot of the existing information to be migrated to the new properties until they become useful.

Cheers, Susanna Ånäs (Susannaanas) (talk) 11:22, 30 March 2019 (UTC)Reply

Hi, works for me. I am curious where this is going. Ziko (talk) 12:53, 30 March 2019 (UTC)Reply

Will be glad to have implemented! ɱ (talk) 19:25, 31 March 2019 (UTC)Reply

Overall it is good. I have few points:

• "remove statement" should be replaced with "remove all statements" which makes more sense.
• "Learn more" should be next to depicts.
• QID should be next to item label like "rock (Q8063)" like we have in wikidata because people unfamiliar with QID would wonder what is it if kept to much away from the label.
• Why should we need "Edit" and "Publish Changes" buttons? Anybody clicking on Structured Data tab should be able to add items directly without clicking edit button. Clicking searchbox (Search to add items) means I am about to add a statement and when I select a statement from droplist in searchbox, I am about to publish it. So instead of those buttons, we should make those actions automated. It will save time and energy of editors. Sometimes editor may miss to click "publish changes" button and his edits will not save. We can avoid that as well.

Everything else seem great. Thank you for all the hardwork. Regards,-Nizil Shah (talk) 05:23, 2 April 2019 (UTC)Reply

1. Okay, let's test!
2. First moments I searched the search field and thought I can add some other structured data (apart from depicts, e.g. alt text or main color) through the search field. When I was not successful, I tried to click on "edit" button next to depicts, but was not successful either.
   • Also I thought the changes are saved immediately, I haven't noticed publish button for some time. I was confused nothing is saved in the page history. As an afterthought I found out I have to click the publish button to make my changes save.
   • Finally I was confused what Remove statement button is for. It seems this is just a wording issue, it should be Remove all statements or something similar. First I thought it makes checkboxes to remove selected ones.
3. Mark as prominent: this easy-to-understand and easy-to-use switch should be added to Wikidata as well!
4. Add some possibility to add other structured data like alt text, main color, etc. would be awesome. First I thought this works like that, but then I was disappointed there isn't any other data apart from depicts.
5. As I mentioned earlier, what Remove statement button does and how should I publish changes.
6. As I mentioned earlier, other structured data apart from depicts.
7. Not sure about this, no.

--Dvorapa (talk) 09:36, 3 April 2019 (UTC)Reply

4. Now you can click "add qualifier" to precise depicted item. 5. "Depicts" is a statement. So it will remove all content in this statement. See Wikidata terminology. To publish click button on top right corner of table. 6. yes, they are planned. --Wargo (talk) 18:55, 23 April 2019 (UTC)Reply

Did one short, very non-extensive test on test-commons, did not encounter a bug. Hope that helps, Jean-Fred (talk) 10:50, 16 April 2019 (UTC)Reply

In the box titled "Search to add items", when typing in a label, there's no option to show more possible items in the suggestions box. If the item isn't in the top 7 hits for that label, there's no way to access it. --Yair rand (talk) 02:43, 17 April 2019 (UTC)Reply