[Developers] Addresses!

[Jeff Prucher]

The list of Is-A vs. Has-A types doesn't exist yet, but we might as well
start making one. The types that have an address property of one sort or
another are listed in the "incoming properties" of the Address type:
https://www.freebase.com/type/schema/location/address
 
Of the commons types, I suggest that these are Is-A, and should have
Location as an included type (all the address properties for these are
simply labelled "address":
/architecture/landscape_project 	
/architecture/museum	
/architecture/structure	
/award/hall_of_fame	
/business/business_location	
/business/shopping_center	
/education/educational_institution	
/library/public_library	

/medicine/hospital
 
and these are Has_A, and should not have location as an included type
(address property label is in parens):
/religion/religious_organization  (address)	

/book/newspaper (headquarters)
/business/company (headquarters)	
/medicine/cancer_center (mailing address)	
/organization/organization (headquarters)	
 
There are an additional 42 types in various user domains and bases, but I'd
like to start with the commons types.
 
To answer your second question, the address property on the specific
co-types will go away (at the very least, simply hidden, as suggested by
Brendan).
 
Jeff


  _____  

From: developers-bounces at freebase.com
[mailto:developers-bounces at freebase.com] On Behalf Of Faye Harris
Sent: Tuesday, April 28, 2009 1:41 PM
To: For discussions about MQL,Freebase API and apps built on Freebase
Subject: Re: [Developers] Addresses!


I'm glad we're taking a second look at addresses.

My top concerned is the following:


Types that only have a Has-A relationship to location will not be cotyped

as Location...and geocodes for the address will not be stored anywhere.

  

What's the full list for these types? If something is typed Location and has
a geocode, it's indexed and searchable via /api/service/geosearch. Removing
the Location type and throwing away the geocodes will remove it from the geo
index.

Secondly, if we add "address" to Location, will the more specific cotypes
that currently have an "address" property have it removed? For example:
Business Location, Shopping Center, Structure, etc. 

-- Faye


Jeff Prucher wrote: 

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



  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/developers/attachments/20090429/d3c5d0a6/attachment.htm