Commons talk:Depicts/Archives/2019

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Initial guidelines

Following Keegan (WMF)'s post I've chipped in some ideas for a guideline here. Feel free to edit, remove or talk about anything you disagree with. --99of9 (talk) 05:59, 16 April 2019 (UTC)

Good coverage

Oops, I've already had to backflip on what I first wrote, after reading Commons:Structured data/Get involved/Feedback requests/Good coverage. Let's continue the debate at the talk page there. Should we remove decisive advice on this guideline for now? --99of9 (talk) 06:19, 16 April 2019 (UTC)

I think we are going to strive for good coverage, and within a few months when statements are feature complete then that's the way to go. My suggestion to keep advice to be conservative at first is only temporary. Ideally, people will keep things simple right now and then bring up statement complexity with more support within a few weeks. I wholly expect this policy/guideline to evolve significantly. Keegan (WMF) (talk) 18:50, 16 April 2019 (UTC)

Add no location policy

I think it would be good so add a "no location policy". For adding locations the other statements released later will be better to describe this. So we should say that photographs of objects should not get the location as a depicts statement. Three examples to explain this:
1. A picture of a street. Depicts the street. (Street is liked to location -> not location need anymore)
2. A picture of a plant. Should only get the taxon item as depicts statement. The location can be added when other statements get released and not with the depicts statements.
3. A aerial image. This image can depict a location. --GPSLeo (talk) 10:21, 17 April 2019 (UTC)

Activities, context, background, details, ...

The image shown on the right clearly needs a "depicts (P180): Usain Bolt (Q1189)" statement. But what else:

Clearly, not all detail belongs to the "depicts" statements, but which one do? Do we already have an idea which other properties will be available later, in order to cover at least some aspects of the details outlined above? --MisterSynergy (talk) 07:43, 18 April 2019 (UTC)

