[Developers] Addresses!

[Iain Sproat]

+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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20090428/0e39b856/attachment.htm