Wikidata:Property proposal/botanical photographs

Originally proposed properties

flower photo

edit
Originally proposed at Wikidata:Property proposal/Natural science
   Withdrawn
Descriptiona distinctive image of a flower, inflorescence, or a similar reproductive structure for this taxon
Data typeCommons media file
Domainitem, taxon (Q16521)
Example 1Mangifera indica (Q3919027)→https://commons.wikimedia.org/wiki/File:Inflorescencia_del_Mango_(Mangifera_indica)_(14704955963).jpg
Example 2Psidium guajava (Q166843)→https://commons.wikimedia.org/wiki/File:Guava_flower_-_Flickr_-_pellaea.jpg
Example 3Magnolia champaca (Q167027)→https://commons.wikimedia.org/wiki/File:%E9%BB%83%E8%98%AD_Michelia_champaca_-%E9%A6%99%E6%B8%AF%E8%8D%94%E6%9E%9D%E8%A7%92%E5%85%AC%E5%9C%92_Lai_Chi_Kok_Park,_Hong_Kong-_(9216126584).jpg
Wikidata projectWikiProject Biodiversity (Q60006372)

fruit photo

edit
Originally proposed at Wikidata:Property proposal/Natural science

leaf photo

edit
Originally proposed at Wikidata:Property proposal/Natural science

bark photo

edit
Originally proposed at Wikidata:Property proposal/Natural science

Update

edit

The set of properties before were replaced, due to discussions, by one single property:

taxon aspect image

edit

Originally proposed at Wikidata:Property proposal/Natural science


Motivation

edit

Botany and forestry textbooks often include images of these 4 different parts of flowering plants, which together greatly help identify species/taxa.

It would be great to have dedicated properties to these on Wikidata, enabling e.g. Wikidata-based Wikipedia templates for plant taxa or showing just flowers/fruits/bark/leaves in results of simple SPARQL queries.

Structured Data on Commons also offer ways of modelling this information, but it would be great to have the best image in each of these kinds readily available through Wikidata, particularly at the species level.

They would be added to the list of Wikidata property for linking to a representative image (Q26940804), and play a role in the Wikidata ecosystem similar to properties like nighttime view (P3451) and nighttime view (P3451).

I have bundled the properties in one proposal, as it may make more sense for discussion. TiagoLubiana🌴T🦋C🐬 03:01, 27 July 2025 (UTC)reply

UPDATE: The proposal has been changed from 4 properties to just one + a different modelling strategy. TiagoLubiana🌴T🦋C🐬 23:08, 4 August 2025 (UTC)reply

Discussion

edit

Notified participants of WikiProject Biodiversity TiagoLubiana🌴T🦋C🐬 03:04, 27 July 2025 (UTC)reply

  • OMG I love it! Yes I recall discussing this, but can't recall when - at least 2 years ago! I want this for personal curiosity reasons, but as a Wikimedian I would probably try to use it somehow on paintings - maybe as a qualifier for depicts (P180). Jane023 (talk) 05:40, 27 July 2025 (UTC)reply
  • I am a bit on the fence, here. Due to the number of properties it is already pretty challenging to navigate the property space in wikidata. Why not simply use image (P18) for the image and then depicts (P180) as a qualifier? This way a SPARQL query would be more efficient, one can get all images by simply querying for images and only specialized images if we need all. Andrawaag (talk) 06:40, 27 July 2025 (UTC)reply
    Most queries or API requests for P18 just wants one image, the main image of the subject (think infoboxes or external tools). If they have to filter out all sorts of qualifiers, it will make the usefulness of the property in whole worse. Ainali (talk) 08:43, 27 July 2025 (UTC)reply
