[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites

Sat May 3 20:11:54 UTC 2008

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
>