From heafits@legacy.gsfc.nasa.gov Wed Jun 2 21:23:59 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6051" "Wed" "2" "June" "1993" "21:21:13" "-0400" "Don Wells" "dwells@fits.CV.NRAO.EDU " nil "116" "RESULT: WFC endorses BINTABLE/IMAGE/Blocking" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA07712; Wed, 2 Jun 93 21:23:48 EDT Received: by inet-gw-2.pa.dec.com; id AA27048; Wed, 2 Jun 93 18:23:03 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA14195; Wed, 2 Jun 1993 21:21:13 -0400 Message-Id: <9306030123.AA07709@fits.cv.nrao.edu> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: dwells@fits.CV.NRAO.EDU (Don Wells) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: RESULT: WFC endorses BINTABLE/IMAGE/Blocking Date: Wed, 2 Jun 1993 21:21:13 -0400 -=- WFC has approved the BINTABLE/IMAGE/Blocking proposals -=- Don Wells (WFC Chair) June 1, 1993 The WFC [WGAS FITS Committee] has voted unanimously, 20-0, to approve the BINTABLE, IMAGE and Blocking proposals which are currently being considered by the regional FITS committees for adoption as additions to the FITS standards. The WFC is the regional FITS committee for North America. WGAS is the Working Group for Astronomical Software of the American Astronomical Society. The voting membership of the WFC is representative of North American observational astronomy, both ground-based and space-based, at all observed frequencies. These three proposals were approved by the European FITS Committee [EFC] in April 1992, and the EFC reaffirmed their approval at their annual meeting in Garching in April 1993. The Japanese FITS Committee will vote on the proposals in the near future. If, as expected, they also approve them, the proposals will be considered by the IAU [International Astronomical Union] FITS Working Group, which controls the FITS standards. The Chairs of the FITS committees hope, and expect, that it will be possible to obtain IAU final approval of these proposals in time to have a FITS resolution passed by the General Assembly of the IAU at its triennial meeting at the Hague in August 1994. -=- Anonymous-FTP Information -=- Drafts of the three proposals are available at fits.cv.nrao.edu [192.33.115.8] in directory /fits/documents/proposals/ as the files 145877 May 18 16:29 bintable2.ps 38591 May 18 16:27 bintable2.tex 2183 Oct 1 1991 blocking90.txt 94980 Jun 4 1992 image.ps 12973 Mar 12 1992 image.tex Information about the current FITS standards is in the directory /fits/documents/standards/ as the files 7895 Oct 26 1992 fp89.txt 431252 Dec 29 1991 standard.ps 8325 Dec 29 1991 standard_read.ME 2710 Jan 24 1992 xtension.txt -=- The BINTABLE extension proposal -=- The 1979 Basic FITS Agreement specified an architecture for encoding an n-dimensional matrix with a self-documenting syntax. The 1979 design allowed for the possibility that arbitrary object types might be appended to the matrix. The FITS community has traditionally called such appended objects "extensions". The 1984 Generalized Extensions Agreement specified a set of meta-rules for the syntax of approved extension types. The first extension conforming to the Agreement was type TABLE, a self-describing syntax for tables in ASCII form which was also negotiated in 1984. The BINTABLE (BINary TABLE) extension is very similar to TABLE, but the data are encoded in binary rather than ASCII. In addition to the obvious advantages of compactness and processing efficiency, BINTABLE has a special superiority over TABLE: fields in the table are allowed to be *vectors*, not just scalars. This rule enables BINTABLE to encode sets of n-dimensional data matricies in the table. In fact, arrays of arbitrary *structures* can be encoded in BINTABLE, and can thereby gain the advantage of portability in a self-documenting form. The requirement to append extensions to the primary FITS matrix is not really a limitation on the use of TABLE and BINTABLE (and other extensions), because the rules of Basic FITS permit the primary matrix to have dimensionality zero. The prototype for BINTABLE was the experimental extension A3DTABLE, which was developed by Bill Cotton for the VLBA [Very Long Baseline Array] project in the mid-80s. The VLBA and the VLA [Very Large Array] had several years of production experience with A3DTABLE in the 80s. In the late 80s features were added, the wording of the draft document was refined, and the FITS committees agreed to use the name BINTABLE for this extension. Interoperability trials occurred circa 1989. More recently BINTABLE was selected as the interchange format for photon event data in the high energy astrophysics community. The committee votes on BINTABLE are acknowledging that BINTABLE is the de facto interchange and archive standard for a number of critical applications in astronomy. The FITS Committees consider the basic BINTABLE architecture to be the foundation for a variety of conventions to be negotiated in the future. For example, in 1991 Doug Tody and Bill Cotton proposed a simple trick that enables BINTABLE to encode variable length data structures in a backward compatible fashion (see Appendix A of the bintable2 document mentioned above for the details). More recently there has been extensive discussion of proposed conventions for encoding matricies in fields (Appendix B) and for arrays of character strings (Appendix C). All of these conventions will be layered on top of BINTABLE. Discussions of these ideas during the past three years has led to significant improvements in the BINTABLE draft. The committee votes on BINTABLE are acknowledging that BINTABLE now appears to be strong enough and flexible enough to support the layered conventions that astronomy will surely need in the future. -=- The IMAGE extension proposal -=- The IMAGE extension also conforms to the Generalized Extensions Agreement. It encodes an n-dimensional matrix. This extension is not intended to supercede the matrix capability of Basic FITS, but rather to augment it. IMACE enables datasystems to append things like PSFs and validity masks to matricies, thereby keeping the related objects together in one file. IMAGE was proposed by designers associated with the IUE [International Ultraviolet Explorer] satellite. -=- The proposed Blocking convention -=- FITS was described as a "tape" format in the original FITS papers, but it was redefined as a bitstream format in the 1984 Generalized Extensions Agreement. Blocking conventions must be negotiated for each new type of medium which may be used to convey FITS bitstreams in interchange. The 1990 Blocking proposal codifies de facto blocking conventions which have been in widespread use in the FITS community in recent years. From heafits@legacy.gsfc.nasa.gov Thu Jun 17 15:48:00 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03469; Thu, 17 Jun 93 15:47:58 EDT Received: by inet-gw-2.pa.dec.com; id AA21753; Thu, 17 Jun 93 12:47:00 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA18648; Thu, 17 Jun 1993 15:45:11 -0400 Message-Id: <930617154043.20e000bd@ROSGIP.GSFC.NASA.GOV> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: GEORGE@ROSGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: OFSP Proposal for standard RA & dec keywords: Note of a FITSBITS post Date: Thu, 17 Jun 1993 15:45:11 -0400 ------------------------------------------------------- | PROPOSED STANDARD KEYWORDS FOR THE SPECIFICATION | | OF RA & DEC WITHIN FITS FILES | ------------------------------------------------------- The 1st meeting of the newly-formed of the OGIP FITS Standards Panel (OFSP) at NASA/GSFC was held on 1993 Jun 16. During this meeting the panel reviewed the various keywords currently used to describe the RA,dec within FITS files. It was found that the current scheme to be rather confusing, in some cases ambiguous, and insufficient to meet all the needs of the OGIP. After a review of many possible options, the OFSP has therefore recommended the adoption & use of a (new) set of standard keywords for this purpose. Since this is an issue likely to be of interest to the general FITS community, the OFSP felt the best forum for discussion of such a proposal is the FITSBITS exploder, and thus the proposal was posted there (today). Since some HEAFITS recipients may still not be members of the FITSBITS (details below), a copy of the proposal is appended below. However it is **STRESSED** that all discussion should take place on FITSBITS. To subscribe to FITSBITS - the international forum for general FITS format and standards issues: send a mail message to: fitsbits-request@fits.cv.nrao.edu In the body of the message, simply ask to be added to the fitsbits mail exploder. It should be noted that copies of future OFSP proposals which have been sent to FITBITS are extremely unlikely to also be posted on HEAFITS. For your information, the current membership OFSP is Bill Pence (chair) Mike Corcoran (ROSAT) Richard Fink (ASCA) Ian George (HEASARC) Tom McGlynn (GRO) Arnold Rots (XTE) Lorella Angelini (HEASARC) ----------------------- Start of included message --------------------------- ----------------------- (as exploded on FITSBITS) --------------------------- ------------------------------------------------------- | PROPOSED STANDARD KEYWORDS FOR THE SPECIFICATION | | OF RA & DEC WITHIN FITS FILES | ------------------------------------------------------- Version: 1993 June 17 At a meeting on 1993 Jun 16 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of the various keywords currently used to describe the RA,dec within FITS files. The OFSP found the current scheme (at least as often used within the High-Energy community) to be rather confusing, in some cases ambiguous, and insufficient to meet all the needs of the OGIP. After a review of many possible options, the OFSP therefore proposes & recommends the adoption & use of the (new) keywords listed below. Since this is an issue likely to be of interest to the general FITS community, the OFSP would welcome any comments (via FITSBITS) on this proposal. It should be noted that this proposal is restricted to FITS extensions containing data from a single 'pointing' (ie EXCLUDES extensions containing datasets from instruments capable of simultaneously observing in more than one direction, and from scanning experiments). Furthermore due to the pressures imposed by currently flying missions (ASCA, CGRO & ROSAT) there is an extremely urgent need for a convention for these keywords within the OGIP (& High-Energy community in general). The OFSP therefore plans to meet again in a couple of weeks to make its final recommendations. Thus FITBITS subscribers are urged to response with any comments etc on this timescale. THE PROPOSAL ************ 1) Reference Frame keywords --------------------------- The OFSP recommends both the following keywords are mandatory if one or more pairs of keywords specifying RA & dec (as defined in 2) are given. RADECSYS - a string denoting the stellar reference frame in use e.g. values: 'FK4','FK5' etc EQUINOX - a real giving the date of the equinox in decimal years (AD) e.g. values 2000.0, 1950.0 etc 2) The RA & dec coordinates --------------------------- In all cases listed below, the values of keywords are reals expressed in decimal DEGREES. Obviously only those keyword pairs considered necessary need be specified. However, the values of ALL such keyword pairs MUST be given in the same reference frame as specified by the values of the RADECSYS & EQUINOX keywords (see 1). a) The Positions of astronomical objects/sources The OFSP recommends the position of a source is given using the keywords: RA_OBJ DEC_OBJ b) The Pointing Direction of the Instrument. The OFSP recommends the pointing direction of the instrument is given using the keywords: RA_PNT DEC_PNT where, - in the case of imaging instruments, the values of these keywords give the direction of the optical axis of the instrument (after all borsighting corrections etc have been applied). - in the case of non-imaging instrumentation, the values of these keywords give the direction of some other (instrument-specific) vector. It is anticipated that in most cases this will be the direction of maximum instrument sensitivity. For instruments with <100% stable pointing accuracy, the above pair of keywords should be the mean values during the observation. c) The orientation of the Spacecraft The OFSP recommends the orientation of the spacecraft (or telescope platform) is given by the specification of any/all of the following keyword pairs: RA_SCX DEC_SCX RA_SCY DEC_SCY RA_SCZ DEC_SCZ giving the orientation of the spacecraft X-, Y- & Z-axes respectively. For instruments with <100% stable pointing accuracy, the above pairs of keywords should be the mean values during the observation. ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Jun 17 From heafits@legacy.gsfc.nasa.gov Thu Jun 17 16:01:31 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2537" "Thu" "17" "June" "1993" "15:58:58" "-0400" "CORCORAN@ndadsb.gsfc.nasa.gov" "CORCORAN@ndadsb.gsfc.nasa.gov" nil "82" "OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03505; Thu, 17 Jun 93 16:01:30 EDT Received: by inet-gw-2.pa.dec.com; id AA22694; Thu, 17 Jun 93 13:00:48 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA19486; Thu, 17 Jun 1993 15:58:58 -0400 Message-Id: <930617160106.22c00259@ndadsb.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: CORCORAN@ndadsb.gsfc.nasa.gov Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: OFSP proposal - SOURCE ID KEYWORDS 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 heafits@legacy.gsfc.nasa.gov Thu Jun 17 17:35:19 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03610; Thu, 17 Jun 93 17:35:17 EDT Received: by inet-gw-2.pa.dec.com; id AA27003; Thu, 17 Jun 93 14:34:35 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA20755; Thu, 17 Jun 1993 17:32:45 -0400 Message-Id: <9306172134.AA12448@urania.harvard.edu> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Jonathan McDowell" Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS 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 heafits@legacy.gsfc.nasa.gov Thu Jun 17 18:06:39 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] [nil nil nil nil nil nil nil nil nil nil nil nil "^From:" nil nil nil]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA03688; Thu, 17 Jun 93 18:06:37 EDT Received: by inet-gw-2.pa.dec.com; id AA28352; Thu, 17 Jun 93 15:05:54 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA21278; Thu, 17 Jun 1993 18:04:04 -0400 Message-Id: <930617174842.20a00204@HEAGIP.GSFC.NASA.GOV> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: GEORGE@HEAGIP.GSFC.NASA.GOV (Ian M George, Code 668, NASA/GSFC, USA (Usque ad mortem bibendum)) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: PFSP Proposal for 2 new keywords: Note of a FITSBITS post Date: Thu, 17 Jun 1993 18:04:04 -0400 Yet another recommendation of the OFSP meeting on 1993 Jun 16 was that the OGIP change its use of the EXTNAME keyword, and that two new keywords be introduced. Again, since these new keywords may be of interest to the general FITS community, the OFSP felt the best forum for discussion of such a proposal is the FITSBITS exploder, and thus the proposal was posted there (today). Since some HEAFITS recipients may still not be members of the FITSBITS, a copy of the proposal is appended below. However it is **STRESSED** that all discussion should take place on FITSBITS. ----------------------- Start of included message --------------------------- ----------------------- (as exploded on FITSBITS) --------------------------- ------------------------------------------------------- | THE USE OF THE EXTNAME KEYWORD AND THE PROPOSED | | INTRODUCTION OF TWO NEW KEYWORDS | ------------------------------------------------------- Version: 1993 June 17 At a meeting on 1993 Jun 16 of the OGIP FITS Standards Panel (OFSP) within the Office of Guest Investigators (OGIP) at NASA/GSFC, there was a review of the use of the EXTNAME keyword within the OGIP. The OFSP found that it was common practice within the OGIP to use the value of the EXTNAME keyword to simultaneously describe both the generic *kind* of dataset being stored, and additional *details* of the dataset. Thus values of the EXTNAME keyword were being formed by the concatination of 2 or more sub-strings. This gives rise to long, and often user-unfriendly, EXTNAMEs essentially containing a variety of different pieces of information. More importantly these strings are apparently incompatible with a number of IRAF tasks. An example is: EXTNAME = 'GTI_STANDARD' meaning the dataset is a list of all 'standard' "Good Time Intervals". An (admittedly extreme) example is: EXTNAME = 'SGL_SPEC_STAT_+UNC' meaning the dataset contains the positive statistical uncertainties on a single spectrum. Whilst such use of EXTNAME keyword is legal FITS, the OFSP proposes & recommends the adoption/use of the two keywords listed below. Since this is an issue likely to be of interest to the general FITS community, the OFSP would welcome any comments (via FITSBITS) on this proposal. Furthermore due to the pressures imposed by currently flying missions (ASCA, CGRO & ROSAT) there is an extremely urgent need for a convention for these keywords within the OGIP (& High-Energy community in general). The OFSP therefore plans to meet again in a couple of weeks to make its final recommendations. Thus BITFITS subscribers are urged to response with any comments etc on this timescale. THE PROPOSAL ************ The OFSP recommends the use of the EXTNAME keyword be changed (at least within the OGIP), and that two new keywords, EXTCLASS & EXTTYPE be introduced: EXTNAME - Can be any string & is essentially not used by OGIP s/w (NOTE: IRAF can only cope with 6 character strings) EXTCLASS - Is a new string describing the sort of dataset stored (see below) EXTTYPE - Is a new string available to give more specific details on exactly what type of data is stored (see below) A few examples should make the distinctions between the keywords more obvious: 1) For various "Good Time Intervals" EXTNAME = 'ABCBEF' (or whatever you like) EXTCLASS = 'GTI' (some sort of GTI is stored) EXTTYPE = 'STANDARD' (the GTIs from standard processing are stored) or EXTTYPE = 'ALL' (all times when the instrument is on are stored [no filtering has been applied]) or EXTTYPE = 'UNKNOWN' (uncertain what is stored) 2) For various "Events" lists EXTNAME = 'GHIJKL' (or whatever you like) EXTCLASS = 'EVENTS' (some sort of EVENTS list is stored) EXTTYPE = 'GOOD' (accepted events [only] are stored) or EXTTYPE = 'BAD' (rejected events [only] are stored) or EXTTYPE = 'ALL' (all events [no filtering] are stored) or EXTTYPE = 'UNKNOWN' (uncertain what events are stored) The two new keywords follow a logical hierachy, solve all the current problems, and seem general enough to give us (the OGIP, and general FITS community) flexibility in the future. ----------------------------------- END ---------------------------------- Ian M George NASA/GSFC OFSP 1993 Jun 17 From heafits@legacy.gsfc.nasa.gov Thu Jun 17 21:14:32 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1791" "Thu" "17" "June" "1993" "21:11:58" "-0400" "Lee E. Brotzman" "leb@Hypatia.gsfc.nasa.gov " nil "31" "Re: OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04179; Thu, 17 Jun 93 21:14:29 EDT Received: by inet-gw-2.pa.dec.com; id AA04392; Thu, 17 Jun 93 18:13:48 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA22429; Thu, 17 Jun 1993 21:11:58 -0400 Message-Id: <9306180109.AA02585@Hypatia.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS 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: leb@hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB@GIBBS From heafits@legacy.gsfc.nasa.gov Fri Jun 18 06:57:34 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2849" "Fri" "18" "June" "1993" "06:53:32" "-0400" "Lucio Chiappetti" "lucio@ifctr.mi.cnr.it" nil "61" "Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04442; Fri, 18 Jun 93 06:57:33 EDT Received: by inet-gw-2.pa.dec.com; id AA19853; Fri, 18 Jun 93 03:56:51 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA25726; Fri, 18 Jun 1993 06:53:32 -0400 Message-Id: Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Lucio Chiappetti Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP Proposal on the use of EXTNAME,EXTCLASS & EXTTYPE keywords (v 93-Jun-17) Date: Fri, 18 Jun 1993 06:53:32 -0400 On Thu, 17 Jun 1993 GEORGE@HEAGIP.GSFC.NASA.GOV wrote: > ------------------------------------------------------- > | THE USE OF THE EXTNAME KEYWORD AND THE PROPOSED | > | INTRODUCTION OF TWO NEW KEYWORDS | > ------------------------------------------------------- > Version: 1993 June 17 > > The OFSP recommends the use of the EXTNAME keyword be changed (at least > within the OGIP), and that two new keywords, EXTCLASS & EXTTYPE be > introduced: > > EXTNAME - Can be any string & is essentially not used by OGIP s/w > EXTCLASS - Is a new string describing the sort of dataset stored (see below) > EXTTYPE - Is a new string available to give more specific details on > exactly what type of data is stored (see below) > I am really perplexed by this proposal, and I fail to see a clear distinction between what is used for inter-package data exchange (i.e. to make the file readable, or at least understandable to a "foreign" package) and what is used exclusively within a GIVEN package. My approach would be to use EXTNAME to classify in a broad sense the kind of file. In particular in the high energy astrophysics context the "kinds of files" I am using are : 'SPECTRUM' count/s (or photon/s) spectra 'RATE' time profile (anything vs time) 'PHOTON LIST' list of photons or events in addition to these I consider images and response matrices (but in my view they are images, not bintables, therefore do not use EXTNAME) If each one of those supports variations, these are either in the form (e.g. number and names of columns; and therefore are self-docu- mented by other standard keywords like TTYPEn TFORMn etc.), or are in the semantics (which is relevant within a particular package only, and can be described by whatever optional keyword). Being my primary interest in the possibility of EXCHANGING data (i.e. importing/exporting them from/to my own package to/from other packages) I would as far as possible avoid the use of "specialized" convention, which may force to have a dedicated conversion utility for each package, instead of a generic reader. As a conclusion, I do not see why you cannot use EXTNAME (instead of EXTCLASS) for the top-level classification (to be kept to a FEW classes, essentially the ones I listed above ... the exact names can be agreed if you are concerned with imbedded blanks, or more than 6 or 8 characters), and whatever YOU like for the bottom level classification. Still, I perceive that the top-level classification (EXTNAME) is of relevance within the X-ray (HEAFITS) community (but not necessarily within a larger - fitsbits - community), while the lower level classification is only "private" to your software. From heafits@legacy.gsfc.nasa.gov Fri Jun 18 07:13:52 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["2795" "Fri" "18" "June" "1993" "06:45:21" "-0400" "Lucio Chiappetti" "lucio@ifctr.mi.cnr.it" nil "58" "Re: OFSP Proposal for standard RA & dec keywords (v 93-Jun-17)" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04661; Fri, 18 Jun 93 07:13:50 EDT Received: by inet-gw-2.pa.dec.com; id AA20606; Fri, 18 Jun 93 04:13:08 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA25349; Fri, 18 Jun 1993 06:45:21 -0400 Message-Id: Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Lucio Chiappetti Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP Proposal for standard RA & dec keywords (v 93-Jun-17) Date: Fri, 18 Jun 1993 06:45:21 -0400 On Thu, 17 Jun 1993 GEORGE@ROSGIP.GSFC.NASA.GOV wrote: > ------------------------------------------------------- > | PROPOSED STANDARD KEYWORDS FOR THE SPECIFICATION | > | OF RA & DEC WITHIN FITS FILES | > ------------------------------------------------------- > Version: 1993 June 17 My general feeling is that it is a very reasonable proposal, in the framework of high energy missions at least. > > a) The Positions of astronomical objects/sources > b) The Pointing Direction of the Instrument. > c) The orientation of the Spacecraft I agree with the above list of items, which is more or less what I was using in the past (non-FITS) for the description of a pointing. Misalignments etc. should in principle be accounted for as "calibration" data. However I wonder if there are any relationships or interferences between things like a misalignment matrix and the WCS stuff. I do not have time to look into the matter, but I would appreciate knowing if anybody has done / will do a more detailed analysis of this. I still expect that each mission will need to do its own bits of trigonometry etc. to do things like computing collimator transmissions or vignetting or whatever. But it is much better to describe those mission-specific calculation using a common nomenclature, which is what is proposed here, therefore I support it. > 2) The RA & dec coordinates > In all cases listed below, the values of keywords are reals expressed > in decimal DEGREES. Obviously only those keyword pairs considered necessary > That's fine for me. However I remember there was some discussion in the past about preferring radians to degrees. How did that go ? > RA_OBJ > DEC_OBJ You mean the target here, don't you ? I.e. the object named in the OBJECT keyword. If yes OK for me. (if there are many interesting objects in the FOV one might think to RA_OBJ1, RA_OBJ2 etc. but I am personally not enthusiastic with number-indexed keywords unless REALLY necessary) ----------------------------------------------------------------------------- A member of G.ASS : Group for Astronomical Software Support ----------------------------------------------------------------------------- Lucio Chiappetti - IFCTR/CNR Milano | U N I C U I Q U E via Bassini 15 - I-20133 Milano - Italy | System Manager Internet: LUCIO@IFCTR.MI.CNR.IT | FORTUNAE SUAE Decnet: IFCTR::LUCIO (39610::LUCIO) | Bitnet: | ----------------------------------------------------------------------------- From heafits@legacy.gsfc.nasa.gov Fri Jun 18 07:14:02 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1120" "Fri" "18" "June" "1993" "06:39:38" "-0400" "Lucio Chiappetti" "lucio@ifctr.mi.cnr.it" nil "27" "Re: OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA04666; Fri, 18 Jun 93 07:14:01 EDT Received: by inet-gw-2.pa.dec.com; id AA20656; Fri, 18 Jun 93 04:13:19 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA25060; Fri, 18 Jun 1993 06:39:38 -0400 Message-Id: Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: Lucio Chiappetti Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS Date: Fri, 18 Jun 1993 06:39:38 -0400 On Thu, 17 Jun 1993 CORCORAN@ndadsb.gsfc.nasa.gov wrote: > > Source ID keywords: An OGIP FITS Standards panel (OFSP) proposal > 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. So here it is (to HEAFITS only and not to fitsbits, OK ?) > 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 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 heafits@legacy.gsfc.nasa.gov Sat Jun 19 15:28:08 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1044" "Sat" "19" "June" "1993" "15:25:33" "-0400" "Lee E. Brotzman" "leb@Hypatia.gsfc.nasa.gov " nil "27" "Full reference to Dictionary of Nomenclature" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA09162; Sat, 19 Jun 93 15:28:07 EDT Received: by inet-gw-2.pa.dec.com; id AA10567; Sat, 19 Jun 93 12:27:23 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA01709; Sat, 19 Jun 1993 15:25:33 -0400 Message-Id: <9306191918.AA11365@Hypatia.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Full reference to Dictionary of Nomenclature Date: Sat, 19 Jun 1993 15:25:33 -0400 Hello, Several people have sent me E-mail asking for the full reference to Fernandez, Lortet, and Spite. It seems of general enough interest to post here. Note that the first edition consumes an entire issue of the A&A Suppl., and hence is not all that easily Xeroxed (plus it has color-coded sheets for extra-added value). If you wish to use it very much at all, you're best bet is to order the back issue from A&A. The First Dictionary of Nomenclature of Celestial Objects, Fernandez, Lortet, and Spite, 1983, A&AS, 52, No. 4. First Supplement to the Dictionary of Nomenclature..., Lortet and Spite, 1986, A&AS, 64, No. 2. There may be another supplement or two, I haven't kept up since the first supplement. Let me just say once again that these dictionaries are extremely useful to astronomical data hounds. -- -- Lee E. Brotzman Internet: leb@hypatia.gsfc.nasa.gov -- Hughes STX DECNET: NDADSA::BROTZMAN -- NASA Goddard Space Flight Center BITNET: ZMLEB@GIBBS From heafits@legacy.gsfc.nasa.gov Mon Jun 21 16:48:33 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1149" "Mon" "21" "June" "1993" "16:45:58" "-0400" "William Pence" "pence@tetra.gsfc.nasa.gov " nil "30" "Re: OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02856; Mon, 21 Jun 93 16:48:32 EDT Received: by inet-gw-2.pa.dec.com; id AA04761; Mon, 21 Jun 93 13:47:49 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA23305; Mon, 21 Jun 1993 16:45:58 -0400 Message-Id: <9306212047.AA14198@tetra.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: pence@tetra.gsfc.nasa.gov (William Pence) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS Date: Mon, 21 Jun 1993 16:45:58 -0400 Jonathan McDowell wrote: >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. > ... >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. > ... > 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' 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 heafits@legacy.gsfc.nasa.gov Mon Jun 21 16:54:45 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["263" "Mon" "21" "June" "1993" "16:52:12" "-0400" "\"Jonathan McDowell\"" "jcm@urania.harvard.edu" nil "8" "Re: OFSP proposal - SOURCE ID KEYWORDS " "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02866; Mon, 21 Jun 93 16:54:43 EDT Received: by inet-gw-2.pa.dec.com; id AA05461; Mon, 21 Jun 93 13:54:01 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA24001; Mon, 21 Jun 1993 16:52:12 -0400 Message-Id: <9306212051.AA23498@urania.harvard.edu> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: "Jonathan McDowell" Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS 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 heafits@legacy.gsfc.nasa.gov Mon Jun 21 18:12:21 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["554" "Mon" "21" "June" "1993" "18:09:48" "-0400" "William Pence" "pence@tetra.gsfc.nasa.gov " nil "15" "Re: OFSP proposal - SOURCE ID KEYWORDS" "^From:" nil nil "6"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA02923; Mon, 21 Jun 93 18:12:20 EDT Received: by inet-gw-2.pa.dec.com; id AA09782; Mon, 21 Jun 93 15:11:38 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA25266; Mon, 21 Jun 1993 18:09:48 -0400 Message-Id: <9306212211.AA14273@tetra.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: heafits@legacy.gsfc.nasa.gov Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: pence@tetra.gsfc.nasa.gov (William Pence) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Re: OFSP proposal - SOURCE ID KEYWORDS 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. From heafits@legacy.gsfc.nasa.gov Thu Jul 1 15:27:08 1993 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["6174" "Thu" "1" "July" "1993" "15:24:29" "-0400" "William Pence" "pence@tetra.gsfc.nasa.gov " nil "125" "Minutes of the OGIP FITS standards panel meeting" "^From:" nil nil "7"]) Return-Path: Received: from inet-gw-2.pa.dec.com by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA27956; Thu, 1 Jul 93 15:27:05 EDT Received: by inet-gw-2.pa.dec.com; id AA09934; Thu, 1 Jul 93 12:26:19 -0700 Received: by legacy.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA26541; Thu, 1 Jul 1993 15:24:29 -0400 Message-Id: <9307011925.AA06017@tetra.gsfc.nasa.gov> Originator: heafits@legacy.gsfc.nasa.gov Errors-To: oneel@arupa.gsfc.nasa.gov Reply-To: pence@tetra.gsfc.nasa.gov (William Pence) Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas From: pence@tetra.gsfc.nasa.gov (William Pence) Sender: heafits@legacy.gsfc.nasa.gov To: dwells@fits.CV.NRAO.EDU Subject: Minutes of the OGIP FITS standards panel meeting Date: Thu, 1 Jul 1993 15:24:29 -0400 --------------------------------------------------------------- | MINUTES OF THE OGIP FITS STANDARD PANEL MEETING 1993 June 30 | --------------------------------------------------------------- The second meeting of the OGIP FITS Standards Panel (OFSP) was held on 1993 June 30. Panel members present: - B.Pence (chair), M.Corcoran (ROSAT), T.McGlynn (GRO), A.Rots (XTE), L.Angelini (HEASARC). Absent: I.George (HEASARC) (George gave his proxy vote to Angelini for this meeting). R.Fink resigned from the panel and as yet a replacement from Code 630 has not been appointed. Others present - None Summary of Discussions & Recommendations: ----------------------------------------- The main business of the meeting was to discuss and make a final vote on the 4 proposals that were made at the previous meeting: a) Use of underscores vs hyphens in keyword names b) EXTNAME, EXTCLASS & EXTTYPE keywords c) RA & Dec keywords d) Catalog source ID keywords More details are given below, but in the end the OFSP approved the first 3 proposals with minor modifications. It deferred a vote on the the last proposal and instead proposed a new recommendation which will be circulated for comments on the HEAFITS mail list server. Full Minutes ------------ 1) On the use of underscores and hypens in FITS keywords and column names: The panel agreed that it was useful to recommend that only one of these punctuation type characters be used in FITS keyword names and in FITS table column names (i.e., in the value field of the TTYPEn keywords) in order to eliminate needless debate over which character to use when creating new keyword names and to reduce confusion and errors on the part of software developers and users when entering keyword names. After some discussion the panel voted (5-1) in favor of using underscores and to discourage the use of hypens except in two circumstances: (1) when there is already a well established precedent for using a hyphen (e.g., in the 'DATE-OBS' keyword) or when (2) the hyphen is specifically used to represent a minus (negation) sign. The full text of this OFSP recommendation (R1) will be distributed separately on the FITSBITS and HEAFITS mail list servers 2) On the proposed new EXTCLASS and EXTTYPE keywords to provide a hierarchical classification scheme for the various types of FITS extensions used within the OGIP: The Panel reviewed the comments that had been received in response to circulating a draft of this proposal on the FITSBITS and HEAFITS mail list servers. Most of the comments dealt with the confusion between the usage of the existing EXTNAME keyword and the proposed new EXTCLASS keyword. The problem with using the EXTNAME keyword for any new precisely defined purpose is that different groups are already using the EXTNAME keyword in a variety of mutually incompatible ways, so it would be impossible to impose a new convention for this keyword without requiring that some gromps modify their existing software and FITS files which could be very costly. The reason for this variety of usage is that the FITS standard, which defines the EXTNAME keyword, provides almost no guidance in exactly how it should be used. Given this situation, the Panel felt that it was preferable to invent a new keyword (EXTCLASS) which will be used in a well defined way within the OGIP. The Panel then approved the EXTCLASS/EXTTYPE proposal by a 6-0 vote with some minor modifications to the text. The full text of this recommendation (R2) will be distributed separately on the FITSBITS and HEAFITS mail list servers. An action item on the Panel is to develop and maintain a list of permitted values for the EXTCLASS and EXTTYPE keywords within the OGIP. 3) On the proposed new RA and DEC keywords giving the position of the observed object, the telescope pointing, and the spacecraft axes: The Panel reviewed the comments on the FITSBIT mail list server about this proposal. Some of the comments questioned the need for these new keywords, suggesting instead that the standard World Coordinate System (WCS) FITS keywords already provide this information. But the Panel agreed that this was not the case, and that the proposed new RA and DEC keywords supply additional information and that they can also be used in cases where the WCS keywords would be inappropriate (as in some Binary table extensions). There was some discussion of whether the KEYWORD names should be shortened to 6 characters to enable a 2 digit sequence number to be added in cases where the dataset contains multiple objects or multiple telescope pointings. Most of the Panel did not favor this idea, and preferred to keep the more legible keyword names which are up to 7 characters long. The Panel accepted the suggestion (from Pat Wallace) to clarify the wording of the EQUINOX keyword, and further, to recommend that the EQUINOX always be either 1950.0 or 2000.0, with 2000.0 being strongly recommended for all new data sets. The Panel then approved this proposal by a 6-0 vote. The full text of this recommendation (R3) will be distributed separately on the FITSBITS and HEAFITS mail list servers. 4) On the proposed catalog name and ID keywords: A number of comments received on this proposal questioned the need for splitting the catalog name and catalog ID number into 2 separate keywords. The Panel agreed that there was no compelling reason to have 2 keyword instead of just one string keyword giving both the standard catalog appreviation (from the A&A Suppl articles by Fernandez et al.) and the catalog number. It was further decided that it would be better to give the full bibliographic reference to the catalog, if needed, as a series of COMMENT keywords, rather than inventing a new keyword (CATREF) for this purpose, since it is unlikely that software would need to read the value of this keyword. Due to the extensive changes that were made to this proposal, it was agreed that Corcoran would circulate the new proposal on the HEAFITS mail list server for further comments before making a final vote on it. The next meeting of the Panel will be held on July 21st.