[Developers] Addresses!

Robert Cook robert at metaweb.com
Tue Apr 28 21:14:45 UTC 2009 

Developing "correct" data models to accommodate extremely rare edge  
cases carry a much higher cost than most of us like to believe.  When  
most people on earth have a colloquial understanding they will be  
confused when presented with something more "correct".  Confusion  
causes bad data -- far more errors than inaccuracies because of  
incorrectly represented edge cases.

R

On Apr 28, 2009, at 12:50 PM, Brendan Neutra wrote:

> If a building is not a location, then I think we are being  
> inconsistent?  We (current standard assertions in freebase.com) say  
> that lakes are locations, cities are locations, mountains are  
> locations. Yet all those things change (at different rates, for  
> sure). If a building moves, then just assert that, now, it IS_A  
> different location. The bottom line is, users who come into edit  
> data in freebase routinely type buildings as locations, because it  
> just seems intuitive. I'm being a little strident here, but I've  
> been waiting for a couple of years for this to be resolved. It seems  
> to me that we're being very semantically strict here (in a domain  
> that I admin and care about).
>
> brendan
>
> ----- Original Message -----
> From: "Iain Sproat" <iainsproat at gmail.com>
> To: "For discussions about MQL, Freebase API and apps built on  
> Freebase" <developers at freebase.com>
> Sent: Tuesday, April 28, 2009 12:25:21 PM GMT -08:00 US/Canada Pacific
> Subject: Re: [Developers] Addresses!
>
> +1 to the proposal.
> Brendan - a building can be moved (see
> http://www.freebase.com/view/en/structure_relocation and
> http://en.wikipedia.org/wiki/Category:Relocated_buildings_and_structures 
>  for
> examples).  It is fairly rare, granted, but I feel that
> /architecture/structure fits better with HAS-A location and/or HAS- 
> A(n)
> address.  This would also fit better with temporary structures.
>
> Iain
>
> On Tue, Apr 28, 2009 at 11:04 PM, Brendan Neutra  
> <brendan at metaweb.com>wrote:
>
>> +1 to addressing this, even if painful.
>>
>> one thing I want to clarify. you said:
>>
>> "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)"
>>
>> I'm not clear on all the use cases but for /architecture/structure  
>> (and
>> /business/business_location):  there is a HAS_A relationship to the  
>> address.
>> These topics are generally not co-typed location, they point to a
>> mailing_address object that is co-typed location. I've always  
>> disliked that.
>> I prefer the assertion this building IS_A location, and as such  
>> HAS_A(n)
>> address (as you propose, yes?)
>>
>> And I think we agree that we should not remove the existing address
>> property link (e.g. /architecture/structure/address) for a grace  
>> period,
>> maybe never; mark the old address prop. as hidden, reflect it's  
>> deprecation
>> in the "doc string" for the property and leave it at that. That way  
>> 3rd
>> party apps (like archiportal) will not break but will just get  
>> stale over
>> time.
>>
>> Brendan
>>
>>
>>
>> ----- Original Message -----
>> From: "Jeff Prucher" <jeff at metaweb.com>
>> To: "Freebase data modeling mailing list" <data- 
>> modeling at freebase.com>
>> Cc: "For discussions about MQL, Freebase API and apps built on  
>> Freebase" <
>> developers at freebase.com>
>> Sent: Tuesday, April 28, 2009 11:01:23 AM GMT -08:00 US/Canada  
>> Pacific
>> Subject: [Developers] Addresses!
>>
>> 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
>> _______________________________________________
>> Developers mailing list
>> Developers at freebase.com
>> http://lists.freebase.com/mailman/listinfo/developers
>>
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers

More information about the Developers mailing list