Even if we go with the option of using a qualifier, it seems to me this useful use-case warrants having its own property to separate it from general pictures (call it "botanical image" or something). I support the proposal regardless of the solution you go for. I don't think it's a good idea to go for a sub-optimal modelling if the only reason is it's less convenient to use. This can be abstracted away, so it shouldn't matter. Although this is functionality that clearly should have been baked into the Lua extension library from the start. Infrastruktur (talk) 13:05, 27 July 2025 (UTC)reply
There's also already a related image (P6802) but the constraints don't allow it to coexist with a main image. -wd-Ryan (Talk/Edits) 16:22, 27 July 2025 (UTC)reply
Good points, everyone. Surely there will always be trade-offs. Of note are other things in the taxonomic space that may merit their own props/modelling (e.g. "eggs", "seed", "larvae", "seedling", "male", "juvenile" or more complex for, say, insects with several instars).
I like Infrastruktur's suggestion, maybe it strikes a good balance. Less bloating on the prop space, more flexibility, but harder to retrieve on Wikipedia for now. Would you prefer something like a "taxon aspect image" + a well documented set of qualifiers that attribute meaning to the images? Using either depicts (P180) or applies to part (P518) TiagoLubiana🌴T🦋C🐬 11:56, 28 July 2025 (UTC)reply
I like this suggestion. Infrastruktur (talk) 12:02, 28 July 2025 (UTC)reply
'Taxonomic image' is snappier. Any reason it could not be applied to all species, not just the plants that 'botanical' implies. I guess that taxonomy has formal poses that can be listed as qualifiers Vicarage (talk) 20:38, 30 July 2025 (UTC)reply
Adapt please. Infrastruktur (talk) 22:00, 4 August 2025 (UTC)reply
The proposal has changed from 4 properties to a single one, reducing risk of bloating the property namespace and covering more use cases. @AdamSeattle, Infrastruktur, Vicarage, Nat (WDU), Wd-Ryan, Jane023: @Andrawaag, Ainali: as you commented here before, you might be interested on these developments. TiagoLubiana🌴T🦋C🐬 23:08, 4 August 2025 (UTC)reply
 Support I like this more because it can apply to animals too. -wd-Ryan (Talk/Edits) 23:16, 4 August 2025 (UTC)reply
 Support in its new form, though I'd call it "taxonomic image" Vicarage (talk) 04:33, 5 August 2025 (UTC)reply
 Strong support Thanks for tagging, Tiago, I like the new approach! Nat (WDU) (talk) 15:39, 5 August 2025 (UTC)reply
Interesting developments here! Looking it over on the mango item included above, I see the issue for botanical illustrations which often contain several aspects of a plant in one page. I also agree that 4 properties seems a bit much, and I guess considering the comment about color the list of images used in various properties could become quite long per item. Maybe it's better to create a "depicted aspect" property to be used as a qualifier for P18? I sympathize with the need for a set of dedicated image properties, and we see this for castles and such with the "aerial view" image property, but you still need to fill good old P18 if you need any kind of historical images or views from different sides. I don't see the benefit of a dedicated property requiring a qualifier, or maybe I am missing some reason for that. Jane023 (talk) 08:23, 5 August 2025 (UTC)reply
I think it's because taxonomic views are formally couched in a few categories for each type of species, and have stylistic constraints that keep them apart from casual photos of a plant or animal. I do a lot of work with castles, and actually find all the balkanisation of images a nuisance, as I have to code up logic like
OPTIONAL {
{?item wdt:P3311 ?standardimagelist} # design plans
UNION {?item wdt:P9721 ?standardimagelist} # entrance
UNION {?item wdt:P8592 ?standardimagelist} # aerial view
UNION {?item wdt:P1621 ?standardimagelist} # detail map
UNION {?item wdt:P5775 ?standardimagelist} # interior
UNION {?item wdt:P11101 ?standardimagelist} # model
UNION {?item wdt:P2713 ?standardimagelist} # sectional view
UNION {?item wdt:P5555 ?standardimagelist} # schematic
}
or
VALUES ?images {
wdt:P3311 # design plans
wdt:P9721 # entrance
wdt:P8592 # aerial view
wdt:P1621 # detail map
wdt:P5775 # interior
wdt:P11101 # model
wdt:P2713 # sectional view
wdt:P5555 # schematic
}
OPTIONAL {?item ?images ?standardimagelist}
Having an 'building view' with qualifiers would have been much easier in many ways, but there isn't a standard for architecture like there is for plants. Vicarage (talk) 08:51, 5 August 2025 (UTC)reply
It is a good point.
One reason I see to avoid image (P18) for that is the single-best-value constraint (Q52060874); in Portuguese Wikipedia, for example, many infoboxes pull P18 automatically and not having a single "best" value breaks that.
For example, there are many images for Mangifera indica (Q3919027), but a simple query will return just the "best" value. Adding ?st wikibase:rank ?rank . FILTER(?rank != wikibase:DeprecatedRank) to queries will get you all valid values. It is not terrible, but adds complexity.
Also, changing usage for such a core prop (image (P18)) may have some mysterious side effects and break things for others.
That said, I don't have a super strong opinion on that. I just would love for this kind of info to be available on Wikidata under a commonly agreed upon model :) TiagoLubiana🌴T🦋C🐬 00:52, 6 August 2025 (UTC)reply

✓ Done @TiagoLubiana: Created as taxon aspect image (P13696) Infrastruktur (talk) 14:24, 6 August 2025 (UTC)reply