[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

Sun May 4 01:04:30 UTC 2008

On May 3, 2008, at 1:31 PM, Ed Laurent wrote:
>
>  Take a look at how I am starting to model Natural and Artificial  
> satellites. Earth is a good example. I typed it as a Natural  
> satellite which has a single property so far set as Orbited body  
> (for lack of a better name) and is co-typed with Orbit. Orbited body  
> is reciprocated. I did the same for Artificial satellite to keep  
> them separate in the reciprocation but keep all the properties that  
> are associated with any satellite (e.g., orbital characteristics) on  
> a single type.
>
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?

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.

> 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.
But these properties are not really connected the fact that the  
satellite is an Earth Orbiting Satellite. Many Earth Earth Orbiting  
Satellites do not have them, and satellites in synchronous orbit  
around other planets do have them.
-danny
>
>
>
> 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
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling