Wikidata:Property proposal/flower colour

flower colour edit

Done: flower color (P2827) (Talk and documentation)

Description	colour of flowers of a plant species, hybrid or cultivar
Data type	Item
Domain	flowering plants
Allowed values	colours
Example	Jasminum officinale (Q515610) → white (Q23444)

Motivation

Of interest to gardeners, florists, botanists and others. We may need to create items for colour ranges or groups, as used by reliable sources (e.g. en.WP describes Hyacinthoides non-scripta (Q164013) as "violet–blue"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:18, 29 July 2015 (UTC)[reply]

Postscript: Prior discussion is at Wikidata:Project chat#Adding property colour (for flowers), and I should have mentioned that I posted this at the request of User:Timboliu, posting as an IP on my talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:59, 30 July 2015 (UTC)[reply]

Discussion

A Flower:
1. receptacle (Q497512)
2. sepal (Q107216)
3. petal (Q107412)
4. stamen (Q103129)
5. carpel (Q1113448)

I really like it that we are venturing more and more into covering traits now (after things like eye color (P1340) and mushroom cap shape (P784)), but I have not seen a strategic discussion as to whether it would be better to use more generic properties on more specific items or more specific properties on more generic items, though the issue keeps popping up (see also the volcano eruption discussion). With this in mind, I am not sure about the benefit of this proposed property over starting an item for "flower of Jasminum officinale" and using colour properties like color (P462) on it. --Daniel Mietchen (talk) 01:12, 30 July 2015 (UTC)[reply]

WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Daniel Mietchen (talk) 01:15, 30 July 2015 (UTC)[reply]

I think this may get complicated very quickly. For example, this means having to deal with "violet–blue", "violet and blue", and "violet or blue". I suggest first looking at existing databases (here is one, and another, but there should be lots of them). - Brya (talk) 04:54, 30 July 2015 (UTC)[reply]

There is WikiProject Identification Keys, but I'm not sure if it actually goes somewhere. --- Jura 05:02, 30 July 2015 (UTC)[reply]

Comment A flower consists of multiple parts. The proposal is refering to which one? Flora of North America says „violet-blue or rarely white or pink“. So we would need at least an additional qualifier. Characters (or traits) are not stable. They are depending from a certain taconomic viewpoint. I agree with Daniel. We need a more general discussion. Watson and Dallwitz are using 581 characters in their The families of flowering plants to describe flowering plants. GrassBase uses 1090 characters for species belonging to Poaceae (Q43238). We are far away from defining our own plant ontology. --Succu (talk) 08:37, 30 July 2015 (UTC)[reply]

Perhaps we need properties for petal colour, sepal colour, etc? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:59, 30 July 2015 (UTC)[reply]

@Pigsonthewing: I think not. Constructions like

⟨ Flower of whatever ⟩ has part Search ⟨ 107412) ⟩
color (P462) ⟨ blue ⟩
number of elements Search ⟨  4 ⟩

would be pretty nice in this case ... author TomT0m / talk page 09:27, 30 July 2015 (UTC)[reply]

Oppose I guess there would be a discussion if the discussion for standard flower color representation, but it seems it's not that well defined, so I think here there would be absolutely no benefit to try to be specific for no precise reason. Even if the discussion of a specific color standard was at sake, this solution would work anyway with the item datatype for color, assuming there is an identifier property, an item for each color in the standard, with

⟨ color as defined by standard S ⟩ subclass of (P279) ⟨ color ⟩

⟨ blue whatever ⟩ instance of (P31) ⟨ color as defined by standard S ⟩

, and

⟨ blue whatever ⟩ S standard identifier Search ⟨ blueZZZZZ ⟩

, used as in my comment above:

⟨ Flower of whatever ⟩ has part Search ⟨ 107412 ⟩
color (P462) ⟨ blue whatever ⟩
number of elements Search ⟨  4 ⟩

– The preceding unsigned comment was added by TomT0m (talk • contribs).

