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

[Iain Sproat]

+1, great to see this moving forward.

On Tue, Jul 7, 2009 at 10:51 PM, Faye Harris <faye at metaweb.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20090707/7321e825/attachment.htm