[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 Tom Morris
> Sent: Tuesday, April 28, 2009 12:39 PM
> To: For discussions about MQL,Freebase API and apps built on Freebase
> Cc: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] [Developers] Addresses!
> 
> 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.

I'm proposing a simple pattern to deal with this: the address property on
Location would be used for street address. Any address properties on other
types would be mailing addresses.

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


It would require a lot of client logic (plus a lot more data than we have
now) to allow adminstrative division and country to be programmatically
determined from the city. For one, we'd have to determine which
administrative divisions for which countries are appropriate values for
mailing addresses, and then make sure they were connected to (all!) their
cities and to their countries. We only have the structure of administrative
divisions mapped out for a handful of countries, and even those are not
fully populated. Plus, there's no current logic that autopopulates
properties based on other property values, even if the data were there.
Having the multiple fields may make it take a bit longer to enter an
address, but no longer than any other address form out there.

Jeff

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