[Developers] Addresses!

[Brendan Neutra]

+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