[Data-modeling] [Developers] Addresses!

[Jeff Prucher]

> -----Original Message-----
> From: data-modeling-bounces at freebase.com 
> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Mov GP 0
> Sent: Tuesday, April 28, 2009 1:48 PM
> To: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] [Developers] Addresses!
> 
> 
> What I'm currently missing in postal addresses are
> * House Number
> * Stairway Number
> * Floor Number
> * Door Number

You can enter these as part of the (non-unique) street address property.
Having different properties for every conceivable part of an address, for
every place in the world, is probably not possible, and would make the form
extremely cumbersome if we tried.

Jeff

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