[r-t] Minor Blocks: Poll results

[Tim Barnes]

> MBD:
> So how about an "Option F". In this, a method is defined as the shortest
> sequence of place notation, and has a canonical name. However, it is
> perfectly acceptable for a method to have other names for replications or
> rotations of the sequence - we might even call them variations ... The
> method libraries would sprout another level - beneath a method would be
> lists of its known/rung variations - but this would beneficial in that a
> layer of hitherto-ignored ringing terminology could be recorded. Software
> which uses the method libraries wouldn't need to change unless the
> programmer wanted to expose the variations.
>

Mark's suggestion increases in usefulness if we agree rotations can be
separately named.  Rotations are on my list of questions to ask / debate,
and as opinion seems to be in favor of not having a non-divisible rule
(though we should wait to see what the survey results are), I was wondering
if this implied an overall preference for a less locked-down set of rules
that would also lead to consensus that rotations can be separately named.

So in looking at Mark's suggestion, let's assume rotations can be
separately named.  (And let's ignore problems like treatment of
non-standard starts in Stedman until we actually get to debating
rotations.)  In the group of related methods that includes, say, Original,
x16x16 and Plain Hunt, it's easy to define Original as the canonical name,
as the group member that can't be divided further.  But if the group also
includes the method 16x, it's then less clear which would be the canonical
name.

Similarly as Magenta has already been named ahead of the method 56.1T, it
seems a little unsatisfactory for Magenta to be the canonical name just
because it happened to be named first.

I'm therefore wondering if an improvement to Mark's suggestion would be to
leave the Method Collections as a single level structure where all
replications and rotations have equal status as methods, and then add a
group identifier property that links methods that are replications or
rotations of each other.  So the tables might include the following:

x16 -- Original -- Group ID = 1234
16x -- Backward Original (if named as such) -- Group ID = 1234
x16x16x16x16x16x16 -- Plain Hunt (if named as such) -- Group ID = 1234
56.1T.56.1T.56.1T.56.1T.56.1T -- Magenta -- Group ID = 2345
56.1T -- Cyan (if named as such) -- Group ID = 2345
&x36x14x12x36x14x56,12 -- Cambridge -- Group ID = blank (no replications or
rotations yet named)

Anyone looking to determine which methods are related in this way can then
search by Group ID.  Maintaining a single-level structure would avoid
problems such as when ringing spliced, do you separately count number of
methods and number of variations, and it generally keeps things simpler.

I also like the idea of the Method Collections including a.k.a. names,
although there would challenges in determining when an alternative name has
had sufficient use to justify inclusion in the tables.  Alternative names
don't seem to benefit from the tables having a two-level structure - this
can be done through the existing single-level structure.

Mark - would you view the above as a friendly amendment, or do you see
inherent value in the Method Collections having a two-level structure?  If
the latter, I could put the above forward as Option G...

When we get to questions such as can methods have a one-lead course, and
should there be a 4 blows in one place limit, hopefully this will all get a
bit easier!

TJB