Lately I have begun thinking about how to identify the various proof notes in the census. At present, the Haxby ID is the most generally accepted and useful method. The key problem with the system is that if Haxby didn't see a note or a variation, the system provides no real means of assigning a definitive ID number to a note discovered ex post facto. In short, the Haxby identification system is not extensible.
The underlying methodology Haxby used is perfectly accessible and extensible... but when crafted into a full blown identification system it becomes somewhat rigid. Too rigid.
To understand the problem, let's work through a hypothetical sitation that reflects actual situations I'm encountering all the time.
Let's say I have a note in hand that is very similar to one described in Haxby. It has the same vignettes, denomination, title graphics, and so on to a note (say, PA-105-G2). Let's assume, for the sake of this discussion, that Haxby doesn't list any variations besides the one he knew about, and that one has a red textual overprint, an imprint of BBC/BC, and a printed date of Sept 1, 1854.
In most respects the note I have in hand is identical... but mine is a uniface proof (no overprint, no tint). We could simply identify it as a PA-105-G2 and make a note of the fact that this note has NO OP. As long as there aren't too many differences, this approach might be reasonable.
But now let's assume that the issued notes for PA-105-G2 have an orange lathework tint and red textual overprints. Now assume I have a number of proofs that each have some differences:
#1 is a uniface proof, as in the previous example #2 has red numeric overprints, but no tint or lathework #3 has red textual overprints, but no tint or lathework #4 has green numeric overprints, but no tint or lathework #5 has green textual overprints, but no tint or lathework #6 has red lathework, but no overprints #7 has red lathework and red numeric overprints #8 has a slightly different imprint (BBC without the BC) #9 has no printed date
and so on.
Each of these is fundamentally a proof of the same design as PA-105-G2, but they were not the final approved design for that note. Any reasonable census should note that the proof variations exist, without creating some new base ID that effectively detaches the variants from the issued note (or from each other).
In some cases the existing Haxby ID system does precisely that by calling out proof-only variants and assigning them a completely different number (for example, PA-105-G152).
In our census we have an inconsistent approach to handling this problem. In most cases, we have deferred to the opinions/methods used by the writers of the catalogues we reference. For example, some catalogue writers would notice the differences and declare each of the proofs to be "unlisted" (PA-105-Unl) because they differ from the description of PA-105-G2. In other cases they say "similar to PA-105-G2", and call out the differences (which would result in our records showing PA-105-G2 and requiring someone to read the desctiption to note the differences). Still others just call it PA-105-G2 and ignore the differences. Yet others create "new" numbers that don't exist, such as PA-105-G2a, arbitrarily assigning a number that does not exist in the reference.
If our census is to have any meaning or value we need to have a consistent means of identifying these variations, because that's really what makes proofs different from issued notes.
My initial thought is that we simply extend the current Haxby ID to include some additional data. At present, the system breaks down as follows:
SS-BBB-T###, where SS is the state code, BBB is the bank ID number, T is the Type code (G=Good, A=Altered, S=Spurious, R=Raised, C=Counterfeit) and the numbers and letters that follow the type code are the note identifiers.
I'm thinking we need to tack something on to the end that enables us to track specific variations from the higher order type. The simplest solution would be to devise an addendum to Haxby that specifically focused on proof variations. Using the above example, the variations might be listed as
PA-105-G2-V1 PA-105-G2-V2 PA-105-G2-V3 . . . PA-105-G2-V9
As new variations are discovered they simply get added to the bottom of the current list of variations.
Anyone have a better or more elegant solution? Anyone see a fundamental problem with this approach?
- Greg
|