[Data-modeling] [Developers] Addresses!

[Mov GP 0]

2009/4/28 Tom Morris <tfmorris at gmail.com>:
> 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.

Simple. Add an Address Type Field. This can store information like "Street Address" or "Postal Address". An postal address refer to street and location or to a Post office box or something other. 

What I'm currently missing in postal addresses are 
* House Number
* Stairway Number
* Floor Number
* Door Number

>
> 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.

You can't do that, because the center-location of a city is usually not the same then the center-location of a specific house. 

>
> 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
>>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 268 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebase.com/pipermail/data-modeling/attachments/20090428/3e21a074/attachment.pgp