Comment I think before discussing this property, we should write up a RFC and let outsiders of this knowledge domain weigh in. I have been thinking about this a lot lately and see no clear path to follow. For example TomT0m's suggestion is nice, but it is hard to imagine that we can retrain a whole community to use constructs like that. There is also the problem of adding too much information in the qualifier-rows. Readability and editablity are concerns for Wikidata and we have to be pragmatic about that. - In my opinion the most manageable solution would be to create items for all subparts and dump all the metrics in there. There are some examples of that already on Wikipedia: Acer saccharum (Q214733) has part Canadian Gold Maple Leaf (Q119457). But that also means creating many items ("bee wing", "shark tooth", ..). --Tobias1984 (talk) 10:31, 30 July 2015 (UTC)[reply]

why not ? It's not that hard. And similar structure for the whole project greatly limit the amount of examples needed. I don't agree that this structure is hard to grab. author TomT0m / talk page 15:04, 30 July 2015 (UTC)[reply]
Comment List of mushrooms seems to work mainly with specific properties, open to non-specialists and non-template editors. Maybe a similar sub-field could be identified to build a similar set of properties. --- Jura 11:11, 30 July 2015 (UTC)[reply]
and a subproject specific to a kind of mushrooms would have its own set of incompatible but similar properties ? Please don't take that path /o\ author TomT0m / talk page 09:15, 31 July 2015 (UTC)[reply]
- I think it's a good path to follow collaboratively built samples that can be compatible. This way we are sure we don't just follow idle chat. --- Jura 09:25, 31 July 2015 (UTC)[reply]
@Jura1: So ... why chatting at all ? It's for that reason we have a property proposal process (plus I have a few stalled properties myself, easy to say I'm idle after that) but enough personal iddle chatting. On the list : in which way edibility is specific to mushrooms, to take an example in the list ? having specialized properties for no good reason could create the need for a merge later ... author TomT0m / talk page 13:03, 31 July 2015 (UTC)[reply]

Well, at some point one has to evaluate if all the talk of participants actually leads to some collaboration within the project or not. --- Jura 07:20, 1 August 2015 (UTC)[reply]

@Jura1: Let's be clear : should I consider this a personal attack ? You should be clear on what you consider a "contribution". There is many ways to contribute. Mine is not "maximising the editcount on the main namespace". author TomT0m / talk page 10:25, 1 August 2015 (UTC)[reply]

@TomT0m: Specialized properties don't necessarily need to be merged. They can also be subclassed to more generic properties. - And I still think the structure is hard to grab. If we have many properties that each take one or a few simple statements it is easier to work with than totally generic properties that can hold 1000s of statements each with their own qualifier structure. How would a user read such a list without thinking he is reading a programming language? - But I could also be totally wrong about this assertion. In any case I still think an RfC would be a better idea than dispersing the discussion over so many property proposals. --Tobias1984 (talk) 20:39, 31 July 2015 (UTC)[reply]

@Tobias1984: Yout RFC argument is also valid for discussion on similar properties spreads on a lot of property discussions. And the outcome of discussions in many specialised properties is likely to become inconsistent decisions. I also don't see an obvious way to subproperty "color of parts" like properties as the kind of part would not be specified by an item. A Rfc why not but ... This would not prevent property proposals anyway and I would not know what to ask. On the contrary the structure I propose can be used in a variety of usecase, and a few examples with the color of the flower of some plant and the color of the superhero costume pant should suggest it applies to anything ... Plus the fact that there will be property proposals for people who does not knows that is an opportunity to tell them that, and those who knows won't ever have to go through this and will just enter their statements smoothly. There is so many advantages for so less understanding problems ... author TomT0m / talk page 21:06, 31 July 2015 (UTC)[reply]

