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

[John Giannandrea]

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