[Prev][Next][Index][Thread]

Re: (IAAC) Deep sky designations



At 08:25 AM 3/14/98 +0000, you wrote:

>I have followed the debate over what catalogue names should be used with
>much interest especially being a PN enthusiast and I think I have to
>disagree with Jeff on a lot of points. First the PN G designation may be
>used by professionals but as someone else said ( Sue ?) we are not
>competing with them and most if not all material on the list is for
>ourselves and of not interest to them therefore we should use whatever is
>the most popular designations amongst amateurs. 

I think you are missing the point here.... If you are planning to database
observations of planetaries, what is the best catalog to use to key the
observations under? There is absolutely no question in my mind that
Strasbourg-ESO is the one to use. The reasons for this are simple. 

One, it has unique identifiers that cannot be confused with other catalogs
(unlike PK, DDDM, KO, etc). This means it is well suited for use as a
database key.

Two, it contains cross-references to "all known designations of cataloged
planetaries, including citations to its first publication". This means that
the database designer does not need to do any laborious work in making any
given planetary identifiable under all of its previous designations. *ALL*
of them, not just the "most popular" of them. Xref'ing planetaries in this
manner would mean that you can search the IAAC archives on whatever you
consider most popular, whatever some other guy considers most popular, and
whatever some third guy considers most reliable. This is helpful to the
broadest possible range of users.

Three, it is comprehensive to a relatively recent time. This means that new
galactic planetaries discovered since the catalog was finished are not
likely to be observed by a number of amateurs. (Also, since the catalog
uses positional identifiers, we could 'fudge' the issue and make up some
new entries as we go along, if it were necessary for maintaining the
database.) In turn, this means that the database maintainer is unlikely to
need to contemplate the possibility of changing to a new key source at any
time in the near future.

Can you honestly tell me that any of these three things is incorrect?

As far as what Sue does in her article, as I said, I just gave an opinion I
stole from Brian Skiff. I don't care if the opinion is used or not; I'm not
an editor of the solicited publication anyway. (Though, come to think of
it, Skiff is....)

>The Strasbourg-ESO
>catalogue is not in wide circulation ( And yes I do have a copy of the
>paper edition ) and despite Emil using it in Megastar I suspect most people
>still have references which refer to the PK numbers. 

Probably most people do have references to PK in their observing tools.
This is completely irrelevant, for two reasons. First, Skiff's idea (as I
understand it) of using Strasbourg-ESO followed by the priority designator
would result in PK numbers being used for all such planetaries. Second, it
would allow Megastar and SkyMap (etc) users to search for Strasbourg-ESO
numbers without the need of finding a source of cross referencing.

Strasbourg-ESO is in wider circulation than PK is, and it is in much wider
circulation than the DDDM or the KO. It is available free in electronic
format; what more could be asked? Neither the PK, KO, or DDDM is available
that way, as far as I know.

>Emil was rather unlucky
>as a large paper refining the postions of most of the PN's in that
>catalogue above -40 came out just after he printed the CD. there have been
>numerous corrections to the data in that catalogue, 

The paper refining the positions did just that - the positions of the
planetaries in question were already quite good enough to get the objects
in an amateur telescope's FOV, in all but a handful of cases. This
manifestly cannot be said of the PK, which still has improperly positioned
planetaries despite decades worth of corrections applied to it. Since the
PK is an abandoned catalog, we are not likely to see to many more
corrections to it in the future. It can at least be said of the
Strasbourg-ESO that the past corrections to its source catalogs have been
applied, if the catalogs citations itself are to be trusted at all.

>a lot printed in the
>Webb Soc journals ( Plug )and I know Brian at one point did not think too
>highly of the data in the ESO catalogue. 

I can't speak to this. Which data in particular was Brian not impressed with?

>It would also be a shame to lose
>all these interesting names just to get the objects into galactic
>co-ordinates. 

The Strasbourg-ESO catalog contains positions in RA and Dec. It cross
references to all of the interesting names. I still fail to see how using
this catalog for a key is a bad idea; no-one has proposed a better one.
Certainly, amateurs with access to the collection of more obscure catalogs
do not seem to be doing much to make them more widely available (and the
pros have no reason to), which considerably complicates the position of
recommending the use of very old, print catalogs as a key source.

>As for the PGC v Arp debate yes the PGC in some of its
>incarnations is more accurate but if you mention the Arp number at least we
>know what you are talking about rather than having to get a charting
>program out to fire up and find out what other designations the object must
>have. 

I never mentioned Arp vs. PGC. All I said was that a galaxy with an NGC-IC
designation should be referred to as such rather than by its Arp
designation. Doing otherwise is rewarding obscurity for its own sake, and I
suppose if the point is to posture and make one's self look knowledgeable
and fluent in a wide range of catalogs to the uninitiated, then it would be
desirable to do so.... As I recall it, this was one of the failings of the
early DSM's (that and their simultaneous use of Arp Globular designations
without differentiation - very confusing). There are exceedingly few
amateurs who have more familiarity with, or resources that use, the Arp
catalog over the NGC-IC.

