Discussions on Astronomy

Seems pretty comprehensive.

you probably would make things easier in the judicious use of enumerated type creation. The one property for meteorite broad category (I was very puzzled by that title...Is that the best and most accurate way to cover the composition of a meteor?). It really should be an enumerated list of topics to choose from (please try to use existing topics only if they will correctly match up with what is intended, there is an existing topic page for "iron meteorite"). A nice simple example is:

Destruction Method

A newer example is the Celebrity type's Sexual Orientation Phase.

In your case the expected type for meteorite broad category could be 'Meteoric Composition' and that in turn would be the enumerated type with the various possible compositions. The user can easily pick out a correct composition from the drop down menu and be prevented from creating by mistake duplicates.

I think that for the specimen location, we'd want something more specific than "Topic" if we can come up with something appropriate.

How does "Former (alternate) designations" differ from the "Also known as" property on /common/topic? That's one way that AKA is often used, already.

Also, I don't know much about comets, but looking at Epoch, Eccentricity, and so forth, I see a lot of floating point numbers. Are these really just numbers with no associated units? Seems unlikely to me. I suspect that you may want some more specific expected type there, though I don't know what.

K.

Good questions. A designation is a formal naming. A comet will typically have one currently recognized designation and sometimes many formal former/alternate designations. It may also be known by a colloquial or plain English name. That's the distinction. The same problem, BTW, will crop up with other Astronomy Types such as a Galaxy that have formal and former/alternate formal designations, in addition to a colloquial "also known as" name. Anyway, I think the distinction is an important because to me a formal designation is more specific than "also known as."

As far as the properties relating to comets go, those were taken from Wikipedia and are no different than the many floating point numbers associated with the Star and Celestial Object Types. If those numbers are good enough for those types, they're good enough for the Comet Type, IMHO, as they represent values folks interested in comets want to know about.

Re floating point numbers, you can make these be specific (in most cases, not having a measurement unit specified makes the data ambiguous) by editing the property and filling in the "Unit of Measurement" fields that are shown there. I'll open up a bug to add units to the existing astronomy types -- they definitely need them!

The advantage of using AKA is that names listed in that property are more likely to bring the topic up in a search, whereas names entered in a simple text field, while semantically more precise, probably won't.

One other thing to note is that the property "comet class" should have an expected type of "comet class", rather than /common/topic. This will allow you to create a reciprocal link on the "comet class" type, so that when someone enters the type on a comet topic, that comet is also automatically listed in the corresponding property on the comet class topic.

I strongly encourage the use of the "Also known as" property for alternative names, rather than creating a new property. 1) The search/autocomplete algorithm indexes the values of "Also known as" so as to allow people to find topics by any known names, whereas your "Former (alternate) designations" will not get the same (special) treatment. 2) Developers against Freebase are aware of querying for the "name" and "also known as" to get the name(s) of topics. Adding yet another property to hold names for an object would make this a special case.

Jeff and Faye, I'll remove my Comet Type property "Former (alternate) designations" after I copy/paste the data into the Also known as property for the individual comets I've linked to this type.

BTW, is there a way to do this from within Freebase? That is, if you're deleting a property that has values, Freebase only asks for confirmation that you want to delete the property. If the property has data in it, could a mechanism also be added to ask the user if they want to transfer the data to another property?

Jeff, as far as the floating point numbers go for the Comet Type, they all have measurement units except for the ones such as Eccentricity that don't have a measurement unit. I've also updated the Epoch property of Comet so it's a Julian year measurement unit.

Jeff, when I try to edit the Expected Type of the Comet class property I'm blocked from doing so and told to remove the existing relationships. At the moment there are 8 of those. If there are a very high number of existing relationships I think this will pose a problem for users. Can this also not be handled within Freebase by allowing a change of Expected Type by asking the user if they want to reestablish the relationship? I will go in and delete those relationships and reestablish them manually, but I believe this kind of block will impact on user willingness to edit Freebase.

There is definitely a need for more comprehensive editing tools -- I run into the problems you're seeing all the time; I can't promise anything anytime soon, but I will forward your suggestions to the relevant people.

Michael, this sounds like a good idea. Does it overlap with Gordon’s suggestions below? Perhaps you two could collaborate on some candidate schema changes and then ask the domain administrators to promote them.

Good idea. Right now, the satellite type is earth-centric. What other properties would we need for a general "orbits-around" type?