[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

[Ed Laurent]

> 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?

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.


> 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.


I completely agree. There have been several discussions on crosswalking or
crossreferencing classes that show how difficult classes are to work with.
In fact, I've been trying to think of how to frame a feature request
discussion about giving users a box in each property's list of behaviors
that provides an option for short mjt scripts that define rules for that
property. This would allow class types in particular to be automatically
entered or updated if more quantitative data are available through linked
properties instead of expecting all users to know the exact definitions of
classes and their nuances.

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.

-Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080503/a12b0b47/attachment.htm