[Developers] Addresses!

[Brendan Neutra]

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