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

[Danny Hillis]

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