[Data-modeling] Astronomy: CelestialObjects andNaturalSatellites
Ed Laurent
spatial.db at gmail.com
Sat May 3 20:31:38 UTC 2008
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/dd6eaab7/attachment-0001.htm
More information about the Data-modeling
mailing list