I would only add Usain Bolt (Q1189) and athletics at the 2008 Summer Olympics – men's 100 metres (Q754844) here. That are the main topics depicted by the image, all other should be added later with other statements like "clothing", "in the background", "reason for activity" or other ones. --GPSLeo (talk) 08:16, 18 April 2019 (UTC)
One that for some reason questions me: Should we add depict=blue hour (Q882565) on eg File:Iglesia de San Francisco, Quito, Ecuador, 2015-07-22, DD 217-219 HDR.JPG? Jean-Fred (talk) 15:17, 18 April 2019 (UTC)
I would also say no. For time and weather we should wait for the other statements. --GPSLeo (talk) 16:22, 18 April 2019 (UTC)
All that interesting statements will be added soon or later. If they are added now, they can be migrated to new properties when they are available. I wouldn't overthink this. emijrp (talk) 08:45, 19 April 2019 (UTC)
In general I agree ; however I think that the lack of documentation & guidelines ahead of the File captions rollout contributed to some of the unhappiness with said rollout (I certainly don’t think guidelines ahead would have been everyone happy, but based on people’s reaction I think it could have helped). So big props to 99of9 for fleshing out the page − even if indeed we may be revisiting parts of it with more experience with the feature or when more people get involved. Jean-Fred (talk) 17:19, 19 April 2019 (UTC)
Yes, it would be very difficult to craft a perfect guideline page even before the actual feature has arrived. In fact, the guidelines about how to use the feature are community business, not WMF or dev team business. Thus, I do not expect guidelines to be part of the shipped feature; however, as someone who has watched the SDC project from a rather remote perspective until now, I ask for community input here, because there may already be a plan how to continue with the depicts statements. If not, we now have a place for discussion :-) —MisterSynergy (talk) 17:29, 19 April 2019 (UTC)
Excellent issues. I've tried to reflect these concerns on the page. Feel free to edit. --99of9 (talk) 05:26, 20 April 2019 (UTC)
I say Don't belabor minute details. That would probably hinder rather than help people find content. If an image depicts a full shot of a car, it will also depict tires, a windshield, mirrors, headlights, and dozens of other items. Name the brand of car, but don't sweat the nitty gritty: save "depicts windshield" for a closeup photo of a car windshield, or a windshield being crafted outside of an automobile. An image of a map will also have dozens, hundreds, or thousands of inherent subtopics depending on scale. Stick to the most relevant stuff. If there's a tiny element far back in a crowd shot, it's probably not going to be useful for people looking for images of that thing (we're not just training robots to take over the the world, humans still use Commons, right?) Use commons sense. --Animalparty (talk) 03:23, 28 April 2019 (UTC)

Missing Wikidata items

After a discussion about new Wikidata items for depicts statements I would suggest to include this in these page here. For that I wrote a short king of path-guideline:(This is definitely not finished yet)
There is no Wikidata item for the depict, what to do?
1. Check is the file es in the project scope -> If it is not request it for deletion. If it is only for usage on an userpage or an project portal look for an less specific item. As one example the image of yourself for you userpage could get woman (Q467) as depict.
2. Look for other spellings of the name. If you find the correct item you maybe should ad the spelling you searched first for as an alias.
3. Search if the depict dose have any sources in a Wikimedia project or external
4. Think about the specificity. Maybe these special depict dose not have an item but the class of these depicts dose have an item. As one example: not every tree in a park has his own item, but the park and the species of the tree have.
5. Create an item for the depict of the image. Give all statements you know and have a source to these item.
This is my first suggestion please change it or make a total different suggestion. --GPSLeo (talk) 23:07, 19 April 2019 (UTC)

Missing the purpose

The purpose can move mountains, the motivation to add information about what is depicted in the image should be included in this page. I know people who still wonder about the purpose of the caption, if there is already a description field. Just an idea. I believe in this case we could enable a search in the native language of the use, whatever this may be (versus the current categories/descriptions that have to be explicitly added). Best, --Poco2 11:58, 23 April 2019 (UTC)

Prominence

Confused by marking as prominent. E.g. in File:Cornel happens to love pizza.jpg, the pizza is prominent in this photo but this is not a prominent photo of pizza. Which am I claiming with prominence? The pizza is prominent here or this piece of media is prominent in the media depicting pizza? —Justin (koavf)❤T☮C☺M☯ 15:58, 23 April 2019 (UTC)

The prominence means on these photo. Otherwise it would crash the current QI, FP and VI system. --GPSLeo (talk) 16:24, 23 April 2019 (UTC)
@GPSLeo: How would it "crash" those systems...? —Justin (koavf)❤T☮C☺M☯ 16:41, 23 April 2019 (UTC)
For getting a status a a good image that is the best or good for the topic new we have a proposal and review process. If everyone could just say "this image is prominent for this item" there would be a system that would look like to do the same but without these control. --GPSLeo (talk) 16:59, 23 April 2019 (UTC)

Bug? (Redirected items on Wikidata)

I added some items in the depicts. Before clicking the "Publish Changes", I merged one of the items with another item on Wikidata so the item which I added in depicts is now a redirected item on Wikidata. So it does not let me "Publish Changes" and mark that redirected item as not existing. Other existing items are not saved either. I can not do anything except "Cancel". It should save the existing items and redirected item should be automatically changed.-Nizil Shah (talk) 05:20, 24 April 2019 (UTC)

Two-dimensional faithful representations of two-dimensional artworks not to be covered by Depicts?

Since several weeks, Wikidata has the dedicated property digital representation of (P6243), intended for Wikimedia Commons, to indicate that a file on Commons is a faithful representation of a two-dimensional artwork on Wikidata. It has copyright-related implications (roughly: if the work is public domain, the image is public domain too). So personally I'm not adding any depicts (P180) statements on Commons to images representing two-dimensional artworks for which I know there is a Wikidata item, because I think this new property digital representation of (P6243) should be used to point to it as soon as other statements are enabled. Do others agree with this, and is it something we want to document here too?

Also, how about the things depicted in the two-dimensional work? Do we put these under Depicts? The team will work on 'Depicts of depicts' search later, but that will only 'travel' through the Depicts statement on Commons for now. The team is interested to hear the community's input on whether to extend this to other properties. I'm wondering what we want to recommend as best practice now. FYI, I work for the Structured Data on Commons team as User:SandraF (WMF) but am writing this with my volunteer hat on. I truly have no strong opinion on the matter, and just want to put this on the agenda :-) Pinging Jarekt and Multichill who gave active input in the digital representation of (P6243) property proposal discussion. Cheers! Spinster (talk) 07:03, 24 April 2019 (UTC)

