[Developers] Addresses!

[Jeff Prucher]

> -----Original Message-----
> From: developers-bounces at freebase.com 
> [mailto:developers-bounces at freebase.com] On Behalf Of Brendan Neutra
> Sent: Tuesday, April 28, 2009 12:04 PM
> To: For discussions about MQL,Freebase API and apps built on Freebase
> Subject: Re: [Developers] Addresses!
> 
> +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?)

Yes, that's what I was trying to say. Some types, including structures,
would be typed as locations, and they could also have an address if it was
appropriate.

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

Right. The exact procedure for implementation will have to be worked out
(once we've agreed on the revised schema), but we would definitely want to
give adequate notification to app builders that the model was changing, and
hiding the old properties for (at minimum) a grace period should be part of
that.

Jeff