[Data-modeling] Types (was Astronomy: CelestialObjects...)

[Ed Laurent]

If a type has no User Created Properties but does have two or more co-types
with Included Properties, does that tag provide information? It certainly
provides utility. A type that only includes a single co-type and no
properties may not provide either.

-Ed

On Wed, May 7, 2008 at 1:00 PM, Danny Hillis <danny at appliedminds.com> wrote:

> JG,
> I think the question here is not whether a type defines a set, but
> under what circumstance is to best use that mechanism to encode
> knowledge, rather than the property mechanism. Jeff's example shows
> how encoding it in properties makes a query easier.
>
> For example, some of the specific cases being discussed were proposed
> types which had no expected properties. There seem to be two schools
> of thought on whether it is better to represent these classification
> tags as types or properties.
> -Danny
>
> On May 5, 2008, at 11:49 PM, John Giannandrea wrote:
>
> >
> > Danny wrote:BTW, I think this point is connected to Jeff's comment
> > about Types.
> >>
> >> Types don't really mean anything except to the degree that they are
> >> different collection of properties. We should not try use Types to
> >> create classes.
> >
> > At the risk of prolonging the thread....
> >
> > Types are more than just collections of properties.  There is a
> > property (/type/object/type) which asserts that a specific object is
> > an instance one or more types.  Everything is an object, and some
> > things have the additional assertions that their /type/object/type
> > is /
> > common/topic or /baseball/baseball_player.  Making this assertion is
> > saying something, that this object is in that set, that it has the
> > semantic meaning of membership in that set.   Some systems call this
> > 'kinds' or 'classes'.   The property is not unique, you can have an
> > object that is in many sets at once, such as /people/person and /
> > baseball/baseball_player.
> >
> > Further, a type itself (not the instance of the type) specifies a set
> > of properties.  The expectation is that things "of that type" might
> > have one or more assertions which are instances of those properties.
> > It seems useful to group them in this way because one can query the
> > type schema to find out what kinds of things might be available to
> > query and constrain on, such as date_of_birth.  In fact several apps
> > that third parties have written do exactly that introspection.
> >
> > The type system is not normative.  You do not need to be a /people/
> > person to use one of the person properties.  But if we know that the
> > object is a person, that fact is recorded and now you can at least
> > expect that date_of_birth could be interesting for that class of
> > objects.
> >
> > Jeff wrote:
> >>
> >> This means that you cannot do even a simple query like
> >> "people born in Baltimore before 1900 and the sport they play".
> >
> >
> > We certainly could have a property called /people/person/
> > sports_played.   Or you could dispense with types altogether and just
> > have /common/topic/sports_played (which would presumably never be
> > asserted on a building object).    This would be very much more RDF
> > like.  But it doesnt really solve the problem I think because if we
> > only had /common/topic/baseball_team_played_for that still doesnt
> > automatically assert the sport they played.
> >
> > Knowing that baseball players have teams or that people have
> > dates_of_birth is much more "object" like and allows programmers to
> > approach the system without knowing there is a graph underneath.
> > Almost all computer programming languages have a type system, with or
> > without polymorphism.  It seems useful to be able to model and query
> > data with that in mind.
> >
> > Its also entirely possible to group the types and create an ontology
> > overlay that knows that baseball is a kind of sport and that a
> > baseball player is an agent in that game, that teams have N players
> > and so on.  It seems that we know that Babe Ruth is a baseball player,
> > but not that baseball players play baseball.  We do have some early
> > examples of this kind of meta structure, for example /freebase/
> > type_profile/equivalent_topic.  Id be happy to see experiments with
> > more, bearing in mind that we explicitly eschewed building a reasoner.
> >
> > -jg
> >
> > _______________________________________________
> > 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/20080507/454c4256/attachment-0001.htm