[Developers] Addresses!

[Faye Harris]

I'm glad we're taking a second look at addresses.

My top concerned is the following:

    Types that only have a Has-A relationship to location will not be cotyped
    as Location...and geocodes for the address will not be stored anywhere.
      

What's the full list for these types? If something is typed Location and 
has a geocode, it's indexed and searchable via /api/service/geosearch. 
Removing the Location type and throwing away the geocodes will remove it 
from the geo index.

Secondly, if we add "address" to Location, will the more specific 
cotypes that currently have an "address" property have it removed? For 
example: Business Location, Shopping Center, Structure, etc.

-- Faye


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20090428/0141e332/attachment.htm