Forum OpenACS Development: Re: Comments on the new postal-address module (and kin)
I'm that person - and no i did not say i would not use postal-address just that i have worked without it until now and will integrate it later - when postal address is "stable". Things like the ones you are mentioning are the types of issues that kept me from designing it with postal address built in - but i need to street it will be EASY to add it later... once things like this are sorted out.
Your concern about the necessity of persons related to postal-addresses is one of mine as well that i would have brought up later. I want a "contact" to also be assigned an address and they won't necessarily be a person in the system... so i agree with Alfred on this one. Having a seperate mapping table, where you map and address_id to a object_id would take care of this - because presumeably all services that would use postal-address would have objects that the address can be linked to. I also don't think it is necessary for a postal-address to even be an acs_object. We won't be needing to do permissions on individual addresses and there is no need (in my view) to clutter up those other systems. A simple unique address id created by a sequence should be enough.
Now, regarding alfreds points
- Fantasitic idea - i modeled mine after "deleted on this date" but yours is better.
- I agree with Jon that HR-XML takes care of htis problem - its a matter of correctly inputting data into the HR-XML standard - and this requires the appropriate fields to be filled out for US costomers - but it also allows people in other countries to satisfy their address requirements. I also based my contacts addresses on HR-XML before i knew postal-address existed as a package and independenly came up to the same conclusion as Jon on this one so i'll say i think its the right one.
- I think it makes more sense to store longitude/latitude with zip codes and reference it that way. or, do you know of reference data that says house number "1234" on street "X Avenue" is at thisxthat degrees? This is primarily a matter of having longitude and latitude data for every house (and we can't expect users to enter it correctly themselves).
- If postal-address is a service then this suggestion should be handled by some other package that references the postal-address service.
- Same point as above
- With the contacts system i am creating this will be possible - though i don't think it should be mandatory throughout openacs, but be something that can be activated via a parameter. Many online services don't care about a persons address.
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?
