[Data-modeling] architecture schema task DA-841: included types

[brendan]

Glad you brought that up. Seems that I should add to this task:

* mark the address property as hidden and update the documentation  
string for that property to reflect it's deprecated status
* write/run a script that:
- co-types all existing structures/buildings/houses/etc as locations
- migrates/copies the existing mailing_address/location property  
values (that are currently on a separate object/topic) on to the  
structure/location object itself (these include things like  
geolocation and the address components)

"write/run" probably means "ask the data team to write/run".  I could  
do it. But they will find the optimal way to do it.

Brendan


On Jul 7, 2009, at 11:51 AM, Faye Harris wrote:

> +1 on adding /location/location as an included type for all of the  
> types
> listed.
>
> Since "address" is deprecated on Structure (which we've previously
> determined "is-a" location, not "has-a" location), including
> /location/location on the types that include Structure would allow
> address info to be entered. Makes sense to me.
>
> -- Faye
>
>
> brendan wrote:
>> (https://bugs.freebase.com/browse/DA-841)
>> <https://bugs.freebase.com/browse/DA-841%29>.  the
>> /architecture/structure type is the root type for several other
>> architecture types (building, house, skyscraper, tower), meaning  
>> those
>> types have "structure" as an included type. Sometime ago, we agreed
>> that /architecture/structure "is-a" location.  /location/location was
>> added as an included type for "structure".
>>
>> I'd like to add "/location/location" as an included type for the
>> following 4 types:
>>
>> /architecture/building, house, skyscraper, tower
>>
>> (I know we had a discussion about removing the tower type. I've  
>> punted
>> on that since we didn't find consensus , and it's doing no harm)
>>
>> [skip this part if you already understand type inclusion]
>> The included type system is really just a hint for the freebase.com
>> "application".  In particular, when a user adds a new type to a  
>> topic,
>> the list of included types associated with that type will *also* be
>> added to that topic. But the process is not recursive.  So, for
>> example, if I mark a topic as a "house", it will also be marked as a
>> "structure" but the included types for structure (e.g.
>> "/location/location") will not be added to that topic.  This is by
>> design.  I think the basic justification for the design choice is  
>> that
>> it's easier to maintain these things explicitly rather than have
>> complex chains of inclusion that are difficult to keep track of.  At
>> any rate, this inclusion does not happen at the mql layer and my
>> proposed change should not affect any existing users/apps.
>>
>> There are a number of types outside of /architecture that include
>> /architecture/structure.  Arguably, all should include
>> "/location/location".  Frankly, this scenario makes a pretty good  
>> case
>> *for* type inclusion chaining.  Maintaining type inclusion on all the
>> following types (with different admins) seems a little daunting.
>>
>> /theater/theater <http://www.freebase.com/tools/explore2/theater/theater 
>> >
>> /sports/sports_facility
>> /cricket/cricket_stadium
>> <http://www.freebase.com/tools/explore2/cricket/cricket_stadium>
>> /religion/place_of_worship
>> <http://www.freebase.com/tools/explore2/religion/place_of_worship>
>> /olympics/olympic_venue
>> <http://www.freebase.com/tools/explore2/olympics/olympic_venue>
>> /base/fires/fire_station
>> <http://www.freebase.com/tools/explore2/base/fires/fire_station>
>>
>> and a bunch more /base types
>>
>>
>> brendan
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Data-modeling mailing list
>> Data-modeling at freebase.com
>> http://lists.freebase.com/mailman/listinfo/data-modeling
>>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling