Subject: OFSP proposal - SOURCE ID KEYWORDS

From: [email-masked]
Date: Thu, 17 Jun 1993 15:58:58 -0400

Source ID keywords: An OGIP FITS Standards panel (OFSP) proposal

PROBLEM
It is a common occurence that information in a FITS extension or file
refers to a single astronomical object.  In such cases it is necessary to
be able to provide the source identification in the file or extension
header.  

PROPOSAL
The OFSP proposes that source id be coded using the following
header keywords:

KEYWORD		VALUE TYPE	COMMENT
CATIDn		string		entry of source in catalog
CATREFn		string		Name of catalog
NCATREF         i*2 		number of catalog references in header

where a "catalog" can be an astronomical catalog (HD, NGC) or a list which
is specific to a given observation (such as the ROSAT final source list,
which is generated individually for each observation), and "n" is an
integer.  A couple of examples of usage

CATID1  = '153919' / entry of source in catalog
CATREF1 = 'HD'  / Name of catalog

or

CATID1  = '1700-37'/ entry of source in catalog
CATREF1 = '4U' / Name of catalog: 4TH UHURU

or 

CATID1  = '3'/ entry of source in catalog
CATREF1 = 'MPSLX' / Name of catalog: ROSAT MERGED SOURCE LIST

Multiple id's are allowed:

NCATREF =                    3 / number of catalog references
CATID1  = '3'/ entry of source in catalog
CATREF1 = 'MPSLX' / Name of catalog: ROSAT MERGED SOURCE LIST
CATID2  = '153919' / entry of source in catalog
CATREF2 = 'HD'  / Name of catalog
CATID3  = '1700-37'/ entry of source in catalog
CATREF3 = '4U' / Name of catalog: 4TH UHURU

USAGE
 1) The suggested usage is that the prime ID is designated as n=1.  
 2) If CATIDn is used, the CATREFn keyword must also be given in the header
 3) The use of NCATREF is optional but encouraged

COMMENTS
Note that these keywords are meant to augment, not replace, the standard
OBJECT keyword.  An obvious example is a ROSAT PSPC observation at the
North Ecliptic Pole in which a serendipitous source is discovered.  An
extension which contains the spectrum of the serendipitious source would
have the following keywords in its header:

OBJECT  = 'NORTH ECLIPTIC POLE'
CATID1  = '5' / source is 5th in catalog
CATREF1 = 'MPLSX' / name of catalog: ROSAT MERGED SOURCE LIST

REQUEST FOR INPUT
Before adopting the CATIDn, CATREFn keywords, the OFSP would like to have
input from all interested parties on this mail exploder.  Please respond to
this exploder within one week in order that a consensus can be determined.

Cheers,

Mike Corcoran

The OFSP:
Bill Pence, chair
Ian George, Secretary
Lorella Angelini
Mike Corcoran
Rich Fink
Tom McGlynn
Arnold Rots

---

From: "Jonathan McDowell" <[email-masked]>
Date: Thu, 17 Jun 1993 17:32:45 -0400

I think it would be better to have the full catalog
name in the CATID field rather than assume it from
the CATREF. Also I think what you call CATREF should
instead be CATNAM, with an optional CATREF being the reference to the
catalog.
For example:

CATID1 = 'HD 153919'  / Entry of source
CATNAM1= 'HD'   / Standard name of catalog
CATREF1= 'Cannon, A., 1925 Ann. HCO' / Reference to catalog
or
CATID1 = 'Delta 2 Aps'  / Name of source in Bayer system
CATNAM1= 'Bayer'   / Bayer system (Uranometria)
CATID2 = 'HR 6021'  / Name of source in BSC5
CATNAM2 = 'BSC5'  / Bright Star Catalog, 5th edition

This usage would prevent people writing overly simple-minded
readers to just append the CATID to the CATREF, which for
many catalogs does generate a valid object name, but for
equally many does not. 

The only advantage of the way you've done it is to 
allow the catalog entry to be used as an integer index
when it does in fact have integer values (cf your MPSLX
example). I think if you want this functionality it should
be in a separate keyword (CATIDX?) I feel strongly that
it's a bad idea to separate the '4U' from the '1700-37',
there's too much danger someone will think 1700-37 represents
a position rather than just being part of the label '4U 1700-37'
(yes, I know it *is* meant to represent a position, but some of
those 4U names are so way off they dont mean a whole lot). 

 - Jonathan McDowell

