Broken Bank Notes Message Board

Building a database on obsolete proofs
Page 22 of 24

Author:  Bernie [ Wed May 20, 2009 2:12 pm ]
Post subject:  Re: Building a database on obsolete proofs

Actually the All_lots does have the census data in column 2 just as in the Christies catalog. It does span more than 1 row and it would probably be easier to extract that data from the Obsolete spreadsheet and put it into the All_lots than to redo the extraction from column 2.

I am not a data base expert because I have been able to accomplish anything I needed with the data base @functions in Excel.

How about you set up a data base model and I will try to duplicate an equivalent model in Excel.

By the way, which data base program are you using?

Can a data base report write out a spreadsheet for Excel?

Author:  Greg Davis [ Wed May 20, 2009 4:55 pm ]
Post subject:  Re: Building a database on obsolete proofs

I'm using Access to model the data. I know that Microsoft provides an Access Snapshot Viewer that enables you to look at the data without having a full version of Access.

And as an aside, I can get you the full licensed version for next to nothing. I have a lot of close contacts within Microsoft and can get one of them to provide me with a copy at their employee discount price (which will be about $25, I think). Since you and I are the only ones doing any real work on this, I think it would make sense fot you to have a copy, if you wanted to stay involved once I begin moving in that direction.

- Greg

Author:  Bernie [ Wed May 20, 2009 9:53 pm ]
Post subject:  Re: Building a database on obsolete proofs

I do 99% of my computing on a MAC and there is no Access for Macs. I do have Access on my PC. So I will try to learn it.

Author:  Greg Davis [ Thu May 21, 2009 9:09 am ]
Post subject:  Re: Building a database on obsolete proofs

Attached is my initial take on the data map for the database. I've color coded the key fields that are used to relate the various tables. The data map will make more sense if you think about it in terms of how the union of the records form a specific report. I haven't yet concieved of the reports, but I think we both know what sort of reports we're interested in seeing. I know, for example, you want to be able to generate reports showing face different proofs, so I built in some potential data redundancy to allow us to generate such reports.

Take a look and let me know if you see any problems.

- Greg

Data Map.xls [25 KiB]
Downloaded 461 times

Author:  Greg Davis [ Thu May 21, 2009 8:49 pm ]
Post subject:  Re: Building a database on obsolete proofs

Today I received a box full of catalogues, including the Guevrekian (1977) and Vacca (1981) sale catalogues. Very exciting. Both are full of proofs and essays. I have my work cut out for me again.

In addition there were eight other catalogues with obsoletes, including Schingoethe 2 and the Wismer-Osmun collection sale from 1969. What a haul.

- Greg

Author:  Bernie [ Fri May 22, 2009 10:32 am ]
Post subject:  Re: Building a database on obsolete proofs

Not being a data base expert, let me try to understand your logic.

I presume that you are going to have a separate record for each proof(or separate face different proof) and that therefore every table in its data base record is an attribute “vector” for the proof?

The first 3 tables seem to describe all of the possible inherent attributes of a particular proof. Table 1 describes the note issuer. Table 2 and 3 attempt to correlate the proof with catalog numbers and give detailed attributes. Is there a reason to have a separate table for an alternate catalog?

Table 4 and 5 indicate the history of how the proof sailed through its life.

Table 6 is just an imprint definition table like at the front of the Haxby volumes.

I have some detailed questions about the deinition of some of the entries. These could best be answered after you have created a few records.

How will you take care of the UNL problem?

Where is the census data?

So why can’t I just take all of the vector elements, make a column for each, eliminate duplication, and each record would represent a row in an Excell spreadsheet? I guess I am still trying to understand what additional capabilities a data base program would give us over a spreadsheet.

Author:  Greg Davis [ Fri May 22, 2009 1:37 pm ]
Post subject:  Re: Building a database on obsolete proofs

Here are the principles that informed ny choices regarding the data map.

1) Fixed or constant data should be entered once and referenced indefinitely. This reduces the likelihood of errors and increases the ability to address errors as they are introduced. Examples of constant data are Imprints and Alternate Reference Sources.

2) Referenced data must be entered before the data that references it. This prescribes a sequence of data entry. For example, the Imprints table can essentially stand alone, since it does not depend on any other tables. Other tables depend on the Imprints table, so Imprints should be among the first tables created. In fact, I've already created that table in the actual database.

3) Tables and fields should be subdivided to allow maximum flexibility for the application, while also considering the effort required to enter and maintain the data. To that end I wanted to maintain the Haxby Notes information separate from the Notes Sold information, despite the obvious similarity in the data. This allows me to easily separate Notes that exist from those that are merely being described. I suppose I could do this by putting a flag field in the Notes data and leaving other cells vacant on the Haxby reference information, but to me it made more sense to separate the data (if for no other reason than the Haxby data is static and serves as reference data for the notes sold).

To better understand what I hope to accomplish by all this, and to see how this method is an improvement over Excel, I'll need to illustrate by example.

Using the current format of All_Lots there is only one column containing numerous pieces of critical data (State, City, Bank, Denomination, printed date, etc.). My ability to sort on that data is based entirely on the fact that I have organized the data within those cells in a specific way, and I cannot easily alter that sort pattern. So when I sort on that column I will always see things in the order of State/City/Bank/Denomination. Now suppose I wanted to do a report showing all banks named "Farmers and Mechanics". The current spreadsheet doesn't allow me to do that. Likewise, if I want to sort by denomination, I cannot do that.

Using a database with SQL queries I can combine and organize the data any way I want by simply composing the query correctly.