Still, if you are a database writer and you key on the PGC, you get many of
the same benefits as keying planetaries on Strasbourg-ESO - extensive
cross-referencing into other well-known catalogs, unique keys to all
galaxies within defined criteria of size and brightness (meaning no musical
keys on the part of the database manager, again), and so on. Perhaps my
initial thoughts to use NGC-IC as keying material was hasty and ill-informed.

>I think we are trying to get too scientific here without good cause.

The good cause is easily explained, Owen. If you are drawing up an internet
collection of deep sky observations, such as the netastrocatalog, you will
eventually reach a volume of data that, in order to be manageable, you will
want to put in a database(s). Since the career from which I am retiring has
a lot to do with the conceptual issues surrounding large or complex
databases, I tend to think about these things from time to time. Here are
some of the conceptual issues:

Common databases of the sort that Lew is likely to use to store all this
data are very likely to require something called a "primary key" or "root
marker" for data integrity and access purposes. This is a unique field that
is used to designate various kinds of entries (what kinds depends on
whether you have a relational, flat field, balloon, bubble cell, or object
database - and maybe even other kinds). Setting that key is one of the
'black arts' of database writing (and though I have experience in the area,
there are database writers who have more knowledge of their specific
platforms that might have better ideas than I do, when it comes to those
platforms).

To decide how to set the key, a number of technical questions need to be
asked (which are dependent on what database is used), and some
user/administrative questions need to be asked. In netastrocatalog's case,
we have to ask what is going to best serve the user of the netastrocatalog,
and what is going to best serve Lew. Well, here are some things that will
help Lew out a lot if he is in the position of placing large numbers of
observations into a database and maintaining them:

1) The key has long-term integrity and stability, so he will not have to do
any nerve-racking key modifications in the foreseeable future.

2) When the key does become obsolete, there is an assurance that the work
which supersedes it will have a cross reference back to the original source
of keys. This will make changing keys much easier and less dangerous to the
dataset, since a lookup table can be used to change the keys.

3) The key comes from a source that is freely available and is already in
electronic format. This way Lew does not have to spend any (more) money to
set up a good key, and does not have to type in manually a large
catalog(s), and does not have to live with an arbitrary, serial key that
has no meaning but takes up space in the database. (This latter is
certainly do-able, but is not very good form.)

And here are some of the things that will help out the user:

1) A good choice of key means that the observations in the database can be
cross-referenced to all other known designations of the object. A user can
search on any past or current designation for any given object, and have a
very good chance of finding it. For example, I am not equipped with the
DDDM in any of my resources. If Sue French happens to add an observation of
DDDM 1 to the log under current practice, it will never do me (or most
amateurs) any good. However, I *am* equipped with a charting program that
uses PN G, so if the database allowed cross-referencing, I could search for
the object by that designation and be assured of finding it. The amateur
who *does* have the DDDM could search for the object as DDDM 1, and *also*
find it. Since the object in question appears in NO COMMON CATALOG, this
feature is very desirable if a useful database is to be developed.

2) Using a reliable source catalog for primary keying allows the database
to add traditional catalog data to an observation that is submitted which
lacks such data (I know we all would like "reliable" to be "perfect", but
that will never happen in real life). That is, when I submit an observation
I rarely if ever include information on the object's RA and Dec, or
magnitude, and so on. The intelligently keyed database can take an
observation without this information, and add it, thus saving the submitter
some typing. (It can also take an observation that includes this
information, and check it for typos, mismatched id vs. description, etc, if
we want to write a fuzzy routine to do so - chalk that up to an advantage
for both Lew and the user, I guess.) This has benefits to the other kind of
user, too - the person who is browsing the database and finds an
interesting observation report on an object they would like to see, will
automatically have in front of them the information that allows them to
find or plot the object on their atlas.

There is at least one thing that helps out both Lew and the user:

1) Good keying is one element of insuring good performance in a database.
Pick a good way to key, and you have picked a fast way to run, to a certain
approximation. So a good key reduces the amount of time needed to perform a
database function, and results in less need for expensive processing and
memory requirements to maintain a given data set. This means smaller bills
for Lew or his bankrollers. It means faster performance for the users.

And, after all this, I can think of one possible drawback to the practice
of keying-up a database in this way:

1) It is likely that this practice has not yet been adopted, which means it
would require a certain amount of initial hard work on the part of Lew and
his volunteers.

And of course the corollary to (1) above would be:

2) Since it is primarily Jeff who is shooting off his mouth about the
long-term health of the database in question, and it is primarily Jeff who
has made some recommendations about how to insure that long term health, it
is probably Jeff who will be asked to volunteer his labor first!

And possibly, judging from reaction thus far, there might also be:

3) A certain number of people who do not understand much about database
structure (or are at least not thinking along those lines) who would rather
not see the database work ever done for whatever reason.

So Lew, you let me know when you are ready to take this bite, ok? I will
help out as much as I can. Also, if I were to draw up some manual
cross-referencing tables for DSO's in html, would you be interested in
mounting those for the time being?



--
Jeff Medkeff          | Acting Assistant Coordinator
Rockland Observatory  | Association of Lunar and Planetary
Sierra Vista, Arizona | Observers, Solar Section

On the web at http://shutter.vet.ohio-state.edu/