---

From: [email-masked] (Lee E. Brotzman)
Date: Thu, 17 Jun 1993 21:11:58 -0400

Upon cursory inspection I think the proposal for standardizing nomenclature of
astronomical objects is both feasible and appropriate.  I would only add at
this time that I think a reference to the A&A Suppl. articles by Fernandez,
Lortet and Spite regarding proper nomenclature formats for objects should be
included.  (I am at home right now and don't have complete references, but I
can provide them if needed.)  

Back in my days as a catalog jock, I found this reference to be invaluable for
determining the source of some of the more, shall I say, "esoteric" names
astronomers provide for objects of interest.

Regarding the proposal for standardizing references to RA,DEC specifications,
my only comment is that, if I were to attempt to apply the rule set in that
proposal to many of the more common astronomical catalogs, I might have a
problem with RADECSYS and EQUINOX.  The reason being that many catalogs have
RA,DEC pairs in both B1950 and J2000.  It may be better to allow a means of
specifying the reference frame and equinox for each RA,DEC pair
independantly.  I realize, however that for your purposes, this may clutter
things up with redundant keywords, since object, pointing, and spacecraft
coordinates would almost certainly all be specified in the same system.
Your intensions are to describe single observations (I presume), not
collections of observations in tabular form, so I don't think that this is a
big deal.  I'd just like to apply whatever standards are accepted by the
community at large to my own work (like the ones set forth for physical units).

-- 
-- Lee E. Brotzman                    Internet:  [email-masked]
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- NASA Goddard Space Flight Center   BITNET:    ZMLEB@GIBBS

---

From: Lucio Chiappetti <[email-masked]>
Date: Fri, 18 Jun 1993 06:39:38 -0400

> this exploder within one week in order that a consensus can be determined.

  So here it is (to HEAFITS only and not to fitsbits, OK ?)

> OBJECT keyword.  An obvious example is a ROSAT PSPC observation at the

  The proposal looks reasonable to me (although I consider it a "third
  rank" issue, i.e. for documentation only and not relevant for data
  processing). In particular I agree with the "COMMENT" above.

  As a further counter-comment to somebody else's comments, I am not at
  all scandalized by the fact you propose to separate e.g. "4U" from
  "1700+37", on the contrary this is in agreement with common jargon,
  where one refers to the object as "1700" or "2155" and willingly
  forgets/drops the catalog name.

---

From: [email-masked] (William Pence)
Date: Mon, 21 Jun 1993 16:45:58 -0400

Jonathan McDowell wrote:

>   ...
>   ...
> I feel strongly that

Personally, I don't see anything wrong with separating the '4U'
from '1700-37' into different keywords.  Can you give some examples
of where appending the CATID to the CATREF does not 'generate
a valid object name'?

I like the suggestion of using CATREF for a bibliographic reference and
using CATNAM for the catalog name (abbreviation) instead.  I think we
considered using CATNAM,  but have forgotten why we suggested CATREF
instead.

-Bill Pence

---

From: "Jonathan McDowell" <[email-masked]>
Date: Mon, 21 Jun 1993 16:52:12 -0400

Well, I had a couple of examples in my post I think. Like
the objects in the Bright Star Catalog are correctly
designated HR rather than BSC. Also, how would
you do the quasar III Zw 2?

What is the point of separating them into two keywords anyway?
 - Jonathan

---

From: [email-masked] (William Pence)
Date: Mon, 21 Jun 1993 18:09:48 -0400

Jonathan McDowell wrote (re. source ID keywords):

> Also, how would you do the quasar III Zw 2?

Well, you've got me on that one.  Would CATNAMn = 'III Zw' and
CATIDn = '2' ??  I don't know.

>What is the point of separating them into two keywords anyway?

This is more of a philisophical issue.  If you have 2 independent
pieces of information such as a catalog name and a catalog number,
isn't it preferable to store them in separate fields/keywords?  This
is a design principle in relation databases which makes it easier
to do queries on the data.