Sandra, Yes the split of which matadata goes to SDoC and which goes to Wikidata is going to be an issue, but it makes sense that in case of several files showing, lets say, the same painting for which we have Wikidata item, than we will keep one set of Depict statements on Wikidata and not add them to individual files. However that will likely complicate writing code for search engines that search depict statements. It is probably not possible to prevent people from adding depict statements to individual files depicting object on Wikidata, So Wikidata depicts should be somehow inherited and displayed so there is less need to add them here. Adding digital representation of (P6243) should not be too hard as we will just have to go through Category:Artworks with Wikidata item and capture filenames and matching wikidata items. We might have to filter it so the items correspond to 2D artworks and that image is mostly of that artwork, but we should be able to populate digital representation of (P6243) quickly, once we can use tools like QuickStatements. By the way, are there plans to activate tools like QuickStatements for Structured Data on Commons? QS seems to have already interface that allows to pick a project (Wikidata, Wikidata-test or Commons) but Commons does not work yet. --Jarekt (talk) 12:35, 24 April 2019 (UTC)
Thanks Jarekt! Yes, I agree with all you say. Concerning QuickStatements - some time ago I think Magnus Manske said that it would be doable/possible to make QS work with structured data on Commons too. I also just thought about PetScan, which I also sometimes use to edit Wikidata and which would allow us to play with Commons categories in a refined way. Not sure when Magnus would be able to get around to this though. Spinster (talk) 13:30, 24 April 2019 (UTC)
QS tool seems to be able to pick projects, so I think Magnus part for QS is probably mostly done. Something I am not sure about: Is there a way to communicate with SDoC, like through SPARQL, Lua, pywikibot, etc? And if there is than is there documentation for it. If there is anybody from Structured Data on Commons team at Wikimedia Hackathon 2019, I would love to learn more or help. --Jarekt (talk) 13:43, 24 April 2019 (UTC)
Jarekt, CParle (WMF) will be at the Hackathon, you two should talk about what you want to work on there when he gets backs from holidays next week. Any other folks attending the Hackathon who have projects they want to work on, or want a SDC-related project to work on? Abittaker (WMF) (talk) 20:23, 24 April 2019 (UTC)

Search

I dont understand how to search. If I fill the keyword "haswbstatement:P180=Q146" to the search box it goes nowhere. I am not sure if I undertand the guideline well. Juandev (talk) 07:15, 24 April 2019 (UTC)

Your search term is correct, but searches aren't working yet. It's currently being worked on and should be operational soon, though. See https://phabricator.wikimedia.org/T221691 for updates. Mmullie (WMF) (talk) 08:41, 24 April 2019 (UTC)

UI observations of the Depicts feature

Now that I have been testing Depicts with actual content, I have a couple of comments/suggestions to think about.

  1. The tabbing hides the original metadata from where tags and facts are picked to be entered as structured data. Having them in the same view would be useful.
  2. It would be useful to have an option and a dialog to add a Wikidata item if it does not exist. For a similar UI I have created the search pulldown with the last item being "Create new item"
  3. Batch tagging came to mind, but is probably not high in priorities.

Great work, love the future landscape already! –Susanna Ånäs (Susannaanas) (talk) 15:09, 24 April 2019 (UTC)

Replacing categories

Do we see depicts statements replacing categories any time soon? For instance, if a file today only uses depicts statements (and not categories), is that something bad? I'm trying to decide if WLE for Sri Lanka should encourage uploaders to use depicts statements only (as it is much much easier to use to non-wiki people). Also, when will those option be added to the upload wizard? Rehman 11:48, 25 April 2019 (UTC)

