Forum OpenACS Development: Re: Comments on the new postal-address module (and kin)

8: Re: Comments on the new postal-address module (and kin) (response to 1)

Posted by Jon Griffin on 05/29/03 05:14 PM

Having a ref-address package does nothing. Address data is not reference data. (reference data is seldom changed and usually from a 3rd party.).

Unless someone can come up with a very compelling reason not to have addresses and telephone numbers acs_objects they are going to stay that way. Comparisons to the way "AD" did it aren't reasons.

The current model is designed to make all addresses and phone numbers objects for many reasons, including site wide search and auditability.

As Alfred suggested, I am planning on tcl procs to do address verification. This is not trivial though and the system now works the way it is. Also, none of this has any effect on the data model or HR-XML.

Everything you guys are talking about should be built on top of the telecom-number and postal-address services. They are only repositories of data, what you do with them is another package.

Marketing data has to be stored seperatly, that is another package.

Longitude/Latitude is already incorporated into the ref-zipcodes service. Please note that getting this data is country specific with many if not most countries not having it. It really has no place embedded in the core data model.

There will be some changes to persons:


alter table persons add column formatted_name varchar(200);
alter table persons add column preferred_given_name varchar(100);
alter table persons add column middle_name varchar(100);
-- need to drop the not null constraint, I believe PG 7.3 allows this.

Also, person__new et al need to be replaced. I already did this for PG and Oracle will be just as simple.

10: Re: Comments on the new postal-address module (and kin) (response to 8)

Posted by Alfred Werner on 05/29/03 06:05 PM

I guess I don't fully appreciate the distinction between making them objects and not making them objects or calling it a service...

If you do 'verification' in tcl procs the best you are going to do is confirm that an address 'looks' well-formed.

I make a strong distinction between well-formed and valid data. Well formed passes some initial regexp rules that you can do either client side or server side with a round trip. It's not VALID unless its actually accurate. It's just like the email registration process - OACS makes sure there is an @ sign and thats about it. If I want to ensure that I have VALID emails, I have the system send the email and make the new user click through from the email to fully register.

I am trying to get the community to incorporate at least the fundamentals of correct address processing - the USPS and Bundespost will both give good discounts for properly formatted and address verified mail.

If I can save .03 per mailing per piece, I save a good amount of money over time. If the company sends even a moderate amount of mail, its worth doing properly.

The added bonus to us as developers is we can charge our customers to validate the data through 3rd party address quality providers.

Longitude/Latitude at the ZIP code level? That is based on the centroid and can be many miles away from the address. I can get it to the street address level - its used for proximity, routing, etc. It's all from TIGER anyway. If a particular user doesn't need it - they can leave it blank, but if I send out my list to get geocoded, I'd like to have a consistent place to put it.

And when you say marketing data - remember that once you wipe off the polish - that is also just TIGER data from the census bureau. Classifying an address as falling into a specific DMA is a US government distinction, not some arbitrary marketing decision. That doesn't work across all lands, but I'm willing to bet that a lot of other countries over time will do it similarly.

I would also argue that you might want to add timezone to the addresses - it's more of a warehouse mentality - put the facts in with the record itself. If you want to call someone who is registered in your system (customer support for example), there are only certain hours where you're allowed to do so.

Whee! Another can of worms.

11: Re: Comments on the new postal-address module (and kin) (response to 8)

Posted by Alfred Werner on 05/29/03 06:39 PM

Having a ref-address package does nothing. Address data is not reference data. (reference data is seldom changed and usually from a 3rd party.).

That's what list brokers do ...