Matthew - I was speaking from memory - sorry if I misquoted or misread your intentions.
I'm not sure what I ought to do about the situation at this point! It sounds like you and Jon are both willing to coordinate your efforts - I am willing to work on whatever needs working on also. I'm open to suggestions - but maybe if I built a ref-addresses? Jon's HR/XML and your contact packages would refer to it (eventually)?
And then on the admin side we link up demographics to user tables?
To your points above:
1. Thanks, and there are a few subtleties that still need to be incorporated to do date guessing and granularity (you might only know that someone moved in a certain year)... Also probably best to mark at least one of the join records between person (or business) and address as current. That will save expensive queries in most cases, because you will primarily deal with current addresses.
2. I am absolutely NOT refuting the structure of Jon's design for addresses based on HR-XML (or apparently yours) - the only thing I was urging was to decouple people and addresses. The original ACS had all that stuff in the user table and then they created address-book, ecommerce, etc, etc where addresses kept popping up. That's the only situation I'm trying to prevent here - let's build ONE place in the system where we deal with postal addresses - hopefully someone from China will build an address verification routine for Chinese addresses, etc etc ...
3. Longitude/Latitude can be purchased down to the address level. A company that has a true use for geocoding will have already done this. (I do this for several sites I work on). Someone ambitious could probably get the TIGER dataset and create it for OACS.
4. If you're saying that the "marketing" data should be stored separately, I don't really agree, unless you push back and argue that it's not consistent internationally.
Several of those fields are directly copied from the census bureau classification.
It's not really computable in any easy sense - better to just store it with the data.
5. You're saying that e-commerce should reference the postal-address/ref-address package? I agree.
6. Agree. But many do too :) Those are the ones I'm trying to help..
So once again - what next?