Maybe categories get obsolete one day but for now I would add both. Especial for WLE there is no way to use structured Data this year. We do not have them in the UploadWizard and we do not have the located in protected area (P3018) statement activated, that would be needed to show the protected area. A photography can not depict a protected area, that is just a juristic item. --GPSLeo (talk) 12:26, 25 April 2019 (UTC)
Thanks, GPSLeo. Rehman 02:57, 26 April 2019 (UTC)
Its too early to kick categories. More over depicts is still on the beggining so I would not relay on it any official or semiofficial acitivity. There are still not qualifiers, nor search for depicts, so I would wait and maybe next year we can count with depicts. Juandev (talk) 07:23, 28 April 2019 (UTC)
Personally I would expect categories still to be in place in 5 years time (certainly); and still in ten years time (probably). The ability to curate and present a view of a particular group of images in an ordered way together with an overall free-wikitext description of what the group represents, with good established tools like cat-a-lot allowing those groups to be added to or refined or subdivided easily at will, is something that I don't believe the community is going to give up.
A while back I suggested that upload projects may be blocked if they fail to give good categorisations for their images. That was too strong, and I was corrected over it at COM:VP. Nevertheless, I do think that a project that didn't even try to make an honest attempt at categorisation for creator, source, and subject would be frowned upon (now and in future). Jheald (talk) 09:15, 28 April 2019 (UTC)
Agree with the above posters ; that said, as the WLE for Sri-Lanka organisers, I would say it’s fine if you prefer to encourage uploaders to only use depicts, and then as organisers you add categories based on it (ideally automatically or semi-automatically). That may well be an awful idea if it ends up taking lots of time to few volunteers (especially as such automation still has to be figured out) ; but hey, that’s up to you, if you think it makes sense for your context :) Jean-Fred (talk) 18:12, 29 April 2019 (UTC)
Thank you, Jean-Fred. That could be something to consider :) Rehman 02:06, 30 April 2019 (UTC)

Wikidata Items

file

How to handle the pictures from items like An der Läuterau 2 (Q49346079). Is it possible to get the statements from Wikidata in structured Commons? I would give statements in Wikidata and the only statement in Commons would be the Item itself. Ist that ok? I want to prevent doubled work... In Wikidata we have for example Upper Lusatian house (Q1362233), inception (P571) or heritage designation (P1435). Thank you, Regards, Conny (talk) 13:30, 28 April 2019 (UTC).

If the object depicted has an item on Wikidata, then add such information there. It should be able to help image discovery here eventually; might eventually get summarised in the User Interface here; and should also be accessible from queries, once Commons gets its own SPARQL query service; but currently there is a lot of other stuff the dev team need to be working on first, before any of this. (Though IMO they should be moving ahead on SPARQL, because that will be being done by a different team).
If the object that is depicted does not have an item on Wikidata, then that opens up a more difficult set of questions. As a first option, consider creating an item on Wikidata, especially if there are reliable sources you can reference, that can verify statements you would make about it. In some cases, however, the underlying object might not pass the notability criteria at Wikidata. (This is still a bit of a grey area at the moment). In such a case it's not entirely clear what will be the best strategy. Jheald (talk) 14:07, 28 April 2019 (UTC)
Thank you very much, that sounds great for me. Have a nive day, Conny (talk) 04:52, 29 April 2019 (UTC).
Well, personally I understand structured data on Commons as a partial replacement of categories. So if someone will be looking for images of yellow houses and you would have under this image just An der Läuterau 2 (Q49346079), they wont find this image. So I would leave under the image also other items, even the guidelines say now. Juandev (talk) 08:36, 29 April 2019 (UTC)

Adding "depicts" info with a bot

I am using AutoWikiBrowser and wonder how to use it to add "depicts" info. Since the depicts-info is not in the wiki code I'm not sure how it's done. -abbedabbtalk 20:09, 28 April 2019 (UTC)

At first, just add depicts statements manually. When we are ready for them, bots should seek bot approval for this specific task. --99of9 (talk) 06:45, 29 April 2019 (UTC)
I think AutoWikiBrowser dose not work with Wikibase. --GPSLeo (talk) 07:23, 29 April 2019 (UTC)
Indeed not: phab:T138754. Jean-Fred (talk) 18:05, 29 April 2019 (UTC)
I just changed the Bots section. -abbedabbtalk 04:47, 6 May 2019 (UTC)

Wikidata label text search?

@Keegan (WMF): I understand that haswbstatement does an exact search on the statement ; but would a depict statement also enable normal text search?

Ie, if I have a picture of Barack Obama, and there is no mention of Obama in neither the filename, the wikitext or the captions, but there is a depicts statement P180=Barack Obama (Q76), then would Special:Search/Obama return that file?

And same question with multingual labels, if I have P180=pumpkin pie (Q2118270), will it show up for Special:Search/tarte à la citrouille? Tested this quickly with there, looks like not :-(

Jean-Fred (talk) 10:36, 29 April 2019 (UTC)

There is advanced search for structured data in the works that will help find these things, I'll keep you posted as it's developed for testing. Keegan (WMF) (talk) 19:26, 30 April 2019 (UTC)

"Cat-a-lot" for depicts?

Is there a tool like "Cat-a-lot" to add the same statement to several files at once? For example, on Category:L’Union - Eglise Saint-Jean Baptiste, most of the files depicts d:Q38631748. As with "Cat-a-lot", I'd like to select these files and add P180: Q38631748. Is it or will it be possible to do that? Thanks. Ayack (talk) 10:58, 6 May 2019 (UTC)

There is no such tool at the moment. I added a “Tool support” section to document that.
Jean-Fred (talk) 12:20, 6 May 2019 (UTC)
That might be a good proposal for hackaton, if it is possible to propose them what to code. Juandev (talk) 12:37, 8 June 2019 (UTC)

Usage statistics?

Since depicts is alive for almost one month, do we have some stats about its usage? How many statements, on how many files, by how many users? Thanks. Ayack (talk) 12:41, 20 May 2019 (UTC)

More instances for basic search

How to search using haswbstatement more instances? Or to search via qualifiers. E.g. Id like to list files from Prague with the depiction of bridge. Something like "in P276=Q1085 find P180=Q12280". Is there any road map for haswbstatement, what will be possible? Juandev (talk) 07:07, 8 August 2019 (UTC)

Ive just found it in the manual on Mediawiki.org. Something like haswbstatement:P131=Q1792 haswbstatement:P180=Q746708 allready works.Juandev (talk) 07:26, 8 August 2019 (UTC)

Switching from adding "most specific" tags to "all applicable" tags

Per the discussion here, it sounds like we need to update these guidelines to be less strict about only adding the most specific tags, as the eventual search interface for this will not support traversing the Wikidata item hierarchy to figure out that a search for "dog" should include images tagged as just "Chihuahua". Kaldari (talk) 20:34, 10 October 2019 (UTC)

 Agree with the change. The depicts (P180) property we use on commons is also used on over 100k items in Wikidata and they use "all applicable" tags approach, not the "most specific" approach. Our use on Commons should not be different than the use of the same property on Wikidata. --Jarekt (talk) 20:25, 6 November 2019 (UTC)
That’s not what I see on Wikidata: there are 259 depicts:cat and they’re not double-tagged with depicts:mammal  ; there are ~200 depicts:car, and none are tagged with depicts:land_vehicle.(which, unless I am mistaken, is what this proposal is about). Jean-Fred (talk) 09:12, 8 November 2019 (UTC)
 Agree, though I don't feel I actually have a say wearing my staff hat :) I first proposed narrow guidance for depicts when it was released, in order to avoid some open, mass-tagging sprees with the new tool. Now that the software has been out for a while and we've seen how it can affect workflows, I'd encourage opening up labeling to be more broad. This is additionally helpful as development is currently unable to traverse Wikidata to find associative properties (though hopefully one day, this will be achieved). Keegan (WMF) (talk) 20:47, 7 November 2019 (UTC)
 Strong oppose That is totally against the structure and ontology of Wikidata. No Item has two statements where one is the subclass of the other. I think querying for all items having this statement or a subclass is very standard. --GPSLeo (talk) 01:34, 8 November 2019 (UTC)
@GPSLeo: Yes, it's standard for Wikidata Query Service, but the main use case for depicts is the new Commons search interface which will not be able to traverse the Wikidata ontology. The structure of data on Commons doesn't need to follow the conventions of Wikidata, as we have very different use cases. Kaldari (talk) 21:04, 14 November 2019 (UTC)
Why should that be the main search interface or Wikibase data on commons? On Wikidata it is not(and I think it works well). I would prefer to build easy to use GUI wrapper for the Queryservice then thy to use the standard search engine for such things. --GPSLeo (talk) 22:59, 14 November 2019 (UTC)
  •  Comment I have issues with the premise of the proposal: “as the eventual search interface for this will not support traversing the Wikidata item hierarchy” → This is not my understanding. My understanding, based on the discussions with SDoC folks at WikidataCon, is that the search interface will not support traversing the hierarchy “right now” nor “right away” (which is fine, I can readily believe it’s a tough nut to crack), but that at some point it will (that’s also what Keegan says above). That’s a big difference in my book. Jean-Fred (talk) 09:12, 8 November 2019 (UTC)
  • Just to confirm, the idea of hierarchy traversal isn't on the current roadmap, but it has not been forever abandoned. It's still on the (albeit long) wishlist for a new round of SDC improvements. Keegan (WMF) (talk) 17:59, 12 November 2019 (UTC)
  • @Jean-Frédéric: Being on a wishlist is very different than being on an actual implementation plan. Regardless, if we don't make the depicts statements more broad, the new search interface will be useless in the meantime (which might be forever). Kaldari (talk) 21:10, 14 November 2019 (UTC)
I'm going to withdraw this proposal until we get clearer guidance from the WMF. Kaldari (talk) 18:11, 20 November 2019 (UTC)
@Kaldari: I think we should not close this discussion the usage of the statements is very important for the functionality of structured data. The WMF will not give any clear guidance to us. They are giving tools, maybe with some suggestions, to us. But the community has to develop the exact usage and the guidelines themselves. --GPSLeo (talk) 18:30, 20 November 2019 (UTC)
I unarchived it. It seems like it will be hard to reach consensus, however, without knowing exactly how Commons' search is going to use this data (which sounds like is still unresolved). Hopefully we'll know more by the end of the year. Kaldari (talk) 21:04, 20 November 2019 (UTC)
There is already a Beta of the Commons Query Service. I think this could come this year. --GPSLeo (talk) 21:21, 20 November 2019 (UTC)
@GPSLeo and Jean-Frédéric: Here is some clarification I received directly from the Structured Data on Commons Product Manager: "Adding one, very specific tag and calling it a day simply isn't going to be an effective way to expose Commons files for search and other purposes. We recommend against it. As both Keegan and I have mentioned on on-wiki discussions since last year, hierarchy traversal on Wikidata is unfortunately unpredictable (in some cases wildly so) and not something we can rely on in the foreseeable future... We strongly encourage adding multiple tags (which doesn't hurt if everything is accurate), but we also don't want people not tagging files if they think they should wait for some community argument to play out or some magical advancement to happen." I hope you will reconsider your stances in light of that information. Kaldari (talk) 16:05, 24 November 2019 (UTC)
I am still not understanding the problem. I think it is no problem to query for all images where the depicts (P180) value has the statement instance of (P31) lake (Q23397). If I want to get all images of lakes. --GPSLeo (talk) 19:37, 24 November 2019 (UTC)
@GPSLeo: First, understand that there is a difference between "search" and "query". Yes, SPARQL should be available (with luck) soon, that power users will be able to use to run their own tailor-made queries. But most users are not power-users, and will not be writing SPARQL queries. The question here is really about what the regular Commons "search" box will be able to find. At the moment, as I understand it, it can find an exact Q-number that is used as the value of a "depicts" statement and ... that's about it. This is the present situation, which is (I think) what is motivating Kaldari's proposal. Going forward, it's likely that search will go through a number of iterations and developments; but I'm not clear on the likely roadmap or timescale for any of them. At the moment, I think, the urgency is to try to get as much SDC basic minimum functionality out of the door by the end of the first funding period, across the whole of the project, to try to make the best case for getting some more money. Refinements will have to wait longer. Also, the foundation my be rather under-strength currently for database wranglers, to fill the gap created when Smalyshev left.
Some of the other things one might want in future search are presented on phab:T213358; there's also a big desire for faceted search - i.e. be able to add additional search terms or conditions, or refine existing ones. (phab:T213560 / phab:T213562 / phab:T213360). Also there is a push to include "depicts of depicts" -- where the depicts information (eg for a painting) is on Wikidata, not Commons. Given all of that being foregrounded, the priority of matching broader search tems may have faded a little for the team.
Does a structured search for lake (Q23397) at the moment return everything with a "depicts" with a Q-number that is instance of (P31) lake (Q23397) ? At the moment, I think it doesn't. (Except perhaps though a specific haswbstatement: kludge as immediately above) Will it in future? I would damn well hope so, but (as per the above), no guarantees, at least not in an immediate time-frame. Would it return everything with a depicts that is instance of (P31) loch (Q1172903) ? Probably not, and not definitely certain, even if loch (Q1172903) were made subclass of (P279) lake (Q23397). Would a search for woman (Q467) return all pictures of women? Tricky, because individual women are not P31/P279* Q467. Would a search for mammal (Q7377) include all pictures of kittens? Tricky, because house cat (Q146) is not P279* Q7377. Do we want a search for "vertebrate" (Vertebrata (Q25241)) to include all the pictures of kittens in its returns? Or does one primarily want pictures that relate to the search term more specifically, with suggestions for particular directions for refinement, such as Category:Vertebrata tries to give?
Work-arounds could certainly be found for some of these issues; and some of them could be good scoring systems / probabilistic choice systems (eg "show more depictions of the things that are nearest the search term; but a few of the best of the most common things in the sub-class hierarchy, even if they are individually further away). But that's quite a step from the SDC's basic opening strategy for search, name to include some Q-numbers as strings in a bundle of strings attached to each image, and then use the existing string-search machinery and indexing to find them.
Indeed, the basic reaction of the SDC team when first looking at the Wikidata subclass tree at all closely was to run away screaming. (phab:T199119; thread here; thread on wikidata-l (and following month)).
So hope that helps as a bit of background on this. Jheald (talk) 12:06, 25 November 2019 (UTC)
I know. But on Wikidata there is the same issue. The regular search does not work. Querys are used for nearly everything. I think we should say the search is deprecated and only for the old not structured data. We should focus on new easy to use tools based on SPARQL, where the user only sees a simple GUI but in the background there are complex queries build. --GPSLeo (talk) 13:04, 25 November 2019 (UTC)
@GPSLeo: Regular users won't wait 30 seconds or more for a search to return (or fall over); nor, I suspect, would the SPARQL backend scale to support the full user-demand of being the primary search mechanism. So Commons is going to continue to need a search service, distinct from the query service, that can support most of the needs of most regular users -- which was, after all, what was initially pitched as the big possibility that SDC would open up. Jheald (talk) 14:23, 25 November 2019 (UTC)
I think if a person wants a very specific composition it is okay to wait some time. Now it would take much longer trying to find it. But if we really have no other way then I would propose to use separate properties for this. The depicts (P180) just for what really can be seen on the image as specific as possible and a "tag" property for all the image can be associated with, like people know this from Flickr and other image hosting platforms. --GPSLeo (talk) 16:40, 25 November 2019 (UTC)
  •  Oppose I think this would cause significant problems down the line, when we want to use qualifiers to say eg where in the image the depicted thing is; what the person is wearing; what body pose they are in; what attributes they are depicted with; etc, etc. This becomes a real pain, if there are multiple redundant tags for each thing in the image; as well as the redundancy making it much harder to identify how many distinct things are in the image, that we might eg want an app to prompt the user to give more information about.
What is being proposed here is a short-term fix, that will end up storing up much more long-term issues for us than just doing it the right way from the start.
The right medium-term fix here, I think, which has been discussed, is to introduce redundant additional shadow tags which are closely attached to the most specific tag (eg like qualifiers), so there is only one tag-group for each thing, but with the shadow tags still being picked up by the search engine. It's not a great solution, and would still involve a huge bloating of the triplestore database, but it may be the best we can do for the moment. If anyone wants to propose such a qualifier (eg "broader search term", aka "shadow tag"), for use specifically as a qualifier on depicts statements on Commons, I would give that a support !vote.
But the present proposal I think we should discourage. Let's not rush in to do things now as a quick fix, just because we can, that we will then regret. Instead let's take a little more time and do something rather more sustainable. Jheald (talk) 10:22, 25 November 2019 (UTC)
@Jheald: You seem to have a very ambitious (and I would argue, unrealistic) idea of what Commons search is eventually supposed to work like. Wikidata has been around for 7 years and still doesn't have a single structured data feature in its search interface. Why do you think that Commons is somehow going to leapfrog that with the same technology? Unfortunately, Wikibase just wasn't built with search in mind. Like it or not, depicts is basically just a tagging system (as far as search goes). And honestly, I think that's a huge improvement over what we have now. I would be thrilled if Commons would let me search for all photos of cats, licensed as CC0, created in 2018; and I would be fine if Commons never let me search for all photos of cats, facing left, sitting in someone's lap. Besides, that's basically what descriptions are for. Unfortunately, I don't think I'll be able to execute either search on Commons so long as we keep making the perfect the enemy of the good. Kaldari (talk) 19:56, 28 November 2019 (UTC)
@Kaldari: I don't see that the compromise I suggested would be making the best the enemy of the good. And it would be dead easy to implement from the search perspective -- just add the qualifier values to the bundle of words indexed for each image. Jheald (talk) 23:40, 28 November 2019 (UTC)
@Jheald: I'm still skeptical of the added complexity, but I'll try to see if anyone on the Structured Data team has an opinion on your suggestions. If it's doable, it might be a decent solution. Kaldari (talk) 19:54, 2 December 2019 (UTC)
@Kaldari: Thanks. I believe (but you might like to confirm) that they will be adding their own "shadow tags" to the indexed terms for each image, machine-made by generalising slightly from the "depicts" value(s). So it should be possible to treat these hand-added shadow tags in the same way. Ideally the auto-added ones will also (eventually) be shown by the interface, perhaps with options to remove. This would be good, because it would show shadow tags already in play, that would not need to be specified in the qualifier. Jheald (talk) 20:08, 2 December 2019 (UTC)
  •  Oppose There are already some community created SPARQL query tools for Commons. That is the future for search, not the search box. And that will be severely damaged if the data is under par. Let's keep to high standard of data entry to make sure there are ways to find the best available images. Ainali (talk) 06:56, 29 November 2019 (UTC)
    • @Ainali: Surely you're joking. Wikidata Query Service gets a few dozen queries per day. Commons search box gets over 100,000 queries per day. First of all, Wikidata Query Service could never withstand that level of usage. If you think it's slow now, just wait until it has 10,000 times the traffic. Second, regular users are not going to learn SPARQL and Wikidata Q codes in order to find pictures of kittens. Kaldari (talk) 20:03, 2 December 2019 (UTC)

Notes (Annotations) vs. Structured Data 'Depicts'

I have a use case of identifying genes mentioned in biological pathway diagrams, e.g., File:Glucocorticoid_Mineralocorticoid_Metabolism.png. In that diagram, I added a note (annotation) linking the gene "CYP11A1" to its Wikidata entry. I also added structured data to indicate the diagram depicts CYP11A1, with qualifier 'relative position within image' = 'pct:25.736,14.297,5.046,1.650'. In this case, it seems the note and the structured data overlap in purpose. Is there a good option for handling this use case? (Earlier discussion). --Ariutta (talk) 04:48, 12 October 2019 (UTC)

The Wikidata Image Positions tool does almost this, except it's looking at the Wikidata content, not the Commons structured data. --Ariutta (talk) 21:52, 14 October 2019 (UTC)
As of the most recent update, the Wikidata Image Positions tool now supports WM Commons structured data. This tool could now augment or replace the Notes tool. --Ariutta (talk) 18:51, 28 October 2019 (UTC)
Related discussions on the ImageAnnotator Gadget talk page and the Wikidata Image Positions talk page. --Ariutta (talk) 19:06, 28 October 2019 (UTC)
"Depicts" is certainly not a complete replacement for image annotation. Not all annotations are simply indications of what is depicted. For example, they can be transcription of the wording of a sign, or a remark that a particular feature has certain implications about the dating of a photo. - Jmabel ! talk 05:08, 8 November 2019 (UTC)
For what it’s worth, I also wrote a user script to show such statements directly on Commons, similar to the ImageAnnotator gadget – see the announcement for details. --Lucas Werkmeister (talk) 19:33, 17 November 2019 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Depicts/Archives/2019&oldid=708246538"