By maintaining the Haxby Note information separate from the Notes Sold information I can structure a query that essentially says "show me all the notes for which the Haxby Note imprints are different from the Notes Sold imprints". I could create a second query that seeks out all the notes for which the printed dates are different. I could combine these queries into a single report showing face different proofs. Though I didn't include the fields in the original map, I could also add information to track tints and overprints, pledges, security information, and so on... and write queries that show when those things don't match the Haxby description.

If these things are possible using Excel, I don't know how to do them.

By the way, the database described by the data map does not include the ability to maintain a census, since there are no count fields, save for the count of the number of plates on a sheet (which is not a cumulative count field).

As you can see, it's still a work in progress. I have, however, already learned how to import data from Excel and append it to existing tables.

- Greg

Author:  Greg Davis [ Sun May 24, 2009 8:02 am ]
Post subject:  Re: Building a database on obsolete proofs

I scanned in the Guevrekian catalogue yesterday, and have begun the process of integrating it into All_Lots. Since I know New York proofs are of special interest to you, I think this catalogue will be too. Jack Guevrekian specialized in New York obsoletes. I scanned in all of the pages from Session 2 (the Guevrekian session), so you could have a look. I had to remove some of the images, but many are still there. If you're interested you can download the scanned pages here.

Author:  Greg Davis [ Mon May 25, 2009 9:40 am ]
Post subject:  Re: Building a database on obsolete proofs

After primary processing of Guevrekian I've added 314 rows, almost all of which are New York notes.

Author:  Greg Davis [ Fri May 29, 2009 10:40 pm ]
Post subject:  Re: Building a database on obsolete proofs

If anyone is curious, I've begun processing the catalogues I bought recently. Most interesting (since processing Guevrekian and Vacca) are two catalogues from 1969... Wismer-Osmun sales I & II. These take a bit longer than more current catalogues because they are so short on information, I have to backfill much more just to get the listings to sort properly in the spreadsheet.

Anyway, I've done the primary processing on Sale II, and have just begun with Sale I. I'll post another copy of the spreadsheet when both are processed.

- Greg

Author:  Greg Davis [ Wed Jun 24, 2009 5:59 am ]
Post subject:  Re: Building a database on obsolete proofs

Over the weekend I discovered some additional lots residing on the Heritage archives that had previously not been included in the database. The way I discovered the missing lots was by processing the Chain of Custody information in the database, and finding references to a prior CAA auction that could not be resolved. Ostensibly, I had already processed that auction, and there were dozens of entries from that auction in the database, so there should not have been any unresolvable references. When I did a deeper analysis it turned out that there were about 60 lots from that auction that did not show up in the first pass.

The problem seems to be that the HA search engine does not operate with the same level of precision when scanning through all archives that it has when scanning through a specific auction's lots. It may be specific to the old CAA auctions... but at present I don't know that.

Of course, this raises the question of how many other lots have been overlooked... and I'll have to develop some methodical means of discerning that (and resolving any other problems). I'm plesaed to have found these 60 lots... but disturbed by the fact that the search methods are not operating as expected.

- Greg

Author:  Greg Davis [ Wed Jun 24, 2009 3:40 pm ]
Post subject:  Re: Building a database on obsolete proofs

Another update. This one includes the John J. Ford Part III listings, plus some additional records founf in Heritage and a lot of corrections.

- Greg

Author:  Greg Davis [ Sun Jun 28, 2009 9:58 am ]
Post subject:  Re: Building a database on obsolete proofs

This latest update contains many (~300) of the lots from the CAA auctions that escaped collection on the first pass. This brings the new total to over 15,100 listings. Also, of course, the usual corrections and updates to prior listings.

- Greg

All_Lots.xls [7.18 MiB]
Downloaded 454 times

Author:  Bernie [ Mon Jun 29, 2009 11:55 pm ]
Post subject:  Re: Building a database on obsolete proofs

Take a look at this 50-100 sheet of proofs being offered on ebay (400058878973) now. This is RI-325-G12 (SENC) and G14 (issued). It was not listed in Christies. Your All_lots lists a separate 50 auctioned by Stack's in 2007 and a separate 100 auctioned by Smythe in 2005. Any idea on its origin or is it a copy? It looks like some of the cream colored proofs from "sample books?"

By the way what does the yellow shading in the All_lots on the RI-325 proofs mean?

Author:  Greg Davis [ Tue Jun 30, 2009 6:25 pm ]
Post subject:  Re: Building a database on obsolete proofs

The notes currently on offer on eBay strike me as modern proprietary proofs, made by ABNCo and released after the Christie's sale.

Regarding the yellow cells in the spreadsheet, that generally means the cell needs attention for some reason. In the case of the surrounding notes, it means I don't have a complete Haxby ID for the note... only the bank ID.

You'd be surprised how much time I spend trying to clear the yellow from those cells. Ideally the whole spreadsheet should become coloroless some day.

Getting a complete ID on items from older auctions can be tricky... and maybe even impossible, so I leave the Haxby ID cells marked yellow until I resolve the mystery. If I determine that it cannot be resolved without actually seeing the note, I change the color to red so that I can stop having my attention drawn to that cell, but still know that I am aware the data is incomplete, internally inconsistent or otherwise not right.

The only other color I've been using is light green, which I use in the Chain of Custody column to indicate that I have found the forward or reverse reference noted in that cell and tagged that listing being the same as the one referencing it. In that case green means "no need to keep processing this cell".

- Greg

Page 22 of 24 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group