[Retros] More on terminology for castling and e.p. right

[Rol, Guus]

Retro-friends,
 
In the thread about castling rights and repetitons I made some suggestions for an improved terminology on castling "rights". I have quoted them at the bottom with a few minor edits to the original text.
 
The next question that might arise concerns "e.p. right" and how to view it in the conceptual terminology proposed for castling. There may not appear to be a great demand to separate e.p. RIGHT and e.p. OPPORTUNITY (pending the verdict on my unanswered query in the forementioned thread), but there is every reason to inspect its role in composition through the e.p. LICENSE. When clearly the e.p. license is different from the castling license how do we separate the two in language? Having considered this question for years, I finally came up with a satisfactory terminology last month. The right to castle in a composition is a DOMINANT LICENSE in the "FIDEX" and the right to play e.p. a RECESSIVE LICENSE. The words "dominant" and "recessive" are introduced from the field of genetics and based on close conceptual parallels. A dominant gene manifests in the child if one of the parents contributes the gene, the recessive gene only if the gene is contributed by both parents. The dominant license to castle manifests if one of the proof games for the position "contributes" the right to castle, the recessive license to play e.p. only manifests if all proof games for the position "contribute" the right to play e.p.. If the latter is not the case, the right to play e.p. is 'masked', another common description in genetics that seems well suited to both disciplines.
 
One characteristic of an appropriate conceptual terminology is that it has the power to generate new applications by nominating new formal identities. If the DOMINANT LICENSE to castle can provide the opportunity to castle and the RECESSIVE LICENSE to play e.p. provides the opportunity to play e.p. only if justified à posteriori, then why not locate more such opportunities by locating other dominant and recessive licenses? Example: "claiming not to have a right to castle is a RECESSIVE LICENSE - per its proof game definition". My R#6 à posteriori some months ago was based on this perception.
 
An interesting and so far untouched field is that of the AUTOMATICITIES. Can mate/stalemate/other-draws be considered DOMINANT/RECESSIVE or may be NEUTRAL? A subject for another time I guess.
 
Guus Rol.
 
........................
 
(edited from the discussion thread on repetitions with castling and the FIDE distinction between "temporary" and "permanent" castling right):
 
(a) CASTLING RIGHT. Would only apply to the permanent castling right which refers to the static game state property of being in possession of the right to castle.
 
(b) CASTLING OPPORTUNITY. Would replace the temporary castling right.
 
(c) CASTLING LICENSE. Would refer to the castling right granted in the composition field. It is non-absolute in the (post factum) sense that the license can be taken away by some competing license during the solution - as in mutually exclusive castlings.
 
In search of a methaphor to explain/communicate the need for this diversity I came up with the "company parking lot". Next to the head office of a company in retrograde fashion design is a parking lot for the middle and upper management. Anyone below that level doesn't even qualify to receive a license to enter the lot. The middle manager of the personnel procurement department receives a license but he is not guaranteed a parking space. On busy days he must compete with other middle managers in the tailoring and materials departments. However, when the CEO enters, he will always have access to the private parking spot which bears the reservation to his name. He has the unalienable right to park there. If any manager fails to show up with his car, of course the opportunity to park will pass by.
 
Think "castling" instead of "parking" and you get a pretty neat picture of the relationship between castling "rights", "licenses" and "opportunities".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pairlist.net/pipermail/retros/attachments/20071023/23e101ab/attachment.htm>