[Developers] Comments sought on proposed change to schema for addresses

[Jeff Prucher]

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.


Jeff Prucher
Typelibrarian and Ontologist
Metaweb