We are considering making a change to the way that addresses are handled in Freebase to respond to some concerns with the current model. This would be a major refactoring, in terms of the data affected, and would probably also break most applications that make use of addresses, so it's not something that we're going to undertake lightly, if we undertake it at all. If you are interested, or have written an application that might be affected, please take some time to look over the proposed changes and let us know what you think. The main thing we want to determine is whether users think that the proposed changes are enough of an improvement over the current model to make it worthwhile for them to have to rewrite existing code.

The background: The current "mailing address" type has "location" as an included type, which allows an address to also have a geocode (latitude and longitude), which is a property of the location type. This allows applications to pinpoint addresses on a map. "Mailing address" is a compound-value type, and is used as the expected type on properties such as "address" and "headquarters" on a variety of other types. http://www.freebase.com/view/schema/location/mailing_address http://www.freebase.com/view/schema/location/location

The problems: 1) The mailing address type is linked to from a number of different types (currently 13, but this will surely grow). This means that any application that starts with an address (or geocode) and wants to know what's at that location must use /type/reflect to discover the topic and its type. And a separate query to retrieve all the property names and values for the connected Topic.

2) There are some instances of types that it would be useful to be able to plot on a map, but which are exceptional enough that it doesn't make sense to add the address property to the type. One example of this that has come up is public artworks. It typically doesn't make sense to type them as "location", and adding an address property to the "artwork" type is somewhat counter-intuitive.

The proposed change: Create a new type called "addressed topic" which has a property with an expected type of "mailing address". This type would be an included type on any type that needed an address property. This would make it simpler for applications to be able to say what topic is represented at a given address, since there would only be one link to the type. This type could also be applied to any topic that could have address data, regardless of the other types on that topic.

View this type in my private domain: http://www.freebase.com/view/schema/user/jeff/default_domain/addressed_topic

Please bear in mind that this is only a proposal, and our decision about this change will depend on the responses we get.

Thanks in advance for you comments.