[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

Sat May 3 21:51:40 UTC 2008

I thought I should mention that the approach I describe below was learned
from Jeff and Faye during our interaction in the Publishing
Domain<http://www.freebase.com/view/book>among others. It took me
awhile to wrap my head around it but I've found it
to be a very powerful style of data modeling. Schema that describe nested
hierarchies like Organism
classification<http://www.freebase.com/view/biology/organism_classification>were
also very influential.

Other examples of natural satellites that can have discrete times when their
orbits change include comets and asteroids affected the "sudden" proximity
of a gravity well. Apophis
<http://www.freebase.com/view/en/99942_apophis>springs to mind.

-Ed

On Sat, May 3, 2008 at 4:31 PM, Ed Laurent <spatial.db at gmail.com> wrote:

> I don't think the name "Type" has much to do with it. Baseball and
> Basketball player aren't bad names if they contain properties that are
> universal to all baseball or basketball players and no one else. I would
> personally create a more generic "Professional sports player" type co-typed
> with "Team member" and the "Baseball player" type. It's properties like
> "Current team" on a very specific type (i.e., Baseball player) that tend to
> cause these conflicts.
>
> Take a look at how I am starting to model Natural and Artificial
> satellites. Earth<http://www.freebase.com/view/guid/9202a8c04000641f80000000000140e1>is a good example. I typed it as a Natural
> satellite<http://www.freebase.com/tools/schema/user/spatialed/artificial_satellite/natural_satellite>which has a single property so far set as Orbited
> body<http://www.freebase.com/tools/schema/user/spatialed/artificial_satellite/orbited_body>(for lack of a better name) and is co-typed with
> Orbit<http://www.freebase.com/tools/schema/user/spatialed/artificial_satellite/orbit>.
> Orbited body is reciprocated. I did the same for Artificial satellite<http://www.freebase.com/tools/schema/user/spatialed/artificial_satellite/artificial_satellite>to keep them separate in the reciprocation but keep all the properties that
> are associated with any satellite (e.g., orbital characteristics<http://www.freebase.com/tools/schema/user/spatialed/artificial_satellite/orbit>)
> on a single type.
>
> Earth orbiting satellites will get their own special properties like
> latitude or local time crossing the equator and that will be dependent on a
> co-type that will probably be dependent on their type of orbit. I haven't
> gotten to that point yet.
>
> I've encountered one major problem so far. The orbits of both natural and
> artificial satellite's change over time. Think of Mir<http://www.freebase.com/view/en/mir>and
> Phobos<http://www.freebase.com/view/guid/9202a8c04000641f80000000000672d0>.
> That means that orbit should be a CVT so multiple instances could be added.
> However, the units of time used to describe changes in natural vs.
> artificial satellite orbits are orders of magnitude different and have much
> different precisions (e.g., 23 Mar 2001 vs. 3 Billion years ago). Units of
> time therefore cannot be pre-defined... and since there is no way to nest
> CVTs, there is no way to track changes in orbits for a generic satellite.
> That is more a limitation with the system than with data modeling.
>
> Maybe this approach is not the 'best' but it seems to be the most
> parsimonious and flexible that I've seen so far. The models are not
> difficult to use either but are difficult to build because they need to
> consider the generality of every property of every type.
>
> -Ed
>
>
>
> On Sat, May 3, 2008 at 4:11 PM, Danny Hillis <danny at appliedminds.com>
> wrote:
>
> > Jeff,
> > Yes, I agree that the word "type" is confusing, and in this particular
> > case there are also other issues.
> >
> > The Type/Class issue. Since type mean a collection of properties we
> > should problem use  the term "Classification", "Class", "Category" or
> > "Genre" for named classes . This would suggest that the property name
> > should be "Orbit Classification" or "Orbit Class" instead of "Orbit
> > Type".  A deeper version of this issue, which you point out,  is that
> > we have no good way to tie a class to a type, hence the demoralization
> > of professions.
> >
> > The Natural Satellite issue. A second issue is that we started out our
> > orbit properties on a more specific type that was appropriate, sInce
> > orbits don't really care if the bodies are natural or artificial, and
> > since they are recursive (Ranger9 orbits moon orbits earth orbits
> > sun...) That one can be fixed by moving them to Celestial Body.
> >
> > The Conditional Property issue. A third issue is that a few useful
> > properties (like longitude) only make sense for a artificial
> > satellites in geosynchronous orbit. We could put those properties on a
> > separate type (like Communications Satellite) or we could just make
> > just a property that is not always filled in. In such cases, where a
> > property does not always apply (see for example Government Position
> > Held), we have sometimes used the covention putting parenthetical in
> > the property name, explaining when the property makes sense, like
> > "Longitude (if orbit is geosynchronous)". I have alway thought this as
> > a temporary crutch until we can explain rules like this the UI, but I
> > am beginning to think wonder if we should just make another co-type in
> > these cases.
> >
> > -Danny
> >
> > On May 3, 2008, at 11:33 AM, Jeff Thompson wrote:
> >
> > > Perhaps this is confusion caused because Freebase is designed to
> > > let you attach a set of properties to a topic, and the properties
> > > are supposed to contain the information about the topic.  But
> > > (unfortunately?) the set of properties is called a "Type", so people
> > > naturally assume that they should use the name of the "Type" as
> > > they do in common language so that the name itself conveys the
> > > information, not the properties.
> > > Thus we have the types
> > > http://www.freebase.com/view/basketball/basketball_player
> > > and
> > > http://www.freebase.com/view/baseball/baseball_player
> > > where it is not a property but the name of the type which conveys
> > > the meaning of what sport is played.  If "Type" had been called
> > > "a collection of the properties which actually convey the
> > > information" this
> > > would not have happened.
> > >
> > > I think the same is happening in this case.  I like the fact
> > > that you have moved the distinction between a natural and
> > > artificial satellite from the type name to a property called
> > > "Orbit type".  This way a query does not need to examine
> > > the type name and guess its meaning.  It has to guess because
> > > in Freebase we are not allowed to annotate a type with more
> > > information
> > > needed to say how the name of the type distinguishes it from another.
> > > But the "Orbit type" property points to a topic which can be
> > > filled out with properties as needed so that the information is
> > > in the properties, not obscurely hidden in a type name.
> > >
> > > Danny, I've heard Roberts opinions on this, but I'm interested in
> > > what you think about "tagging" a topic with a type where the
> > > (unannotated) type name represents the knowledge.
> > > - Jeff
> > >
> > > Danny Hillis wrote:
> > > > Going back to Gordon's original question, the proposal below would
> > > > imply that we replace the Moon(s) property with an Orbiting bodies
> > > > property of type Celestial Body.
> > > > -Danny
> > > >
> > > > On May 3, 2008, at 10:43 AM, Danny Hillis wrote:
> > > >
> > > >> My concern is in adding too many types . Since all Celestial
> > > Objects
> > > >> have  orbits, why don't we just put the orbit properties on those,
> > > >> including "Orbit type"  and a property for "Orbits around" which
> > > >> reciprocates as "Orbiting bodies". Artificial Satellite (which we
> > > >> could just call Satellite) could include both celestial body and
> > > >> Spacecraft. his would work for the Mars Reconnaissance Orbiter, and
> > > >> satellites orbiting satellites, like Ranger-9. The Satellite schema
> > > >> would have the other properties that currently on Earth Orbiting
> > > >> Satellite, plus the few extra properties that are useful for
> > > >> geosynchronous satellites, for example "Longitude (if
> > > synchronous)".
> > > >> If get's to be too many, we could factor out Observation
> > > Satellite as
> > > >> separate type.
> > > >> -Danny
> > > >>
> > > >>
> > > >> On May 2, 2008, at 8:39 PM, Ed Laurent wrote:
> > > >>
> > > >>> What about the Mars Reconnaissance Orbiter and other artificial
> > > >>> satellites that orbit things besides Earth? I was thinking of
> > > >>> Satellite as a very simple and generic type that could include an
> > > >>> "Orbiting body" property, reciprocated with "Satellite(s)".
> > > Maybe it
> > > >>> would have a couple other properties too? Many of the "Earth
> > > >>> orbiting satellite" properties should probably be split into
> > > >>> "Geostationary", "Sun-synchronous" and other orbiting types so
> > > that
> > > >>> their orbits can be properly described.  Some of these types might
> > > >>> be appropriate for any satellite. An "Artificial satellite" type
> > > >>> might have a few more properties but would certainly be co-typed
> > > >>> with "Spacecraft". Specialty artificial satellite types could then
> > > >>> be co-typed depending on whether the satellite was used for
> > > >>> observation or other purposes.
> > > >>>
> > > >>> Co-typing, naming, and descriptions would be key so that users
> > > don't
> > > >>> get lost in these minutia when they're just trying to add some
> > > basic
> > > >>> data to Io vs. Hubble vs. Landsat 7 vs. ....
> > > >>>
> > > >>> Too complex?
> > > >>>
> > > >>> -Ed
> > > >>>
> > > >>> On Fri, May 2, 2008 at 10:35 PM, Danny Hillis
> > > >>> <danny at appliedminds.com> wrote:
> > > >>> I like what you suggest about moving Discoverer,etc.
> > > >>>
> > > >>> One issue that we should consider is that almost any celestial
> > > >> object
> > > >>> is orbiting around something, even is it is the black hole at the
> > > >>> center of the galaxy. Maybe the idea of "orbit" is more useful for
> > > >>> this than making the type Satellite too generic. We could keep
> > > >>> Satellite as meaning as earth-orbiting artificial satellite and
> > > give
> > > >>> all celestial bodies an orbit and (as you suggest) a set of
> > > orbiting
> > > >>> bodies.
> > > >>> -Danny
> > > >>>
> > > >>>
> > > >>> On May 2, 2008, at 6:10 PM, Gordon Mackenzie wrote:
> > > >>>
> > > >>>> Metapsyche and I did some work a while back to add more useful
> > > >>>> properties for his exoplanet type and I am considering moving
> > > most
> > > >>> of
> > > >>>> those properties to Celestial Object and adding planet as a co-
> > > >> type.
> > > >>>> Celestial Object is our workhorse of a generic Astronomical
> > > Object
> > > >>>> type that is included by Star, Planet, Natural Satellite,
> > > >> Asteroid,
> > > >>>> Comet types. I'm unsure what specifically to retain within
> > > >>> exoplanet,
> > > >>>> pretty much most of the non-celestial object bound properties
> > > >>> could be
> > > >>>> placed within the Planet type. Exoplanet could be just a boolean
> > > >>> true/
> > > >>>> false for is this planet an exoplanet for that matter.
> > > >>>>
> > > >>>> So Celestial Object would have added specifically:
> > > >>>>
> > > >>>> Discoverer, Discovery Date, Discovery Method, Discovery status,
> > > >>>> Discovery Institution/organization
> > > >>>>
> > > >>>> And then remove/move the data for the related discovery
> > > properties
> > > >>> in
> > > >>>> Planet/Asteroid/Comet  types to the equivalents in Celestial
> > > Body.
> > > >>>> Planet type might have both jupiter and earth-based radius and
> > > >> mass
> > > >>>> properties.
> > > >>>>
> > > >>>> One question I have is whether Natural Satellites should be
> > > >>>> individually added as a property to Planet and Asteroid types or
> > > >> to
> > > >>>> add as a single property to just Celestial Object. The latter is
> > > >>>> simpler, but the former allows cleaner demarcation of moons of
> > > >>>> planetary bodies and asteroidal moons.
> > > >>>>
> > > >>>> ~ Gordon
> > > >>>>
> > > >>>> <<< gordon at metaweb.com >>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> Data-modeling mailing list
> > > >>>> Data-modeling at freebase.com
> > > >>>> http://lists.freebase.com/mailman/listinfo/data-modeling
> > > >>> _______________________________________________
> > > >>> Data-modeling mailing list
> > > >>> Data-modeling at freebase.com
> > > >>> http://lists.freebase.com/mailman/listinfo/data-modeling
> > > >>>
> > > >>> _______________________________________________
> > > >>> Data-modeling mailing list
> > > >>> Data-modeling at freebase.com
> > > >>> http://lists.freebase.com/mailman/listinfo/data-modeling
> > > >> _______________________________________________
> > > >> Data-modeling mailing list
> > > >> Data-modeling at freebase.com
> > > >> http://lists.freebase.com/mailman/listinfo/data-modeling
> > > >
> > > > _______________________________________________
> > > > Data-modeling mailing list
> > > > Data-modeling at freebase.com
> > > > http://lists.freebase.com/mailman/listinfo/data-modeling
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Data-modeling mailing list
> > > Data-modeling at freebase.com
> > > http://lists.freebase.com/mailman/listinfo/data-modeling
> > >
> >
> > _______________________________________________
> > Data-modeling mailing list
> > Data-modeling at freebase.com
> > http://lists.freebase.com/mailman/listinfo/data-modeling
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080503/64e76f67/attachment-0001.htm 