Postal Address Attributes

[BJ Freeman]

Like to create a postalcodeAttributes and PostCodeAttrType enitities
these woulld be used with the Address correction.
Like Highrise, Verified, Deliverable, checkshipper

pretty much a catch all to conditions and types of addresses.

any suggestions or approval.

[David E Jones]

On Nov 3, 2007, at 6:10 PM, BJ Freeman wrote:

> Like to create a postalcodeAttributes and PostCodeAttrType enitities
> these woulld be used with the Address correction.
> Like Highrise, Verified, Deliverable, checkshipper
>
> pretty much a catch all to conditions and types of addresses.
>
> any suggestions or approval.

The type/attribute pattern is not meant to be used for anything that  
can be planned for in advance. Also, they should only on top-level  
entities, not those like PostalAddress which is really a type of  
ContactMech (so, ContactMech is the top-level entity and PostalAddress  
is a subsidiary).

In any case the type/attribute pattern is not what you're looking for,  
because it sounds like you know in advance what the data elements are  
(and not at run-time or in some emergency where you can't change the  
database in a reasonable amount of time).

The best way to approach it is to make a list of data elements (with a  
definition for each) that you can't find in the data model and then we  
can discuss entities and fields that already exist that might cover  
them, or make proposals about new fields (or entities if necessary).  
The best way to decide where to put fields, BTW, is to look at the  
cardinality relative to existing entities (for example is there one  
per Party, or one per ContactMech, or maybe not applicable to  
ContactMech but only to the sub-type of PostalAddress, etc).

-David

[BJ Freeman]

three catagories so far, Each of these can be multiple.
Address types: Highrise, Residential, Business,etc these are defined by
USPS in thier address DB.

Status of Address: Verified, Unknown, Linkedvalid, linkinvalid

Address Usablity: Deliverable, Check shipper, Unknown -- these would
depend on a shipper.

There is only one physical address
however someone may move, or it maybe specified in more that one Contact
mech but have a differet ID.

part of the Address verification is to go through on a regular bases and
match different postalAddress and to link the ones that match.

It a maybe is is valid or it may not.

David E Jones sent the following on 11/3/2007 8:05 PM:

> On Nov 3, 2007, at 6:10 PM, BJ Freeman wrote:
>
>> Like to create a postalcodeAttributes and PostCodeAttrType enitities
>> these woulld be used with the Address correction.
>> Like Highrise, Verified, Deliverable, checkshipper
>>
>> pretty much a catch all to conditions and types of addresses.
>>
>> any suggestions or approval.
>
> The type/attribute pattern is not meant to be used for anything that can
> be planned for in advance. Also, they should only on top-level entities,
> not those like PostalAddress which is really a type of ContactMech (so,
> ContactMech is the top-level entity and PostalAddress is a subsidiary).
>
> In any case the type/attribute pattern is not what you're looking for,
> because it sounds like you know in advance what the data elements are
> (and not at run-time or in some emergency where you can't change the
> database in a reasonable amount of time).
>
> The best way to approach it is to make a list of data elements (with a
> definition for each) that you can't find in the data model and then we
> can discuss entities and fields that already exist that might cover
> them, or make proposals about new fields (or entities if necessary). The
> best way to decide where to put fields, BTW, is to look at the
> cardinality relative to existing entities (for example is there one per
> Party, or one per ContactMech, or maybe not applicable to ContactMech
> but only to the sub-type of PostalAddress, etc).
>
> -David
>
>