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

[Sarah Milstein]

Hey, any reason you or I shouldn't post this on the blog, too?

S

Jeff Prucher wrote:
> 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
>
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers
>   

-- 
Sarah Milstein
Community Manager
Metaweb Technologies, Inc.
sarah at metaweb.com