Babel Development Log

The corners of the triangle that I described previously were black, white, and the saturated hue. The areas around those corners can be described by the adjectives ‘dark’, ‘pale’ (or ‘light’) and ‘bright’. My initial attempt at a system of predicates to describe regions of this triangle will be based on those adjectives:

• colour:dark
• colour:pale
• colour:bright

These can be combined with each other, and also with hedge operators such as ‘very’ and ’slightly’. I’ve chosen the word ‘pale’ rather than ‘light’ because being both ‘dark’ and ‘light’ sounds like a contradiction in terms, whereas ‘dark’ and ‘pale’ suggests the desired meaning of ‘greyish’. As always, the choice of predicate name does not necessarily indicate how the concept should be translated. I’ve not yet decided what hedges to provide or how to define them, but will do soon.

There is a complication, in that the triangle is not symmetrical. Consider shades of blue. Whereas the bright corner represents the best example of ‘bright blue’, the dark corner does not qualify at all as ‘dark blue’ because it is actually pure black. Similarly, the pale corner is pure white. Put another way, the unqualified colour ‘blue’ doesn’t refer equally to all parts of the triangle. Instead it is most true for the region around to the bright corner, and not true at all on the grey edge that connects the other two corners.

For this reason I think it is necessary to define the hue predicates as if they had a built-in qualification of colour:bright. That gives approximately the right semantics for representing unqualified basic colours such as ‘red’, ‘yellow’, ‘green’ and ‘blue’. Further desirable effects are that:

• Explicit qualification using colour:bright would reinforce the implicit qualification, placing the colour very close to the bright corner, whereas qualification using colour:dark or colour:pale would pull it only half-way down the triangle.
• Qualification using one of colour:dark or colour:pale will cause the colour to peak at the edge of the triangle, as opposed to a band crossing the interior.
• However dark or pale a colour is made, it cannot reach the grey edge of the triangle.

This raises the question of how you do represent colours along the grey edge of the triangle. As hue is mathematically indeterminate along that line I have no problem with treating these colours as special cases:

• colour:black
• colour:white
• colour:grey

I’m leaving it open whether colour:black and colour:white are shorthand for extreme shades of grey, or whether they represent distinct concepts. Either way, they are important enough that they should not need to be explicitly synthesised.

That, I think, is as much as I want to specify at present. I don’t intend to tie the predicates to an absolute colour space (such as sRGB), partly because I haven’t been able to formulate any defensible basis for selecting one, but mainly because I’m not convinced that the colour terms typically used in natural languages imply any particular colour space. Similarly, I’ve avoided making any distinction between transmitted and reflected light (although there will be a need to address concepts such as transparency and reflectivity at some point in the future).

Having established that one of the components of a colour should be its hue, it is necessary to decide what hues to provide, at what level or levels of precision, and how to name them.

In the first instance I intend to provide predicates for hues at 30° intervals and with the following names:

• colour:red (0°)
• colour:orange (30°)
• colour:yellow (60°)
• colour:chartreuse (90°)
• colour:green (120°)
• colour:spring-green (150°)
• colour:cyan (180°)
• colour:azure (210°)
• colour:blue (240°)
• colour:violet (270°)
• colour:magenta (300°)
• colour:rose (330°)

This ought to provide sufficient resolution for the colours that are commonly used in most natural languages. It won’t be sufficient for very specific colour names like ‘burnt umber’ or ‘cerulean blue’, but I have my doubts as to whether it is feasible to translate those at all. I’m open to the possibility of narrowing down to 15° or less if that would allow ordinary colours to be translated more accurately, but would want to see evidence.

I want to stress that just because a particular colour name has been used for a predicate does not mean that the same name will be used when it is translated into English, nor that languages need to provide distinct readings for all twelve hues. For example, my expectation is that the default English translations for colour:azure and colour:blue will both be ‘blue’.

It will be desirable to have some method available for expressing precision because there are some situations where you do need to distinguish between ‘azure’ and ‘blue’, however:

1. in the case of colours this can and probably should be done by qualifying the predicates listed above in some way (not by creating a separate set of low-precision predicates); and
2. rather than being specific to colours, it would be preferable for the method to be a generic one.

In view of the latter point I’m going to defer the issue of precision and treat it as a separate topic. In the meantime, any readings that are created will assume a ‘basic’ level of precision (meaning the level that would typically be used in the absence of any reason to be more specific).

Colours were one of the first types of concept that I tried to define predicates for, but it quickly became apparent that there were a number of quite complex issues to resolve before any firm decisions could be made. These include:

• which of the many possible colour models to use as the basis for the system of predicates;
• whether to provide one level of precision or several, and what those levels should be;
• when to synthesise and when to enumerate; and
• how to handle characteristics which cannot be made fully independent of each other.

From a programmer’s perspective the simplest and most familiar colour model is RGB, but that would not be a good choice for this application because its purpose is to model the physical composition of light, not how it is perceived and verbalised. For example, while it is quite common in English for cyan to be called ‘blue-green’, I’m not aware of any natural language which expresses yellow as ‘red-green’ or white as ‘red-green-blue’.

More promising candidates are HSL (Hue, Saturation, Lightness) and HSV (Hue, Saturation, Value). They more closely correspond to the surface forms that are commonly found in natural languages because of their separation of hue from the other two attributes. Examples include ‘knallrot’ (German, bright red), ‘vert foncé’ (French, dark green) and ‘glas golau’ (Welsh, light blue).

The main advantage of HSL is that it treats lightness and darkness on an equal footing, whereas HSV does not. Although both systems have a component called ’saturation’ they define it in different ways. In HSL especially the behaviour of this component can be counterintuitive because colours can be 100% saturated even if they are very pale. Both systems allow colours to be 100% saturated but very dark.

These idiosyncrasies are the result of mapping a coordinate space which is naturally triangular onto a square. The three corners of the triangle are black, white, and the saturated hue. All three edges of the triangle are smooth gradients, whereas this is only true for two (HSL) or three (HSV) edges of the square. Because of this I don’t intend to relate the system of predicates directly to HSL or HSV, but instead to the underlying triangular coordinate space.

Update 2009-07-15: Two colour systems which I should have mentioned are the ISCC-NBS and CNS systems. In some ways they are both very similar to the system I have chosen, in that they attempt to represent colours in a manner that is both systematic and linguistically meaningful. Unfortunately both of them are quite biased towards English (ISCC-NBS more so than CNS), and consequently are rather less systematic than they could have been. I did consider using a notation very similar to CNS for representing lightness and saturation, and may yet do so if current plans fail to deliver, but I wanted a system which allowed more extensive use of hedges and that was not directly based on HSL.