@TomT0m: For example this RfC also proposed a really simple and generic way of handling images on Wikidata: Wikidata:Requests_for_comment/Image_properties:_many_properties_or_many_qualifiers. But even that rather simple scheme did not catch on and we still have all the specialized image properties as far as I know. So the topic might require an RfC that we need to make certain changes to the user interface that makes it easier for people to use generic properties. I might have time to draft something next week and I will ping you for your input. --Tobias1984 (talk) 21:28, 31 July 2015 (UTC)[reply]

I'm not sure if Wikidata actually has the technology for this RFC nor if it's planned to develop it in the long term. --- Jura 07:20, 1 August 2015 (UTC)[reply]

@Jura1: As a lot of your post, I don't understand what you mean. author TomT0m / talk page 10:25, 1 August 2015 (UTC)[reply]

Support I support the flower color proposal as a generic property. The values have to be added as needed. There are many standards, but most data sources use their own vocabulary, which needs to be matched. As to petal color, sepal color etc.: It may be desirable to add this, but it will not replace the unspecified flower color. For practical reasones, unspecific "flower color" is relatively highly used property in botany, without specifying the parts. Thus data available for flower color cannot be easily mapped to (often unavailable) data for the color of specific parts). --G.Hagedorn (talk) 11:47, 8 August 2015 (UTC)[reply]
Support as above. If different parts have different colours then use applies to part (P518) as a qualifier to identify the part associated with each colour. Joe Filceolaire (talk) 17:34, 8 August 2015 (UTC)[reply]
@Filceolaire: Excuse me but such a model is prone to give me headeaches :) Flowers are parts of a plant. To tell the color of the flower, or the color of any other part, like leaves, we will use either part of (P361) qualified, or ... a property "color of the part", and when the part has several color, we will use applies to part (P518) ? OK, but we could also put statements like
⟨ plant ⟩ color (P462) ⟨ yellow ⟩
applies to Search ⟨ flower ⟩
... I really don't like this. We should try to stay consistent in the ontology and limit the number of ways to express the same thing. This means that we should try to adopt the most straightforward rule with as few exceptions as possible, and "in the case of part colors use has part qualified with colors except for the case of flowers where we use "flower color" and when the color has parts we put several "flower color" statements qualified with "applies to" seems to me where we cross a complexity line. author TomT0m / talk page 08:10, 10 August 2015 (UTC)[reply]
Support somehow the discussion got side-tracked. --- Jura 06:08, 15 August 2015 (UTC)[reply]
Oppose The property color (P462) already exists, and can be used together with applies to part (P518) without problem. I see no benefit to creating a new property for flowers. --Yair rand (talk) 06:46, 16 December 2015 (UTC)[reply]

Yes we have, but how would you describe the colorparts of Union Jack (Q3173323) with a generic property and applies to part (P518)? --Succu (talk) 23:17, 25 December 2015 (UTC)[reply]

Comment I agree with using color (P462), about the rest I'm not sure. Regardless on whether we use it with qualifiers, or on a data item describing the flower part of that plant, things can get even more complicated than described above - I have two comments. First, consider e.g. butterflies. How do we describe the color of the upperside forewings of the male imago of a butterfly? Forewing is definitely "a part of the object", but in this case we have also other categories: gender male, developmental stage imago, and also upperside (which is perhaps also "a part of the object"). Second, sometimes it's not clear whether the property should apply to the whole object or its part. Is deciduous/evergreen the whole plant, or its foliage? Is phyllotaxis a property of the leaf, or the stem, or the whole plant? Prot D (talk) 09:47, 4 March 2016 (UTC)[reply]

@Pigsonthewing, Daniel Mietchen, G.Hagedorn, Filceolaire, Jura1: Done as sub-property of color (P462). I see a slight consensus in favor of creating a sub-property, although it is not really clear-cut in this multi-year discussion. In the end I opted for creating this specialized property, since the color of a flower is a very important aspect for identification, but also for the general public. Much more so than the color of any other part of a plant. --Srittau (talk) 21:30, 8 May 2016 (UTC)[reply]