This entity (P18) is used by Wikimedia's setting of Wikidata. Please contact the development team or file a bug on Phabricator before big changes (renaming, deletion, merging, etc.).

v t e   Person properties Name given name family name patronym or matronym second family name in Spanish name first family name in Portuguese name name in kana birth name married name name in native language pseudonym religious name subject named as Roman praenomen Roman nomen gentilicium Roman cognomen Roman agnomen professional name Vietnamese middle name code name Birth date of birth birthday place of birth ancestral home ethnic group native language Death date of death (date of disappearance, place of disappearance) place of death date of burial or cremation place of burial image of grave cause of death manner of death killed by had as last meal last words General sex or gender image signature country of citizenship affiliation work location official residence residence permanent resident of award received notable work archives at coat of arms image audio recording of the subject's spoken voice social classification personal library at artist files at replaces replaced by has certification Education educated at academic major academic minor academic degree academic thesis doctoral advisor / doctoral student student of / student Profession occupation field of work employer position held member of floruit work period (start) work period (end) academic appointment reports to Views religion or worldview member of political party net worth lifestyle Body hair color eye color wears height mass blood type medical condition handedness voice type Family family relative father mother stepparent godparent sibling spouse / unmarried partner child Category:Person properties (210); See also: Authority control properties

How many images we should add to one item? I saw that some of the items contains many images, but I think that they should not contain many images. --Stryn (talk) 10:18, 18 February 2013 (UTC)[reply]

Example: Maria Sharapova (Q11666), 10 pictures. I thought Commons is a gallery... --Stryn (talk) 14:10, 28 May 2013 (UTC)[reply]

I believe that, when a Commons category (P373) is available, we should avoid adding image (P18), so a Lua module could automatically choose the best image by framing, size, background, etc. (maybe with priority to Featured Pictures). --Ricordisamoa 23:40, 6 June 2013 (UTC)[reply]

Currently Commons category (P373) has too many invalid values. — Ivan A. Krestinin (talk) 04:08, 7 June 2013 (UTC)[reply]

Please always have an image property, even if a Commons property exists. Theoretically you could get a random image from Commons, but no serious tool would ever do that, because you have 50% chances that the image is of bad quality, 10% chances that the image is misclassified, 0.1% that it is a dick pic. Add the cost of additional network requests, the hassle of developing it (many companies reusing Wikidata database dumps have zero experience with wiki software), and you understand that all items need one image, ready-to use. Syced (talk) 02:56, 29 August 2016 (UTC)[reply]

+1. And please don't import low quality pictures with wdfist while there are already better ones at Commons.--Kopiersperre (talk) 06:10, 29 August 2016 (UTC)[reply]

Now we have "single value" constraint, so we have about 1900 violations of that. We should decide it these cases are appropriate. --Infovarius (talk) 11:11, 17 January 2014 (UTC)[reply]

Currently the property is used in many ruwiki templates. Its fail if property contains multiple values. If we want to fix the templates then we need algorithm for the best image selection. The algorithm is not trivial, this is complex computer vision task. So I suggest to leave the constraint and clean up ambiguous images. — Ivan A. Krestinin (talk) 18:45, 17 January 2014 (UTC)[reply]

Stil is still not solved (as far as I know). My take on this is that you are fine to have more than one image for one item as long as:

• The image has not an item by itself
• The image can not be used in a different property (like nighttime view (P3451), image of interior (P5775), aerial view (P8592), etc.)
• The image can be described with a Qualifier and an Item
• The first image shows this detail or view too poorly or not at all
• The first image shows this object state too poorly or not at all (eg. steel (Q11427), could also show molten steel)

Any thoughts on this?
--D-Kuru (talk) 10:59, 14 November 2020 (UTC)[reply]

How about some consensus on which properties to use as qualifiers?

Suggestions:

