[r-t] Descriptions (was: A date to pencil ...)

[John Harrison]

In article <8C0A0658BC7B4E9E86B2A72AD44A1956 at Modak>,
   Philip Earis <pje24 at cantab.net> wrote:

> Now there's never going to be a 1:1 correlation of (a sequence of
> changes rung) : (ways a ringer might think about / ring them).  Even in
> the same performance, different band members will likely approach the
> same sequence in different ways.

Agreed on both counts.  In the absence of any codified descriptive
framework the chance of two bands who rang the same thing (which in itself
would be less likely) describing it in the same way is probably pretty low.

The aim of the descriptive service is to help people to describe ringing
performances (a) to make it easier and (b) to increase the use of shared
descriptions.  Codification helps both, especially if it is designed to
handle the sort of things that people are likely to ring.  

The interesting question is how to handle the grey area around the edge of
what (given a well designed scheme) is so glaringly obvious that everyone
will use it.  

There seem to be two different sorts of greyness.  One is things that might
be described as 'breaking the notation', ie they can't be handled by the
notations used to make the core codification efficient.  Obvious examples
are jump changes and methods with dynamic structure.  The solution there
probably lies in extended forms of notation - probably less compact but
with wider scope - and an orderly way of ignoring or adapting concepts that
no longer apply.

The other are is things that might be described as 'breaking the
assumptions about how to use the notation' ie they are things that can
easily be described using the concepts and terminology of the core
codification but in ways that don't conform to assumptions that were made
when the descriptive infrastructure was developed.  Examples include
multiple covers, variable stage, X+Y, whole pull ringing, and so on.  Here
the need (apart from accepting that the assumption is arbitrary and
therefore should not be imposed) is to understand the impact of such on the
rest of the infrastructure, notably record keeping and various supporting
tools such as proof and musical analysis.  How much effort it is worth
putting into those supporting services to remove the various assumptions
will need a judgement, based on the likely demand.

-- 
John Harrison
Website http://jaharrison.me.uk