[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

[Danny Hillis]

On May 3, 2008, at 7:21 PM, Ed Laurent wrote:

>
> I think it is a good idea to provide separate properties for natural
> and artificial satellites, because people are more likely to be
> querying for one or the other than both.
> But I don't see the benefit of creating all these types (orbit,
> orbited body, natural satellite and artificial satellite) when all of
> their properties could be be put on celestial body. This is especially
> true since every celestial body potentially has these properties
> whether we know them or not. Do you some problem with this solution?
>
> The problem is partly one of QA/QC and efficiency in data entry,  
> modeling, and queries:
>
> Data entry: More types allow more reciprocation which means more  
> data can be entered automatically rather than by hand and there are  
> less opportunities for errors.

>
> Modeling: If you have 2 types with 20 of the same properties and 1  
> that is different, why model so many redundant properties even if  
> they were on such different types as starfish blood and cheetah  
> plasma?
I agree with the statement, but since I am arguing for putting all the  
properties on one type it is hard for me to see how it argues against  
what I am proposing.
>
> Queries: What if you are interested in querying for something that  
> is a common property of 20 types but that property was set to  
> Floating Point Value in all 20 types instead of "Orbital period"?  
> That would mean that you would need to find all the different types  
> with that property regardless of how it was named (e.g., Orbit  
> period, Orbital period, Obital period) and summarize them before you  
> could figure out if a proposed satellite will collide with anything.

This is an important issue, one that comes up a lot. I assume it will  
eventually be addressed by property sharing across types. In the mean  
time, the most successful workaround has been just to try to use  
consistent naming conventions.
>
> Types can also be used as properties instead of just wrappers for  
> properties. In other words, the context of the collection of  
> properties within the type has some additional meaning that would  
> not be present if the properties were not collected within the type.

I think this may be the source of our disagreement. The problem with  
using Types to represent "additional meaning" is that we do not have  
such flexible ways of querying it. The type system was just not  
designed to be used for that,  and it is a very inflexible way to  
represent knowledge. What do we do, for example, with an orbiting body  
when we don't know if it is natural or artificial?  We should be able  
to show what we do know about it without knowing that particular fact.  
The meaning needs to be in the properties, not the type.

-Danny

>