• use point in time (P585) to indicate the date a photo was captured (can be sourced by bots on commons)
• use depicts (P180) to indicate that the photo depicts another related item (such as a character featured in a book, where the book is the main subject)
• use applies to part, aspect, or form (P518) to indicate which part (item) of the subject is shown (e.g. applies to part, aspect, or form (P518) = roof (Q83180) photo of the subject building's roof)
• use instance of (P31) to indicate that the image is a painting, a panoramic photo, a photo, an aerial photo, collage, etc.
• any others?

depicts (P180) and applies to part, aspect, or form (P518) seem to be similar, perhaps we should use depicts (P180) only? Danrok (talk) 17:11, 1 September 2013 (UTC)[reply]

Hi Danrok,

I’ve just pictures on Rennes City Hall (Q532811) and Palace of the Parlement of Brittany (Q2351981). I didn’t read this page before so I used applies to part, aspect, or form (P518) to indicate that the pictures represent façade (Q183061). I wasn’t sure what qualifiers to use so I came here.

Now I’ve read this and I’m a bit puzzled. What is the difference beetwen depicts (P180) and applies to part, aspect, or form (P518) ? You said « depicts another related item » but a picture never show the whole item (and if the picture depicted the whole item, the qualifier wouldn’t be needed ), it always a part of the item which can be understood as « another related item » (and which can be a Wikidata item itself).

Cdlt, VIGNERON (talk) 16:25, 2 September 2014 (UTC)[reply]

Should all commons media items be an item in wikidata, so as to avoid making the same claims over and over for the same photo within each item where it is used? Danrok (talk) 17:14, 1 September 2013 (UTC)[reply]

It seems a good idea, I feel like we’re adding over and over the same claims to differents items. Cdlt, VIGNERON (talk) 16:25, 2 September 2014 (UTC)[reply]

Given that the image might change at any point and that we also have a caption, is there a way to store the caption per language within the image ? Is there a per-article way to store it ? --Teolemon (talk) 10:53, 9 November 2013 (UTC)[reply]

Users of the data would be able to pull the caption(s) from directly from articles without too much work, if they need them. Also, it's possible that wikidata might support Commons images as data items in the future, see here; Wikidata:Development_plan#Wikimedia_Commons

I just tried to add a source for an image listed in Scorpaena grandicornis (Q2197411) but am not sure that part of (P361) was the appropriate choice, nor did I find guidelines. Pointers appreciated. --Daniel Mietchen (talk) 10:10, 18 January 2014 (UTC)[reply]

I'd suggest leaving it until some development for Commons has been done, see Wikidata:Development_plan#Wikimedia_Commons. Danrok (talk) 18:08, 30 January 2014 (UTC)[reply]

In ru-wiki image in infobox can have an additional caption, that explains who created the image (author of painting, for example), where it was taken or stored, dates, etc. How can we store that infromation in wikidata? -- Vlsergey (talk) 08:54, 29 January 2014 (UTC)[reply]

Came here with the same question and the answer is media legend (P2096). --Lockal (talk) 07:36, 10 January 2017 (UTC)[reply]

Hi, I try to summarise common errors during this property import. There are some cases then image must not be imported:

1. Image does not exists on Commons (the image can be local or deleted).
2. Image is located in commons:Category:Image placeholders or its subcategory.
3. Item contain some another property with this file. Current image properties list: video (P10), route map (P15), logo image (P154), taxon range map image (P181), seal image (P158), bathymetry image (P207), signature (P109), astronomic symbol image (P367), Sandbox-CommonsMediaFile (P368), pronunciation audio (P443), coat of arms image (P94), locator map image (P242), chemical structure (P117), flag image (P41), traffic sign (P14), orbit diagram (P491), audio (P51), Gene Atlas image (P692), page banner (P948), spoken text audio (P989), audio recording of the subject's spoken voice (P990), document file on Wikimedia Commons (P996).
4. Item has instance of (P31) = human (Q5) and file format is SVG. There are few exceptions: Zweeloo Woman scheme.svg, Vladimir Ivanov.svg, Veronica Lario.svg, Kumaranasan.svg, Arkadi Rozengoltz.svg, Robert Livingston Stevens.svg, Ritrat ad Rainer Werner Fassbinder SW.svg, Spartak 176.56.svg

Please use these checks in your bots. And extend this list if you know some more cases. — Ivan A. Krestinin (talk) 11:32, 13 June 2014 (UTC)[reply]

Hi Ivan, I numbered your point to make it easier to refer to them. 1 shouldn't happen with illustrate_wikidata.py, if you find an example with a pywikibot based bot I would like to see it. 2 shouldn't show up as an image in the extension. Do you have an example item with page? Does the page have that image as a property? The extension the bot relies on filters out small and placeholder images. For 3 the bot should be updated. I think 4 is caught by the same code as 2. Multichill (talk) 20:28, 15 June 2014 (UTC)[reply]

1. One bot made this mistake two days ago. Pywiki is not the only used framework on Wikidata. 2. [1]. — Ivan A. Krestinin (talk) 20:49, 15 June 2014 (UTC)[reply]

Considering the very important number of images of people's grave, I would suggest to add a type of image (for people), to indicate that the picture is representing the grave or tombstone, not the actual person (or portrait)... --Hsarrazin (talk) 21:05, 13 July 2014 (UTC)[reply]

•  Support -- Vlsergey (talk) 08:58, 14 July 2014 (UTC)[reply]
•  Support, please move the discussion to WD:PP. — Ivan A. Krestinin (talk) 21:31, 5 August 2014 (UTC)[reply]

Some examples:

Tainan	103 images including ,
Malawi	60 images including ,
Zakarpattia Oblast	43 images including ,

Looks like P18 is on the way to unstructured image collection. Commons galleries and categories are structured more better. Are we need images with unspecified relation between item`s object? Are we need so many images per item? Suggestions: 1. Change description of the property from "any related image" to "image of the object". 2. Clean all images except one by bot (excluding images with qualifiers maybe). — Ivan A. Krestinin (talk) 10:17, 18 August 2014 (UTC)[reply]

@Ivan A. Krestinin: see Wikidata:Project_chat/Archive/2014/08#new "game"? problems with adding of multiple images (P18) – Magnus already added a "warning" to the game where such additions come from (since then i didn't see newer edits like these, at least not more than 5 or 6 images).

If you see something again, please revert (or otherwise reduce to 1 image) and notify the user who added the mess (like [2] or [3]). If you see newer edits like these (made after today), i think it would be helpful if you could leave a notice at the forum, so others are also aware of the problem. Holger1959 (talk) 10:33, 18 August 2014 (UTC)[reply]

It's not necessarily the game though; several of my tools use the WiDaR "bridge". Mass edits could also be from here. In the end, these tools give users great power, and with... --Magnus Manske (talk) 15:59, 18 August 2014 (UTC)[reply]

The illustrate_wikidata.py script by Multichill looks very nice, what's the progress in running it? Is it only run upon request for specific wikis?

I'd like to import some more images where missing, especially as they can then be used for image addition campaigns like Taketa's on multiple wikis, to increase consistency. The first data source I'd like to use is the commons:Category:Images_from_Wiki_Loves_Monuments_in_Italy in conjunction with WMIT's monument database. WLM images are often too hard to add to articles, with current tools. --Nemo 08:54, 2 April 2015 (UTC)[reply]

User:Multichill's script only works if the images are already in WP. Importing images from commons:Category:Images_from_Wiki_Loves_Monuments_in_Italy could only work if the images have a template with the monument identifier. But in that case one need first to create an Italian monument identifier property. --Pasleim (talk) 08:29, 26 April 2015 (UTC)[reply]

Would someone please consider how we can look to provide guidance on the use of "preferred" and "normal" rank for images. For infoboxes to work, we need to encourage that the best (personal opinion) image should be selected as the preferred image of an item, otherwise we get double choice and infoboxes fail.

Similarly, would it be possible to put in place a compliance check to see that where there are multiple images that one is marked as preferred, and to note that we also only want one, so a reverse check for only one preferred is also required.  — billinghurst sDrewth 05:09, 5 January 2016 (UTC)[reply]

The discussion above seems to indicate that each item should have only one image. This makes sense, since Wikidata is not Commons. --Srittau (talk) 05:49, 5 January 2016 (UTC)[reply]

Infoboxes should attempt to select the one image (this can be done in LUA). Multiple images generally use qualifiers to define the year.
--- Jura 06:24, 5 January 2016 (UTC)[reply]

There have been some discussion about it in the past here and on the Project chat. Should we add a unique value constraint on this property? I think this property would be most useful to provide one image that represents the subject best. This is basically the image that you would put on the top of a page or in a list like Special:Nearby. Having multiple images listed here is not only something that would be best left to Commons galleries (even if they are mostly defunct at the moment), it would also defeat the purpose of having one well-defined image for automatic display. --Srittau (talk) 12:14, 9 January 2016 (UTC)[reply]

What prevents you from selecting the first or preferred one?
--- Jura 12:39, 9 January 2016 (UTC)[reply]

There is no "first" value. What is the use of duplicating Commons categories in this property? --Srittau (talk) 15:45, 9 January 2016 (UTC)[reply]

We are adding properties with Commons files as Commons can't supply images in a structured way. Do you have a sample of the problem you are trying to solve?
--- Jura 16:29, 9 January 2016 (UTC)[reply]

The problem is that currently a renderer that wants to display an image has to pick one. There is no way to pick the same one consistenly, or the pick the most appropriate one, since there is no appropriate image. Commons does supply images in a more structured way than just adding lots of images to an item, which is what people are doing here. In the future, structured data on Commons will even improve on this. Which problem are you trying to solve by having multiple images on an item? --Srittau (talk) 16:27, 13 January 2016 (UTC)[reply]

@Jura1: Hi, where is the discussion regarding removing the unique value constraint (diff)? Surely we can add checks in Lua for qualifiers or other stuff, but in this way we are adding complexity to a property that was very easy to use before. Please re-add unique value constraint. --Rotpunkt (talk) 11:55, 29 January 2016 (UTC)[reply]

It's a misleading constraint. If you read the comment above, you will notice that new editors or editors that don't contribute in building the image database tend to think that it only allows for one image while it just required users to add qualifiers. If there is something broken in an infobox or elsewhere, it needs to be fixed there. Obviously, one shouldn't add as many images on self-portrait of Van Gogh. From the comments by Srittau, it appears that Commons will provide you what you are seeking, so you might want to check there instead.
--- Jura 13:11, 29 January 2016 (UTC)[reply]

@Jura1: No, I disagree. (1) Where is the discussion about your unique value constraint removal (diff)? This property has the unique value constraint from 2013 and after two years you remove it, when all of us are used to have just 1 single image (2) looking for qualifiers is not the standard way users are used to with P18 (3) << Commons will provide you what you are seeking >> what does it mean? AFAIK now I have only P18 for infoboxes. --Rotpunkt (talk) 13:29, 29 January 2016 (UTC)[reply]

Please re-add unique constraint. 99% of the applications that use Wikidata data use only one image. Allowing more images is wasting contributor's time, and making the first image less representative. Syced (talk) 08:10, 18 April 2016 (UTC)[reply]

 Done Restored the single(!) value constraint per this discussion. --Srittau (talk) 10:51, 19 April 2016 (UTC)[reply]

• @Syced: the constraint doesn't ensure that there is only one image and it shouldn't really have an impact on contributor's time. Would you have a diff where this actually made an impact on contributor's time?
  --- Jura 11:25, 19 April 2016 (UTC)[reply]

I don't have a diff, but I can easily imagine an overly enthusiastic contributor wasting their time finding several images showing different aspects of an item. Maybe I am overthinking this though so do as you want :-) Syced (talk) 01:17, 20 April 2016 (UTC)[reply]

I'm late to discussion. Multiple images are used as collages: Tainan City's cover.jpg or TE-Collage Ursus.png

1. Some Wikidata items correspond to multiple (many) objects, therefore it is meaningful to use several items (up to 10) with subjective "proffered ranks".
2. Another use of multiple images is to show how objects are different across the globe, but serve the same function or correspond to the same "Wikidata item".
   • For example, how could we describe the same or different models of cars without pictures? It would be overly wordy.
   • 1 image for "Knife" is more than enough, but if an item corresponds to extinct object, more Images would be helpful to identify object (or corresponding Wikidata item).
   • In second case images from P18 can be moved in has use (P366) section as qualifiers (or in other sections as qualifiers). d1g (talk) 15:02, 21 April 2017 (UTC)[reply]

• If multiple images are permitted, then we may as well add every image from the related Commons category. Presumably they all show slightly different aspects of the item, so they are useful. If such use of multiple images is not desired, put the single value constraint back (I support the latter). Ghouston (talk) 22:12, 5 August 2018 (UTC)[reply]

I think you mix this up. One picture can be good enough to be the picture on different WD obejcts

I restored the change from @Nvrandow:

• unique means that a picture can only be used on one object
  • Help:Property_constraints_portal/Unique_value
• single value means that you have just one picture per WD object which I think is a better restriction
  • Help:Property_constraints_portal/Single_value

- Salgo60 (talk) 17:06, 24 August 2018 (UTC)[reply]

• I agree with Salgo60 and others. Unique value constraint isn't right for this property. Single value constraint is fine if we decide to restrict the depiction of each item to one picture. Deryck Chan (talk) 11:19, 27 August 2018 (UTC)[reply]

Is ist possible to save (and read) the orientation (portrait/landscape) of the image? Would be useful, because our module uses it for infoboxes. So i can change the size if necessary. -- DerFussi 12:20, 13 January 2016 (UTC)[reply]

@DerFussi: You have probably found a solution in the meantime, still, for other's reference as a similar question came up below: Take a look at mw:Extension:Scribunto/Lua reference manual#File metadata. --Marsupium (talk) 04:45, 3 November 2018 (UTC)[reply]

@Marsupium: Many thanks for the link. -- DerFussi 13:44, 24 August 2019 (UTC)[reply]

I had the doubt with d:Q3908225 but it is the same with every item of a "collective" concept such as "history of ...", "churches of ...", "list of airports of...". Some of these items are lists, some of thm aren't but still it is almost impossible to have a collective image for them.

It is a strange thing because even a precise item (a person, a building, even a town) can have tons of possible images to describe it, but it is clear that in that case a selection is possible. For a town I try to use to biggest panoramic picture available, for example, but still I can have my own idea.

For a vague or collective item it becomes instead weird to chose. You can solve it with a collage of picures if it available, I guess. In any case I have a feeling something is missing, that we should write some guideline. I don't want to say to newbies "just skip it"--Alexmar983 (talk) 17:45, 20 February 2016 (UTC)[reply]

How about not allowing image (P18) for instances of Wikimedia list article (Q13406463). Bridges of Pisa (Q3908225) should somehow link to bridge (Q12280), which has an image (P18). What do you think about this? Syced (talk) 10:57, 17 May 2017 (UTC)[reply]

Which quality images should have to be placed at P18? What about excluding images tagged at Commons with Low quality? And what about pictures showing not an individual, but a group of people?--Kopiersperre (talk) 19:41, 9 April 2016 (UTC)[reply]

A low quality image is acceptable is there is no better picture available, I would say. For instance an item about an event that happened a century ago. Syced (talk) 08:07, 18 April 2016 (UTC)[reply]

Same from my point of view. Low quality picture is still better than no picture. Also for picture of groups, it is still better than no picture. For group situations there is a nice template on Commons - c:Template:Crop for Wikidata. --Jklamo (talk) 11:08, 19 April 2016 (UTC)[reply]

• Low quality images aren't ideal, but if there is nothing else to add ..
  Personally I avoid group images unless it's fairly easy to determine who is the person (e.g. a female in a group of males). I'm not much into cropping ..
  --- Jura 11:27, 19 April 2016 (UTC)[reply]

Many former buildings don't have a picture because they disappeared before any wikicommonist thought about taking a picture.

In such cases, is it OK to put an image of whatever happens to be at that place nowadays?

For instance, a castle used to stand here but now it is a lawn, or a hotel.

Thanks! Syced (talk) 07:53, 19 April 2016 (UTC)[reply]

My opinion: Yes it is OK as it is better than nothing, but obviously any depiction of the real thing would be better, even if low quality. Syced (talk) 07:53, 19 April 2016 (UTC)[reply]

Personally, I don't like this, because this would give the impression that the depicted place is actually the building. On the other hand, I don't think it provides much information about the item. --Srittau (talk) 10:48, 19 April 2016 (UTC)[reply]

• Drawings should still be possible. I think we should avoid pictures of other buildings, maybe images of ruins or a lawn?
  --- Jura 11:31, 19 April 2016 (UTC)[reply]

• IMHO it's absolute bullshit to place the image of the successor for a demolished building. If any software uses data from P18, how should it determine whether the image is from the object or just from a related object?--Kopiersperre (talk) 15:01, 19 April 2016 (UTC)[reply]

• Successor building or bare lawn sounds unacceptable for me, but ruins or at least outlines in lawn sounds acceptable for me (unless we do not have better picture). --Jklamo (talk) 22:33, 19 April 2016 (UTC)[reply]

Understood, thanks for the insight! :-) Syced (talk) 01:18, 20 April 2016 (UTC)[reply]

I would like to open a question of plaque relevance as P18. I am sure that plaques like this are not relevant illustration and thus are not suitable to be added as P18, but what about plaques like that? These plaque images seems to be relevant to me and suitable to be added as P18. --Jklamo (talk) 18:50, 7 September 2016 (UTC)[reply]

There is plaque image (P1801) for both. The 2nd image, I'd add it also to P18 (unless there is some other available).
--- Jura 19:01, 7 September 2016 (UTC)[reply]

I was trying to add logo image (P154) to a few institutions but soon realized that most logos I could find on Wikipedia were not on Commons because of license issues. These images are on Wikipedia as fair uses - can't we link to them from Wikidata by the same token? Is there any way to do this? Thanks! − Pintoch (talk) 05:03, 29 November 2016 (UTC)[reply]

This property clearly says only Commons links are OK, so I am afraid it is not possible now :-/ Syced (talk) 08:33, 17 May 2017 (UTC)[reply]

A core of the idea of Wikidata is that our data get's reused. It's not easy to know whether fair-use applies to a given reuse of data and therefore we stay with the images from commons. ChristianKl (talk) 13:40, 19 May 2017 (UTC)[reply]

My guess: waiting for m:NonFreeWiki, which can provide a centralized non-free file repository. --Liuxinyu970226 (talk) 05:05, 6 September 2017 (UTC)[reply]

Is there a technical solution to add derivatives to the property? In Arabic wikipedia, we invoke a lot of infobox properties. Some times the problem is that there is a translated Arabic derivative of the picture (see example). The problem is that we lose that information when we invoke from Wikidata. The ideal situation would be to add a list of derivatives by language.--Helmoony (talk) 01:55, 8 August 2017 (UTC)[reply]

You can add a qualifier to specify the language. P18 isn't limited to English/enwiki
--- Jura 06:14, 6 September 2017 (UTC)[reply]

Currently this property is heavily used on items about templates, e.g. Template:Cheese-stub (Q5613054), despite the conficts-with constraint. Should we drop the constraint or remove the statements? --Pasleim (talk) 15:30, 31 August 2017 (UTC)[reply]

• Are they actually used or is this some failed import operation? The positive thing about it is that these images get excluded from wdfist suggestions.
  --- Jura 06:16, 6 September 2017 (UTC)[reply]

Collages have their own property: montage image (P2716)

Please add collages to this property, as image (P18) is often used in small sizes at which collages are totally unreadable.

Similarly, if you write an infobox and prefer collages, please make the infobox call montage image (P2716) and only use image (P18) as a fallback if no collage is available.

Archived discussion: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2017/05#Are_montages_acceptable_as_an_item.27s_image_.28P18.29.3F

Thanks! Syced (talk) 08:47, 16 September 2017 (UTC)[reply]

• P vip.svg
• Importez le logo individu-fr.svg

Teolemon (talk) 11:19, 1 October 2017 (UTC)[reply]

• Just add its to commons:Category:Image placeholders directly or to one of subcategories. — Ivan A. Krestinin (talk) 11:32, 1 October 2017 (UTC)[reply]

I'm not an admin yet, unfortunately. Teolemon (talk) 12:15, 1 October 2017 (UTC)[reply]

@Ivan A. Krestinin: cat added for the first one, the second one is already in a subcat.

@Teolemon: no need to be a admin to add a category.

Cdlt, VIGNERON (talk) 18:27, 16 October 2017 (UTC)[reply]

If only one image is to be used to represent a concept (I am interpreting the discussion at the top of this page to mean that is the case), who decides which image is best for the purpose, and what happens if someone disagrees and changes it? For example: If I choose an image to illustrate Scuba diving on English Wikipedia, and link to it as the image property, and someone from German Wikipedia decides that a different image is most suitable for German Wikipedia, can they change the image? If I decide that a different image is better, as it recently became available, and change the lead image on EN:WP, should I also change it on Wikidata? If an IP editor finds a better image on commons, can they decide to change it on WD?

For the time being, it is not in any way regulated. Usually, if there is no image in an item somebody just adds an image. However, sometimes user aggressively push their own images and even edit-war over this.Pretty much the same as in Wikipedia, with the difference that here the vast majority of the items only have one image.--Ymblanter (talk) 16:24, 11 December 2017 (UTC)[reply]

I agree. It should be a bit like choosing image for the infobox in Wikipedia article: people should come to consensus on the talk page. Also, I hate arguing with people pushing their own images, as they often do not seem to be very objective and if you point out some shortcoming of the image then they get defensive. So if you think your photograph is the best to illustrate something and others think other (not their) photographs are better than I would urge people to recuse themselves from making that call. --Jarekt (talk) 13:15, 4 January 2018 (UTC)[reply]

In case of book articles image (P18) seems to be often used to store PDF or DjVu files with the book itself. See With Fire and Sword (Q927292) or Mademoiselle Fifi (Q3275889). Shall we keep it in P18 or should we create some more specialized property?--Jarekt (talk) 13:33, 4 January 2018 (UTC)[reply]

• It's document file on Wikimedia Commons (P996). Wikidata:Lists/Decameron editions and translations lists images and pdfs.
  --- Jura 13:38, 4 January 2018 (UTC)[reply]

It would be really useful if we were able to indicate that where there are multiple images that one is to be set as preferred, and similarly to indicate where it is not set that it is reported. If the wikis are pulling one of the images back to display, then having a preferred/better/... image set would be useful.  — billinghurst sDrewth 07:32, 20 January 2018 (UTC)[reply]

Currently there exists a "used for values only constraint" for this property. But (Commons) images can also be legitimate references for Wikimedia projects and therefore also for Wikidata items. I just created an item (Franz London (Q52157989)) for a mathematician of whom the exact dates of birth and death can maybe only be found on his gravestone (commons:File:Grabstein von Franz London, Bergfriedhof Kessenich.jpg). So what would be the right way to insert this as reference? The only other property that comes into question seems to be Wikimedia import URL (P4656). But the property description states that Wikimedia projects (e.g. Wikisource) can be actual references, so why shouldn't Commons images be as well?--Leit (talk) 14:58, 24 April 2018 (UTC)[reply]

• @Leit: You might like Help:Sources#Headstones_at_Commons. Eventually, it should be possible to adjust the constraints accordingly. I will try to update it once it works for both tools.
  --- Jura 20:09, 24 April 2018 (UTC)[reply]

Thanks. So I guess images of information boards and architectural dates (I haven't found a Wikidata item for both yet) could be used as reference the same way? However, I think images of an item object (e.g. a building) itself can at least on rare occasions be a reference. I think of sculptures that have been stolen or destroyed at an unknown point in time so a specific image of the object (and/or of the former location of it) is sometimes the only proof of the end time (P582) of the existence or physical location of the sculpture. Probably type of reference (P3865) could be applied in this case as well, simply with the value image (Q478798).--Leit (talk) 21:02, 24 April 2018 (UTC)[reply]

Ivan A. Krestinin has added an allowed qualifiers constraint property with the only allowed value as "point in time". I am also adding "media legend" as allowed qualifier, since I have used it hundreds of times. What else is valid? - PKM (talk) 01:45, 18 July 2018 (UTC)[reply]

I saw sex or gender (P21) (for animals). Matěj Suchánek (talk) 07:55, 18 July 2018 (UTC)[reply]

@PKM: I propose language of work or name (P407) to identify the language in schemes. See Least Concern (Q211005), where it exists some months ago. Amadalvarez (talk) 21:39, 21 July 2018 (UTC)[reply]

Just add required properties to the constraint. I added only one because had no information about others. — Ivan A. Krestinin (talk) 22:05, 21 July 2018 (UTC)[reply]

language of work or name (P407) and sex or gender (P21) both sound right. - PKM (talk) 22:17, 21 July 2018 (UTC)[reply]

Excuse me, @PKM:, it should be better Wikimedia language code (P424) instead of language of work or name (P407), because the code language is usefull to make software that have to select the image of local language (I'm thinking in infoboxes from WPs, for instance). Otherwise, we need a double get to get the WM code language (P424). Thanks, Amadalvarez (talk) 18:06, 22 July 2018 (UTC)[reply]

I would vote for language of work or name (P407). If we store this, two steps are needed to get the language code. But what if we store Wikimedia language code (P424), and then want to get other data, like language name or Wikipedia article? It can be achieved only using a SPARQL query, which is not available for on-wiki modules. It’s also easier for the user to type in a language name than a code, and they get instant feedback—if the language name is incorrect, the statement can’t be saved. (It’s less of a concern, but according to the latest constraint violation report, language of work or name (P407) is used on 65 items, while Wikimedia language code (P424) is only on 2.) —Tacsipacsi (talk) 18:22, 22 July 2018 (UTC)[reply]

No, language of work or name (P407) should be used. Infoboxes can also select this, either with double step or by item identifier. Wikimedia language code (P424) is "Wikimedia language code", mostly irrelevant to the world of languages. Matěj Suchánek (talk) 07:24, 23 July 2018 (UTC)[reply]

@Tacsipacsi, Matěj Suchánek, PKM: Longer, but not a problem to me handle language of work or name (P407). Thanks for your reasoning. Salut !, Amadalvarez (talk) 17:14, 25 July 2018 (UTC)[reply]

I added depicts (P180) - Salgo60 (talk) 08:27, 23 August 2018 (UTC)[reply]

Looking at violations will show all kinds of things that can be plausibly added [4]. E.g., creator (P170). copyright license (P275), length (P2043), sex or gender (P21). Basically anything that can describe an image or the thing depicted. Ghouston (talk) 09:44, 23 August 2018 (UTC)[reply]

There is a format constraint (?i)((?!\barms of).)*, which exists to make sure that people choose coat of arms image (P94) over more generic image (P18). However, this approach has an issue: this format constraint incorrectly gives the warning in property image (P18) for coat of arms themselves. See, for example, royal coat of arms of the United Kingdom (Q165762), coat of arms of Russia (Q165508), coat of arms of Germany (Q133018). Perhaps, the items qualified as coat of arms (Q14659) or national coat of arms (Q645466) could be excluded from the format constraint report somehow. —⁠andrybak (talk) 09:09, 5 September 2018 (UTC)[reply]

I don't understand, coat of arms (Q14659) is already a exception to constraint (P2303), but the warning keeps popping up. Ivanbranco (talk) 09:26, 24 September 2022 (UTC)[reply]

This property should have a single-value constraint. There's no good reason for having more than one image in an entity as galleries and categories of images on Commons are quite easy to link to from Wikidata. Whenever the image is re-used, such as for an infobox, the user will want a single image representative of the topic. Any application requiring multiple images will source them from Commons anyway, and Wikidata shouldn't be attempting to duplicate Commons. Once a Wikidata entity becomes a dumping ground for an unlimited number of images, there's no way for the re-user to know that they need specify a particular image by setting one of the images as preferred rank. Having a single-value constraint – even if not enforced – would make it far easier to find issues with multiple images having the same rank. --RexxS (talk) 23:04, 8 October 2018 (UTC)[reply]

• I sort of agree. Should it be possible to have multiple images distinguished by certain qualifiers, e.g., sex, since it's popular to have images of male and female birds? Or should somebody just be forced to pick one? If there are multiple images, how are users like infoboxes going to decide which one to display anyway? Ghouston (talk) 19:24, 31 October 2018 (UTC)[reply]

I totally agree. Just choose the most representative image. Allowing several images leads to galleries such as the one at input device (Q864114) where people waste time adding all sorts of devices. It is counter-productive. Syced (talk) 01:55, 5 August 2019 (UTC)[reply]

I've added aspect ratio (W:H) (P2061) to the allowed qualifiers list. Seems like a logical addition, and it might be useful for applications and maybe for structured data on Commons as well. Husky (talk) 21:41, 30 October 2018 (UTC)[reply]

@Husky: I don’t think it useful: the aspect ratio of an image can be computed quite easily from the height and width of the image file, it doesn’t need to be stored. Can you give an example when it adds data to add it as a qualifier? (As far as I know, Commons structured data is always stored as statements, not qualifiers, so this constraint is not affected by it.) —Tacsipacsi (talk) 14:16, 31 October 2018 (UTC)[reply]

I agree with Tacsipacsi. It is easily ascertainable from height and width, you can get those:

• by looking at the statement on the item page, they are shown below the image,
• from the API, see Special:ApiHelp/query+imageinfo's size,
• in the WDQS with SPARQL, see mw:Wikidata Query Service/User Manual/MWAPI and the API documentation or
• with Lua, see mw:Extension:Scribunto/Lua reference manual#File metadata.

So no need for redundant aspect ratio (W:H) (P2061) perhaps? --Marsupium (talk) 04:45, 3 November 2018 (UTC)[reply]

Inspired by a tweet from user:DarTar [5], I would like to raise the suggestion that this property's primary label "Image" (and equivalent in other languages) is perhaps a bit misleading - since the subject of the property MUST be on Wikimedia Commons. This is a major and deliberate constraint on the scope of the property, but it is not clear by any of the current labels or aliases. Therefore, perhaps “image on Wikimedia Commons” is a more appropriate label, with "image" being an alias instead. For comparison, we have document file on Wikimedia Commons (P996) and also Commons compatible image available at URL (P4765).
Sincerely, Wittylama (talk) 16:19, 7 February 2019 (UTC)[reply]

You make a very good point, I like your suggestion. Wikimedians might take it for granted and feel it is slightly redundant, but in the linked data world it is good to make it explicit, and it also helps newcomers. Ainali (talk) 16:28, 7 February 2019 (UTC)[reply]

I think property names should be short and simple, and since no other images are accessible to Wikidata that constraint seems logical. Information that some projects might have local files, not accessible by any other project, does not seem necessary in this property name. --Jarekt (talk) 20:00, 7 February 2019 (UTC)[reply]

Yes the constraint on the Property is logical - and should remain. I'm saying the title of the Property should match the expectation. The other two examples I gave are not "scanned file" or "image available at URL" but specifically identify that the property relates to what is on Commons. The title "image" is misleading in that it implies you can either upload your own file directly or that it allows you to link to any image-URL across the whole internet. Instead, the scope is ver specifically on Commons and should IMO be overt about that. Not the least because we're lacking a LOT of very well known images on Commons: for copyright reasons. This query for "works by Andy Warhol - with year, and optionally image" makes it look like we are really bad at collecting images. But in fact it's for copyright reasons that column is empty - not because we don't know how to find Warhol's works. Wittylama (talk) 22:34, 7 February 2019 (UTC)[reply]

• No need. The description can clarify this. --- Jura 09:10, 10 February 2019 (UTC)[reply]

Does it therefore follow that you would say that document file on Wikimedia Commons (P996) should be simply “scanned image” (or just “scan”) and that Commons compatible image available at URL (P4765) should be “image available at URL” - with the explanation of their scope to Commons in the description field being sufficient? I would argue that these three properties should be consistent in the way they’re labelled. Wittylama (talk) 12:58, 10 February 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

• I think you are confusing things. P4765 says something about the licensing of the image. P18 and a few others have one of the datatypes that restricts values on Wikidata to files on Commons. P996 is a bit of an oddity, possibly done from a Wikisource POV. It's likely to renamed anyways. --- Jura 19:20, 10 February 2019 (UTC)[reply]

Having run into this myself multiple times (sometimes just an "oh I have to upload that to Commons", but also "oh only Commons files are allowed) I agree the name of the property should be changed to reflect Commons. Whether the image can be displayed on Wikidata from the property is irrelevant. Jane023 (talk) 13:08, 10 February 2019 (UTC)[reply]

There is a problem with format/property constraint in following item "image": Q44316 click on the table to see its ! icon, PLEASE FIX IT, THANKS. Editor-1 (talk) 12:37, 9 February 2019 (UTC)[reply]

I see what you mean, but I don't understand the regular expression in the constraint. What does "(?i)" do? Ghouston (talk) 06:13, 11 February 2019 (UTC)[reply]

I am not familiar with regular expression, so can't help too much, but I think it is related to following part of the image title: "version 3.30 (2018-09)", it seems the image File:GNOME Shell with GNOME Clocks, Evince, gThumb and GNOME Files at version 3.30 (2018-09) in Dark theme.png breaks the defined regular expression. -- Editor-1 (talk) 09:46, 11 February 2019 (UTC)[reply]

@Editor-1, Ghouston: No it isn't the version number. It's "gThumb" which triggered the warning. My guess is that the writer of the regex wanted to prevent imports of image links which use a GThumb logo or screenshot as a placeholder image. I'm not sure how to proceed yet - my best hunch is that we should add an exception to this constraint where things that instances and/or subclasses of free software (Q341) should be exempt to the "gthumb" regex constraint, because it makes sense to illustrate a free software package with a gthumb screenshot. Deryck Chan (talk) 17:40, 11 February 2019 (UTC)[reply]

@Pasleim: You added the GThumb constraint. [6] What's the purpose? Deryck Chan (talk) 17:42, 11 February 2019 (UTC)[reply]

Gthumb.svg is used in some articles as placeholder which leads to wrong data import, e.g. [7], [8]. With the regex, this can be prevented. But feel free to change the regex if it causes other troubles. --Pasleim (talk) 19:51, 11 February 2019 (UTC)[reply]

Is only File:Gthumb.svg itself problematic (i.e. not files with similar names)? Then it can be moved to a new constraint specifically matching the whole value case-sensitively instead of this case-insensitive ((?i)) substring match. —Tacsipacsi (talk) 22:26, 11 February 2019 (UTC)[reply]

Thanks, (?i) sets a PCRE option for case-insensitive matching, it makes more sense now. What you suggest seems like the way to go. Ghouston (talk) 23:56, 11 February 2019 (UTC)[reply]

There are plenty of other icons in c:Category:No image icons, but nothing with a similar name, so it looks good. Ghouston (talk) 00:01, 12 February 2019 (UTC)[reply]

I had a go at changing it, but it looks like it should be done by somebody who understands PCRE syntax. Ghouston (talk) 00:17, 12 February 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I've split the constraint into two. I removed the "gthumb" part from the long formatting string and made a separate one that specifically rejects filenames beginning with "gthumb", case insensitive.[9] Deryck Chan (talk) 11:38, 12 February 2019 (UTC)[reply]

• @Deryck Chan: "made a separate one that specifically rejects filenames beginning with "gthumb", case insensitive" what?! "gThumb" is the name of 1 famous free and open-source image viewer and organizer in Linux and it has its own article on many different wikis and also a category in Wikimedia Commons: w:en:gThumb & c:Category:GThumb -- there are many images that begins with "Gthumb" or "GThumb" which only 4 of them are taken by me and I still want to take more screen-shots for newer versions! |: -- Editor-1 (talk) 13:48, 12 February 2019 (UTC)[reply]
  • @Editor-1: Hmmm I think you have a point. There are only a total of 17 images on Commons whose titles begin with "gthumb", 4 of which (File:Gthumb.png, File:Gthumb.svg, File:GThumb Logo.svg, File:GThumb logo.png) can be used as placeholder images. I think the "logo" constraint will catch the two "GThumb logo" files, so I changed the contraint to catch "gthumb." (including the dot) only, and all your screenshots will be fine. Deryck Chan (talk) 14:29, 12 February 2019 (UTC)[reply]

Hi, I was looking this entry Q187943, and a notice the error warning saying that we shouldn't include a sex gender in photos entries, however I see a great value in adding this information when we have sexual dimorphism. So, what could be a solution for this issue? I don't see including a media legend as a solution, as this is not a machine readable solution.

Another thing, to identify a animal we use parts of the animal, and to be a high educational value, we could start to show images of this parts, and their skeletons, if we have those, how we can implement that here?

x0x0 Rodrigo Tetsuo Argenton (talk) 07:36, 25 March 2019 (UTC)[reply]

I believe skeleton worth its own property (and many "images" of fossils will fall into this property). I agree that sex qualifier is quite useful. --Infovarius (talk) 12:59, 26 March 2019 (UTC)[reply]

If you are going to include all varieties and all parts of the item, you are potentially going to need a lot of images. It's true that for some animals the males and females are quite different, but sometimes so are the adults and juveniles (and their eggs). Car models are sold with a range of colours. Hotels come in all kinds. Maybe you just have to settle for one image, and use a montage if there are more. Ghouston (talk) 01:06, 27 March 2019 (UTC)[reply]

If you want multiple images, you can also create a Commons gallery and link it from Wikidata. Ghouston (talk) 01:09, 27 March 2019 (UTC)[reply]

I was talking about animals.

Yes it's true that it will increase the variety of images, however, all of them are educational relevant.

I don't see why it's a problem better illustrate the entrance.

It could increase a lot the educational potential, people and machines will easily find an example of the animal searched, and have a better panorama about it.

Or we could maybe create an entrance as "female ostrich", "juvenile ostrich", "Greta oto larval fase", I do not like this idea however.

Rodrigo Tetsuo Argenton (talk) 22:15, 29 March 2019 (UTC)[reply]

I think in some cases, you'll end up turning Wikidata items into a photo gallery plus a little data. Animals aren't the only things that vary in appearance. Even when we have items for individual animals, typically individual humans, they can vary a lot from one photo to another. On Commons there are categories like c:Category:Shirley Temple by year, and if multiple images are encouraged, then it may be reasonable to include one image from each year. Being able to pick a single image to represent something is useful, since infoboxes can generally only take a single image from P18. Obviously, a single image can't represent all facets of a given topic, but neither can 2 images, 10 images, or 100 images. Ghouston (talk) 02:31, 30 March 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ See this: [10] this is wiki made by Biologists to Biologists, they have a set of images to identify the animal, 12 photos, a lot of information. I can't see why you have trouble with that. Again, I'm not talking about people, cars... I'm talking about animals. Rodrigo Tetsuo Argenton (talk) 05:06, 31 March 2019 (UTC)[reply]

Infoboxes like that would give a justification for including multiple images. I'm not sure if P18 with qualifiers would be the best for that, or if new properties should be created. Ghouston (talk) 09:09, 31 March 2019 (UTC)[reply]

P18 is a single image that represents the item. If you want several images to represent the male/female/fetus/winter/summer variations to show in infoboxes, good, just create new properties, but do not hijack P18. I am developing an app that shows P18 as an illustration for each item, and I don't want to show a picture of a fetus because nobody will recognize the animal. Syced (talk) 03:24, 6 August 2019 (UTC)[reply]

The Commons file is 宗門人別改帳 Shumon Jinbetsu Aratamecho.jpg

It is used at terauke system (Q1164211).

I have already observed the same problem with many other files.  – The preceding unsigned comment was added by Syced (talk • contribs) at 10:21, 27 March 2019 (UTC).[reply]

@Syced: It’s not because of the Japanese characters. It’s because of the underscores instead of spaces, which has been fixed in the meanwhile by a bot. —Tacsipacsi (talk) 20:57, 27 March 2019 (UTC)[reply]

Oh I see, thanks for the explanation! Maybe the web UI could perform that replacement? When you look at a file such as https://ml.wikipedia.org/wiki/500_%E0%B4%89%E0%B4%82_1000_%E0%B4%89%E0%B4%82_%E0%B4%87%E0%B4%A8%E0%B5%8D%E0%B4%A4%E0%B5%8D%E0%B4%AF%E0%B5%BB_%E0%B4%B0%E0%B5%82%E0%B4%AA%E0%B4%BE_%E0%B4%A8%E0%B5%8B%E0%B4%9F%E0%B5%8D%E0%B4%9F%E0%B5%81%E0%B4%95%E0%B4%B3%E0%B5%81%E0%B4%9F%E0%B5%86_%E0%B4%A8%E0%B4%BE%E0%B4%A3%E0%B4%AF%E0%B4%AE%E0%B5%82%E0%B4%B2%E0%B5%8D%E0%B4%AF%E0%B4%82_%E0%B4%87%E0%B4%B2%E0%B5%8D%E0%B4%B2%E0%B4%BE%E0%B4%A4%E0%B4%BE%E0%B4%95%E0%B5%8D%E0%B4%95%E0%B5%BD,_2016#/media/File:Ldf_human_chain_against_de_monitisation_in_kerala.jpg in the media viewer, the only image name that can be copied has its spaces replaced with underscores. Cheers :-) Syced (talk) 03:15, 28 March 2019 (UTC)[reply]

@Syced: I see only one place from where I can copy the link: the bottom left corner (after scrolling), with spaces. Where did you find the underscore version? By the way, there’s already a task whose goal is to normalize file names (Normalize Wikimedia Commons file names via a ValueParser), although not very active since its creation half a year ago. —Tacsipacsi (talk) 12:18, 29 March 2019 (UTC)[reply]

From the browser's URL bar, as the filename is not easily copyable from anywhere else in the media viewer. Syced (talk) 15:27, 30 March 2019 (UTC)[reply]

@Syced: It is, I highlighted it on the above screenshot. —Tacsipacsi (talk) 22:23, 5 April 2019 (UTC)[reply]

Hi,

Now that commons:Commons:Structured data (SDC) do we still need depicts (P180) as qualifier? (and probably other qualifiers)

Especially in the cases where P180 is self-referencing: https://w.wiki/4kr where is see little to no value for this statements. depicts (P180) could eventually be useful when the image depicts something else than the concept (which is a strange and debatable practice) but I see no reason to stat the obvious like that (or else, it should be done always to be consistent, not only in 90 items).

Ping top users of this property: @Aktron, Hsarrazin, Magnus Manske, DavidMar86hdf, Teolemon, Simon Villeneuve:

Cdlt, VIGNERON (talk) 16:23, 9 June 2019 (UTC)[reply]

• Can you demonstrate how that replacement "now" works on Wikipedia? --- Jura 16:41, 9 June 2019 (UTC)[reply]
  • @Jura1: commons:Commons:Structured data and especially commons:Commons:Depicts explain how it works in details, in short: use depicts (P180) directly on Commons file. Cdlt, VIGNERON (talk) 16:52, 9 June 2019 (UTC)[reply]
    • With "demonstrate how it works on Wikipedia" I mean provide a link to a Wikipedia pages that makes use of both and shows their equivalence. --- Jura 16:54, 9 June 2019 (UTC)[reply]
      • @Jura1: AFAIK, none is never used in any Wikipedia pages (or elsewhere for that matter), do you have an example? VIGNERON (talk) 17:25, 9 June 2019 (UTC)[reply]
        • • No, but can you demonstrate the equivalence in some context? e.g. Query server? --- Jura 17:26, 9 June 2019 (UTC)[reply]

VIGNERON, I agree, image (P18) should depict the item it is added to and does not need depicts (P180) qualifier "to state the obvious". That was true before and after commons:Commons:Structured data on Commons, so nothing changed. --Jarekt (talk) 17:27, 10 June 2019 (UTC)[reply]

@VIGNERON, Jarekt: I totally agree with you : P18 should only be used with pictures directly representing the item, therefore depicts (P180) is useless as a qualifier :) - could you please point me to where I added this ? I don't remember ever doing it… maybe as a try for multilingual legend ?... --Hsarrazin (talk) 01:55, 11 June 2019 (UTC)[reply]

@Jarekt, Hsarrazin: a recent example I just saw: Special:Diff/965621885 by Olaf Kosinsky (not the first time I see an edit like this - I'm wondering if it was WEF also the previous times - and this is why I mixed the two separate subject SDC and self-referencing, which is not a good idea). Cheers, VIGNERON (talk) 12:39, 21 June 2019 (UTC)[reply]

@VIGNERON: I often use WEF, but never for pictures !! - no specific module for it, so it is not really easy. Olaf Kosinsky must have added all qualifiers by hand in WEF, probably through WEF Biographic module ^^

I thought also of edits previous to the creation of numerous properties for tomb, logo, street name signs, etc... but the example you give is much too recent. Maybe a wp project uses those qualifiers for caption ? (instead of P2096) ? but certainly NOT dewp... who are even more AGAINST wikidata than frwp --Hsarrazin (talk) 13:42, 21 June 2019 (UTC)[reply]

• I think some images that should be using P180 actually use P31 as qualifier. --- Jura 12:46, 21 June 2019 (UTC)[reply]
  • @Jura1: instance of (P31) is rarely used as qualifier of image (P18): https://w.wiki/5AE and it's never self-referencing https://w.wiki/5AF Cdlt, VIGNERON (talk) 13:47, 21 June 2019 (UTC)[reply]
    • My bad: it's sex or gender (P21), not instance of (P31). --- Jura 13:57, 21 June 2019 (UTC)[reply]

OK, example where I can understand the P180 qualifier... there are 2 values, completing each other ;) : Battle of Trzciana (Q380067) - but these could probably be extracted from King Gustav II Adolf of Sweden at Stuhm (Q18573182) p180, no, or even better, from Commons, where I just added them (and more) ? --Hsarrazin (talk) 13:54, 21 June 2019 (UTC)[reply]

• I think the go live for actual use of anything you add at Commons isn't anytime soon. --- Jura 13:57, 21 June 2019 (UTC)[reply]

P18 is, as far as I can see, mend for an image of the subject of the item. If the item is about a human being (P31=Q5), it should preferably be a picture of that person. If the item is a painting, P18 should contain a picture of the painting.

If the person is an artist (for instance a painter), sometimes there is a picture of an artwork made by that person instead of a picture of that person. Is there a specific property for items made by that person? P109 is mend for the autograph of a person, P800 for a list of 'notable works'.

A contribution like this one eliminates the (in this case) painting from the painter, but I'd prefer to have 'Drentse Aa.jpg' moved to another property instead of removing it completely. Any suggestions?

Thanks in advance, RonnieV (talk) 15:30, 15 July 2019 (UTC)[reply]

In the case of a person, I would be in favor of not accepting anything but an image that shows that person's face/silhouette/body. Syced (talk) 08:57, 2 August 2019 (UTC)[reply]

Yes. I have deleted numerous instances of such images, mostly imported from en.wikipedia, fr.wikipedia, it.wikipedia or some other wikipedia project. --Anvilaquarius (talk) 17:27, 31 May 2021 (UTC)[reply]

See Saint Cecilia Cycle (Q65600631). Should "applies to part" be added as an acceptable qualifier for image (P18) to accommodate this? Or should I should just be using depicts (P180)? Calliopejen1 (talk) 18:58, 17 July 2019 (UTC)[reply]

• I'd place those images on the parts. I had used the qualifier on Q7146416#P1442, but I'm not really convinced of that either. --- Jura 19:17, 17 July 2019 (UTC)[reply]
  • They are already on the parts. But isn't it also desirable/appropriate to have an image/images for a cycle of paintings? Calliopejen1 (talk) 20:08, 17 July 2019 (UTC)[reply]
    • Yes, an image. --- Jura 20:54, 17 July 2019 (UTC)[reply]
      • I guess I could make a collage but that seems like a strange solution. Is that what you would suggest? This problem also could arise, for example, for The 20th-Century Architecture of Frank Lloyd Wright (Q65051038) (a World Heritage site consisting of eight buildings in different cities). Calliopejen1 (talk) 22:37, 17 July 2019 (UTC)[reply]

• Choose one and remove the others. An historian could find out tomorrow that the Saint Cecilia Cycle contains one last painting, which was 95% burnt so we only have a picture of the remaining 5% which only shows a cloud. Will you add that pitiful cloud to the P18? If yes, there is a chance that it will represent the whole cycle, and you would see that pitiful cloud appear in apps that represent items by their P18, such as the Commons app (screenshot on the right). Syced (talk) 09:07, 2 August 2019 (UTC)[reply]

Hi all,

When an item contains a collage as their image (P18), please do the following:

1. Create a montage image (P2716) property with the same value
2. Open the collage image in a new tab
3. Select the most representative image in that montage
4. In the source section, copy the filename of that image (feel free to use a different image if you find a better one)
5. Paste that filename in the item's image (P18) value
6. Save everything

Here is a query that finds all P18s with "collage" or "montage" in their names.

Thanks! :-) Syced (talk) 03:05, 2 September 2019 (UTC)[reply]

Why is there a constraint warning against adding an image to a Wikimedia list article (Q13406463)? What benefit is derived or risk mitigated to offset prohibition of the attachment of a representative or sample image - something that in many editorial contexts might seems sensible & desirable? --Tagishsimon (talk) 01:19, 15 October 2019 (UTC)[reply]

I agree, an item such as list of landmarks in Lithuania (Q6624911) could use a P18. Syced (talk) 03:27, 10 February 2022 (UTC)[reply]

@ainali: Did you ever figure out how to deal with "The value for image (Marlin Park, Redwood Shores - Mapillary (BfaZGd61UYoWrFh5jWWSLw).jpg) should match “Please use "locator map" (P242) instead” (regex: (?i)((?!\b(map|carte)).)*)." ? I saw you ran into this earlier in Amsterdam? (I ran into it on Q49521947) Effeietsanders (talk) 23:09, 18 April 2020 (UTC)[reply]

I just ignored it since the regex is too simplistic to cover all cases, it just looks if "map" or "carte" is in the filename and suggests that another property might be better but of course there will be thousands of exceptions to this (just think of all items about maps for example). Ainali (talk) 07:47, 19 April 2020 (UTC)[reply]

I also had a false positive on Q91464541 since "carte" matches "carte postale" (postcard in French). -- Okhjon (talk) 09:39, 9 May 2020 (UTC)[reply]

Hi. How to deal with unfree images that are hosted on Wikimedia commons for some US-law-only reasons (random example: commons:File:Rod Thorn.jpg)? I do not feel like they are very useful for Wikidata, because if those pictures were allowed in P18, this item could not automatically be used by hardly any Wikipedia besides en.wikipedia. Opinions? Yellowcard (talk) 10:46, 11 May 2020 (UTC)[reply]

As far as I know, any Wikipedia can legally use any image from Commons, since all the Wikipedias are hosted in the US and are under US laws (and this is the reason that Commons requires that all files be free in the US). Are there any Wikipedias that impose restrictions on which Commons images can be used? Ghouston (talk) 14:15, 11 May 2020 (UTC)[reply]

@Ghouston: Legally, it does not really matter for most legislation where the project is actually hosted: en:Lex loci protectionis, valid for probably all European countries. I do not know how each Wikipedia deals with this situation; the German Wikipedia, however, only hosts images that are free in Germany, Austria and Switzerland. Images that are free in all three of those but not in the US are hosted locally and not in Commons and can be used in the German Wikipedia. I assume that many other Wikipedia language versions proceed in a similar way. Yellowcard (talk) 14:45, 2 August 2020 (UTC)[reply]

We were talking about files hosted on Commons, not files hosted on a Wikipedia, which can't be linked in Wikidata. Sure, if you are in Germany, you are subject to German law, and there may be files on Commons that you can't republish in Germany. I don't think that this is an issue for Wikidata, since Wikidata is not published in Germany, and any file from Commons can be used. Ghouston (talk) 00:23, 3 August 2020 (UTC)[reply]

Hello How to add a foreign image link (eg https://eclipse.gsfc.nasa.gov/5MCSEmap/-1999--1900/-1980-06-12.gif to solar eclipse of June 12, 1981 BC (Q5692098) ? Bouzinac (talk) 14:12, 1 July 2020 (UTC)[reply]

Upload it to Commons first. Ghouston (talk) 02:22, 2 July 2020 (UTC)[reply]

Hello Ghouston (talk • contribs • logs), I don't want to upload for 2 reasons :

• NASA copyright
• there are ~5000 images

All of them have a link {NASA page link-date of the solar eclipse} Bouzinac (talk) 07:16, 2 July 2020 (UTC)[reply]

Uploading 5000 images is not a problem, but if the copyright is not compatible then it cannot be used on Wikidata. Aren't NASA pictures usually compatible with Commons licenses though? Syced (talk) 03:21, 10 February 2022 (UTC)[reply]

Not useful, I get a warning for "MapungubweHill.jpg" at Q1136251.--Sinuhe20 (talk) 17:07, 5 August 2020 (UTC)[reply]

You can add yet another exception to the constraint, but we can question whether a constraint with so many exceptions is really desirable. Ghouston (talk) 00:26, 6 August 2020 (UTC)[reply]

Talking about constraint see also Topic:Vs06to7zxbqf8dye. I asked at the village pump beofre such use, so I am very surprised to discover half a way it was now putting a warning--Alexmar983 (talk) 23:34, 13 August 2020 (UTC)[reply]

I’ve just added color (P462) to an image (P18) statement about Logitech K400 Plus (Q106727147), to signify that the image is of the black variant. This is apparently discouraged, as a “Potential issues” tooltip is shown. What structure should I use to convey that fact? Theanswertolifetheuniverseandeverything (talk) 14:40, 22 May 2021 (UTC)[reply]

Several metro station items have a P18 value showing the entrance of the station, and one P18 value for each line that the station serves (example).

Is it always OK to remove all but one P18 value?
Or can I at least always mark one as "preferred"?

My app shows an image for each item, having a different image show up each time creates confusion.

Thanks! Syced (talk) 08:42, 2 August 2021 (UTC)[reply]

I wrote a small SPARQL script to list items that have multiple images:

SELECT DISTINCT ?item ?itemLabel ?coordinates
WHERE 
{
  ?item wdt:P17 wd:Q17. # Limit to a single country to avoid timeouts
  ?item wdt:P625 ?coordinates.
  ?item wdt:P18 ?image1.
  ?item wdt:P18 ?image2.
  FILTER(?image1 != ?image2)
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

I hope it can help with housekeeping. Cheers! Syced (talk) 09:09, 2 August 2021 (UTC)[reply]

I saw that Wikipedia now has a template "CSS image crop" that (in theory) allows you to show part of an image by specifying coordinates, this is useful, for example for showing one person in a group photo. This would seem useful in an entry for highlighting what in a given image is relevant (and without having to adapt of fork the original image)

Could/does image store parameters to do this?

Back ache (talk) 08:07, 22 October 2021 (UTC)[reply]

Great idea, I don't think the underlying database has such a feature yet, unfortunately. For now, if an item is represented by a part of an existing picture, then it is worth cropping that picture using https://croptool.toolforge.org . Thanks! Syced (talk) 03:18, 10 February 2022 (UTC)[reply]

Images are extremely useful, apps use them to help contributors select the right item. So, we should do our best to make sure most popular items have a P18 (when relevant).

To find images suitable for P18, looking at the Wikipedia article(s) of the item is the best.

But when no Wikipedia article nor Commons category is available, here is another possibility:

1. Replace the QID in this query.
2. Run the query
3. Click on the results (if any)
4. If you find an image suitable as a P18 (one-by-one manual review is indispensable), use it.
5. If you find irrelevant depictions being used, please remove them, thanks!

By the way, this query gives Wikidata items that have Commons depictions but no P18 (yet?).

Cheers! Syced (talk) 03:16, 10 February 2022 (UTC)[reply]

I have created an item for the book series British Regional Geology, and wish to add an index map of Great Britain showing the coverage of the individual volumes: File:British Regional Geology Index Map 1965.jpg. If I add it as an image, I get the error message: "The value for image (British Regional Geology Index Map 1965.jpg) should match “Please use "locator map" (P242) instead” (regex: (?i)((?!\b(map|карта|地図)\b).)*)". But if I add it using P242, I get another error message: "Entities using the locator map image property should be instances or subclasses of one of the following classes (or of one of their subclasses), but British Regional Geology currently isn't: ". Frustrating. Is there a good way of dealing with this? Add as an image and ignore the error? Create an image file that doesn't contain the word "map"? Kognos (talk) 22:26, 23 February 2022 (UTC)[reply]

What to do about the following claim?

It's added by @Middle river exports, but it breaks the Constraint Violation reports by Krbot2 (operated by @Ivan A. Krestinin) Either the claim needs to be removed from the property, or the report needs to be fixed. Keeping the current situation isn't helpful for people monitoring constraint violations. Mbch331 (talk) 17:56, 1 September 2022 (UTC)[reply]

The report just needs to be fixed. It seems like the bot maintainer considers this type of constraint to be out of scope of what the bot is for?

Linking previous discussions on this topic for reference:

• User_talk:Ivan_A._Krestinin/Archive#Maintenance_of_Constraint_violations/Errors
• User_talk:Ivan_A._Krestinin#constraint_scope_(P4680)_qualifier,_error_on_KrBot_update
• Topic:Wzzstkgrf6bxjkh9
• User_talk:Ivan_A._Krestinin#multi-value_constraint_and_constraint_scope:

Middle river exports (talk) 18:02, 1 September 2022 (UTC)[reply]

I don't think the fact that the bot-generated reports don't work is a good reason to remove instances of these constraints. That is a problem with that bot and those reports, the constraint scopes work otherwise. عُثمان (talk) 00:44, 6 November 2022 (UTC)[reply]

In any case I find the existence of these regular expression constraints on the image property to be quite pointless to begin with. This site and Commons are multilingual yet the expressions largely only use English, and the terms they check for are ambiguous enough that a lot of the time the recommended replacement property is not even applicable.

For the image I wanted to link that happened to be a diagram for a lexeme with a sense meaning "throat," I just ended up creating a translated version of the diagram to link in part to avoid the constraint (with the side benefit of it fitting better anyway).

As far as I know, Punjabi does not even have a specific word for "diagram," which further makes these constraints just seem like a nuisance to anyone editing content in a language other than English. عُثمان (talk) 00:49, 6 November 2022 (UTC)[reply]

The bot owner doesn't want to change his bot. Mbch331 (talk) 10:24, 6 November 2022 (UTC)[reply]

This property seems to contain a whole list of format constraints that just produce false positives. I propose we remove these or lower to suggestion. Multichill (talk) 19:51, 1 August 2023 (UTC)[reply]

Hello! I have an image of the rebuilt Our Lady of the Angels School at Q7111000. I want to document that the new building was built because the former school burned in 1958 (Our Lady of the Angels school fire), but P18 doesn't yet allow "has cause".

Thank you, WhisperToMe (talk) 00:40, 10 September 2024 (UTC)[reply]

See meta:Community Wishlist/Wishes/Suggest media set in Wikidata items for their Wikipedia articles. Lots of Wikipedia articles do not have an image, especially in smaller language versions. Often, they only have a much less useful one. Suggesting the image in WD would mean images set there would, if useful, trickle down into their articles. Prototyperspective (talk) 22:00, 21 October 2024 (UTC)[reply]