[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

[Ed Laurent]

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


I was proposing that the the 20 properties go on one type and the other
property go on another type instead of having two types with 20 of the same
properties.



> > 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.
>
>
I understand what you are saying. However, it seems that a well designed set
of types should handle that. If it is expected that there would be even a
single important instance of a unknown origin satellite, then a property of
that name (i.e., "Unknown origin satellite") could be added to orbited body
and reciprocated with a clone of one of the other satellite types, differing
only in name. The orbit co-type on this clone allows all this unknown's
orbit properties to be queried with the other satellites but its link to a
different property on the orbited body type allows it to be queried as a
separate entity. It is still linked to the orbited body, however, so it can
be queried with all the other things that have orbits and are linked to the
orbited body. Properties are lumpers, types are splitters.

I just got your other email. I'll start working on synchronous and
asynchronous as the next set of co-types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080504/5910f77c/attachment.htm