[Data-modeling] [Developers] Addresses!

[Tom Morris]

I agree with Brendan that, as painful as it might be to address now,
it'll just be more painful if this is delayed.

One thing that's not clear to me is how you propose handling the
distinction between a street address and a mailing address, since
they're not the same thing.  A company might have a headquarters
building with a street address of 100 Main St., Anytown, USA
(important for getting there for your interview), but have a mailing
address of P.O. Box 5000, Anytown, USA (or perhaps all resumes go to
the HR Dept.'s mailstop which is 100 Main St. - M/S: C2-3/Q56).  A
street address can often be used as a mailing address, but they should
be modeled separately since they have different forms, requirements,
and semantics.

The other thing that I find weird about the current address structure
is that you have to enter city, state, country, when the geo hierarchy
is available to use.  Seems like the various address fields should
either be raw strings (probably not) or be derivable from the
city/town and not have to be re-entered.

Tom

On Tue, Apr 28, 2009 at 2:01 PM, Jeff Prucher <jeff at metaweb.com> wrote:
> 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
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers
>