[Data-modeling] New properties for the "Visual Art" domain "Color" type

[Faye Li]

First chance I've got to return to this discussion...hopefully everyone 
else hasn't lost interest yet. :)

For a color with multiple names: The Freebase convention is one topic 
per entity, so it would make sense to have a single color topic, 
preferably with a recognizable English name (more on that later) per 
color. The alternative names can be captured either in aliases (simpler 
approach), or done via specific co-types that can be created as needed.

For a name that represents different colors -- i.e. a green Toyota 
Celica vs. a green VW Golf, well, they're different colors, really, and 
should be entered as distinct topics. I like the disambiguation of 
prefixing brand name in front of the color: it's obvious with the vendor 
name that "Toyota Green" and "VW Green" are different colors.

I realized when we were talking about color, the examples given were 
often not color, but color products. Crayola SkyBlue is a crayon that 
has a color, which may or may not map to the color topic "Sky Blue", if 
there is one. Instead, it maps to whatever color has the same 
CIE/RGB/some-other-metric value. A separate property could point to the 
"Sky Blue" topic as the color Crayola SkyBlue implements -- the techie 
in me considers this relationship that of one between a spec and an 
implementation. I.e. "Teal" is a color, and "Disney Never Land" paint is 
a color product that is a vendor-specific representation of teal. I 
think this is along the same line as Ed's suggested property "Equivalent 
Color".

As subjective as color names can be, it is still useful to have a 
readable English name for a color topic, rather than its RGB value or a 
guid. "Sky Blue", however ambiguous, immediately communicates at least 
the region of the color wheel (or dots in a n-dimentional color space?) 
concerned. #80daeb does nothing for users looking at it as a property 
via the Freebase UI -- it could as well be olive, orange, or salmon, or 
chocolate (hmm, color names derived from food -- an idea for a user 
Catalog?). Anyway, I think there's value in having readable display 
names for color topics.

Otherwise, the main "Color" type is down to very few properties (and I 
can even eliminate 2 & 3).
1) CIE xy value
2) Wavelength range (nm)
3) Frequency range (THz)

A "CSS Color" type seems ready for data:
1) Hex triplet value
2) CSS color name (?)

Can I add these properties to "Color" and create a "CSS Color" type for 
now (on sandbox first, of course)? Other color dictionaries can be 
modeled as we go.

-- Faye



Ed Laurent wrote:
>
>     If we want to represent that sRGB is Crayola SkyBlue and
>     #87ceeb is CSS3 skyblue then we have to decide if the name is the
>     common topic or the sRGB value is.
>
>
> Why not have a #80daeb topic of type Color with a "Color dictionary" 
> property of expected type color_dictionary set as "sRGB", and a 
> SkyBlue topic of type Color with a "Color dictionary" property of 
> expected type color_dictionary set as Crayola ? The Color type could 
> also have a property of "Equivalent color" with expected type Color.
>
>     One option might be to have the sRGB topic defined by a particular
>     value dominate and then have keys into various namespaces, /color/
>     crayola/skyblue
>
>
> I think this is the approach I described above. Correct?
>  
>
>     Alternatively we could endeavor to take the existing Azure topic
>     /guid/
>     9202a8c04000641f8000000000385053 and add different properties for RGB
>     or a compound value type that has the pair, sRGB and color
>     dictionary.   I think this was where Faye was heading.
>
>
> I think Faye's approach is not that different than described above 
> except that there is extra complexity in the model that reduces the 
> amount of data entry. The property that links colors would expect a 
> topic(s) of a specified color dictionary. For example, there could be 
> a property named "Equivalent sRGB color(s)" with an expected type of 
> sRGB_color that is co-typed with the more generic Color type.
>
>     Your suggestion, if I understand it, is to make standalone topics even
>     for the same sRGB triples but to have an explicit property that allows
>     people to say that these are the same or corresponding colors?  I
>     agree that that would most explicitly capture the arbitrary nature of
>     this color matching.
>
>
> Not quite. There would only be one instance of a topic for any given 
> sRGB triple. However, the "Equivalent color" or "Equivalent Crayola 
> color" property could accept multiple values (e.g., SkyBlue, LightBlue).
>
> One difficulty is that there will rarely be truly equal colors because 
> the color dictionaries have different scales (e.g., 8 bit vs. 32 bit) 
> of different primary color combinations (e.g., RGB, CMYK, CIE xy). So 
> there is really a range of equivalence measured in multiple dimensions 
> among _the spaces between_ colors of different dictionaries. The 
> colors themselves may not ever truly overlap because they are points 
> within the multidimensional space of the color dictionary. CIE xy and 
> CIE XYZ are colors that will overlap because one is measured in two 
> dimensions and the other in three dimensions. If I understand Nick's 
> excellent description correctly, all CIE XYZ values of a specified X 
> and Y are "Contained by" the color defined by the same x and y values 
> of CIE xy.
>
> More questions than suggestions I guess...
>
> -Ed
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>