[Data-modeling] Addresses!

[Jeff Prucher]

The issue of addresses came up again while I was on leave, and I'd like to
see if we can resolve it.

The issue(s) the proposed solution tries to address are as follows:
1. The geocode of many topics is buried on the Address CVT, making it
difficult to enter 
2. Many topics are both typed as Location and also have an address, opening
up the possibility of having different geocode values (one on the main
topic, and one on the Address CVT instance.
3. Mailing Address is used in both Is-A and Has-A relationships (e.g., a
company with the mailing address of its headquarters has a location; a
building with a street address is a location), making it difficult if not
impossible to differentiate between the two patterns.

This is the model that I think will work (I've talked it over with a number
of folk in person, and I think it's pretty similar to some of the proposals
made elsewhere):

1. Add an "address" property to the Location type.  Any type that represents
something that Is-A location would have Location as an included type.
2. Address CVT instances will no longer be cotyped as Location. The bot that
currently finds the geocode of addresses will continue to do so, but will
put the geocode on the main topic, rather than on the CVT as it does now.
3. Types that only have a Has-A relationship to location will not be cotyped
as Location, and will continue to have properties for their addresses;
ideally the labels for these addresses would make the relationship clearer:
"mailing address", "headquarters address", etc. The CVT instances of these
addresses will not be typed as locations, and geocodes for the address will
not be stored anywhere.

This is obviously a major refactoring, and would affect a lot of existing
applications, so, assuming we can agree on a model, any refactoring will be
carried out cautiously with as much notfication as possible.

Comments? Thoughts? Did I miss any problems with the current model?

Jeff Prucher